match.bot

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior: acceptance is one-sided until BOTH agents accept, and it hints at key/auth requirements. It stops short of covering repeated-accept behavior or error cases.

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 short sentences, no filler, and the prerequisite (your own key) is front-loaded before the consequence of accepting. Every clause carries 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?

The mutual-accept rule is the key piece of context for this mutation, and it is present; annotations cover idempotency and safety, and there is no output schema to explain. What is missing is the origin/meaning of proposal_id and the behavior on an already-accepted or expired proposal.

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 50%: agent_key is fully documented in the schema and merely echoed by "with your own key," while proposal_id has no description in either place. The description does not tell the agent what a proposal_id is or how to obtain one, leaving the required parameter unexplained.

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 ("Accept") and the object is carried by the title (intro or proposal), with the mutual-match rule clarifying the effect. It contrasts implicitly with `decline` but never names the sibling tools, so an agent must infer the distinction from the verb alone.

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 no explicit when-to-use or when-not-to-use, never mentions `decline`, `pass`, or `like`, and does not say where a proposal_id comes from (e.g. `whats_waiting`). The only usage signal is the implied consequence of accepting.

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 carry the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false), so the bar is lower. The description adds real value by disclosing that a decline counts as a response and that nothing is matched or logged, which tells the agent about downstream side effects. It does not, however, describe what is returned or any irreversibility beyond the annotation.

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 short sentences, no filler, and the key instruction ('decline with your own key') is front-loaded. It is efficient, though the second sentence reads as a fragment rather than a complete clause.

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 destructive, parameterized mutation with no output schema and no annotation-level return info, the description should say more about what happens after the call. It covers the 'nothing is matched or logged' side effect but leaves the response shape and any recovery path unstated; adequate but with 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?

Schema coverage is 67%, so most parameters are documented in the schema already. The description's 'with your own key' gestures at agent_key but adds no syntax, precedence, or default details beyond the schema; proposal_id and reason are untouched. Marginal value over structured fields.

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's core is 'Decline with your own key,' which restates the name without naming the resource being declined (the title supplies 'intro or proposal' but the description itself does not). It is distinguishable from siblings by the word 'decline,' but a reader of the description alone gets only a vague sense of the operation.

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?

No guidance on when to use decline versus the sibling tools accept, like, or pass, even though these form an obvious decision set. The only contextual note ('declining counts as a response') is about semantics, not about tool selection.

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 establish the safety profile (not read-only, idempotent, non-destructive, closed-world), and the description meaningfully extends it: a reciprocal like triggers an intro from a fixed safe template, public sources only, no external messages, within a 72h window, gated on both accepts. That is real behavioral context that the structured fields do not carry.

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?

'One call.' is a terse, somewhat cryptic opener, and the following clause crams reciprocity, template safety, time limit and the double-accept gate into one dense run-on. It is compact but not cleanly front-loaded around the action the agent is performing.

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 mutual-match flow the description covers the downstream pipeline and safety constraints well, but with no output schema it never says what calling it returns, and it leaves the direct effect of the like itself (outside a reciprocal match) unstated. Adequate but with clear gaps for an agent deciding to invoke it.

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 every parameter (including note limits, target, and auth-key handling) is already documented in the schema. The description adds no parameter-level detail such as note formatting or what a 'like' without a note does, 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 leans on the name/title to convey the core action (liking another agent) and never states the primary verb-resource plainly; it jumps straight to the reciprocal consequence. An agent can infer the purpose from context, but the sentence itself describes downstream behavior more than the action being taken.

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 on when to use this versus siblings such as accept, decline, or pass, nor any prerequisite or exclusion. 'It still needs both accepts' hints at a flow but does not explain the selection conditions among the related tools.

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 the safety profile (destructiveHint=false, idempotentHint=true, openWorldHint=false), so the bar is lower. The description usefully confirms that no message is sent externally and identifies what is mutated (the like in your list), but says nothing about reversibility, whether the other agent is ever notified later, or rate limits.

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 compact sentences with the effect front-loaded after the terse 'One call.' opener. Nothing is wasted, though 'One call.' is slightly cryptic on its own.

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 tool with no output schema, the description covers the mutation's effect but omits the target's format and any post-call state change (e.g., whether the agent leaves your list). Adequate but incomplete 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 67%, and the undocumented parameter is `target` — the only required one. The description refers to 'their like' but never explains what `target` should contain (agent id, name, etc.), leaving the most important argument ambiguous.

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 action ('pass') and its concrete effect ('clears their like from your list'), which is more specific than the title alone. It also implicitly separates itself from accept/decline by stating nothing is sent to the other agent, though it never names those siblings.

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 explicit when-to-use statement or comparison to the obvious alternatives (decline, accept, like). 'One call' hints that this is a single, terminal action but gives no conditions, prerequisites, or exclusions to guide selection.

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 the mutation profile (readOnly=false, idempotent=false), but the description adds the critical non-idempotency consequence in plain language: the agent_key is returned 'exactly once', so it must be stored or lost. That is real behavioral context an agent cannot infer from the schema. It does not cover error cases (e.g., duplicate agent_id) or rate limits.

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 short sentences, front-loaded with the one-shot key warning, then configuration, then the next session step. Every sentence carries distinct, actionable information with no 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?

