drying_advisor

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

With no annotations, the description carries the full behavioral burden and largely fails it. It never says whether the tool reads live AMS/printer state or works offline, whether it mutates anything, what the verdict output looks like, or what happens when slot/ams_id are omitted (all params are optional). The tier-gating sentence is the sole piece of real behavioral context, and the rest of the copy describes features unrelated to drying.

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?

The useful content is one line; the remaining three lines are upsell boilerplate naming unrelated features (mid-print edits, textures, decorations) plus a pricing URL. That material does not help an agent invoke the tool and actively dilutes the single sentence that does. Front-loading the question is the one structural merit.

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 and no annotations, so the description must cover return semantics, parameter behavior, and preconditions; it covers almost none of them. For a six-parameter tool with a default mode and no required arguments, an agent cannot tell what to pass or what it will get back.

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 67%, and the description contributes nothing about any of the six parameters — mode (defaulting to 'verdict'), slot, ams_id, material, show_math, or printer_name are all left to the schema titles alone. show_math in particular is opaque and unaddressed. This is below the baseline 3 that high coverage would justify, since a third of the parameters are undocumented anywhere.

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 opening line does convey the domain — assessing whether a spool is dry enough to print and how to dry it — which is more than a restatement of the name. But it is phrased as an end-user question rather than a specific operation (read state? compute a verdict? emit instructions?), and it never distinguishes itself from the sibling ams_filament_drying, which plausibly overlaps. Purpose is inferable but imprecise.

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?

There is no when-to-use guidance, no conditions that select this tool over ams_filament_drying or the material/filament status tools, and no statement of prerequisites beyond the tier gate. The 'Requires Kiln Pro' line is the only operational constraint disclosed, and it is presented as marketing rather than as a precondition the agent can act on.

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