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 declare this is a non-read-only, open-world, non-idempotent write. The description adds real behavior beyond that: the calling account becomes owner, and participants whose privacy settings block being added receive an invite code instead of being added. This fallback behavior is non-obvious and usefully disclosed, though it does not cover permissions or partial-failure 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?

Two tight sentences with zero filler, front-loading the primary action and then the conditional community case and the invite-code fallback. Every clause carries information an agent needs.

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 mutation tool with no output schema, the description plus annotations and fully documented parameters give an agent enough to call it correctly, and 'see the result' justifiably defers the invite-code detail to the response. Minor gaps remain around required permissions and whether the call is safe/irreversible.

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 all five parameters including idempotencyKey and communityId are already documented with strong per-field detail. The description only adds the conditional meaning of communityId ('inside a community when given'), which is marginal beyond the schema's own explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create a WhatsApp group') and adds meaningful scope: the account acts as owner, and the group lands inside a community when communityId is passed. It distinguishes itself from community/channel siblings implicitly, though it never names the adjacent tools (e.g. manage_community, manage_group_settings) it should not be confused with.

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 by the create semantics plus the conditional 'inside a community when communityId is given'. There is no explicit when-to-use/when-not guidance and no routing to alternatives for existing groups or communities, so an agent must infer the boundaries from the sibling list.

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, non-obvious behavior that annotations cannot convey: the secret URL is a credential and is NOT returned by this tool, so the user must retrieve it from the dashboard. It also documents the accepted payload formats (JSON {text} or plain text, no API key). This is exactly the kind of context annotations (readOnlyHint=false, idempotentHint=false) leave uncovered.

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, both load-bearing, with the core behavior front-loaded and the credential caveat following. No filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create tool with no output schema, the description anticipates the most likely agent confusion — expecting the returned URL — and explains where it actually comes from. Combined with the annotations covering the mutation profile, nothing essential to calling this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (accountId, name, to) are already fully documented in the schema, establishing a baseline of 3. The description reinforces the notion of a 'fixed' destination but adds no new syntax or format meaning 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 uses a specific verb+resource and explains the mechanism precisely: it creates a secret URL that turns inbound POSTs into a WhatsApp message to one fixed destination. It does not explicitly distinguish itself from the sibling create_webhook (a separate webhook family), so an agent must infer the incoming-vs-other distinction from the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the mechanics of the POST-to-message flow make the use case reasonably clear, but there is no explicit when-to-use guidance and no named alternative among the many webhook siblings (create_webhook, update_incoming_webhook, etc.). No prerequisites beyond the accountId reference 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 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?

Annotations cover the mutation safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, and the description clears it by disclosing a non-obvious behavior: the signing secret is deliberately withheld from the tool response and must be retrieved out-of-band from the dashboard. That is exactly the kind of consequence an agent must relay to a user. It does not cover retry/delivery semantics or what the call returns, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, and the second sentence carries the critical secret-handling caveat rather than filler. The parenthetical with the dashboard path is slightly dense but each clause is actionable, so no material waste.

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 compensates on the single most dangerous gap — that the secret is not returned — and the schema carries the parameter contract. It omits what the successful response looks like (endpoint id, etc.), which an agent would need to chain into update_webhook or delete_webhook, so it is strong but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (url, events, projectId, idempotencyKey) are already fully documented in the schema, including the https pattern, the 2xx/10s contract, and the idempotency behavior. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Register a public https URL to receive events as signed POST requests." That is unambiguous about what the tool does and what it produces. It does not, however, name or distinguish itself from the sibling mutators update_webhook/delete_webhook/list_webhooks, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied — you call this to create a new endpoint — but there is no explicit guidance on when to use create_webhook versus update_webhook for an existing endpoint, nor any precondition stated (e.g. one endpoint per event set). It adds a practical workflow note about the signing secret, which is useful context but not 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 declare destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context: it specifies the deletion target (linked devices), clarifies that wuapi-stored messages survive and remain readable via list_messages, and warns that the action cannot be undone on devices. This enriches the safety profile, though auth requirements or error behavior are not covered.

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 the action. The second sentence delivers high-value consequences (stored messages retained, irreversibility) with zero waste.

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 chat-deletion tool with rich annotations and 100% schema coverage, the description supplies the critical behavioral nuance—device vs stored copy and irreversibility—so an agent can call it correctly. It does not route between siblings like archive_chat, but that is a minor gap given the annotation coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines accountId, chatId, confirm, and deleteMedia. The description adds no parameter-level syntax or constraints beyond what the schema provides; 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?

