submit_fix_outcome
Report back whether a Denpex fix actually resolved the failure. Call this after you apply a fix from diagnose_crash and observe the result — it is the ONLY way the engine learns, and it directly improves the next diagnosis of this failure class for you and everyone else. Pass the diagnosisId prin...
This record as markdown: /tools/denpex-mcp/submit-fix-outcome.md
What submit_fix_outcome does on Denpex
AI agents use submit_fix_outcome to create or update resources in Denpex, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Denpex environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
note | string | — | What actually happened. On a `did_not_work`, this is the most valuable field in the call — say what the log showed after the fix. |
newFix | string | — | If you found the real fix, what was it? |
outcome | string | Yes | `worked` = the failure is resolved and the job is progressing. `did_not_work` = it recurred or the fix did not apply. |
diagnosisId | string | Yes | The `diagnosisId` from the diagnosis you acted on. |
Parameters from the server's own tool schema.
Why submit_fix_outcome is rated Medium
An AI agent can call submit_fix_outcome faster than any human can review: one bad instruction and it creates or modifies resources in Denpex by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
The rule that runs submit_fix_outcome safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Denpex, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For submit_fix_outcome, this is the rule to start with:
submit_fix_outcome stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Denpex, apply this rule, and every submit_fix_outcome call is checked against it from then on.
Questions about submit_fix_outcome
Report back whether a Denpex fix actually resolved the failure. Call this after you apply a fix from diagnose_crash and observe the result — it is the ONLY way the engine learns, and it directly improves the next diagnosis of this failure class for you and everyone else. Pass the diagnosisId printed at the bottom of the diagnosis. If the fix did not work, say what actually happened in note (and newFix if you found the real one) — a specific negative is worth more than a vague positive. It is categorised as a Write tool in the Denpex MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
submit_fix_outcome accepts 4 parameters: note, newFix, outcome, diagnosisId. Required: outcome, diagnosisId. The full parameter table on this page comes from the server's own tool schema.
Register the Denpex MCP server in PolicyLayer and add a rule for submit_fix_outcome: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Denpex. Nothing to install.
submit_fix_outcome is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the submit_fix_outcome rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for submit_fix_outcome. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
submit_fix_outcome is provided by the Denpex MCP server (denpex-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Denpex, and thousands of servers like it.
This server
Across the catalogue