Overlap

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

Annotations already establish the read-only, idempotent, closed-world profile, so the bar is lower, and the description adds genuinely new behavioral context: 'A match can appear days later' tells the agent results are asynchronous and may require re-checking. It also discloses the return shape, but says nothing about auth requirements or result freshness beyond the timing hint.

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 short sentences, roughly 45 words, with the return contents front-loaded in sentence two. The opening fragment 'Where the user stands' is the only slightly wasted phrase, though it functions as framing rather than substance.

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 carries the burden of describing return values, and it does so concretely (match requests, pool size, matches). For a zero-parameter read tool with full annotation coverage, that is enough to call it competently; only the overlap with preview_pool is left unresolved.

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 tool takes zero parameters, which is the baseline case for this dimension — there are no argument semantics to explain. Schema coverage is reported at 100% for an empty object, so nothing is missing.

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 resource and enumerates what the tool returns: every current match request, the number of people in the pool, and any match. That distinguishes it from the singular get_match_details, though the differentiation is implied rather than stated. The opening fragment 'Where the user stands' is vague but is immediately resolved by the following sentence.

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 a usage trigger — 'Use it to answer what the user submitted, and who they matched with' — but names no alternatives and sets no exclusions. Notably, it returns the pool count, which overlaps with the sibling preview_pool, and the description never clarifies which to prefer when the user asks about pool size.

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 only say readOnlyHint=false and destructiveHint=false, so they don't reveal much. The description adds meaningful behavior: only the confirmed request changes, it becomes active until withdrawn, and confirmation requires the exact stored text. This goes beyond the structured annotations and helps an agent predict side effects.

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 compact and front-loaded: effect, non-effect, lifecycle, and precondition each get one short sentence. The instruction 'Always pass its request_id' is slightly redundant given the required schema, but it does not bloat the description significantly.

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 tool with no output schema and no nested objects, the description covers everything an agent needs: what the tool does, what it does not do, how long the effect lasts, and the exact condition under which it should be called. Nothing important 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?

There is only one parameter and the schema description already explains that request_id comes from create_match_request or check_matches and should be the exact approved request. The description mostly repeats 'Always pass its request_id,' adding little beyond the schema. The schema coverage is 100%, so a baseline of 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 clearly states what the tool does: 'Confirm one draft match request and add it to the matching pool.' This distinguishes it from siblings like create_match_request and withdraw_match_request, and also clarifies scope by noting that other requests of the user do not change.

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 gives an explicit precondition: 'Call this ONLY after the user approves the exact stored text.' It also clarifies lifecycle behavior ('It stays active until the user withdraws it') and scope ('The other requests of the user do not change'). It doesn't name specific sibling alternatives, but the trigger condition is clear enough to route an agent correctly.

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?

The description goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing that the call creates an independent DRAFT, that it replaces nothing in the pool, that the draft persists until approved/revised/discarded, and that it must be shown back to the user verbatim. This is meaningful safety-relevant behavior that the annotations alone could not convey.

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 long, but nearly every clause earns its place: writing constraints, an example, privacy rules, and the approval/revision protocol. It loses one point because a couple of rules are duplicated between description and schema (character limit '200–1500 characters'), and the example, while helpful, extends the length noticeably.

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 tool with no output schema, the description fully specifies what the agent must do before calling it (draft from conversation), what it must do after (show verbatim and ask approval), and how to handle each user response (approve→confirm, change→recreate, decline→withdraw). The expected return behavior is fully covered, leaving nothing for the agent to guess.

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?

Although schema coverage is 100%, the description adds substantial meaning: it specifies the sentence count, person, character bounds, third-party wording ('words of the user, not formal or clinical'), the three content areas (situation, where the user is in it, wanted help), and the anti-hallucination/PII rules. It also clarifies the replaces_draft_id semantics within the revision workflow, which the schema states only tersely.

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 opens with a precise verb+resource: 'Submit what the user is going through, to find someone living through something similar.' It clearly defines the deliverable (a match request) and its social function, and its content rules (third person, 2–5 sentences, 200–1500 characters) make it unmistakable against siblings like confirm_match_request or withdraw_match_request.

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/when-not guidance is present: call confirm_match_request only after the user approves the exact version, call create_match_request again for revisions (with replaces_draft_id), and call withdraw_match_request if the user declines. No inference is required to route between the two siblings that act on the draft.

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 idempotentHint=true, and the description's 'It only reads' is consistent with that. The description adds value by detailing what the response contains, which the schema does not cover. The 'Never promise an address' caveat is an extra behavioral instruction. No contradiction with annotations, and the description supplements them.

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, each serving a distinct purpose: what it returns, read-only confirmation, sibling for actions, and a safety caveat. The core purpose is front-loaded in the first sentence, and there is no wasted wording. This is a model of concise, well-structured description.

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?

