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

The description adds meaningful behavioral details beyond the annotations: each result indicates success, and contacts who cannot be added directly yield an invite code. It also highlights an authorization constraint, 'the account administers.' This is useful context that the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) do not provide.

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, with the core action front-loaded and the behavioral nuance following immediately. Every sentence contributes value.

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?

Given the full schema, annotations, and lack of output schema, the description covers purpose, permission scope, and response behavior enough for an agent to call it correctly. It would be slightly stronger with an explicit note on partial success semantics or already-existing members, but the per-result phrase largely covers partial success.

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 each parameter already has a descriptive schema entry (e.g., groupId from list_groups, contactIds E.164 format). The description does not add parameter-level meaning, so the baseline score of 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 states a specific action, 'Add participants to a group', with the resource 'group' and a scope qualifier, 'the account administers'. It clearly distinguishes itself from sibling tools like remove_group_participants or promote_group_participants through the verb 'add' and the invite-code fallback 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?

Usage is implied: the tool is for adding participants to a group, and the prerequisite that the account must administer the group is explicit. However, it does not reference alternatives or state when not to use it, leaving sibling differentiation to the agent.

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=false, idempotentHint=true, and destructiveHint=false, which covers the mutation and safety profile. The description adds the useful nuance that archiving happens 'on the linked devices' and that unarchiving is achieved with `archived: false`, but it does not describe other behavioral traits such as sync effects, visibility changes, or response 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?

The description is a single, focused sentence with no filler. It front-loads the primary action and immediately covers the secondary mode, making it easy to parse and act on.

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 toggle tool with a complete parameter schema and idempotent annotations, the description is nearly sufficient. It explains both archive and unarchive modes and references the account context via the schema. The lack of an output schema and any mention of return values is a minor gap, not a critical one.

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 input schema fully describes all three parameters with 100% coverage, so the baseline is 3. The description adds marginal value by showing how the `archived` boolean toggles between archive and unarchive, which reinforces the schema's 'Default true' note but does not provide substantial new meaning.

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 the operation: archive a chat, and explicitly includes the unarchive behavior via `archived: false`. It names the specific resource ('a chat') and the device scope ('on the linked devices'), but it does not explicitly differentiate itself from sibling chat-state tools like pin_chat or mute_chat.

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 explains how to unarchive by setting `archived: false`, but provides no guidance on when to choose this tool over alternatives such as pin_chat, mute_chat, or mark_chat_read. There is no mention of prerequisites, context, or exclusions, leaving usage inference entirely to the agent.

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 flag destructiveHint=true and readOnlyHint=false, and the description adds useful behavioral context by stating that cancellation makes the link stop working and that completed invitations are exempt. This goes beyond what the annotations alone convey, though it does not discuss error behavior or reversibility explicitly.

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 two short sentences with no filler. The primary definition is front-loaded, and the completion constraint is stated in one additional sentence that 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?

Together with the schema and annotations, the description covers purpose, effect, an important constraint, destructiveness, and the required confirmation flag. No output schema exists, but for a simple cancel operation the provided details are sufficient for an agent to invoke it 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 description coverage is 100%, so the parameter semantics are fully documented in the schema itself, including the confirm requirement. The description adds no additional parameter-level detail, so the baseline score 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 states a clear action and resource: "Cancel an invitation", plus the concrete effect "its link stops working". It also distinguishes the tool's scope by noting "Completed invitations cannot be cancelled", which is a meaningful boundary not present in sibling tool names.

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 implicitly gives a when-to-use rule: cancel an invitation by disabling its link, and an explicit when-not-to-use rule: completed invitations cannot be cancelled. It does not name alternatives like reset_group_invite_link, but the object-specific wording makes the intended use reasonably clear.

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 discloses behavioral outcomes beyond the annotations: the message ends in 'failed' state with error code 'cancelled', and it fails with 'not_queued' if the message is no longer queued. These specifics provide useful context that annotations (destructive, idempotent) do not cover, adding value without contradiction.

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 two sentences with no fluff. It front-loads the core purpose, then provides outcome and the alternative, all in a compact, easily scannable structure.

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 only two parameters, no output schema, and comprehensive annotations, the description covers the essential aspects: what it does, when to use it, what happens on success and failure, and the alternative. Nothing critical is missing for an agent to invoke it 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 description coverage is 100%, so parameters are already well-documented. The description adds contextual information about the messageId parameter requiring a queued state, but does not add new parameter-specific syntax or format details beyond the schema. 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 the specific action: stopping a message that is still 'queued' from being sent. It also distinguishes itself from the sibling delete_message by specifying that delete_message is for messages that have already left the queue, making the purpose 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?

It explicitly says when to use this tool (when the message is still queued) and when not to (when the message already left, use delete_message instead). This direct routing between alternatives is exemplary.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by specifying that it returns contact id, business name, and username when known, and by noting it only reports numbers that have WhatsApp. No contradictions with 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?

The description is two sentences with no fluff. The core purpose is front-loaded, and the usage tip ('Check before sending to a new number') is a valuable addition. Every sentence earns its place; there is no redundancy.

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 explains the return content: contact id, business name, and username when known. Combined with the schema for inputs and annotations for safety, an agent has everything needed to invoke the tool correctly. The 'when known' phrasing appropriately signals that some fields may be 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?

The input schema provides 100% description coverage for both parameters: phones (1-50 numbers, E.164 format) and accountId (the wuapi account id from list_accounts). The description does not add any parameter-specific meaning beyond the schema, so the baseline of 3 applies since the schema does the heavy lifting.

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 the tool checks which phone numbers have WhatsApp and returns contact id, business name, and username when known. The verb 'check' is specific, the resource is 'phone numbers', and the outcome is unambiguous. It distinguishes itself from sibling tools like send_text or lookup_contacts by focusing on WhatsApp presence validation.

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 provides explicit usage context: 'Check before sending to a new number.' This implies the tool is used as a pre-send validation step, which is clear and actionable. However, it does not explicitly name alternative tools or state when not to use it, so it misses the exclusion clause that would earn a 5.

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 provide false hints for readonly, idempotent, open-world, and destructive flags. The description adds valuable behavioral context: linking is billed, a new organization's first number is free, and the call 'starts' a linking flow rather than completing it instantly. This goes beyond the structured fields, though it does not describe failure or response behavior in detail.

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 dense but efficient: four sentences, all informative. It is front-loaded with the purpose and then gives the workflow, billing caveat, and alternative tool. Slightly longer than necessary, but no sentence is wasted.

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 6-parameter tool with a nested object and no output schema, the description covers the key context: how to choose proxyLocation, the two linking paths, billing consequences, and when to use create_invitation. It does not mention what the call returns or failure cases, but the schema fully documents all parameters and the workflow guidance is strong enough to invoke it 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 schema already documents each parameter. The description adds extra meaning by tying proxyLocation to list_proxy_locations, explaining the QR-code versus pairingPhone choice, and noting the 8-character pairing code. This is meaningful value beyond the schema, though the schema remains the primary source for exact formats.

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: 'Start linking a new WhatsApp number.' It also distinguishes itself from create_invitation by explicitly saying that tool is for letting someone else link their own number, so an agent can tell them apart without inspecting schemas.

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 a concrete workflow: pick proxyLocation via list_proxy_locations, then either show the QR code with get_account_qr_code or pass pairingPhone. It also names create_invitation as the alternative when someone else should link their own number, giving clear when-to-use guidance.

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=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false. The description adds valuable behavioral nuance: participants with restrictive privacy settings receive an invite code instead of being added directly. This goes beyond the annotations by explaining a real edge case and pointing to the result for visibility.

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 with no waste: the first states the core action, the second covers an important edge case. Information is front-loaded and every phrase 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?

