Draft a valid IMD order

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

No annotations are provided, so the description carries the full disclosure burden. It helpfully states the return contract (body, plan, cost, similar existing work, checkToken) and that the operation is free, which is real behavioral context. It omits prerequisites (e.g. wallet setup), whether anything is persisted, and what happens when the embedded check fails.

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 dense sentence front-loads the core action ('builds a correct body...') before the return list and the 'Free' qualifier. It is efficient with no filler, though the packing of six job types plus five return values makes it slightly run-on.

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 five-parameter tool with no output schema and no annotations, the description does the important work of enumerating the return payload and pointing to the follow-up order tool. Gaps remain around preconditions and failure behavior, but the essential calling information is present.

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 60%; the required kind parameter has an enum but no schema description, and the description compensates by spelling out the six job kinds ('website, tool, report, audit, image or contracts'). It adds meaning over the raw enum, though it says nothing about siteLabel or minCitations, which the schema partially covers.

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 names a specific verb and resource: it 'builds a correct body' for six enumerated job kinds and runs a check on it. It also distinguishes the tool from imd_order by noting the returned checkToken is 'for imd_order'. It stops short of explicitly naming the siblings it overlaps with (imd_check, imd_find_existing), which its 'runs IMD's free check' and 'similar existing work' phrases shadow.

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?

Usage is implied through the workflow: draft here, then use the checkToken with imd_order, and 'free' signals it is the low-commitment precursor step. There is no explicit when-to-use/when-not statement, and the overlapping imd_check and imd_find_existing siblings are never named as alternatives, leaving the agent to infer the routing.

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