States a specific verb 'Delete' and resource 'a chat', specifies the scope 'from the account's linked devices (the phone and WhatsApp Web)', and distinguishes the local wuapi copy by noting messages are kept and readable with list_messages. An agent can tell it apart from delete_message or archive_chat without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when/when-not guidance or alternatives are named in the description. It only implies deletion is a device-local operation and that stored messages remain accessible. The schema's confirm parameter carries the consent condition, but the tool description itself lacks usage routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real context beyond them: the URL stops working immediately ('at once'), clarifying that the effect is instantaneous and affects any caller still using it. It does not address auth/ownership requirements, but that is carried by the schema's confirm field.

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, zero waste, with the core action and its immediate consequence front-loaded. Nothing redundant with the title or schema.

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, no-output-schema tool whose annotations already cover safety and idempotency, the description plus schema give an agent what it needs to call correctly. A minor gap is the absence of explicit guidance on when deletion is preferable to updating/disabling the webhook.

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%; the confirm field already documents the mandatory-true confirmation and the incomingWebhookId points to list_incoming_webhooks. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Delete an incoming webhook'), and the resource qualifier 'incoming' distinguishes it from the sibling delete_webhook (outgoing webhook). It stops short of naming any alternative explicitly, so it is clear but not sibling-routing.

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 phrase 'for whatever still calls it' implies the intent (stop URL traffic), but there is no explicit when-to-use guidance or comparison against update_incoming_webhook (which could disable/rotate without deleting) or list_incoming_webhooks. Usage is implied rather than stated.

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?

Adds substantial context beyond the annotations: no file re-upload, recipients see it as forwarded, not_forwardable responses for polls/events/reactions/view-once/deleted and contact stories, and a returned list of queued messages to verify with get_message. Annotations cover mutation/open-world, so the bar is lower, but the failure-mode disclosure is genuinely valuable. Slightly short of 5 only because error/permission context outside the not_forwardable cases is not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scope, then tapers into edge cases; every sentence carries a distinct constraint. It is dense and long, but nothing is redundant enough to cut meaningfully.

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 no output schema, the description explains the return shape (one queued message per chat in the order of `to`) and how to verify it. Content-type boundaries, dedup behavior, and the sibling alternative are all covered, leaving no gap an agent needs before calling.

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 messageId, to, and idempotencyKey including formats and the 5-item/forwardedManyTimes limits. The description reinforces the 'up to 5 chats' and forwardedManyTimes constraints but adds no syntax or meaning beyond the schema, so the baseline 3 is correct.

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 (Forward) and resource (a stored message, received or sent) with scope ('to up to 5 chats of the same account'). It explicitly distinguishes itself from the send tools, so an agent can route between forwarding existing content and sending new content without inspecting siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative explicitly ('To label new content as forwarded, use a send tool with `forwarded: true` instead') and enumerates which content types are non-forwardable, giving the agent clear when/when-not boundaries. The forwardedManyTimes one-chat-per-call constraint further clarifies selection.

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

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

Annotations already 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 declare readOnly/idempotent/non-destructive, so the bar is lowered, yet the description adds genuine behavioral semantics beyond them: a missing state field means 'unknown', not `false`, and a chat with no stored message yields a `not_found` result. These are real disclosure points an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the resource and scope, then adds the unknown-vs-false caveat and the not_found behavior in compact form. The final sentence ('A chat wuapi stored no message of answers `not_found`') is grammatically awkward, slightly reducing clarity, but no padding 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?