With no output schema, the description should hint at what the caller receives, and it does via 'see the result' for invite codes. However, it does not specify the overall return shape (e.g., group ID, status). Given strong schema annotations and full parameter documentation, this is a minor gap rather than a fatal one.

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. The description adds meaning beyond the schema by explaining that the participants parameter may result either in direct addition or in invite codes depending on privacy settings. It also clarifies that accountId makes the account the owner. This enriches parameter understanding beyond the schema's plain field 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 uses a specific verb and resource: 'Create a WhatsApp group with the account as owner.' This clearly distinguishes it from sibling tools like add_group_participants, get_group, or leave_group. The ownership detail adds precision beyond the title.

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 explicit guidance on when to use this tool versus alternatives is provided. An agent must infer from the name and the sibling list that this is for creating a new group rather than modifying an existing one. No mention of 'use this for new groups; use add_group_participants for existing groups'.

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 carry no positive hints (all flags false), so the description shoulders the burden. It discloses a non-obvious, critical behavior: the 'url' is returned only here and may be emailed via inviteeEmail. It doesn't cover expiration or cancellation, but it adds meaningful side-effect context beyond what annotations provide.

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 core function. Each sentence adds distinct value: what is created, how to share it, and an optional email side-effect. There is no 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 tool with 12 optional parameters and no output schema, the description covers the most important output (url) and a side effect, but it does not explain the full response shape, error conditions, or the invitation lifecycle (e.g., later retrieval or cancellation). 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 description coverage is 75%, so most parameters are already documented. The description adds useful context for inviteeEmail (wuapi can email the URL) and the returned url. However, three parameters (historySync, inviteeName, inviteeEmail) lack schema descriptions, and the description only partially compensates by explaining inviteeEmail.

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 verb ('Create') and resource ('a branded page') and adds a distinctive condition: the customer links their own WhatsApp number without needing a wuapi account. This clearly differentiates it from siblings like get_invitation, cancel_invitation, and create_account.

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 implies use by explaining what it creates and noting that the 'url' is returned only here, but it never explicitly states when to use this tool versus alternatives, nor does it name any sibling. The phrase 'without an account on wuapi' hints at a contrast with account creation, but no explicit when-to-use or when-not-to-use guidance is provided.

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 are sparse (readOnlyHint=false, destructiveHint=false), so the description carries the disclosure burden. It explains the externalId addressing scheme and the invitation follow-up, but doesn't specify what happens on creation (e.g., response shape, idempotency behavior beyond schema). The description adds some context beyond annotations but leaves behavior on creation largely implicit.

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 concise sentences that front-load purpose, then explain key usage and the next step. No wasted words; every sentence earns its place by conveying critical workflow 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?

Given 5 parameters (one nested object), no output schema, and no detailed annotations, the description covers the core workflow adequately. It omits response format and error handling, but these are less critical for a creation tool whose output can be inferred. The description is sufficient for an agent to correctly invoke the tool in the intended context.

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 80%, so most parameters are documented. The description adds extra meaning for externalId—how to use it for addressing—which goes beyond the schema's pattern description. This elevates parameter understanding beyond what the schema alone provides.

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?

Clear verb-resource pair: 'create a project' with explicit customer scope. Distinguishes from siblings like create_invitation by describing the workflow and naming the specific follow-up tool. The purpose is unambiguous and specific.

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?

Provides explicit workflow: create project, set externalId, then invite customer with create_invitation. Names the alternative tool directly and states the constraint 'Organization keys only.' This gives clear when-to-use and next-step guidance.

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 discloses a critical behavioral nuance beyond the annotations: the signing secret is intentionally not returned and must be retrieved from the dashboard. It also explains that events are delivered as signed POST requests, which is useful context for an agent preparing to handle webhooks. Annotations provide only basic booleans, so the description carries the behavioral burden well.

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 with no redundancy. The first sentence states the core purpose, and the second adds a key security behavior. Every word earns its place; information is front-loaded and well-structured.

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?

Given the schema fully documents all four parameters and annotations are present, the description covers the essential creation behavior and the important secret-handling detail. It does not describe return values (no output schema), but that is not required. Minor gap: it doesn't explicitly say what happens after successful creation (e.g., immediate event delivery), but the overall intent is clear.

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. The description does not elaborate on individual parameters beyond what the schema already documents. It adds general context about public https URLs and signed POST requests, but no parameter-specific details, so it neither compensates nor detracts from the 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?

The description states a specific verb ('Register') and resource ('public https URL to receive events'), distinguishing it from sibling tools like update_webhook and delete_webhook. It also adds a distinctive detail about signed POST requests, leaving no ambiguity about the tool's purpose.

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 implies when to use the tool (when creating a webhook endpoint) but does not explicitly mention alternatives or when not to use it. Sibling tools like update_webhook and delete_webhook are present, but no routing guidance is given; the usage is clear from the name and description but 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the description's job is lighter. It adds important context beyond the annotations: deletion cannot be undone, queued messages are cancelled rather than sent, and forEveryone=false restricts deletion to linked devices. No contradiction exists.

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 deliver the essential information without filler. The main action and scope are front-loaded, followed by the queued-message nuance and the irreversible warning. Every sentence 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 simple destructive tool with three parameters and no output schema, the description covers the key behavioral edge cases: queued messages, device scope, and irreversibility. It does not mention return values or potential errors, but those are not critical for invoking this tool given the schema and annotations.

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 adds value by explaining that forEveryone=false means 'only on the linked devices' — a semantic nuance not present in the schema. Other parameters (messageId, confirm) are already fully documented in the 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?

