vedha_get_auditTrace any result back to the canvases and route that produced it. Use a result ID to get an audit explanation of how that result was generated in the session.
Explain which canvases and route produced a result returned earlier in this session.
| Name | Required | Description | Default |
|---|---|---|---|
| result_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds the session-scoping constraint ('result returned earlier in this session'), which is useful behavioral context, but it does not disclose additional traits beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains all necessary information with no filler. Every word contributes to explaining the tool's scope and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with an output schema present, the description is nearly complete. It explains the purpose, the session constraint, and implies the input. It does not mention failure modes or how to obtain result_id, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly indicates that result_id refers to a result from earlier in the session, but it never explicitly says 'provide the result_id of that result'. The parameter's meaning is partly inferable but not fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Explain') and a specific resource ('which canvases and route produced a result'). It clearly distinguishes this audit tool from siblings like vedha_get_canvas or vedha_get_diagnosis by focusing on result provenance within the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a result was returned earlier in this session and the agent needs to know its origin. It does not explicitly contrast with sibling alternatives, but the session-scoped result auditing is a distinct and well-specified use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.