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

With no annotations supplied, the description carries the full burden, and it does so well: it discloses the price ($0.01 USDC on Solana per endpoint), states that artefacts are processed in memory only and never stored, and explains how partial results are reported (mismatches are named, undeterminable axes become UNDETERMINED, and no composite score is computed). Those are exactly the behavioural facts an agent cannot get from the schema.

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?

Three sentences, front-loaded with the most decision-relevant detail (price and what the payment buys), then modes, then behavioural guarantees. The long axis enumeration in the middle sentence is dense but justified because it tells the agent what the report will contain, and there is no filler or repetition.

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-parameter tool with no output schema and no annotations, the definition covers cost, mode semantics, output philosophy, and data handling, which is enough for an agent to call it correctly. The remaining gaps are modest: the concrete shape of the returned report (signed field, format) is not described, and the relationship to dialect_precheck or dialect_criteria is left unaddressed.

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?

Parameters are documented in the schema at 100% coverage, so the description only needs to add meaning, and it adds little: it restates that probe mode takes a URL for a live 402 challenge and submitted mode takes a captured artefact set, which the schema descriptions already say. The list of graded axes (challenge carrier, client-header names, payload shape, amount field name, network-ID form, receipt headers) describes report content rather than parameter semantics, so it does not raise this dimension above the baseline.

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 uses a specific verb and resource: it produces a 'signed dialect conformance report' on HTTP 402 challenge behaviour, and it clearly splits this into probe mode (fetch a live 402 challenge for a URL) and submitted mode (grade a captured artefact set). The purpose is unambiguous and distinct from generic checks in the sibling list, but it never names dialect_criteria or dialect_precheck, so the agent is left to infer positioning from tool names alone.

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?

The description tells the agent which input each mode needs ('probe mode fetches the named endpoint's live 402 challenge; submitted mode grades your captured artefact set'), which implicitly guides mode choice. It does not say when an agent should call this versus the sibling preflight or criteria tools, and it gives no prerequisites or exclusion conditions, so usage is only implied rather than stated.

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