Taasky

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds critical context they do not carry: the blast radius (closes the room for BOTH parties, not just the caller), the timing rule (out of turn is permitted), and an authorization requirement (human confirmation). It still doesn't say whether in-flight proposals are voided or whether the close is reversible, so not a full 5.

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?

Two terse sentences with zero padding. The destructive consequence is front-loaded before the softer rules (out-of-turn, confirmation), which is the right ordering for an agent deciding whether to call it.

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-parameter, no-output-schema mutation tool, the description covers effect, timing, and authorization. The only residual gap is post-call state (what happens to pending proposals, whether the room can be rejoined), which keeps it just below complete.

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?

One required parameter with 100% schema description coverage, and the schema already explains where room_token comes from ('negotiation_open or negotiation_join gave you'). The description adds no further parameter meaning, so the baseline 3 applies.

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?

States a specific verb (withdraw) and resource (the negotiation) and immediately names the observable consequence — the room closes for both parties. This is distinguishable from siblings like negotiation_respond or negotiation_propose without opening any schema.

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?

Specifies a non-obvious usage condition ('Allowed out of turn') and a prerequisite ('Needs your human's confirmation'), and points at a comparable sibling (negotiation_respond). It stops short of stating when NOT to withdraw versus other exit paths, so it is clear context rather than full when/when-not routing.

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

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

Annotations already disclose non-read-only, open-world, non-idempotent, non-destructive behavior, so the bar is lower. The description adds only the framing that joining declares "the shape of what you can offer," but says nothing about whether joining is one-shot, what happens to a second join, or how the invite code's lifetime works.

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?

A single front-loaded sentence with zero filler: the action, the precondition, and the payload intent in one clause. Nothing redundant is present.

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?

This is a complex, nested-schema, privacy-sensitive tool with no output schema, and the description covers only the entry point. It omits the limits-confidentiality model, the role of previous_room_token, and what state results from joining, all of which an agent needs to sequence its calls correctly.

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?

Coverage is 75% and the schema descriptions for limits, subject_schema and previous_room_token are already extremely detailed, so the schema does the heavy lifting. The description's "shape of what you can offer" only loosely gestures at subject_schema and adds no syntax or constraint detail; invite_code is undocumented in both places.

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?

States a specific verb and resource ("Join a negotiation") plus the precondition ("you were invited to"), which separates it from negotiation_open. It names no sibling explicitly, so an agent must infer that joining is distinct from opening or proposing.

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?

"Join a negotiation you were invited to" implies the trigger condition: you hold an invite. It never says where the invite comes from, whether joining must precede negotiation_propose/negotiation_respond, or what to do if the invitation has expired, so the when-to-use vs alternatives is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does add value by naming the fields returned (state, turn, nearest deadline), which matters since there is no output schema, but it says nothing about ordering, pagination, or the effect of the room_tokens scope.

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?

A single compact fragment with zero filler, front-loading the resource and the three payload fields. Nothing could be trimmed without losing 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?

Because there is no output schema, the brief return-field summary is helpful, but key facts are missing: the required room_tokens input bounds the query to at most 20 requested rooms, which sits awkwardly against the 'Your negotiation rooms' phrasing implying a full listing, and ordering/pagination are unstated.

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 both room_tokens and include_closed are already documented in the schema; baseline is 3. The description adds no syntax, limit, or behavior detail beyond what the schema states.

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?

Names the resource (negotiation rooms) and the three data points returned (state, whose turn it is, nearest deadline), so an agent knows this is an overview/listing tool. It never states a verb like 'list' and does not differentiate itself from siblings such as negotiation_read, so it falls short of a 5.

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 when-to-use guidance, no exclusions, and no mention of alternatives like negotiation_read or negotiation_join. The possessive 'Your negotiation rooms' only loosely implies a status-check use case.

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

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

Annotations already declare write/non-idempotent/non-destructive/open-world, and the description adds real context: the invite link is sent to the other party, the invitation carries the opening terms, and the counterparty can accept them on join. What it does not state is what a repeat call does to an existing room (the non-idempotent hint suggests a new room each time), which would have pushed it to 5.

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 primary action and result, then the flow. Efficient and readable, though the second and third sentences restate the same declare/accept idea and could be tightened.

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?

No output schema exists, yet the description names the principal return value (the invite link), which is the key thing an agent needs. Combined with 100% schema coverage for the nested parameters, it is nearly complete; minor gaps remain around the room token lifecycle.

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 parameters (limits, subject, subject_schema, previous_room_token) are already fully documented in the schema. The description only restates that subject should be passed with the opening terms, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Open a negotiation room') and names the concrete outcome ('get an invite link'). The added flow ('You declare the shape of what you are proposing; they declare theirs when they join') implicitly separates it from negotiation_join/propose, but no sibling is named explicitly, so it stops short of a 5.

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?

Usage is implied rather than stated: 'Pass subject to open with your terms' tells the agent how to populate the call, and the join-on-acceptance note hints at sequencing, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. propose vs open). Adequate but leaves the choice among siblings to inference.

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

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds what the read returns (history plus live terms), but says nothing about volume, pagination, or what happens with an invalid/stale room_token.

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?

A single short sentence, front-loaded with scope ('One room in full') and then the payload contents. No filler, no repetition of the title.

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, the description does the useful work of telling the agent what comes back, which is the main thing it needs. However, for a tool that returns an entire negotiation history it omits response-size/pagination expectations and any usage context relative to the mutation siblings, leaving clear gaps.

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 single room_token parameter is already fully documented in the schema (100% coverage), including where it comes from (negotiation_open/negotiation_join). The description adds no format, validation, or error semantics beyond that, so the baseline 3 applies.

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 resource and its full contents — 'current state, every round, the terms on the table' — which is specific enough to distinguish it from a list-style sibling. The verb is implicit rather than stated, and nothing explicitly contrasts it with negotiation_list, so it stops short of a 5.

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 statement of when to call this versus negotiation_list or the mutation tools (propose/respond/cancel). An agent must infer that this is the inspection step before acting, but the description never says so.

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

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

Adds substantial behavior beyond the annotations: the invocation is not sent directly by the agent, but queued for a human who sees the terms field by field, and only their answer releases the move. It also discloses the completion condition (both parties approving the same hash), which is non-obvious state semantics.

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?

Four sentences, front-loaded with the core action, and each sentence carries distinct information (action, human-confirmation flow, hash requirement, completion condition). Slightly dense but no wasted filler.

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 multi-party approval protocol with no output schema, the description covers the confirmation flow, the hash prerequisite, and the terminal agreed state. It does not describe the response shape or failure modes, but the essential invocation context is present.

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?

With 67% schema coverage, the description compensates by clarifying that subject_hash is required specifically for approve and must match the hash read from negotiation_read, adding meaning the schema's terse 'Required for approve' only partly conveys. room_token and decision remain covered by schema.

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?

States a specific verb+resource pair (accept or decline the terms) and distinguishes itself from sibling tools like negotiation_propose and negotiation_cancel by framing the action as a response to terms already on the table. An agent can identify the operation without opening the schema.

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?

Explicitly names the prerequisite for approve: the subject_hash must be quoted and comes from negotiation_read. It explains the confirmation context (human must confirm). It stops short of stating when to choose this over negotiation_cancel, so it is clear but not exhaustive.

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