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

Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior, so the description does not need to restate those. It adds behavioral scope beyond annotations: the tool covers technical/regulatory possibility only, not commercial viability, and omitting dimension returns all four dimensions. This provides meaningful context without contradicting the annotations.

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 front-loaded with labeled sections: Purpose, Guidelines, Limits, and Examples. Every sentence earns its place, with no filler or repetition of schema content. The structure makes it easy to scan and act on quickly.

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 single optional parameter with strong annotations and an output schema, the description is complete. It covers what the tool does, how to invoke it, what scenarios it applies to, what it excludes, and where to route non-matching needs like pricing.

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 only marks dimension as optional and gives high-level Chinese labels. The description adds exact accepted values in English, the default behavior when omitted, and natural-language query examples like 'rCB application limit in seals'. This materially enriches the bare schema for an AI agent.

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 explicitly states the tool returns the four-dimension substitution boundary of rCB vs native carbon black and enumerates the dimensions: application limits, regulatory access, certification requirements, material spec constraints. It is specific about the resource and scope, and the Limits section differentiates it from calculate_saving on commercial viability, so it is clearly not a tautology.

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?

It gives an explicit usage condition: 'call before any substitution feasibility claim' with a concrete example question. It also states an exclusion — not commercial viability — and routes pricing to calculate_saving, giving an agent clear guidance on when not to use this tool.

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