The description states a specific verb ('Delete'), the resource ('an outbound message'), and the scope ('for everyone' or 'only on linked devices'), making it immediately clear what the tool does. It also distinguishes itself from the sibling cancel_message by clarifying that queued messages are cancelled instead of sent, which helps an agent tell them apart.

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 provides clear context for when deletion is appropriate, including the forEveryone modifier and the queued-message cancellation behavior. It does not explicitly name alternatives or say 'use cancel_message when...', but the behavioral distinction is strong enough that an agent can infer the right choice.

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 destructiveHint=true and idempotentHint=true, so the description does not need to restate those. It adds valuable context by noting that events stop at once, including deliveries still retrying, which is a behavioral nuance beyond what annotations provide.

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 with no fluff. The primary action and its immediate consequence are front-loaded, making it easy for an agent to grasp the tool's function quickly.

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 delete operation with destructive and idempotent annotations, the description covers the essential behavioral impact. No output schema is present, but the response is likely minimal. The only minor gap is the lack of mention of prerequisites or error handling, but that is not critical for this tool type.

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% with both parameters well-documented (webhookEndpointId sourced from list_webhooks, confirm requiring explicit user consent). The description itself adds no parameter information, so it relies on the schema, which is fully adequate. 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 clearly states the action ('Delete a webhook endpoint') with a specific resource and adds the immediate effect of stopping events, including retrying deliveries. This distinguishes it from sibling tools like create_webhook or update_webhook without ambiguity.

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 explains what the tool does but does not explicitly state when to use it over alternatives like update_webhook or list_webhooks. The context of sibling tools makes it obvious for a delete action, but there is no explicit guidance or exclusion, such as 'use only when the endpoint is no longer needed'.

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 establish that the operation mutates, is idempotent, and is non-destructive. The description adds the key behavioral point that affected users remain group members rather than being removed, but it does not discuss partial failures, permissions, or behavior for non-admin contacts. No annotation contradiction exists.

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 a single well-formed sentence that front-loads the action and result with no filler or repetition. Every word adds meaning.

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 mutation with fully documented parameters, idempotent and non-destructive annotations, and a clear outcome, the description plus schema is largely sufficient. It does not describe return values, but there is no output schema and the state change itself is the main contract; the main gap is the missing explicit usage routing.

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 schema describes 100% of the parameters, including accountId, groupId, and contactIds with formats and sources. The description contributes no additional parameter-level meaning, so the 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 uses an active verb ('Turn ... back') and a precise target state ('regular members'), making clear that this tool removes admin rights while keeping users in the group. This distinguishes it from both promote_group_participants and remove_group_participants without ambiguity.

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 implies the usage scenario: use it when group admins should lose admin rights but remain members. However, it does not explicitly say when to prefer this over the sibling promote/remove tools, nor does it state any exclusions or prerequisites.

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 this as mutating, non-destructive, and idempotent. The description adds the two most operationally important traits beyond those annotations: the edit window and the distinct queued-message behavior, both of which are absent from the schema and 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?

Two sentences with the action and key constraint front-loaded, followed by the queued-message nuance. No filler and no repetition of schema details.

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 two-parameter mutation with a complete schema and no output schema, the description supplies the necessary timing and queued-behavior context. It is sufficient for an agent to invoke the tool 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?

The schema already documents both parameters fully (100% coverage), so the baseline is 3. The description adds a useful eligibility cue—the messageId must refer to an outbound text message—which the schema's messageId description does not explicitly state.

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: changing the text of an outbound text message, and delimits scope with the WhatsApp edit window. This clearly separates it from send_text, delete_message, cancel_message, and reply_to_message in the sibling list.

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 clear context: use this when an outbound text message's content must change, but only within the ~15 minute edit window, and queued messages will get the replacement text. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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 read-only, idempotent, non-destructive behavior, so the description is free to add value. It does by enumerating the returned fields and explaining the hasQrCode flag, which tells the agent what to expect in the response. No side effects or hidden behavior are omitted beyond what annotations already cover.

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 filler. The first front-loads the core purpose and return fields; the second clarifies a subtle field and routes to a sibling. Every word 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 one-parameter read-only getter with no output schema, the description is complete: it lists all key return fields and explains hasQrCode. It doesn't mention error cases or pagination, but those are unlikely to be needed for a single-account fetch, and annotations cover safety.

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 parameter accountId is fully described in the schema (100% coverage) with a clear source reference. The tool description adds no additional parameter detail, but the schema carries the burden, 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 states exactly what the tool returns: one account's status, linked phone number, profile name, proxy location, disconnect reason, last error, and QR-code readiness flag. This clearly distinguishes it from list_accounts (list all) and get_account_qr_code (retrieve QR code), so an agent can pick the right tool without opening schemas.

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 implies a single-account lookup and explicitly points to get_account_qr_code for retrieving the QR code. It also benefits from the schema's accountId description ('from list_accounts'), which orients the agent on where the ID comes from. It lacks an explicit 'when not to use' but the context is clear 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavior beyond annotations: QR codes rotate every 20 seconds, it waits during account startup, and returns status or pairing code depending on link state. This is helpful context that annotations do not provide.

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 that are front-loaded with the purpose and then behavioral notes. It is concise and well-structured, though the second sentence packs multiple facts that could be slightly reorganized for readability.

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 tool with annotations covering safety and schema covering parameters, the description explains all key runtime behaviors: waiting, rotation, and conditional return values. Nothing essential for correct invocation 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 description coverage is 100% for both parameters, so the schema already documents them. The description adds context about waiting behavior and rotation that relates to waitSeconds and the overall operation, enriching the meaning beyond the schema definitions.

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 the tool retrieves a QR code for linking a device in WhatsApp, with specific context (Settings > Linked devices). It distinguishes its purpose from a generic 'get' but does not explicitly differentiate it from sibling tools like request_pairing_code, though it mentions pairing code 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?

No explicit guidance on when to use this tool versus alternatives. It gives retry advice (call again if expired) but does not mention any sibling tools or conditions that would make another tool more appropriate, such as using request_pairing_code for phone-number linking.

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 read-only, idempotent, and non-destructive behavior. The description adds value by disclosing that the full API key is never returned, only its name and last 4 characters—a security-relevant guarantee beyond 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?

Two concise sentences with no fluff. The first sentence front-loads the resource and output details, and the second gives a direct usage directive.

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 parameters and no output schema, the description still explains what will be returned and when to call it. Nothing essential for selecting or invoking the tool 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?

