Taasky

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

Annotations declare destructiveHint=true, but the description goes well beyond that: it spells out exactly what is destroyed ('terms on the table lapse'), that the effect is irreversible ('cannot be reopened'), that it is bilateral (closes for both parties), and the side effect on a pending invitation. The human-confirmation requirement is behavioral context annotations cannot express.

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 tight clauses, each carrying distinct information: effect, eligibility, confirmation requirement, and alternative. The irreversible consequence is front-loaded where an agent will read it first.

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, but the description fully covers what happens on success and who is affected, which is what an agent needs. The only gap is the undocumented 'room' parameter, a small but real hole in an otherwise complete definition.

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 0% and the single required parameter 'room' is never explained — no identifier format, no source (from negotiation_list/negotiation_open), no example. The word 'room' appears only in prose about the room closing, which does not tell an agent how to populate the field.

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?

Opens with a specific verb+resource ('Withdraw from the negotiation') and immediately states the consequence ('the room closes for both parties and cannot be reopened'). It also explicitly distinguishes itself from the nearest alternative by naming negotiation_propose for the stay-in-the-room case.

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?

Gives explicit eligibility windows ('allowed out of turn, and before the other side joins'), a prerequisite ('needs your human's confirmation... except in a common_ground room'), and a named alternative ('To turn down terms but stay, counter with negotiation_propose'). When-to-use, when-not-to-use, and the substitute are all present.

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 readOnly=false, idempotent=false and destructive=false; the description earns credit by explaining the non-idempotency concretely — an invitation can be answered only once, and a used one is refused with a reason. It also discloses that limits are kept private from the other side and cannot be changed later, and that omitting subject_schema inherits the peer's (mandatory for common_ground rooms). Missing only side effects like what the other party observes on a failed join.

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?

Front-loaded with purpose and the sibling alternative before any parameter talk, and the return-value note comes last. It is a single dense semicolon-chained paragraph, though, and the subject_schema/limits rules would read faster as separate sentences.

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 mutation with openWorld=true and no output schema, the description covers the cross-parameter constraint, the one-shot invitation semantics, the failure mode, and the return payload (room plus terms_on_table, with whose turn it is). Nothing an agent needs in order to call it correctly is absent.

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 100%, so the schema already documents invite_code, subject_schema and limits in depth; baseline 3 applies. The description does add one genuinely extra rule not in the schema — that limits require you to supply your own subject_schema — but the rest restates schema content such as the privacy of limits and the option to omit subject_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?

"Join a room you were invited to" gives a specific verb and resource, and the very next clause names negotiation_open as the tool for starting your own room. An agent can distinguish this from every sibling without reading 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?

States when to use it (you hold an invitation), names the alternative (negotiation_open) with the condition that selects it, and closes the loop by naming negotiation_respond and negotiation_propose as the follow-up actions once terms_on_table is returned. Exclusions are also given: used, withdrawn, or expired invitations are refused.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds the meaningful default scoping rule — open rooms only unless include_closed — plus the returned fields, which no annotation conveys. It stops short of describing ordering or volume, but for a read-only list this is well beyond the annotation baseline.

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 sentences, no filler. Scope and returned fields come first, the default filter second, and the sibling routing last — a correct front-loaded ordering.

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 enumerates the key return fields (state, round, turn, deadline) so the agent knows what it gets. Combined with the filter default and the sibling pointer, nothing needed to call this correctly is missing.

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 100% schema coverage the baseline is 3, but the description adds value the schema omits: the schema only says 'Include finished rooms' while the description establishes the default of open-rooms-only. That default is exactly what an agent needs to reason about omitting the parameter.

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 ('List all your negotiation rooms') and enumerates the fields returned (state, round, whose turn it is, deadline), which distinguishes it from the other negotiation_* siblings. An agent can identify this as the collection-level read 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 states when to use it ('to see where things stand') and names the alternative for the other case ('for one room's terms and next move, use negotiation_read'). The routing condition between list and read is fully specified.

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 openWorldHint=true, non-idempotent, non-destructive, so the bar is lower. The description adds substantial context beyond them: each call opens a separate room, the invite expires after 72 hours, and limits are private to the caller's side and immutable. It stops short of describing what a failed or duplicate open does, but the disclosed behavior is well above baseline.

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?

Front-loaded with purpose, return value, and routing before the mode-specific detail; nearly every sentence carries a distinct fact. It is dense and long for a description, with the slots/options/expiry facts packed closely, but no sentence is pure 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 six-parameter, zero-required, open-world creation tool with nested objects and no output schema, the description covers return shape (invite_url), lifecycle (72-hour expiry), privacy model (limits never shown to the peer), and the non-binding template caveat. An agent has enough to choose a mode and call 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?

Schema coverage is 100%, so the baseline is 3, but the description earns above it by explaining cross-parameter relationships the schema states only piecemeal: leave out subject when passing slots, options is 'the same for any schema' with the first option as the opening offer, and subject_schema is the shape that renders the confirmation card. This is relational meaning, not restatement.

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 ('Start a new negotiation'), names the concrete side effect ('creates a room'), and the return value ('returns invite_url'). It also explicitly distinguishes itself from the sibling negotiation_join, so an agent can route between the two without opening a 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?

Gives an explicit when-to-use ('when your human wants to agree something with someone') and an explicit when-not with the alternative named ('if you were sent an invite link instead, use negotiation_join'). It further routes between the three opening modes (subject, slots, options/template) with conditions for each.

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?

Beyond the annotations (non-readonly, non-idempotent, open-world), the description discloses that unknown fields reject the move, that final commits the human to stand by the terms now, that need_more_detail passes the turn without new terms, and that deadline expiry ends the room. These are real behavioral consequences not derivable from the structured fields.

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?

Front-loaded with purpose and the escape hatch to negotiation_respond, then a compact mode list, then term constraints. The telegraphic fragments ('counter: different terms') are efficient, though the density of rules in one paragraph makes it slightly harder to scan.

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 a nested subject object, an enum verdict, no output schema, and 60% parameter coverage, the description covers the important gaps: turn discipline, mode semantics, term shape, and rejection behavior. Only the room parameter and post-call outcome are left implicit, which is acceptable given no output schema is needed.

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 60% and the description compensates well: it defines each verdict mode's semantics and explains the terms object, including the specific meeting-slot-vs-availability-window distinction and the subject_schema conformance requirement. room is left unexplained in the description, which keeps it from a full 5.

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 opening clause ('make a move that keeps the negotiation going') is soft, but the enumeration of the three verdicts (offer, counter, need_more_detail) makes the actual operation concrete, and negotiation_respond is named as the contrasting sibling. An agent can distinguish this from respond 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?

It states the precondition ('Only on your turn'), routes acceptance/termination to negotiation_respond, and gives per-mode conditions: offer only when no terms are on the table, counter for different terms, need_more_detail when you cannot decide. Explicit when-to-use and when-to-use-something-else.

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?

Goes well past the readOnlyHint annotation: it states the call changes nothing, describes the blocking/polling semantics with wait: true (returns on room change, or 40 seconds with changed: false, returns immediately on your turn or when the room is over), and explains that for_your_human is a human-facing rendering. These are behaviors an agent cannot infer from the annotations or 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?

Front-loads what is returned before the usage advice, and every sentence carries information (output fields, call timing, read-only guarantee, wait semantics). It reads as one dense run-on clause chain, which costs a bit of scannability but wastes no words.

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 usefully substitutes by enumerating the returned fields including subject_hash and for_your_human. Safety is covered by annotations and timezone handling is covered by the schema. The one real gap is how to obtain the required room id, which neither schema nor description explains.

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 67%, and wait/timezone are already documented in the schema in comparable detail, so the description's wait discussion is largely duplicative. The required 'room' parameter is undocumented in both places – the description only says 'one room', never hinting at the format or where an agent obtains a room id. This is baseline-level compensation for the coverage gap.

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?

Specific verb (read) plus precise scope ('one room in full') and an enumeration of exactly what comes back: state, turn, rounds, terms with subject_hash, next, and for_your_human. An agent can immediately tell this apart from the other negotiation_* siblings such as list, open, propose, or respond.

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?

Gives concrete triggers: 'Call it before every move and when your human asks how a negotiation is going,' plus the wait-loop pattern for the other side's turn. It doesn't explicitly name negotiation_list as the alternative for a multi-room overview, but 'one room in full' implies the distinction well enough.

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?

Goes well beyond the annotations by disclosing the human-confirmation gate ('only their answer releases the move'), the irreversible consequence of reject, the quorum rule (both parties approve the same hash), and the common_ground exception where it 'goes out at once.' This is strong added context for a destructive, non-idempotent tool; only the absence of any note on failure modes (bad/stale hash, wrong room state) keeps it off a 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?

Front-loaded with the action, then the confirmation mechanics, then the sibling alternative and the edge case. Dense but nearly every clause carries operational information; the phrasing is a bit packed into one paragraph, which slightly hurts scanability.

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 3-parameter destructive tool with no output schema, the description covers the decision semantics, the confirmation flow, the quorum condition, and the irreversibility of reject. What it lacks is what the caller gets back on success/failure and how stale or mismatched hashes are handled.

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 only 33% schema description coverage, the description carries real weight: it explains that approve must quote a subject_hash obtained from negotiation_read, and that reject needs no hash. The 'room' parameter's expected value/format is left implicit, which is the one remaining gap.

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 pair (accept/decline) and the exact resource: the terms on the table. It is immediately distinguishable from siblings such as negotiation_propose (keep negotiating) and negotiation_cancel, so an agent can route 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?

Explicit when-to-use and when-not-to-use: 'reject closes the room for good; to keep negotiating, counter with negotiation_propose instead.' It also names the prerequisite (subject_hash from negotiation_read) and the alternative flow for common_ground rooms.

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