fastmean_preview

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and no open world; the description adds real substance on top: native L/midpoint bends are reconstructed exactly, unsupported symbols/detours are rejected, no application window opens, and source data is unmodified. It stops short of saying where the rendered files land or what happens on rejection (error vs partial output).

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?

Front-loaded with the purpose in the first clause, followed by the differentiators and the include_text caveat in descending order of importance. Four short paragraphs with little waste, though the 'Proven native L/midpoint bends' line leans on internal jargon.

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, yet the description never says what the call returns or where the PNG/SVG are written (returned inline? file paths? temp dir?). Combined with the undocumented `path` parameter, an agent knows the intent but not the mechanics of a successful call.

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?

include_text is handled well: the description explains its exact scope (TEXT notes on this image and its bounds only) and that source annotations and parameter bindings are untouched, which the schema does not convey. The required `path` parameter is never explained at all, so at 0% schema coverage the description only half compensates.

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 first sentence gives a concrete verb (render) plus the resource (a wire-connected SCM) and the output artifacts (PNG and SVG) for visual review. It is clearly not fastmean_plot or fastmean_open, and the second sentence reinforces that it is an offline rendering rather than a live screenshot. The unexplained acronym 'SCM' keeps it from a 5.

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 rather than stated: 'for visual review', 'No application window is opened', and 'not a FASTMEAN screenshot' together suggest you pick this when you want an image without opening the app. But no sibling (fastmean_plot, fastmean_open, fastmean_inspect) is named as an alternative, and there is no explicit when-not condition.

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