This tool has zero parameters and the schema coverage is trivially 100%, so no parameter documentation is needed. The baseline 4 for a zero-parameter tool 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 that the tool returns the current server's identity context: organization, API key name/last 4 characters, and project. This aligns with the title 'Who am I' and distinguishes it from account/group/chat-oriented sibling tools.

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 says to call it first when unsure whether the current key is an organization key or a project key. It provides a clear usage trigger but does not name alternative tools or exclusion conditions, so it stops short of a 5.

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 annotations already establish that this is read-only, idempotent, and non-destructive. The description adds useful output-shape context (participants and roles), but it does not disclose error behavior, data freshness, or any other operational quirks, so its contribution is moderate.

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 a single short sentence with no filler and immediately lists the relevant returned fields. It is appropriately sized, though it is a fragment and depends on the title for the verb.

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 two-parameter read operation with strong annotations and no output schema, the description provides enough return-value context to call it. It could improve by clarifying what happens if the group does not exist or by pointing to list_groups for enumeration, but nothing essential 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 description coverage is 100%, and both parameters already have helpful descriptions indicating where their values come from (list_groups and list_accounts). The tool description adds no parameter-level meaning beyond the schema, so the baseline score of 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 title supplies the verb 'Get' and the description clearly enumerates what is returned: name, description, settings, and participants with roles. It is clear this is a single-group read, but it does not explicitly differentiate itself from siblings like list_groups or get_group_invite_link.

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 about when to use this tool versus alternatives. With many group-related siblings (list_groups, create_group, get_group_invite_link), the agent must infer that this tool fetches one group's details; no explicit conditions or exclusions are given.

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, idempotentHint=true, destructiveHint=false, covering safety. The description adds the admin permission requirement and states the return value format, which are not in annotations. This is useful context beyond structured fields, though it doesn't describe error behavior or edge 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 sentences with no waste. The first sentence states the purpose and output format, the second states the key prerequisite. The critical admin requirement is front-loaded after the main purpose. Every word 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 simple read-only getter with two well-documented parameters and no output schema, the description covers the essential details: what is returned and the admin requirement. It doesn't mention what happens if the account is not admin or provide error handling, but for a low-complexity tool, this is sufficient. The output format is explicitly stated, compensating for the missing output schema.

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 both parameters (accountId and groupId) are fully documented with descriptions referencing source lists. The description adds no parameter-specific detail beyond what the schema provides. Baseline of 3 applies since the schema handles parameter documentation.

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 the verb (get) and resource (group's invite link), and specifies the output format (the https://chat.whatsapp.com/... link). It is distinct from reset_group_invite_link and get_invitation, though it doesn't explicitly call out those siblings. 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?

It gives one clear prerequisite: the account must be an admin. However, it doesn't mention alternatives or when not to use this tool, such as when to prefer reset_group_invite_link or get_invitation. The usage context is partially implied but not explicit about exclusions.

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 convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries a low safety-disclosure burden. It adds useful conditional behavior by noting that accountId is linked only once the invitation is completed, but it does not describe status values, error cases, or pagination.

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 a single compact sentence with no filler, and the key output concepts—status and linked accountId—are front-loaded. Every word contributes to understanding the tool's result.

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 read-only tool with strong annotations, the description covers the essential return content and the conditional completion behavior. It lacks explicit status vocabulary and usage routing, but an agent has enough information to invoke the tool 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 description coverage is 100%, and the single invitationId parameter is already well documented as "The invitation id." The description adds no additional parameter-level meaning, so the baseline score of 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 identifies the tool as returning one invitation's status and the linked accountId once completed, which clearly signals a single-invitation lookup. This distinguishes it from sibling tools like list_invitations or cancel_invitation, though it relies on the title for the explicit retrieval verb.

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 singular phrasing implies use when a specific invitation's status or completed accountId is needed, as opposed to listing all invitations. However, it never explicitly states when to prefer this tool over list_invitations or how it relates to cancel_invitation.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating possible statuses and noting that an error is included when the message failed, which is valuable since there is no output 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?

The description is a single, focused sentence that front-loads the core purpose ('One message') and then lists the relevant return fields. Every word earns its place, with no filler or redundancy.

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 low-complexity tool with one parameter, no output schema, and strong annotations, the description adequately explains the return value: status, content, and error. It does not cover not-found behavior or authentication requirements, but given the simple read-only nature and rich schema, the description is sufficiently 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%, and the messageId parameter already has a rich description explaining where valid IDs come from (list_messages, a send tool, or a webhook). The tool description does not add additional parameter-level meaning beyond the schema, so the 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 title provides the verb+resource ('Get a message'), and the description specifies exactly what is returned: one message with its status, content, and error. The phrase 'One message' clearly distinguishes this from list_messages, while the status/content/error focus separates it from edit_message or delete_message.

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: the description indicates this tool retrieves a single message and its delivery status, so an agent can infer it is for checking one message rather than listing or modifying messages. However, it does not explicitly state when to prefer this over list_messages, edit_message, or other siblings, nor does it mention exclusions or alternatives by name.

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, idempotentHint, and destructiveHint. The description adds the requirement of organization keys and specifies the returned fields, which is useful behavioral context beyond annotations. It does not contradict 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?

The description is concise and front-loaded with the purpose and key constraint. Every sentence contributes value: the first states the resource and fields, the second adds the org key restriction.

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 tool with one parameter, the description is sufficient. It specifies the return fields and the auth constraint. Without an output schema, the agent knows what to expect. No critical information 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?

The schema already fully describes the single parameter projectId, including the format (id or ext:<externalId>), with 100% coverage. The description adds little beyond what the schema provides, only indirectly referencing external id in the output fields, so it meets the baseline but doesn't exceed it.

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 the action (get) and resource (project), enumerates the specific fields returned (name, external id, status, account limit and count), and adds a scope constraint (Organization keys only). This distinguishes it from list_projects and other project-related tools.

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 provides clear context that this tool only works with organization keys, which guides when it's applicable. However, it does not explicitly mention alternatives or when not to use it, so it's clear context without exclusions.

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 tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context by specifying what the bill includes and that the total is in cents (USD), plus the org-key restriction.

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 a single, front-loaded sentence that communicates the resource, contents, unit, and scope without any wasted words. Every element 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 no-parameter read-only tool, the description is largely complete: it states what the result includes and its unit. It does not give the exact response shape or clarify timezone/month-boundary semantics, but these are minor for this simple tool.

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 and the schema coverage is 100%, so there are no parameter semantics to explain. The description's mention of organization keys is a scope/auth note rather than a parameter, and with no parameters a score of 4 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 identifies the resource as the current month's bill/usage and lists the specific contents (billable numbers, proxy traffic, total in USD cents). It also signals org-level scope with 'Organization keys only,' which differentiates it from the project-level sibling get_usage_by_project, though it does not name that sibling explicitly.

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 clear usage context by stating 'Organization keys only,' which implies the caller must use an organization-scoped key and that project-level usage belongs elsewhere. However, it does not explicitly mention the alternative get_usage_by_project or state when not to use this tool.

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 tool read-only and idempotent. The description adds valuable context: it returns per-project data, can be filtered by a single project, and is restricted to organization keys. This goes beyond what annotations state, though it does not explain default behavior when no projectId is given.

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 concise and well-structured: it opens with the core output and purpose, then clarifies optional filtering and authorization constraints. Every sentence earns its place without repetition or fluff.

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 tool with two optional parameters and no output schema, the description covers purpose, optional filter behavior, and key restrictions. It does not explicitly state what happens without projectId (likely all projects), but this is reasonably inferable from 'per project' and the optional parameter.

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 input schema fully describes both parameters (month with pattern and default, projectId with format). The description enriches meaning by clarifying that projectId scopes the result to a single project ('that project only'), which is helpful and not redundant with the 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?

The description clearly states the tool retrieves usage numbers, proxy traffic, and messages per project for a month, with a specific purpose (rebilling). It distinguishes from the sibling 'get_usage' by explicitly saying 'per project', making its scope 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 provides concrete usage guidance: 'With projectId, that project only' tells when to filter, and 'Organization keys only' specifies authorization context. It does not explicitly name alternatives like 'get_usage' for overall usage, but the per-project focus inherently differentiates 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 declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context beyond annotations by noting that rejoining requires being added or invited again, which is a meaningful side effect not implied by the annotations alone. It does not contradict any annotations and provides a useful consequence of the action.

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 two sentences with zero redundancy. It states the action upfront and adds the consequence in the second sentence. Every word contributes to the meaning, and the structure is efficient and front-loaded.

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 tool is simple, has no output schema, and the description covers the core action and its reversibility. The confirm parameter requirement is documented in the schema, so its omission from the description is acceptable. The description is sufficient for an agent to understand what the tool does and its impact, though it could optionally mention the confirm step for extra clarity.

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%, with all three parameters (accountId, groupId, confirm) already described in the input schema. The tool description adds no additional parameter-specific information, so it does not exceed the baseline expectation. The description does not compensate for any gaps because there are none.

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 the action (make the account leave a group) with a specific verb and resource. It also clarifies the consequence of leaving (must be added or invited again), which differentiates it from tools like remove_group_participants that remove other members. The purpose is unambiguous and easily understood by an agent.

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 implies when to use this tool (when the account should leave a group) but does not explicitly contrast it with alternatives such as remove_group_participants or create_group. It provides no exclusions or conditions that would help an agent decide between this and similar group-management tools. The usage context is implicit rather than explicit.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral detail beyond those annotations: the account statuses ('ready', 'qr_ready', 'disconnected', 'failed') and their operational meanings, as well as sort order. This helps the agent know what to expect from the call.

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 a single, readable sentence that front-loads the core purpose, then packs in the most actionable status meanings. Every part earns its place and no filler 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?

For a read-only list tool with no output schema and fully documented optional parameters, the description covers the essential behavioral facts: what is listed, the ordering, and the meaning of each status. Pagination details are already in the schema. It is complete enough for an agent to invoke 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 description coverage is 100%, so the input schema already documents limit, cursor, and projectId. The description does not need to re-explain parameters; it adds value primarily through status semantics. 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 states a specific verb ('List') and resource ('linked WhatsApp numbers (accounts)'), and adds ordering ('newest first') plus status semantics. This clearly distinguishes it from sibling tools like get_account or reconnect_account.

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 implies this is the go-to tool for listing linked WhatsApp accounts and interpreting their readiness, but it does not explicitly say when to prefer it over get_account or when not to use it. The status explanations give helpful context for acting on results, but no direct alternative guidance is provided.

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 readOnly, openWorld, idempotent, and non-destructive. The description adds beyond that: data is read live from WhatsApp, covers all groups the account is in, and includes participant count. It doesn't detail pagination behavior, but schema covers cursor/limit and annotations cover safety.

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, front-loaded with scope and data freshness, and a useful pointer to the sibling tool. 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 still conveys the key return element (participant count) and scope. Pagination and full response shape are only implied by the cursor/limit parameters, leaving a small gap, but the description is adequate 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 description coverage is 100%, so parameters are fully documented in the schema. The description doesn't need to add parameter detail and doesn't add much beyond the account scope.

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?

Description states a specific action: list every group the account is in, read live from WhatsApp, with participant count. It distinguishes itself from get_group by pointing to it for participant details.

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 context for when to use the tool (listing all groups) and explicitly routes to get_group when participants are needed. It doesn't exhaustively cover when not to use it, but the alternative is named.

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 destructiveHint=false, so the agent knows this is safe. The description adds the status lifecycle values including 'completed (with the new accountId)', which reveals what the returned items signal. It does not describe pagination behavior, but annotations cover the safety profile, and the description adds behavioral context around statuses.

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 sentence that front-loads the resource and status values. It is compact and informative, though it could be more actionable by adding a usage hint.

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 listing tool with 4 optional params and no output schema, the description plus schema provide a usable baseline. However, it does not mention that results are paginated via cursor/limit, nor does it clarify whether status='completed' includes the accountId in the response. An agent could miss the pagination workflow without inferring it from the cursor parameter.

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 75% (3 of 4 params have descriptions; status has only an enum with no description). The description enumerates status values, which complements the enum list but adds no meaning beyond it. It does not clarify pagination fields or filtering semantics beyond what the schema already states. Baseline 3 is appropriate since the schema carries most of the weight.

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 title and description identify a list operation for invitations and enumerate the statuses returned. It is distinct from sibling tools like get_invitation (single retrieval) and create_invitation (creation), but the description does not explicitly name those siblings or scope the listing (e.g., no mention of filtering by account or time).

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 context for when to use this tool versus cancel_invitation/get_invitation/create_invitation. The status list implies a filtering use-case, and the schema's projectId param hints at scoping, but the description itself provides no explicit when-to-use guidance.

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, idempotentHint, and destructiveHint, lowering the bar for behavioral disclosure. The description adds meaningful behavior beyond those annotations: messages are stored, returned newest first, include both directions, and recent messages are the only way to infer who wrote in the absence of a chat-list endpoint.

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 concise sentences cover purpose, ordering, filtering, and a critical API limitation with no filler. Information is front-loaded and every clause contributes to selecting or invoking the tool correctly.

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 read-only list operation with optional, well-documented parameters, this description is complete enough. It explains what is listed, the ordering, filterable dimensions, and the key caveat about chat listing, so an agent can use it correctly without additional context.

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 high at 83%, so the schema does most of the parameter documentation work. The description reinforces that account, chat, and direction are filters, but it does not add significant detail about limit, cursor, or projectId beyond what the schema already provides.

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?

Describes a specific action (list messages), resource (stored messages), ordering (newest first), and scope (sent and received). Also explicitly distinguishes itself from a chat-list endpoint, which helps differentiate it from sibling tools like list_groups or get_message.

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 the intended use case: filter by account, chat, and direction to read a conversation. The added note that there is no chat-list endpoint is useful context, though it stops short of naming an alternative sibling or an explicit when-not-to-use scenario.

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 convey that this is read-only, idempotent, and non-destructive. The description adds meaningful context beyond annotations: projects are scoped to organization keys, and each project belongs to a customer. This helps the agent understand access boundaries, though it doesn't mention result ordering 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?

The description is short and free of filler, with the key conceptual context packed into two sentences. It is not a full sentence and could be clearer, but it earns its place by defining the resource and scope without repetition.

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 simple optional-filter list tool with strong annotations and a fairly descriptive schema. The description supplies domain context and org scoping, but because there is no output schema and no usage guidance, the agent is left to infer the exact return shape and when this endpoint is preferable to sibling tools.

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 75%, and the description adds no parameter-level detail. limit, cursor, and externalId are documented in the schema, and status is self-explanatory via its enum, but the description itself contributes nothing about how parameters affect the listing.

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 tool name and title clearly state the verb and resource: list projects. The description adds useful context about what a project is — one per customer with its own numbers, keys, webhooks and usage — while the phrase 'Organization keys only' clarifies the scope. It does not explicitly say 'returns all projects' but the intent is 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 gives no guidance about when to use list_projects versus get_project or when to use filters like status or externalId. It provides background context but no usage direction or exclusions, so an agent must infer the appropriate circumstances.

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 read-only and idempotent, and the description adds behavioral detail beyond them: `q` supports partial search, as shown by 'sao' finding Sao Paulo, and the result set is exit locations for new numbers. It could mention pagination explicitly, but cursor/limit in the schema cover that.

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 with no redundant phrasing. The most important information (what the tool lists and why it matters) is front-loaded, and the usage example is compact and concrete.

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 read-only lookup with no required parameters and no output schema, the description conveys the key semantics well: what is returned, for which flows, and how to filter. It leaves response shape implicit, but the purpose is clear enough for an agent to call and interpret the result 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; the description adds one layer of meaning by showing that `q` supports partial search and by framing `country` as a filter. Limit and cursor are left to the schema, which documents them sufficiently, so this is a small but real enhancement.

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 a specific resource (proxy locations) and explains what they are: countries and cities a new number's proxy can exit from. It also ties the tool to create_account and create_invitation, giving it a clear role among the many sibling tools.

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 clearly states the intended context (for create_account and create_invitation) and describes two usage modes: search with `q` or filter by `country`. It doesn't name exclusions or a competing tool, but no comparable alternative appears in the sibling list, so the guidance is adequate.

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 annotations already declare the operation read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that by explicitly stating the returned fields and, importantly, that signing secrets are never shown. Given no output schema, this is valuable disclosure.

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 deliver the essential facts with no filler. The first sentence names the resource and fields, and the second adds a key security-relevant exclusion, all front-loaded and structured clearly.

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 list operation, the description plus schema covers what the tool returns, the notable absence of signing secrets, and all optional filtering/pagination parameters. It is broadly complete, though it could have briefly noted that pagination is supported via cursor even though the schema already documents 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?

All three parameters already have full descriptions in the schema, including pagination defaults and projectId filtering semantics. The tool description adds no parameter-level meaning, so the baseline of 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 clearly identifies the resource as webhook endpoints and names the key returned fields: URL, events, and active status. It is not a tautology and is easily distinguished from create/update/delete webhook siblings, though the description itself lacks an explicit action verb.

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 is given about when to use this tool versus alternatives. There is no mention of when to choose list_webhooks over create_webhook, update_webhook, or delete_webhook, nor any prerequisites or context for fetching webhook configurations.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral limitation that @username lookup is impossible and enumerates the returned contact attributes, which is useful beyond 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?

Two sentences with no filler; the output fields are front-loaded and the username limitation is stated compactly. The first sentence is a fragment, but it is still efficient.

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 read-only, two-parameter lookup, the description plus schema covers inputs, accepted id formats, count limits, and returned fields. No output schema exists, but the description enumerates the key return values; it doesn't discuss errors or pagination, but those are not critical for this simple lookup.

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%, with accountId and contactIds both described, including the accepted formats E.164, digits, or `lid:<digits>`. The description reinforces the 1-50 count and the exclusion of usernames but adds no new parameter-level detail beyond the 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?

The description names the resource (contacts) and the returned fields (about text, WhatsApp username, business name, device count), and the title supplies the verb 'look up'. It is clear but does not explicitly contrast with sibling tools such as check_numbers, so it stops short of full differentiation.

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 tells the agent to look contacts up by number or `lid:` id and explains that usernames cannot be searched because a linked device cannot resolve an @username. This is clear context and a positive/negative usage rule, though it doesn't name alternative 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?

Beyond the annotations, the description discloses that the effect is limited to the unread badge on linked devices and that no read receipts are emitted. This is meaningful behavioral context for a mutation that could otherwise be mistaken for a full read-status action.

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, front-loaded with the primary action and the conditional. Every clause carries necessary information, with no filler or repetition.

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 idempotent toggle with rich annotations and full schema coverage, the description supplies the one missing behavioral nuance: it does not send read receipts. The agent has enough context to select and invoke the tool 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 parameters are already well documented. The description adds value by making the default behavior explicit: call without `unread: true` to clear the badge, or pass `unread: true` to set it unread.

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 exact action ('Clear' or 'set') and the resource ('the chat's unread badge'), and it explicitly contrasts itself with send_read_receipts. An agent can immediately distinguish this from the closest sibling tool.

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 a clear when-not rule: 'Sends no read receipts; use send_read_receipts for blue ticks.' This is an explicit, actionable alternative that leaves no ambiguity about which sibling to choose.

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 establish that the operation is mutable, idempotent, and not destructive, so the description does not need to repeat that. It adds the behavioral nuance that muting can be temporary or indefinite until unmuted. It does not disclose additional side effects or permissions, but none are clearly required for this simple setting.

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 a single compact sentence that front-loads the action and includes the key duration and unmute semantics. No words are wasted, and it is appropriately sized for the tool's simplicity.

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?

Combined with the rich parameter descriptions and annotations, the description makes the tool fully invokable: the agent knows what account to use, what chat identifier formats are accepted, and how duration and muted interact. There is no output schema, but for a straightforward mutation this is not a critical 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 coverage is 100% and the schema already explains accountId, chatId, durationSeconds, and muted well. The description adds only the explicit `muted: false` unmute hint, which is a minor overlay on the schema rather than substantial new meaning.

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 the action: muting or unmuting a chat's notifications. This distinguishes it from sibling tools like archive_chat or pin_chat, which affect chat visibility or ordering rather than notification behavior. It does not explicitly name or contrast siblings, 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?

The description gives useful operational guidance: mute for a duration or until unmuted, and unmute with `muted: false`. However, it does not explicitly say when to choose this tool over alternatives such as archive_chat, pin_chat, or mark_chat_read, so usage context is mostly 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?

The description adds behavioral context by stating that pinning applies 'on the linked devices' and that pinned:false reverses the operation. This supplements annotations like idempotentHint and readOnlyHint without contradicting 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?

A single front-loaded sentence contains the core action, the effect on linked devices, and the unpin mechanism. There is no redundant or filler content.

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 toggle operation, the description covers both directions of the action and the schema covers parameter meanings. No output schema is needed for an operation whose success is evident, and annotations already convey safety and idempotency.

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 schema already documents all three parameters, so baseline is 3. The description goes beyond by explaining that pinned:false triggers unpinning, which clarifies the toggle semantics beyond the schema's 'Default true'.

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 verb and resource: 'Pin a chat to the top on the linked devices, or unpin it'. This clearly distinguishes it from sibling chat-related tools like archive_chat or mute_chat by focusing on the pin/unpin action.

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 clear context for use: pin a chat or unpin by setting pinned:false. It doesn't explicitly name alternatives or exclusions, but the toggle behavior is unambiguous and self-contained.

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=false, destructiveHint=false, and idempotentHint=false. The description adds no behavioral context beyond 'post' — it does not disclose that this is a mutating action (though implied), that it posts publicly to followers, that media must be accessible, or any side effects. The idempotencyKey is explained in the parameter schema, not the description, and the description adds nothing about retry 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?

A single sentence that front-loads the action and concisely lists the supported story types. No superfluous words, and it captures the core functionality effectively.

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 description covers the essential use cases (text/media with optional caption) and is sufficient for a caller to understand the tool's purpose. It omits some details like the requirement for accountId (covered in schema) and the idempotency mechanism (covered in parameter description). With no output schema, the description provides adequate context 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%, establishing a baseline of 3. The description adds semantic value by explaining the relationship between text and backgroundColor (colored background) and between media and caption, which is not fully explicit in the schema. It clarifies the three modes of operation, aiding parameter selection.

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 the action ('Post a story') and the resource type, and specifies the three supported formats: text with colored background, or image/video from a public URL with optional caption. It distinguishes this from sibling messaging tools (send_text, send_media) by focusing on the story context and the account-level action.

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 implies usage for posting stories rather than sending messages, but it does not explicitly say 'use send_text for messages' or provide alternative routing. It relies on the resource type to separate from siblings. There is no mention of when not to use this tool or prerequisites like account availability.

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 readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond the action itself, such as reversible effects, permission requirements, or consequences for already-admin participants. It simply restates the purpose without enriching the agent's understanding of side effects or environment impact.

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 a single, tightly worded sentence that states the core action and a scope qualifier. There is no filler or repetition; it is optimally concise and immediately communicates the tool's purpose.

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 description is sufficient for a straightforward mutation tool with all parameters documented in the schema and annotations covering safety and idempotency. However, it lacks any explanation of the effect on existing admins or the behavior when promoting multiple contacts, and with no output schema, the return value is unstated. It is minimally complete but not rich.

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 baseline is 3. The description does not add parameter-specific details beyond what the schema already provides. It does not elaborate on contactIds format or groupId constraints, which are already well-documented in the schema, so no extra semantic value is added.

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 the action: 'Make participants admins' of a group, which is a specific verb+resource. It implicitly distinguishes from sibling tools like add_group_participants and demote_group_participants by the promotion action, though it doesn't name them explicitly. The constraint 'the account administers' adds scope clarity.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that demote_group_participants is the inverse operation, nor does it offer context on when promotion is appropriate. The only hint is the account-administers constraint, but no exclusions or alternative-condition guidance is given.

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 supply idempotentHint and non-destructive flags. The description adds genuinely useful behavior beyond them: an empty string removes the reaction, and the reaction is tied to the account identity. This is meaningful context an agent cannot infer from annotations alone.

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 compact, front-loaded sentence with no filler. It communicates the core action, the identity constraint, and the removal behavior in minimal space.

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-required-parameter mutation with complete schema descriptions and helpful annotations, the description covers who can react and how to remove a reaction. Nothing essential for correctly invoking the tool 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?

The input schema provides 100% coverage of both parameters, including the empty-string removal behavior for emoji and the messageId source. The description reinforces this but does not add significant meaning beyond the 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?

The description states a specific verb and resource: 'React to a message with an emoji'. The account-scoping clause ('as the account that received or sent it') makes the action precise and differentiates it from generic send or reply tools.

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 clear context by explaining that the reaction is made as the account that received or sent the message, which is an implicit eligibility condition. It does not explicitly contrast with alternatives like reply_to_message, but the intended use is clear.

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 indicate mutation (readOnlyHint=false), idempotency, and non-destructiveness. The description adds a concrete behavioral detail beyond annotations: it 'produces a fresh QR code' when the existing link is invalid. This is useful context without contradicting the annotation profile.

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 two concise sentences. It front-loads the core action ('Restart the account's session') and then gives the trigger and outcome. Every phrase earns its place with no redundant 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 tool with no output schema, the description provides the essential trigger ('disconnected'), the behavior ('restart session'), and the produced outcome ('fresh QR code'). It could go slightly further by explaining the output format or side effects, but nothing critical is missing for correct selection and 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?

The input schema is fully documented with 100% coverage, including the meaning of accountId: 'The wuapi account id of the linked number to act as (from list_accounts).' The description adds no parameter-specific insight, but the baseline of 3 is appropriate given complete schema coverage.

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 verb and resource: 'Restart the account's session.' It further clarifies the concrete outcome by saying it 'produces a fresh QR code' when the link is no longer valid, which distinguishes it from related tools like get_account_qr_code.

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 provides an explicit trigger condition: 'Use it when an account is `disconnected`' and 'when the link is no longer valid.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of fully routing the agent away from sibling 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 mark destructiveHint=true and readOnlyHint=false. The description adds an authorization constraint (administrator scope) but does not disclose irreversibility or the confirmation requirement; however, the schema's confirm parameter covers that. This is acceptable given annotation coverage, but the description contributes only modest behavioral context.

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 no wasted words. It states the action, resource, and scope efficiently.

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 tool with four required parameters, the description is minimal. It relies on schema descriptions for parameter details and annotations for destructive behavior. It could mention the required confirmation, though that is already present in the schema. Overall, adequate but not rich.

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 all parameters (accountId, groupId, contactIds, confirm) are fully documented in the schema. The description adds no parameter-level semantics beyond naming the action, so the baseline of 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?

Description states a specific verb ('Remove') and resource ('participants from a group'), and constrains to groups the account administers. This makes it easy to distinguish from sibling tools like add_group_participants, leave_group, or promote_group_participants.

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 a prerequisite condition ('a group the account administers') but does not explicitly state when to use this tool versus alternatives. It does not mention that self-removal should use leave_group, or that demotion should use demote_group_participants.

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=false (write) and destructiveHint=false (non-destructive). The description adds the quoting behavior and the same-account/same-chat constraint, which are not in annotations. But it doesn't disclose other behavioral aspects like auth requirements, side effects beyond sending, or what happens to the original message. With annotations covering the safety profile, this is adequate but not rich.

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 a single, tightly worded sentence that front-loads the core action and constraint. No filler words; every phrase adds information (reply, quote, same chat, same account, works in direct chats and groups). It is an example of concise, efficient writing.

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 reply tool, the description covers the essential use case and scope. It does not mention the return value (no output schema exists) or any edge cases, but given the schema covers all parameters and the annotations cover safety, an agent has enough to call it correctly. A small gap is the lack of any note about the response, but this is minor.

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 fully documents all three parameters including the optional idempotencyKey semantics. The description does not add any additional meaning about parameters, such as format hints or relationships. Since the schema carries the full burden, the baseline of 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 states a specific verb ('Reply') with a resource ('a message'), and adds the distinguishing feature of quoting the original message. It also specifies scope: 'in the same chat and from the same account' and 'direct chats and groups', which clearly separates it from siblings like send_text (which sends without quoting) and edit_message (which modifies).

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 context: use this when you need to reply with a quoted message. It specifies the chat/account scope and that it works in both direct chats and groups. However, it does not explicitly name alternatives or state when NOT to use it (e.g., for a plain message without quoting, send_text would be appropriate). The guidance is clear but lacks explicit exclusion.

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, it reveals the code's TTL ('lives about 160 seconds') and a specific failure mode (`already_linked`). The open-world, non-idempotent nature is consistent with the description, though other potential side effects are not detailed.

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 each deliver distinct, useful information: purpose, code lifetime, and error condition. There is no filler, repetition, or extraneous detail.

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, the description adequately explains the return value, the code lifespan, and the error behavior. It could be slightly more explicit about prerequisites or side effects, but nothing critical 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?

The input schema already documents both `phone` and `accountId` with 100% coverage. The description does not add significant parameter-specific meaning beyond the phone-based linking context, so a baseline score 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 the resource (a pairing code) and the action: it links by phone number instead of QR code and returns an 8-character code. The contrast with QR code also distinguishes it from the sibling get_account_qr_code.

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 provides a clear usage context: use this tool when linking via phone number instead of a QR code. It does not explicitly name the alternative tool or list exclusions, but the 'instead of QR code' framing gives enough guidance.

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 specific context: 'Anyone holding the old link can no longer join with it.' This clarifies exactly what gets destroyed and the lasting consequence, which goes beyond the annotation. No contradiction with 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?

Two short, front-loaded sentences with no filler. The primary action and consequence are both stated efficiently, and every clause adds value.

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 description covers the core behavior and return value ('return a new one'), and the schema covers parameter meaning and the confirmation constraint. It could be slightly more complete by mentioning the sibling get_group_invite_link for read-only needs, but for a simple destructive action the description is sufficiently 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%, and the parameter descriptions are already clear about accountId, groupId, and the confirm requirement. The tool description does not add new semantic detail about these parameters, so the baseline of 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 uses a specific verb ('Revoke') and resource ('group's invite link'), and clearly states the result ('return a new one'). This distinguishes it from the read-only sibling get_group_invite_link, since it describes a mutating rotation action rather than just fetching a link.

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 use case is implied: use this when the current invite link should be invalidated and replaced. However, it does not explicitly contrast with get_group_invite_link or state when not to use it, such as when the user only wants to view the link without invalidating 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 readOnly/idempotent/destructive hints, so the description's main contribution is that multiple cards are delivered 'in one message'. It adds no additional behavioral context about responses, failures, or permissions, but it does not contradict 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?

The description is a single front-loaded sentence containing only the essential operation and constraint. Every word earns its place, and there is no filler or repetition of schema details beyond the useful cardinality note.

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 schema richly documents recipient formats, accountId, mentions, idempotencyKey, and replyTo, making the tool callable. However, with no output schema and no mention of return behavior or when to prefer this over sibling send tools, the free-text description leaves some context gaps beyond structured data.

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 83%, so the schema already documents most parameter behavior. The description adds only marginal value by framing the contacts array as 'one contact card, or up to 20', which mostly restates the schema's minItems and maxItems.

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 action ('Send') on a distinct resource ('contact card') with an explicit cardinality ('one contact card, or up to 20'). This clearly differentiates it from sibling tools like send_text, send_media, or send_location by payload type.

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 tool versus alternatives, and no exclusions or conditions are provided. The agent must infer from the tool name and sibling list that this is the right choice for contact-card payloads, rather than being told.

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 state this is not read-only, not idempotent, not destructive, and open-world, so the bar for added behavioral context is lower. However, the description adds no behavior beyond the core action: it does not mention delivery side effects, prerequisites like account connectivity, or the effect of idempotencyKey/retries. The description is not misleading, but it is also not informative about 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?

The description is a single focused sentence with no filler, and it front-loads the essential action. It earns its place, though the brevity leaves usage and behavior details uncovered.

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 9-parameter send operation with no output schema and no description of return values or delivery semantics. The single-sentence description is too sparse for an agent to fully understand the tool's behavior without relying heavily on the schema and sibling names.

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 67%, so most parameters already carry their meaning. The description adds only that place name and address are optional, which is already implied by the schema's required list. It does not clarify latitude/longitude semantics or add value for the recipient/account parameters beyond what the schema provides.

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?

Description uses a specific verb and resource: 'send a map pin'. This clearly defines the action and differentiates it from siblings like send_text, send_media, send_contact, and send_poll. The title alone is generic, but the description 'map pin' makes 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 intended use is implied by the tool name and the phrase 'map pin', but there is no explicit guidance on when to choose this over other send_* siblings, nor any exclusions or conditions. An agent must infer the use case from context rather than being told when this tool is appropriate.

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 indicate readOnly=false and destructive=false, so the mutation nature is known. The description adds useful behavioral context: the file must be at a public URL and wuapi downloads it, which clarifies that the caller does not upload bytes. It does not describe side effects or return behavior, but the annotations lower the burden.

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 with no filler. The core action, supported types, and the key download behavior are front-loaded, making it easy for an agent to parse quickly.

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?

Given the rich schema covering all parameters and constraints (URL pattern, size limit, recipient formats, idempotency), the short description is adequate for the core call. It could mention that this sends a WhatsApp message or what the response contains, but no output schema exists and the schema carries most of the load.

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 fully documents all 11 parameters. The description adds little beyond restating 'optional caption' and the media types already present in the enum. This meets the baseline but does not exceed it.

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 ('Send') and resource ('a file from a public URL'), and enumerates the supported media types (image, video, audio, voice note, document, sticker). This clearly distinguishes it from siblings like send_text, send_location, send_contact, and send_poll.

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 conveys a clear context: use this tool to send media files from a public URL, and notes that wuapi downloads the URL itself. However, it does not explicitly mention alternatives or when not to use it, leaving the choice versus send_text or post_story 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 indicate it is a write operation (readOnlyHint=false) and not destructive or idempotent. The description adds valuable context about the outcome (votes arrive via webhooks and poll tally), which is beyond what annotations provide. It does not contradict 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?

The description is two sentences with no redundancy. It front-loads the core purpose and the key constraint, then adds a useful behavioral note. Every word 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 simple send action with no output schema, the description adequately covers what the tool does and the expected result. It does not mention prerequisites like account connection or error handling, but these are likely implied by the broader API context. The behavioral note about webhooks and tally adds completeness.

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 all parameters are documented in the schema. The description adds minimal new information beyond restating the option count range, which is already in the schema. It does not clarify parameter formats or relationships beyond what the schema provides.

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 the action (send a poll) with a specific constraint (2 to 12 options), which distinguishes it from sibling messaging tools like send_text or send_media. It also adds the behavioral detail about how votes are delivered, reinforcing the unique purpose.

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 does not explicitly say when to use this tool versus alternatives or provide exclusion conditions. Usage is implied by the tool's name and purpose, but there is no explicit routing guidance like 'use instead of send_text when a poll is needed.'

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 idempotency and non-destructiveness, so the description only needs to add context. It adds the default behavior ('every unread inbound message wuapi stores'), the blue-tick effect, and the inbound-message constraint, which go beyond the schema and 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?

One concise, front-loaded sentence with no filler. It communicates purpose, scope, and default behavior efficiently, and every clause 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?

The description, combined with the complete parameter schema and annotations, provides enough information for an agent to invoke the tool correctly. It does not describe return values, but no output schema exists and the lack of return-value detail is not critical here.

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. The description adds value by explaining that messageIds is optional and defaults to every unread inbound message, clarifying the relationship between the parameter and the tool's behavior beyond the schema text.

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: send read receipts (blue ticks) for inbound messages in a chat. It clearly distinguishes from sibling mark_chat_read by focusing on receipts rather than chat read state, and the 'given ids or every unread' scope makes the behavior 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 gives clear context: use when you want to send blue ticks for inbound messages, optionally for specific ids or for all unread ones. It does not explicitly name alternatives or exclusions, so it misses the top score, but the intended use case is evident.

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 adds meaningful behavioral context beyond the annotations by disclosing the asynchronous queueing behavior and the return shape (id and queued status). Annotations already convey read-write and non-idempotent traits, so the description supplements rather than repeats 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?

Three sentences with no fluff. The purpose is front-loaded, behavior is stated next, and the usage caution is last. Every sentence 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 sending tool with 100% schema coverage, no output schema, and annotations covering safety traits, the description covers the essentials: what it sends, the async behavior, and the expected result. It could mention idempotency or retries, but that is already documented in the idempotencyKey parameter.

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 baseline is 3. The description adds little beyond the schema—'contact, group or channel' is already covered in the 'to' parameter description, and WhatsApp formatting is mentioned in the schema. The description does not compensate for or extend parameter meaning significantly.

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 verb ('Send') and resource ('text message') with the source ('linked number') and target types ('contact, group or channel'). This clearly distinguishes it from sibling tools like send_media, send_location, send_contact, and send_poll.

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 provides clear usage context: messages are queued and sent at the account's pace, and it warns to send only to people who expect it. It does not explicitly name alternatives or exclusion conditions (e.g., when to use reply_to_message), so it slightly misses the top score.

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 establish that the operation is mutating, non-destructive, and idempotent, lowering the burden on the description. The description adds that `active: false` means paused and mentions resuming, but it does not disclose whether events are replaced or merged, whether URL updates require an active endpoint, or what side effects occur.

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 a single concise sentence with the action front-loaded. It avoids repeating the title or schema details and every phrase adds meaning.

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 tool has four parameters, no output schema, and is a mutating operation. The description plus schema covers the parameter names, but the description does not state update semantics (partial vs full replacement), return behavior, or any required sequence, so it is adequate for selection but not fully self-sufficient.

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 50%, so the description needs to compensate. It names the three mutable parameters (url, events, active) and explains the pause/resume semantics of `active`, but it does not clarify URL format requirements or how events are updated; those details remain in the schema or are absent.

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 ('Change') and names the resource ('a webhook endpoint') along with the exact operations: changing URL, changing events, pausing, and resuming. This clearly distinguishes it from sibling tools like create_webhook, list_webhooks, and delete_webhook.

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?

'Change a webhook endpoint's...' gives clear context that this tool is for modifying an existing endpoint, not creating or deleting one. It does not explicitly name alternatives or state when not to use it, so it falls just short of full explicit guidance.

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