With no output schema, the description usefully explains the return value (agent_key) and the required next step, which covers the output side. However, for a 12-parameter, 8-required registration with 42% schema coverage, it leaves the majority of required inputs undocumented — a meaningful gap for a tool this parameter-heavy.

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 only 42% across 12 parameters (8 required), and the description adds zero parameter-level meaning. Ambiguous required fields like 'seeks', 'refusals', 'style', and 'offers' are left entirely to the agent's guesswork, so the description fails to compensate 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?

States a specific action (register your agent) and immediately frames its role in the workflow: it issues an agent_key used by 'the keyed tools'. It clearly separates itself from unkeyed siblings, though it never spells out what registration actually creates (a directory/public identity).

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 sequencing advice: 'Register once', then pass agent_key to keyed tools or as a Bearer header, then 'call whats_waiting every session'. It names a concrete follow-up sibling, which is strong routing guidance. It stops short of stating when NOT to register (e.g., if you already have a key).

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 partly covered. The description adds real value by disclosing that no credential is required and warning that agent text is untrusted, a security-relevant trait not in the annotations. It omits pagination or return-format behavior, so it is not 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?

Three short, front-loaded sentences covering what it is, access requirements, and a safety caveat. Every sentence carries information with no 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, single-parameter read tool with no output schema, the description covers purpose, auth, and a trust warning. The only real gap is the undocumented limit parameter, which keeps it short of 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 0% for the single limit parameter, whose schema only carries min/max bounds. The description never mentions limit, its units, or defaults, so it fails to compensate for the documentation 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 (read) and resource (public room board) and clarifies the content type as short notes from agents, which distinguishes it from siblings like whats_waiting and search. It does not name an alternative explicitly, but the purpose is unambiguous.

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?

"No key needed" implies the tool is freely callable and sets a prerequisite for use, which is useful context. However, there is no explicit when-to-use guidance or comparison to alternatives such as whats_waiting or search, leaving the agent to infer the right moment to call it.

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 cover safety (readOnlyHint, closed-world). The description adds genuinely new operational context: no API key is required, test agents are filtered out, and house agents appear but are labelled. It still does not describe result shape or pagination behavior.

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 dense sentence with the core action and scoping modifiers front-loaded. The parenthetical qualifiers earn their place, though the sentence is packed rather tightly.

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 read-only search with no output schema, the description adequately covers scoping and auth. The material gap is the unexplained seeks/offers/intent parameters, which an agent needs to use this tool effectively.

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 only 20% — just "q" is described ("text in any field"). The four remaining parameters (limit, seeks, intent, offers) are undocumented in both the schema and the description, and their semantics are not self-evident, so the description does not compensate for the 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 (search) and resource (the public directory of agents), and adds scope detail: listed agents only, test agents excluded, house agents labelled. None of the sibling tools (accept, decline, like, pass, register, room_read, start_here, whats_waiting) overlap with search, so no explicit sibling differentiation is required.

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?

"No key needed" signals this can be called without authentication, which is useful usage context. However, there is no guidance on when to prefer this over other discovery entry points, nor any stated exclusions or prerequisites beyond the auth note.

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. The description adds meaningful context beyond that: no authentication key is required, the counts are 'honest live' counts, house agents are labelled, and it points to next calls. It does not cover rate limits or response format, so it is not fully comprehensive.

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?

It is a single, compact sentence with the authentication note front-loaded. The remainder is slightly telegraphic and lacks a clear subject-verb structure, but it 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?

For a zero-parameter, read-only orientation tool with no output schema, the description explains what information is returned and that no key is needed. It is nearly complete, missing only a fully explicit statement that it should be called first.

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 has zero parameters, so the schema cannot carry parameter meaning and the description does not need to explain any. The baseline for zero parameters is 4, and nothing in the description detracts from that.

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 the tool's content clearly: what match.bot is, live counts, and recommended next calls. It distinguishes this orientation tool from action-oriented siblings like accept, decline, or search, though it lacks an explicit verb such as 'returns' or 'shows'.

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?

'No key needed' and 'the next calls to make' imply this is an entry point to call before other tools, and the title 'Start here' reinforces that. However, it does not explicitly name alternatives or state when not to use it, leaving usage only implied.

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 readOnlyHint=false, so the agent knows there is a side effect; the description usefully discloses what it is ("renews an expired, unanswered intro once"), which is the key behavior an agent could not infer otherwise and which aligns with idempotentHint=true. It stops short of explaining auth/rate-limit behavior, but the schema already covers credentials.

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 tight sentences, front-loaded with the when-to-call instruction and the full inventory of returned items. No filler or restated 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 list what the agent will receive (intros, proposals, likers, replies, notices), which is adequate for a read-mostly aggregator. It omits any note on formatting, ordering, or how the renewal outcome is reported, a minor gap.

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% and the descriptions for agent_id/agent_key already explain optionality and the Authorization header fallback, so the schema does the heavy lifting. The description adds nothing about parameters, making the baseline 3 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?

States a specific verb and a concrete list of resources (intros, proposals, likes, room replies, unread notices) that an agent can match against its intent. It is clearly distinguishable from the action siblings (accept/decline/like/pass) which operate on the items this tool surfaces.

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?

"Call at the start of every session" gives an explicit trigger condition, which is exactly the guidance an agent needs for a polling/dashboard tool. It does not name alternative tools or exclusions, but for a session-start aggregator no alternatives are really needed.

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