Despite having no output schema, the description enumerates the return content. With one required parameter, strong annotations, and explicit routing to a sibling for mutations, an agent has everything needed to call the tool correctly. The safety note adds an important operational constraint.

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 for match_id is 100% with a clear description ('The match_id from check_matches'). The tool description adds no new parameter-specific meaning beyond what the schema already provides. The phrase 'one match' implicitly clarifies match_id identifies a single match, but this is marginal, 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 opens with a specific verb and resource: 'Get the full details of one match', then enumerates the exact content returned (what the other person wrote, why they matched, opener, status). It distinguishes itself from the sibling respond_to_match by stating it only reads, making the tool's purpose unmistakable.

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 routes the agent away from this tool for actions: 'To accept, decline or block the match, call respond_to_match.' It also implies usage after obtaining a match_id from check_matches, and the safety note 'Never promise an address' adds an operational guideline. This gives clear when-to-use and when-not-to-use context.

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 readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: results are 'capped at 10,' no personal details are returned, 'no match request is created and nobody is contacted,' and the input is 'never stored.' This gives the agent a strong safety and privacy model beyond what annotations alone convey.

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 compact and front-loaded, starting with the core behavior and then adding key constraints (cap, no storage, no account needed, intended use case). Each sentence earns its place without redundancy or 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 simple one-parameter read-only tool, the description covers everything an agent needs: return type, cap, privacy guarantees, lack of side effects, account requirements, and usage intent. No output schema exists, but the description fully specifies the return value ('a number and nothing else'), so context is 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?

Schema description coverage is 100%, so the schema already documents the single 'description' parameter thoroughly. The tool description adds context about counting against the description, but does not need to compensate for missing schema information. 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 opens with a precise verb and resource: 'Count the people already in the pool whose situation is close to a description.' It further distinguishes this from sibling tools by emphasizing it 'saves nothing: no match request is created' and 'returns a number and nothing else,' making the tool's unique role clear.

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 states when to use the tool: 'Use it to answer whether anyone is going through something similar, before the user decides whether to join.' It also notes this is the only tool that works without an account. However, it does not name sibling alternatives explicitly, so routing away from create_match_request is implied rather than spelled out.

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 destructiveHint=true, it discloses the side effects of a mutual accept (overlap opens a private conversation and emails each person a link) and the permanent scope of a block versus the one-request scope of a decline. The instruction 'Never promise an address' adds a real-world constraint agents must know.

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 compact, front-loading the core action and enumerating the three values before expanding on side effects and constraints. Every clause—precondition, mutual-accept side effects, address warning, decline scope, block permanence—earns its place.

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 two-parameter tool with no output schema and existing annotations, the description covers when to call, what the response values mean, side effects, and permanent/consequential behavior. Nothing an agent needs to invoke this tool 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?

Schema coverage is 100%, and the schema descriptions for match_id and response already cover their meaning, with the response enum documenting accept, decline, and block in detail. The description adds no additional parameter-level information beyond what the schema provides, so it stays at the baseline 3.

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 opens with a specific verb and object: 'Record the one answer the user gave about a match: accept, decline or block.' It enumerates the three allowed responses, making the tool's function unmistakable and differentiating it from sibling tools that create, confirm, withdraw, or inspect match requests.

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 an explicit precondition: 'Call it only after the user has said which of the three they want.' It also provides when-not guidance by distinguishing decline ('covers this one request, and a later request from that person can still match') from block ('permanent ... send block only when the user asks for exactly that').

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 mark the tool as destructive, and the description adds useful behavioral nuance: it voids a pending match from this request, keeps matches both people accepted, and leaves other requests active. This goes beyond the annotation's simple destructive flag, though it does not detail irreversibility or permissions. Still, the added context is valuable.

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 five short sentences with no filler. The main action is front-loaded, the critical parameter instruction comes second, and each subsequent sentence adds a distinct useful detail. It is concise while still covering disambiguation and behavioral effects.

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 tool with no output schema, the description covers what the tool does, when to use it, how to resolve ambiguity, and what effects it has on pending and accepted matches. The annotation covers the destructive nature. Nothing essential is missing for correct invocation.

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 parameter is already documented. The description adds practical guidance by emphasizing 'Always pass its request_id' and explaining which request_id to use. It also routes ambiguity to check_matches, which helps the agent provide the correct value.

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 uses a specific verb and resource: 'Withdraw one match request, either a draft or an open one.' It clearly states the scope and distinguishes the action from the sibling tools such as check_matches and confirm_match_request. An agent can understand exactly what operation this tool performs.

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 gives explicit guidance: always pass request_id, and 'If it is unclear which one the user means, call check_matches first.' It also clarifies behavioral boundaries: other requests stay active and accepted matches are kept. This gives the agent clear selection and disambiguation rules relative to alternatives.

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