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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds important behavioral context beyond those annotations: it is a forced dry run, it returns rules-evaluation JSON text or validation errors, and it never submits or writes. This exceeds the minimal burden and gives a clear safety profile.

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 two sentences, front-loads the core action and return type, and then gives the critical prerequisite ('Inspect the offer first') and negative side-effect guarantees. Every sentence earns its place and there is no repetition of schema content.

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 validation tool with 7 parameters, 100% schema coverage, and no output schema, the description is complete enough: it explains the dry-run mode, the expected inputs, and the return type. It does not describe the exact shape of the rules-evaluation JSON, but since there is no output schema and the tool is a validator, a little more about the evaluation result structure could help. Still, the description covers the critical context needed to call it safely.

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 100%, so the schema already documents every parameter. The description itself adds some value by telling the agent to inspect offer rules and omit unknown terms rather than inventing them, which is meaningful usage guidance for the requestedTerms object. However, most parameter meaning lives in the schema, so baseline 3 is appropriate.

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 states a specific verb ('Evaluate'), the resource ('proposed terms against an exact offer and the seller's published rules'), and mode ('forced dry run'). It clearly distinguishes itself from a live submission and names what it returns ('rules-evaluation JSON text or validation errors'). This is distinct from siblings like nexez_validate_checkout.

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 explicitly says to inspect the offer first and supply its required terms. It also explicitly lists what it never does ('Never submits a proposal, contacts a seller, or writes a negotiation'), which tells the agent when NOT to expect side effects and implies it is for pre-submission validation. This is strong when-to-use guidance.

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