Show a tool's card with input types, safety, and verification details, or a recipe's problem, steps, key facts, and recorded outcome.
Show a tool's card (use the exact name discover gave): inputs with types, safety, how it is verified. For a recipe: the problem, the steps, the key facts and what happened when it was done.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes |
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, openWorldHint=false, destructiveHint=false, so safety needs no restating. The description instead adds value the annotations don't: it discloses the shape of the returned payload, including that recipe entries report 'what happened when it was done' — genuinely useful context beyond the structured fields.
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 sentences, no filler, with the core action front-loaded. The recipe clause is telegraphic and slightly compressed, but it carries distinct information rather than padding.
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?
There is no output schema, and the description correctly takes on the burden by describing what comes back for both tool cards and recipes. For a one-parameter read-only lookup this is nearly sufficient; only error/not-found behavior is left unstated.
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?
With schema coverage at 0%, the description must compensate for the single 'tool' parameter, and it does by specifying the value must be the exact name returned by discover — a real semantic constraint (case/format sensitivity) not present in the schema. It stops short of describing failure behavior for unknown names.
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?
States a specific verb+resource ('Show a tool's card') and enumerates the card's contents (inputs with types, safety, verification), so it is clearly distinguishable from discover (which names tools) and run (which executes them). 'Card' is mild jargon but is immediately unpacked by the content list.
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 parenthetical 'use the exact name discover gave' establishes the workflow context: this is the step after discover and before run. It gives clear when-to-use context but states no exclusions (e.g. what happens if the name is wrong, or when describe is unnecessary).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.