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

Annotations declare a non-read-only, non-idempotent, open-world mutation; the description adds real behavior beyond them, including that need_more_detail passes the turn back with no new terms, that terms only bind if the other side approves, and that unknown fields cause the move to be rejected. That validation and turn-passing detail is not derivable from 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?

Dense and front-loaded: the core action leads, then each verdict is defined in one clause, then the terms/limits rule and the validation constraint. No filler, though the run-on style across several colon-delimited fragments is slightly harder to scan than it could be.

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 no output schema, four parameters, and a nested subject object, the description covers the modes, the subject constraint, and the rejection behavior; deadline lifecycle is handled by the schema field description. An agent has enough to call it correctly, with only minor gaps like what an approved/rejected response looks like.

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 coverage is already 75%, but the description adds meaning the schema lacks: it defines the verdict enum values operationally, explains that subject must match subject_schema exactly, and draws the subtle terms-vs-limits distinction (exact slot, not the free window). That is genuine value beyond field-level descriptions.

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 names the specific action (make a move in the negotiation) and enumerates the three verdict modes, which makes the tool's role recognizable against siblings like negotiation_respond or negotiation_cancel. The opening sentence 'keeps the negotiation going' is a little abstract, but the verdict breakdown grounds it in concrete behavior.

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 clear when-to-use rules for each mode: offer only when no terms are on the table, counter for different terms, need_more_detail when you cannot decide yet. It does not explicitly contrast with the sibling negotiation_respond, but the mode-level guidance is strong.

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