With no output schema, the description carries the return-value burden and does so by enumerating the relevant fields, the unknown-field semantics, and the failure case. It is largely complete for a single-item read; pagination/format detail is not applicable 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 description coverage is 100% and both parameters (accountId, chatId) are richly documented, including chatId formats. The description adds no parameter-level detail beyond the schema, so 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?

States a specific verb+resource: retrieves one conversation and enumerates what it returns (name, latest message in full, unread/pinned/archived/muted state). The phrase 'One conversation of an account' distinguishes it from the collection-oriented sibling list_chats, though it does not name the 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?

Usage is implied rather than stated: it retrieves a single chat, and the note that a chat with no stored message answers `not_found` gives a useful edge-case context. However, there is no explicit when-to-use versus get_message/list_chats/get_group, nor any prerequisite guidance beyond what the schema provides.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real behavior: it returns the stored fields (saved name, profile name, username, picture id) and returns `not_found` for unsaved numbers. It does not mention auth requirements or rate limits, but for a read tool with full annotations this is solid.

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 tight sentences with no filler; the resource identity is front-loaded and the sibling contrast is relegated to the follow-up clause. Dense but each 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?

There is no output schema, so the description should hint at the return shape — it does so by enumerating the returned contact fields. Combined with the not-found failure mode, an agent has enough to call and interpret it, though a fuller return description would be ideal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (accountId, contactId) are already fully documented, including the E.164 and `lid:` forms. The description restates the identifier forms without adding syntax or edge-case detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('One contact of an account's address book') plus the accepted identifier forms, and explicitly contrasts scope with the sibling lookup_contacts. An agent can distinguish this from lookup_contacts without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative (lookup_contacts) and the condition that selects it: a number not saved on the phone yields `not_found` here, while lookup_contacts queries WhatsApp for any number. That is an explicit when-not plus alternative.

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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond structured data: the URL is deliberately omitted from the response, which prevents a wasted call for an agent seeking the secret endpoint. It stops short of describing not-found behavior or the full field set.

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 tight clauses with zero filler; the returned-fields summary comes first and the key exclusion ('Never its URL') is stated bluntly at the end where it will be read.

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 annotations carrying the safety profile and no output schema, the description carries the return-shape burden and does list the salient fields. It is nearly sufficient; the only real gap is the absence of any contrast with get_webhook, which an agent scanning a large sibling set could confuse it with.

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?

Single parameter with 100% schema description coverage, so the schema fully documents the id and where to source it. The description adds nothing about the parameter, which is acceptable when 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?

States a specific verb (get) and resource (one incoming webhook) and enumerates the fields returned: number, destination, enabled state. 'One' distinguishes it from list_incoming_webhooks, but it never contrasts itself with the sibling get_webhook, so the reader must infer that 'incoming' is the distinguishing qualifier.

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 when-to-use statement and no named alternatives. The closest thing to guidance is the negative constraint 'Never its URL', which implicitly tells the agent not to call this for the webhook URL but never says which tool to use instead. The schema, not the description, is where the link back to list_incoming_webhooks lives.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it lists possible status values, explains that failed messages include an error, and describes the media download default and the direct URL behavior. It does not cover auth requirements or error cases beyond status='failed'.

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, front-loaded with the core return information and then the media behavior. Every sentence adds useful detail without 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?

With no output schema, the description carries the burden of explaining return values, and it does so by naming statuses, content, error, and mediaFile. Annotations cover the read-only safety profile. It is nearly complete, though it omits not-found or auth error behavior.

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 meaning beyond the schema for fetchMedia by saying it downloads media once and returns a direct mediaFile.url that needs no API key. It adds little for messageId beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this returns a single message with its status, content, error, and media details. The singular 'One message' distinguishes it from list_messages, but it does not explicitly name or contrast with any sibling tool. This is clear but lacks explicit sibling 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 gives no guidance on when to use get_message instead of list_messages or other retrieval tools. It explains the media fetch behavior but does not provide usage context or alternatives. An agent must infer 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 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 readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond those: the signing secret is never returned, which sets expectations about what the response will and won't contain. It stops short of noting error cases like unknown or unauthorized ids.

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, front-loaded with what is returned and closed with the key negative constraint. Every clause carries information with zero padding.

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 and a single documented parameter, the description adequately conveys the returned shape (URL, events, active) and the notable omission (signing secret). It is complete enough to call the tool correctly, though it could mention error behavior for missing endpoints.

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 parameter already documents its source ('from list_webhooks'). The description adds no additional parameter meaning, so the baseline 3 applies since the schema carries the full burden.

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 (one webhook endpoint) and enumerates the salient fields it returns (URL, events, active status), so an agent knows this is a single-endpoint fetch. It does not explicitly name the sibling verbs (list_webhooks vs update_webhook) to distinguish use, but the 'one endpoint' scoping makes the get-vs-list distinction clear enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives such as list_webhooks for enumeration. The only routing hint is in the schema's parameter text ('from list_webhooks'), which the description itself does not leverage.

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 declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral context: result ordering, the inclusion scope, and the important caveat that a missing state field means 'unknown to wuapi', not false. It does not cover pagination behavior or result volume limits beyond the schema's cursor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool returns before the filtering and routing guidance, and every sentence carries information. The first sentence is dense and semicolon-packed, which slightly slows parsing, but there is 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 compensates by enumerating the returned fields and the state semantics. It also names the downstream tool for reading a conversation. The only gap is pagination/result-set behavior, which is left to the cursor parameter's schema text.

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 seven parameters are already documented with enums, bounds and defaults. The description restates the filter options and the meaning of q, but adds little syntax or semantics the schema does not already carry, 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?

States a specific verb and resource ('An account's conversations') plus the ordering ('newest message first') and the exact payload fields returned. It also carves out scope ('Only chats wuapi stored a message of'), which cleanly separates it from get_chat and list_messages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit filter guidance (by archived, unread or type, or search with q) and routes the agent onward: 'Read a conversation with list_messages and the chat's id as chatId.' No explicit when-not-to-use statement, but the sibling routing is clear enough to select correctly.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context: results are ordered by saved name and come from stored wuapi data rather than a live lookup, which explains staleness and the absence of `about`/`deviceCount`.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core identity, then the return fields, then the sibling routing. Dense but every clause carries information; only minor cost is a somewhat crammed middle colon-list, so not a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description adequately describes the result shape and ordering. Pagination is handled by cursor/nextCursor in the schema. Good coverage for a list tool, though it stops short of stating default/max page behavior explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents q, limit, cursor and accountId thoroughly (the schema's `q` description is actually broader than the summary in the prose). The description adds no new parameter syntax or format detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (the account's address book synced to wuapi) and its ordering, and enumerates the returned fields (id, number, savedName, profile name, username, picture id). It explicitly distinguishes itself from list_chats and lookup_contacts, so an agent can identify it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names two alternatives and the exact conditions that select them: chatted-with people live in list_chats, and `about`/`deviceCount` require lookup_contacts which asks WhatsApp live. Includes the when-not ('only contacts the phone saved') and the search entry point via `q`.

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/openWorldHint, so the safety profile is covered. The description adds genuine value beyond them: 'read live from WhatsApp' signals fresh (not cached) data, and it explains the communityId/default output semantics. It doesn't mention pagination/latency behavior, so not a full 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the primary purpose front-loaded, then output-field semantics, then the sibling pointer. Every clause earns its place, 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?

No output schema exists, so the description must carry return-value meaning; it does cover the notable output fields (participant count, communityId, default). It stops short of describing the paginated envelope (nextCursor), which the cursor param implies but the description never states, leaving a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so limit, cursor, and accountId are already documented in-schema. The description adds no parameter syntax or constraints beyond what the schema provides, which is the correct baseline of 3 here.

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 (list) and resource (groups) with explicit scope: 'Every group the account is in, read live from WhatsApp.' It also distinguishes itself from the sibling get_group, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the sibling alternative and the condition selecting it: 'Use get_group for the participants.' This gives clear routing context, though it doesn't spell out when-not to use list_groups (e.g., cost/latency of listing everything) or broader trade-offs.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-redundant behavior: the URLs themselves are never returned (a secret-redaction guarantee) and it enumerates the returned fields, which matters 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?

Three tight clauses, front-loaded with the resource definition before the return/redaction facts. No wasted sentences, though the definitional opener takes more space than a bare verb would.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully compensates by naming the returned fields and the redaction rule; annotations cover the safety profile and the schema covers parameters. Only pagination/workflow context is thin, but limit/cursor in the schema make that 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 coverage is 100%; limit, cursor, and projectId are all fully documented in the schema. The description adds no parameter-level detail (e.g., no note on pagination semantics), 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 names the resource and defines it precisely ("secret URLs that send a WhatsApp message from one of your numbers to one fixed contact or group"), and states which fields are shown. It doesn't explicitly contrast with list_webhooks (outgoing) or get_incoming_webhook (single), so differentiation is left to the reader, but the resource is 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the sibling alternatives (get_incoming_webhook for one, list_webhooks for outgoing, create/update/delete_incoming_webhook for other operations). The agent must infer that this is the enumeration 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 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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the non-obvious ordering fact ('newest first') and that both sent and received are returned, but says nothing about pagination limits or result volume beyond what the cursor/limit schema already implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the resource and ordering front-loaded, and the sibling pointer last. Slight awkwardness in the opening ('Messages wuapi stored') but 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 paginated read-only list tool whose annotations carry the safety profile and whose schema covers 83% of parameters, the description says enough to call it correctly. Only return-shape/pagination expectations beyond the cursor field are left implicit.

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% (above the 80% threshold), so the baseline is 3. The description echoes three filter dimensions (account, chat, direction) that the schema already documents, and adds no syntax or format detail for limit, cursor, or projectId.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Messages ... stored') with scope ('newest first: sent and received'), and names a sibling (list_chats) to clarify what it is not. It stops short of distinguishing itself from get_message, but an agent can still tell the general purpose without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Filter by account, chat and direction to read a conversation' gives a clear use context, and 'Use list_chats to see which conversations an account has' points to the prerequisite/alternative source of chat ids. There is no explicit when-not guidance, so it falls 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?

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context not in the structured fields: the 1-to-50 batching limit and the linked-device username-resolution limitation that will silently fail otherwise.

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 returned-fields summary front-loaded and the key limitation second. The opening clause is grammatically muddy ('About text ... asked from WhatsApp'), which slightly hurts readability, but nothing 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?

There is no output schema, and the description compensates by naming the returned fields, which is the right move. Combined with 100% schema coverage and complete annotations, an agent has enough to call this correctly; only the relationship to overlapping siblings is left implicit.

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 (accountId, contactIds) are fully documented in the schema, including the `lid:<digits>` syntax. The description restates the 1-to-50 range and the number/lid lookup form but adds no new parameter-level 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 (look up) and resource (contacts) and enumerates exactly which fields come back (about text, picture id, WhatsApp username, business name, device count), which goes well beyond the title. It also draws a boundary against one sibling by noting saved names live in list_contacts, though it never addresses get_contact, which overlaps in scope.

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 concrete invocation guidance: contacts must be resolved by number or `lid:` id, usernames cannot be searched because a linked device cannot resolve an @username, and it points to list_contacts for saved names. It stops short of saying when to prefer this over get_contact or check_numbers, so there is still inference left 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 cover readOnly/idempotent/openWorld/destructive=false, so the bar is lower; the description still adds value with 'Nothing is changed', visibility caveats ('when the account can see it'), and explicit not_supported failure modes for two actions. It leaves pagination behavior for limits/cursors undescribed beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose followed by a scannable action list; every bullet earns its place. The opening sentence is dense and slightly run-on when it crams the sticker pack and catalog order into the same clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema the description carries the return-value burden, and it does describe what each action yields (picture URL, business address/email/categories/hours, prefilled text, directory, sticker pack contents, order products/quantities/totals). Pagination semantics for bots are the main remaining 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% so the baseline is 3, but the description goes further by tying each action to its relevant inputs (resolve_link's link/kind, order's token/orderId, bots' paging) and explaining what the resulting identifiers refer to. It does not add syntax or format details 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 opening sentence names a specific verb (Read) plus resource (WhatsApp details) and scopes it to a linked number, then enumerates all six actions with a one-line gloss of each. An agent can tell this apart from siblings like lookup_contacts or get_message without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Per-action entries imply when each mode applies and add per-action conditions (e.g. resolve_link 'Fails with not_supported when WhatsApp does not offer it to the account', bots 'as the account sees it'). It does not explicitly name a sibling alternative or state when NOT to use this tool, 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real context by stating the consequence of block (the contact can no longer message or call) and that confirm must be set, which goes beyond the structured hints.

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?

Purpose is front-loaded in one sentence, followed by a tight action list where each entry earns its place. 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?

No output schema exists, and the description does name the list return shape (number and lid: id), which is useful for a read action. Pagination via limit/cursor is left to the schema, and block/unblock outcome descriptions are minimal, so it is strong but not exhaustive for a 6-parameter multi-action 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?

Schema description coverage is 100%, so every parameter (limit, cursor, confirm, accountId, contactId) is already documented. The description only restates the confirm:true requirement and does not add syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (the account's WhatsApp block list) plus a clear verb set, and enumerates the three actions (list/block/unblock) with their effects. An agent can distinguish this from siblings like delete_chat or manage_privacy without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The action breakdown gives clear context for what each mode does and when it applies (e.g. blocking stops messages/calls, unblocking reverses it). It stops short of naming alternatives or explicit exclusions, but the routing between the three actions is unambiguous.

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 idempotent=true, destructive=false, readOnly=false, so safety is covered. The description adds useful context beyond that: org-key scoping and the fact that update returns the resulting branding. It does not flag that the addon_required condition for the footer lives in the schema, but that is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose sentence, then a compact two-item action list. Every sentence contributes; only the slightly prose-heavy first line keeps it from a 5.

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 correctly notes that update returns the branding. For a 6-parameter multi-action tool with full schema coverage and annotations covering safety, this is nearly complete; only the addon gate for hideWuapiBranding is left to the 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%, so every parameter is already documented in the schema, including null-clearing semantics and the addon requirement. The description's field list (display name, logo, accent color, support link, footer) merely maps to those params without adding format or behavior detail. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (invitation branding) and enumerates the exact surface it controls — invitation page, email, display name, logo, accent color, support link, footer. An agent can distinguish it from sibling tools like manage_profile or manage_privacy without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The action list defines when to use get vs update and what each returns. 'Organization keys only' gives the scope prerequisite. It does not name a sibling alternative, but the tool is distinct enough that this is minor.

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, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavior beyond that: it distinguishes the follow/unfollow/mute/unmute state changes, notes create returns the channel, clarifies react removes a reaction with an empty string, and explains that mark_viewed merely counts the account as a viewer. Auth requirements are only implied through the schema's accountId note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the resource definition and the sibling hand-off before the action list, and every bullet carries information rather than repeating the enum names verbatim. It is long, but the length is justified by eleven distinct actions; only marginally more verbose than necessary.

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 13-parameter, multi-action tool with no output schema, the description covers each action's semantics and gives partial return shape for get, list_messages and create (fields, ordering, counts). It stops short of describing list pagination behavior or return shapes for the remaining actions, which is the main remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including per-action requirements, pagination and the idempotency contract; baseline 3 applies. The description contributes only a little extra meaning, chiefly the `...@newsletter` id format and the `to`-field routing for posting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise definition of the resource (WhatsApp one-to-many broadcast channels, ids ending in @newsletter) and enumerates every supported action with a verb-plus-resource phrasing. It also draws a sharp boundary against the sibling send_text/send_media tools for posting, so an agent can tell it apart without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the one ambiguous case to alternatives: 'To post to a channel the account administers, use send_text or send_media with `to` set to the channel id.' Each action bullet states its precondition or scope (e.g. preview_invite 'without following it'), leaving little 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, yet the description adds real behavioral context: create returns the community, unlink leaves the group intact, and admin rights are required for linking. It does not detail error modes or pagination behavior beyond the 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 concept explanation is front-loaded before the action list, and each bullet earns its place. Slightly longer than strictly necessary for a single-tool definition, but no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers a five-action mutation tool with no output schema: it explains return shape for create, list semantics, and the persistence guarantee for unlink. Missing only edge-case behavior (what happens to linked groups when a community is deleted), which 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 coverage is 100%, so the baseline is 3, but the description adds cross-cutting semantics the schema cannot: which params each action needs (name for create, groupId for link/unlink, communityId for the rest) and where communityId comes from.

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 set and resource: creating, listing, linking, unlinking WhatsApp community groups, with each action enumerated and defined. It explicitly distinguishes itself from siblings by naming get_group and create_group and their respective roles.

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?

Routes the agent explicitly: use get_group to read a community, use create_group with `communityId` to make a nested group, list_groups reveals `communityId`. It also states the precondition that the account must admin both groups for link/unlink.

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 (idempotent, non-destructive, open-world), the description discloses meaningful behavior: add/remove are synced to the phone, list reads stored data without contacting WhatsApp, get_file lazily fetches on first use, and re-adding an existing favorite is a no-op. These are non-obvious operational traits that the structured fields do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary is front-loaded, and the per-action bullet structure makes the variants scannable. It is somewhat long, but nearly every sentence carries operational detail rather than 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 an 8-parameter, no-output-schema tool, the description covers per-action behavior and even sketches the list return shape (media.url, media.downloaded, animated/emojis null until fetched). It is close to complete, with only minor gaps around error cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters in detail. The description adds the useful mutual-exclusion constraint for add (messageId or uploadId, 'one of them'), but otherwise largely restates what the schema provides, 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 states a specific resource (favorite stickers / the star tab of the sticker picker) and enumerates the exact operations (list, get_file, add, remove). It distinguishes itself from superficially similar siblings like star_message by scoping to favorited stickers specifically.

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?

Each action carries clear context: list is local-only (no WhatsApp call), get_file needs the account ready, add requires either messageId or uploadId. It clearly routes usage per action, though it does not explicitly compare against siblings such as star_message or send_media.

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 it as a write-capable, non-idempotent, open-world tool. The description adds real behavioral context beyond them: the admin prerequisite, the surprise that `join` may silently become a pending request, and per-action result semantics ('Returns the group id', 'Each result says whether it worked').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded summary sentence followed by a tight action list; each bullet earns its place by naming the action and its outcome. Slightly verbose in the opening clause but no wasted 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 an 8-parameter multi-action tool with no output schema, the description covers every action's purpose and the key gating conditions (admin, approval). Return values are only loosely described, but no output schema exists to compensate, so this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter and its required actions. The description adds only marginal meaning (which action maps to which concept) beyond that baseline.

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 resource (groups) and enumerates the exact five operations (preview_invite, join, list_requests, approve_requests, reject_requests). An agent can distinguish this from siblings like add_group_participants or get_group_invite_link without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the context for each action, including that joining an approval-gated group becomes a pending request and that list/approve/reject require the account to be an admin. It does not, however, name any alternative tool or give explicit when-not-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 destructive and idempotent behavior, but the description adds substantial operational detail: delete_picture removes the picture and needs confirm: true only after user consent; update returns the group; set_picture returns the picture; and set_picture downloads the image from an https URL.

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 front-loaded with the tool's overall purpose, then uses a concise bulleted action list to separate the three operations. Every sentence carries relevant information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, multi-action, destructive tool, the description covers the actions, their required conditions, return values, and input constraints. With the schema and annotations carrying safety and parameter details, 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?

Schema description coverage is 100%, so the schema already documents all 12 parameters individually. The description adds useful action-level grouping of fields but does not introduce much semantic detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.