Free check of any IMD body

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does decently: it discloses the return artifacts (blockers, suggestions, plan, cost, similar work), that it is free, and that it "holds nothing" (no persisted state). It omits auth requirements and rate limits, which would round out a stateless free-check tool, but the core behavioral profile is stated.

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 tight sentences with the core action front-loaded, then the high-value downstream detail (checkToken for imd_order), then a compact "Free; holds nothing." Every clause earns its place.

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?

No output schema or annotations exist, so the description must do more work. It covers the return content and token well, but with seven undocumented action enum values and an input body deferred to an external URL, an agent still lacks enough to confidently pick the right action and shape the body.

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 coverage is 50%. The description clarifies that input is "a body you wrote yourself" (the action's payload), which adds some meaning beyond the external-doc pointer. However it says nothing about the action enum's seven values, so the caller must infer which action to select from the schema alone.

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 and resource: it runs IMD's free check on a body the caller supplies, and lists what it produces (blockers, suggestions, plan, cost, similar existing work). It also ties itself to a sibling by noting it returns the checkToken imd_order requires, which helps disambiguate. It does not explicitly name imd_draft as the upstream step, but the purpose is unmistakable.

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?

"A body you wrote yourself" implies the prerequisite (draft first) and "Returns the checkToken imd_order requires" signals the downstream consumer, giving clear context for when this tool fits between drafting and ordering. There is no explicit when-not guidance, but the positioning in the workflow is inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.