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

Annotations already provide rich safety context: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds only 'deterministic' (which overlaps with idempotentHint) and 'signed,' which is undefined. There is no contradiction with annotations, but the added behavioral insight is minimal.

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 short, but brevity here is under-specification rather than useful compression. It repeats the tool name and adds a vague clause without front-loading any concrete, actionable information.

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?

With two required opaque parameters, no property definitions, and no explanation of the negotiation semantics, the description is insufficient for confident invocation. The output schema exists, but it does not compensate for missing input semantics and absent usage context.

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 requires 'demand' and 'offer' but provides no property definitions, and the description's phrase 'supplied input' adds no meaning to either parameter. An agent is left to guess what shape demand and offer should take, what they represent, and whether additional properties are meaningful.

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 moves slightly beyond a pure tautology by saying the tool produces a 'deterministic signed assessment over supplied input,' but it never states a concrete verb or resource. It does not clarify whether the tool negotiates rate limits, assesses a demand/offer pair, or returns a signed verdict, and it does not distinguish it from sibling negotiation or assessment tools.

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?

There is no guidance about when to use this tool versus alternatives such as capability_negotiation_preflight or agent_budget_guard. No conditions, exclusions, or examples are given; the only implied use case comes from the tool name itself, not the description.

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