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

Beyond the read-only and closed-world annotations, it discloses the price, currency and network, and explicitly states that the tool does not analyze, sign or charge. It also describes the preparation outputs and adds downstream result characteristics—witness points, a conservative bound and a completeness caveat—though the source of those analysis results could be stated more clearly.

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 description is compact and devotes its sentences to the goal, payment model, execution boundary and outputs without filler. Its structure could be clearer: the opening implies direct measurement, the second “Returns” has an ambiguous subject, and “check completeness” is terse and unexplained.

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 three-input request-preparation tool with no output schema, it covers most of what an agent needs: purpose, cost, non-execution behavior and returned request material. Remaining gaps are the threshold semantics, whether witness points and the bound come from the downstream HTTP service, and what specific completeness field or condition the agent should check.

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?

The schema already documents a and b as 2–4 millimeter coordinate pairs, while the description adds the useful context that they represent two curves. It does not explain thresholdMm’s role, such as whether it is a pass/fail clearance requirement, a reporting cutoff or a search limit, leaving one required parameter under-specified.

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?

Identifies the specific job—measuring clearance between two curves for engraving or printing—and then clarifies that this tool prepares the paid HTTP request rather than performing the measurement. This distinguishes it from general preflight and vector-health siblings, although the opening “Measure the gap” wording briefly overstates what the MCP tool itself does.

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?

“Before engraving or printing” provides a concrete use context, and the preparation-only disclosure tells the agent not to expect immediate analysis or payment execution. It does not explicitly contrast alternatives such as prepare_small_features or prepare_preflight, nor explain when curve clearance is the appropriate check.

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