Render a human-readable Markdown report for a run, defaulting to the active run. If no run is active, return an index of all submitted surveys.
Render the human-readable Markdown report for a run (defaults to the active run). With no run and no active run, returns the index of all submitted surveys.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses defaulting behavior, the no-run fallback, and implies a read-only report operation. It does not cover error cases, but none are implied for this simple getter.
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?
Two short sentences deliver the core behavior and fallback without repeating schema or annotation information. No filler.
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, no-output-schema tool, the description covers the main behavior, the optionality of the run, the active-run selection, and the no-active-run fallback, including the Markdown output format.
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?
The only parameter, run_id, has no schema description. The text adds meaning by explaining that omitting it selects the active runcard and that with no active run an index is returned.
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 opens with a specific verb ('Render') and resource ('human-readable report for a run'), then explains the fallback to the survey index. This makes the tool's purpose unambiguous and distinguishable from sibling report/survey tools.
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?
It clearly explains when the default active run is used and what happens when no active run exists. It does not name alternative sibling tools, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.