WhatsMCP

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds the membership/admin prerequisite, which is behavioral context beyond annotations. However, it does not disclose side effects (e.g., notifications to added members), error conditions, or any rate limits. The addition is useful but limited.

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 primary action, followed by a key constraint. No fluff or repetition. 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?

Given the tool's moderate complexity, complete schema (100% coverage), output schema present, and annotations covering mutation, the description is adequate. It includes the essential prerequisite for successful invocation. It could optionally mention what happens on failure or whether adding members triggers notifications, but those are not critical for a correct call. The description covers the essential information.

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 already documented (phone numbers/JIDs format, group JID reference, account reference). The description does not add new semantic meaning about parameters beyond what the schema provides. It does clarify the member format ('by phone number or JID') but that is already in the schema description. 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: 'Add members to a WhatsApp group by phone number or JID.' This is a specific verb-resource pair that distinguishes it from siblings like wa_remove_participants or wa_promote_participants. 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?

The description provides a clear prerequisite: 'The account must be a member (and, for private groups, an admin).' This tells the agent when the tool can be used. However, it does not explicitly name alternatives or say when NOT to use it, though the distinction from removal/promotion is implicit. The prerequisite is valuable but could go further in 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 this is a mutating, non-idempotent, non-destructive operation. The description adds behavioral context beyond that: the permanent effect ('They can no longer call or message this account') and the output behavior ('Reports who was blocked — their number, the name this account's address book has for them, and the country the number belongs to'). This gives the agent useful information about consequences and return value.

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 wasted words. The primary action is front-loaded ('Block a contact on one of your WhatsApp accounts'), followed by the effect and then the output details. Every sentence earns its place, and the structure is clean and scannable.

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 tool, the description is complete. It states the purpose, the effect, and what the response contains. Annotations cover the mutation flags, the output schema describes the return structure, and the schema covers parameters. There is nothing missing that an agent needs to call this tool correctly — the description effectively conveys the action and its consequences.

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% — both parameters (jid and account_id) are explained in the schema. The description does not add any parameter-specific meaning beyond what the schema already provides. It mentions output details (number, name, country) but that relates to the response, not input parameters. Per the baseline rule, a 3 is appropriate when the schema covers parameters and the description adds no further parameter guidance.

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 — 'Block a contact on one of your WhatsApp accounts' — with a clear verb and resource. It distinguishes itself from siblings like wa_unblock_contact (which undoes the block) and wa_list_blocked (which lists blocked contacts). The effect is also described: 'They can no longer call or message this 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 when to use it: when you want to prevent a contact from calling or messaging. However, it does not explicitly mention alternatives or when-not-to-use. For example, it doesn't say 'use wa_unblock_contact to reverse' or 'use wa_list_blocked to view blocked contacts.' The context is clear but no explicit routing to alternatives 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 this a mutation (readOnlyHint=false) that is neither idempotent nor destructive, and the description's 'Create' wording is consistent with them. The description adds value by disclosing the operation's outcome — the new group's JID and an invite link — and, more usefully, plumbing that JID into wa_send_message's 'to' parameter. No contradiction exists between description 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 totaling roughly 30 words, with the core purpose front-loaded in sentence one and the return-value usage in sentence two. There is no filler, no restatement of the tool name, and no redundant echo of the schema's parameter 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?

The output schema exists, so return semantics do not need to be re-explained; the description's mention of the JID and invite link plus the wa_send_message plumbing is a bonus. Combined with 100% parameter documentation and mutation annotations, an agent has everything needed to invoke it correctly. The only notable absence is explicit sibling routing, which belongs to usage_guidelines rather than completeness.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema itself documents max 25 characters for name, E.164/JID formats and the 'do NOT include your own number' caveat for members, and account_id's provenance via wa_list_accounts. The description's 'name and initial members' only echoes the schema and adds no new parameter meaning. No compensation above baseline is needed.

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 the verb 'Create' tied to a precise resource — 'a WhatsApp group with a name and initial members from one of your accounts' — which clearly separates it from siblings like wa_join_group (joining an existing group) and wa_add_participants (modifying an existing group). The 'from one of your accounts' scope removes ambiguity about whose group is being created.

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 purpose sentence conveys clear context: this is for creating a new group with initial members from the agent's own account, and the phrase 'initial members' implies that later membership changes belong to wa_add_participants/wa_remove_participants. However, no alternative tool is ever named, and there is no when-not-to-use guidance despite roughly eight closely related group siblings. The JID follow-up tip ('use it as wa_send_message's to') does provide some downstream usage direction.

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 (destructiveHint=true, idempotentHint=false), the description discloses important behavioral details: it removes every other member, leaves the group, requires admin privileges, and explains the platform limitation behind this approach. This is exactly the kind of context an agent needs to anticipate side effects.

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

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

The description is three tight sentences with the action front-loaded, followed by the operational mechanics and a necessary caveat. Every sentence contributes information; there is no 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 destructive and idempotency annotations plus an output schema already provided, the description covers the non-obvious aspects: admin requirement, member removal, and the leave step. It could additionally note irreversibility or member notifications, but these are minor given the existing annotations and 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 description coverage is 100% and the schema already provides provenance hints ('as returned by wa_list_groups', 'as returned by wa_list_accounts'). The tool description adds no 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 opens with a specific verb and resource ('Delete a WhatsApp group') and precisely defines what that means in WhatsApp terms: remove every other member and leave. This distinguishes it clearly from sibling tools like wa_delete_message and wa_delete_webhook, which operate on different resources.

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 clearly communicates the context for use: the account must be a group admin, and because WhatsApp has no true group-delete, this tool's approach is to empty and exit. It does not explicitly contrast with alternatives like wa_remove_participants or wa_leave_chat, but the intended use is unmistakable.

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 valuable context by explaining that this is a revocation, not a true deletion, and that modern clients honor it. This goes beyond the annotations and gives the agent a clearer mental model of the effect.

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 main action, and immediately adds the crucial revocation nuance. Every sentence earns its place with no filler.

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

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

With an output schema present and annotations covering destructive behavior, the description explains the core behavior (revocation) and the schema covers all parameters. It lacks explicit mention of prerequisites or edge cases (e.g., can only delete your own message unless sender is provided for admin), but those are in the schema, so it's reasonably complete.

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

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

Schema description coverage is 100%, and each parameter already has a clear description (chat, sender, account_id, message_id). The tool description adds no additional parameter-specific guidance, so it doesn't exceed the baseline for high coverage.

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

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

The description states a specific action ('Delete a WhatsApp message for everyone') and resource (WhatsApp message), and clarifies the subtle revocation behavior. It distinguishes from siblings like wa_edit_message or wa_react by focusing on deletion for everyone, and the nuance of revocation vs true delete is explicitly explained.

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 clearly says 'for everyone' which indicates the intended use case, but it doesn't explicitly contrast with alternatives like wa_edit_message or wa_react, nor does it state when not to use it. The sender parameter for admin use is only implied via schema, not described in the usage context.

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

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

Annotations already indicate destructiveness (destructiveHint: true), and the description adds valuable nuance beyond that: it specifies that only the push stops, messages still arrive, and they remain readable through wa_list_messages. This clarifies the exact scope of the destructive action and prevents agents from assuming messages are lost.

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, each essential and front-loaded: the first states the primary action, the second clarifies the consequence. There is no filler or redundant 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?

For a tool with no parameters and an output schema present, the description is complete. It tells the agent what happens, what does not happen, and where to still access messages. 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?

The tool has zero parameters, so the description naturally cannot add parameter meaning. The empty schema is fully covered, and the baseline for 0-parameter tools is 4; the description makes no claims about inputs, which is appropriate 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?

The description states a specific verb ('Stop delivering') and resource ('inbound messages to the configured endpoint'), clearly distinguishing it from siblings like wa_set_webhook or wa_enable_webhook. It also adds a clarifying contrast ('Messages keep arriving... only the push stops') that reinforces its unique purpose.

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

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

The description gives clear context: it is used to stop push delivery while preserving message availability for retrieval via wa_list_messages. It does not explicitly enumerate when-not-to-use or name alternatives, but the behavioral tradeoff is strongly implied by the second sentence.

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 provide only false hints (readOnly, idempotent, destructive all false), so the description carries the burden. It adds the permission requirement (account must be a group admin), which is useful context. However, it does not disclose behavior for edge cases (e.g., non-admin members) or side effects relative to removal, so it gives only partial transparency.

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 with no redundancy: the first defines the action, the second states a necessary precondition. Both earn their place, and the description is front-loaded with the primary purpose.

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

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

For a simple mutation tool with full schema coverage and an output schema, the description covers the essential prerequisite but leaves ambiguity about edge cases (e.g., demoting a non-admin, self-demotion) and the relationship to sibling tools. It is adequate but not thorough.

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 is described with references to related tools (wa_list_groups, wa_list_accounts). The description adds no extra 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 a specific verb ('demote'), identifies the resource (group participants), and specifies the outcome ('back to ordinary members'). It clearly implies the opposite of promote_participants but does not explicitly name any sibling tool, so it misses the highest mark for 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 only guidance is the prerequisite 'The account must be a group admin,' which is a precondition for calling the tool, not a selection criterion. It does not mention when to use this tool over alternatives like remove_participants or promote_participants, leaving that inference 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 indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, which suggest a state-changing, non-idempotent, non-destructive operation. The description adds the time limit but does not disclose other behaviors like whether it can edit only recent messages or whether it fails silently if the message is too old. It doesn't contradict annotations, so a 3 is appropriate.

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, concise and front-loaded with the core action. The time limit is placed second, which is useful but not overshadowing. No filler, and every sentence adds value.

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

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

For a simple 4-parameter tool with a full schema and annotations that indicate mutation, the description covers the key constraint (time limit). It lacks details on error conditions (e.g., if the edit fails) and doesn't mention what the output schema returns, but the output schema exists and may cover that. Overall, sufficient for an agent to call correctly.

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

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

The input schema covers all 4 parameters with descriptions, so the baseline is 3. The description does not add extra semantics beyond the time limit, which is a global constraint rather than parameter-specific. The parameters are well-documented in the schema, so the description doesn't need to compensate.

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

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

The description states the specific action (edit a WhatsApp message) and the resource (a message you sent), which is clear. It does not explicitly distinguish from wa_send_message or wa_delete_message, but the verb 'edit' is distinct enough given the sibling 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 notes the time limit (within about 20 minutes), which gives important context for when the tool is applicable, but it does not explicitly state when not to use it or mention alternatives like wa_delete_message for deletions. The time constraint is a strong usage signal.

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 operation as non-read-only, idempotent, and non-destructive. The description adds valuable behavioral context: deliveries pause/resume without changing endpoint/secret, messages continue arriving while paused, and they stay readable via wa_list_messages. This goes beyond the annotation baseline.

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

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

Two sentences, zero filler. The core action and key constraint ('WITHOUT changing the endpoint or its signing secret') are front-loaded, followed by a concise usage rationale and expectation-setting. 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 boolean-toggle tool, the description covers the core behavior, the temporary-use case, the alternative to avoid, and the post-pause state. With an output schema present and annotations supplying safety/idempotency, nothing an agent needs to invoke it 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%, with the enabled parameter clearly explained and reason described as an optional console note. The description itself does not add parameter details beyond what the schema provides, 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 opens with 'Pause or resume delivery to the configured webhook', naming a specific verb and resource with a clear scope. It also distinguishes itself from deleting/re-creating by noting the endpoint and signing secret are preserved, which separates it from wa_delete_webhook and wa_set_webhook.

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

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

It explicitly states when to use the tool: 'Use this to stop deliveries temporarily'. It also gives the reason to avoid an alternative ('deleting and re-creating the webhook would issue a new secret') and tells what to expect while paused, including that messages remain readable with wa_list_messages.

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 show the operation is not read-only, not idempotent, and not destructive, but they don't explain what side effects occur. The description adds no details about prerequisites, account-state changes, duplicate follows, or response behavior, so it adds minimal behavioral value.

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, direct sentence with no filler. It is efficient and front-loaded, though it partly restates the title and parameter 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?

With an output schema present and two fully documented parameters, the core call is understandable. However, it lacks guidance on sibling tool routing, prerequisites such as having a paired account, and behavior on duplicate follows, leaving the description minimally viable but not 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 coverage is 100%, with both account_id and channel_link already described, including the channel_link format. The description adds no additional semantic detail, so it meets the baseline but does not improve parameter understanding.

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 names the action (follow), the object (WhatsApp Channel), and the mechanism (from one of your accounts using its link). It is specific and readable, though it doesn't explicitly differentiate from nearby siblings like wa_join_group or wa_list_channels.

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 on when to use this tool versus alternatives such as wa_join_group or wa_list_channels. The only contextual hint, 'from one of your accounts', is already implied by the schema, so the description provides little situational direction.

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 the description is consistent. It adds useful behavioral context: the tool reads only the most recent messages, orders them oldest first, and targets a single account. This goes beyond the minimal read-only signal.

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 convey the core behavior, sort order, intended use, and the relevant alternative. There is no filler, and the most important information comes first.

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

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

The tool is simple, has full schema parameter coverage, a read-only annotation, and an output schema. The description supplies the remaining context an agent needs: what to use it for and how it differs from the paging alternative.

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 are already documented in the schema. The description does not add new parameter-level detail, but it also does not need to; the baseline of 3 applies.

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

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

The description states a specific verb ('Read') and resource ('most recent messages for one WhatsApp account'), and distinguishes itself from wa_list_messages. This makes the tool's purpose clear even though the title 'Get Chat' is generic.

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 tells the agent when to use this tool ('for context before replying') and when to use the alternative ('use wa_list_messages to page through everything'). This leaves no ambiguity about tool selection.

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

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

Annotations already indicate readOnlyHint=false verdict. The description adds useful behavioral context by explicitly disclosing that reset=true revokes the current link and issues a new one, and by requiring the account to be a group admin. This goes beyond the bare structured fields without contradicting them.

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

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

Two sentences with no filler. The primary operation is front-loaded, the optional mutation mode is clearly stated, and the key prerequisite is included in a compact final clause.

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

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

For a low-complexity tool with a full input schema and an output schema present, the description covers the operation, the reset side effect, and the admin requirement. Nothing essential 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 coverage is 100%, so every parameter is already documented, including the meaning of reset=true replique. The description adds little beyond restating the reset behavior and the admin requirement. This is the baseline 3 because 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 uses a specific verb ('Get') and resource ('WhatsApp group invite link') and clearly separates the two modes: retrieving the link or setting reset=true to revoke and regenerate it. This uniquely distinguishes it from all siblings, none of which deal with invite links.

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 states the intended use ('Get a WhatsApp group's invite link') and the reset behavior, which is clear context for when to call it. It also notes the group-admin prerequisite. No alternative sibling tool exists for this operation, so explicit exclusions are unnecessary.

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 read-only, and the description adds useful behavioral details: output is base64 and 'refused' signals that no retrievable media exists for the id. This goes beyond the structured annotations without contradicting them.

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

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

Two sentences with no filler. The core capability is stated first, followed by the key input source and the most important return sentinel. 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 two-parameter fetch operation with a readOnlyHint and an output schema, the description covers the essential behavior: what is fetched, how it is encoded, where the id comes from, and what 'refused' means. 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 both parameters are already documented. The description's mention of using message_id from wa_list_messages reinforces the schema but adds no significant new semantic beyond what the schema already provides.

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

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

Description clearly states a specific verb ('Fetch'), the resource ('attachment...a received WhatsApp message'), and even enumerates media types. It distinguishes itself from the many sibling tools by focusing on retrieving media rather than sending or managing chats.

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 instruction 'Use the message_id from wa_list_messages' gives a concrete prerequisite and source for valid input. It does not explicitly name alternative tools or when not to use this tool, but the received-message scope makes the usage context 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 readOnlyHint annotation already covers the safety profile, so the description does not need to restate it. It does add useful context about plan enforcement and refusal reasons, but it does not disclose additional behavioral traits such as response shape or whether current usage values update dynamically. Given the annotation coverage, this is adequate but not rich.

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

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

Two sentences, front-loaded with the core purpose and followed by concrete use cases. Every phrase earns its place, and the description avoids restating the tool name or padding with generic boilerplate.

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

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

For a zero-parameter read-only tool with an output schema provided, the description fully covers what the tool does and when to call it. No additional details about parameters or return values are necessary.

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)Skip; the description cannot meaningfully explain parameter meaning beyond the input schema. Per the baseline for zero-parameter tools, a 4 is appropriate because no parameter documentation burden exists.

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

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

The description uses a specific verb and resource: "Show your plan, its limits, current usage..." and enumerates exact contents including message-send limits, paired-account limits, and excluded_tools. This distinguishes it from all sibling tools, since none of them claim to expose plan-level quota or refusal reasons.

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

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

The description gives explicit invocation contexts: "Call this to see why wa_send_message or wa_pair_account might be refused, how much headroom is left, or why a tool answers plan_required." This is clear usage guidance, though it does not state when not to use it or name alternative tools for the same job.

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 read-only, and the description adds important behavioral nuance: an empty about or picture means the peer has not shared it, not that it doesn't exist. This is valuable beyond the annotation and helps the agent interpret results correctly. It does not contradict the readOnlyHint.

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 purpose, and includes only essential clarifications. Every sentence earns its place, with no redundant wording 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?

Given the output schema exists, the description doesn't need to restate return values. It covers the key behavioral aspect (empty field interpretation), which is critical for correct use. For a read-only lookup with simple parameters, 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 coverage is 100%—both phone and account_id have descriptive entries in the schema. The description adds no additional parameter-level detail beyond what the schema provides, so a baseline score of 3 is appropriate. The mention of 'from one of your accounts' aligns with account_id but doesn't add new semantics.

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 ('look up') and a clear resource ('who a phone number is on WhatsApp'), enumerating the exact data returned (registration status, name, about, picture, and business details). It clearly distinguishes itself from sibling tools like wa_get_chat or wa_get_media by focusing on profile lookup.

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 clearly implies when to use this tool (when you need profile information for a phone number from one of your accounts). It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent can select it without confusion among the many sibling operations.

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, so the agent knows this is a safe read operation. The description adds only that it reports the version of the service, which is a mild extension. It doesn't mention what the return value looks like or any edge cases, but for a simple getter with annotations covering safety, this is acceptable.

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 with zero wasted words. It states exactly what the tool does and nothing more, which is ideal for this trivial utility.

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 an output schema present, the description need not explain return values. For a zero-parameter, read-only version check, the description is fully sufficient. No additional context is required.

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

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

There are zero parameters, so the description need not add any parameter semantics. With schema coverage at 100% (vacuously true), the baseline for 0 parameters is 4. The description doesn't need to explain anything further.

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 'Report the version of this MCP service' uses a specific verb ('report') and resource ('version'), and clearly distinguishes itself from all sibling tools, none of which deal with versioning. An agent immediately understands what this tool does without needing to open 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?

There are no alternative tools for version retrieval among the 40+ siblings, so explicit when/when-not guidance is unnecessary. The description clearly implies its use case: checking the service version. While it doesn't state 'use when you need version info', the context makes it obvious.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: it never returns the signing secret, it reports whether the webhook is enabled, and it provides the reason if disabled. This tells the agent exactly what to expect and what not to expect, which is especially valuable for a read operation.

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 primary function is front-loaded, and the privacy caveat is placed second where it can warn the agent before it relies on getting the secret. Every clause earns its place.

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

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

For a zero-parameter read tool with an output schema and readOnlyHint, the description covers the essential behavioral context: what is returned, what is deliberately omitted, and how disabled state is presented. No additional information is needed to invoke or interpret this 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 tool has zero parameters, so the description correctly adds no parameter explanations. With 100% schema coverage and an empty input schema, there is nothing more an agent needs to know about parameters.

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 ('Show') and a clear resource ('currently configured inbound webhook'), then adds distinctive detail: it reports enabled state and disable reason, and explicitly notes the signing secret is excluded. This differentiates it from wa_set_webhook, wa_enable_webhook, and wa_delete_webhook without needing those 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 phrase 'currently configured' and the read-only framing make it clear this is for inspecting existing webhook state, not creating, enabling, or deleting. The signing-secret caveat also implies that if the agent needs the secret, it must use the creation flow instead. However, it does not explicitly name the alternative tools or state when not to use this one.

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 disclose that the operation is not read-only, not idempotent, and not destructive. The description adds the concrete mutation (joining a group via an invite link) but does not go further, e.g., whether approval-required groups yield only a pending state or how invalid/expired links fail. That missing nuance keeps this from a 4, but the action itself is transparent.

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

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

A single, front-loaded sentence of about 14 words states the verb, object, scope, and required input with zero filler. Every phrase earns its place; there is no redundant background or promise about return values.

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

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

For a low-complexity mutation with two fully documented parameters and an output schema, the description is nearly sufficient. It could additionally note behavior for approval-required or already-joined groups, but nothing necessary to pick the tool or fill the required inputs is absent.

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

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

Schema description coverage is 100%, and both parameters (account_id and invite_link) are already well described, including the hint that invite_link may be a bare code. The description's 'from one of your accounts' and 'using its invite link' paraphrase the schema without adding new semantic information, so it stays at the 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?

The description uses a specific action ('Join') on a clear resource ('a WhatsApp group') with the mechanism ('invite link') and scope ('from one of your accounts'). This distinguishes it from siblings such as wa_create_group, wa_add_participants, and wa_get_group_invite_link without needing to open 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?

'From one of your accounts' and 'using its invite link' give clear contextual conditions for when to call the tool: the agent already has an account ID and an invite link or bare code. It doesn't explicitly name alternatives or exclusions, but the scope language sufficiently separates joining from adding participants or creating groups.

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

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

Annotations already communicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description is consistent with those and adds the specific behavioral scope (group leave vs. channel unfollow), but it does not add further context such as irreversibility, admin requirements, or side effects on messages/membership.

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

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

A single, front-loaded sentence states the action, the target resource types, and the key parameter concept. There is no filler, repetition, or unnecessary detail.

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

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

For a simple two-parameter tool with a full input schema, a destructive annotation, and an output schema present, the description covers the essential semantics. Nothing an agent needs to invoke it 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%, with jid and account_id both documented clearly. The description's mention of 'by its JID' and 'one of your accounts' loosely maps to the parameters but adds no real semantic value beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb-resource pairing: 'leave a group or unfollow a channel' on 'one of your accounts', and it explicitly names the addressing mechanism ('by its JID'). This clearly differentiates it from siblings like wa_create_group, wa_join_group, wa_delete_group, and wa_follow_channel.

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 scope is clear: use when leaving a group or unfollowing a channel. However, it does not explicitly state when not to use it or mention alternatives such as wa_join_group or wa_follow_channel for the reverse operation. The usage context is implied rather than directly contrasted with siblings.

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, so the safety profile is covered. The description adds useful behavioral context: the returned account_id is a prerequisite for other tools, and the 'connected' state is a usability condition. However, it doesn't describe the output structure or whether disconnected accounts are still listed, which would be useful given the state caveat.

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

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

Three short sentences, each earning its place: what it does, why to call it first, and the connected-state constraint. Front-loaded with the action and resource.

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

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

For a zero-parameter read-only list tool, the description covers the essential context: what it returns conceptually (accounts), why it matters (account_id prerequisite), and a usage condition (connected state). The output schema exists, so return values need not be described. Minor gap: it doesn't state whether disconnected accounts appear in the list, but the state caveat implies they may.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details because none are needed. Baseline 4 for zero-param tools 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 ('List') and resource ('WhatsApp accounts available to you'), and distinguishes itself from the many sibling tools by being the account-listing tool. The description also clarifies scope ('available to you'), which is more specific than a generic 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?

Explicitly instructs the agent to call this first because every other wa_ tool needs an account_id from here. This is strong when-to-use guidance and implicitly excludes using other tools before this one. It also adds a usage condition: an account is only usable while its state is 'connected'.

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 readOnlyHint=true; the description adds value by detailing what each entry contains (number, saved name or absent name, country) and explicitly disclosing that block dates are unavailable because WhatsApp does not report them. This avoids the agent expecting a timestamp that will never appear.

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 carry the action, output semantics, and a notable data absence without redundancy. The core purpose is front-loaded and 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 one-parameter read-only list with an output schema and readOnly annotation, the description is complete: it names the scope, explains the returned fields, and flags the missing date. An agent has everything needed to invoke and interpret the call correctly.

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

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

Schema description coverage is 100% and the single account_id parameter is already documented as 'the account whose blocklist to read, as returned by wa_list_accounts.' The tool description adds no parameter-specific detail beyond that, so the baseline score is appropriate.

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

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

The description opens with a specific verb and resource: 'List every contact one of your accounts has blocked.' It clearly distinguishes this read-only listing from siblings like wa_list_contacts (all contacts), wa_block_contact, and wa_unblock_contact by focusing on the blocklist.

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

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

The intended context—reading a specific account's blocklist—is clear from the description and the account_id schema note. However, it never states when to prefer this tool over wa_list_contacts or wa_search_contacts, nor does it mention when not to use it, so the guidance is implied 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?

Beyond the readOnlyHint=true annotation, the description adds valuable behavioral detail: pagination via after_cursor, the need to loop until has_more is false, and that each call indicates whether it was answered and its duration. It also notes the ordering (oldest first). These details are not in the annotations and significantly inform the agent's invocation strategy.

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 primary purpose is front-loaded in the first sentence, and the second sentence efficiently covers pagination and output characteristics. Every sentence earns its place; there is no redundant or extraneous information.

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

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

The tool is a simple read-only list with optional parameters and an output schema. The description covers the core usage (what it returns, ordering, pagination) and the schema documents all parameters. There are no complex side effects or prerequisites to disclose. The description is complete for an agent to call the tool correctly, especially with the output schema available.

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

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

The input schema already describes all three parameters with 100% coverage, giving a baseline of 3. The description adds extra meaning for after_cursor by explaining the pagination loop ('pass back the next_cursor... keep going until has_more is false'), which is not present in the schema. It does not elaborate on limit or account_id, but those are already well-documented, so the added context justifies a score above 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?

The description opens with a specific verb and resource: 'Read call history across your WhatsApp accounts, oldest first.' This distinguishes it from sibling list tools like wa_list_messages or wa_list_contacts, which focus on different data types. The scope (across accounts) is explicit, leaving no ambiguity about what the tool retrieves.

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 the tool's purpose and how to use it (pagination pattern), but it does not explicitly mention alternatives or when not to use it. The distinction from sibling list tools is implied by the resource type, but no explicit exclusion or alternative routing is given. This is 'clear context, no exclusions' per the rubric.

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, so the agent knows it's a safe read operation. The description adds the specific output fields (JID, name, subscriber count) but doesn't mention pagination, ordering, or whether it lists all channels or only followed ones. The description is consistent 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?

A single, concise sentence that states the action, the resource, and the output fields. No wasted words, and the key information is 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?

For a simple read-only list tool with one parameter and an output schema, the description is nearly complete. It could mention whether the list is paginated or if there are limits, but given the simplicity and the output schema, this is 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 the schema already documents the account_id parameter. The description adds that the account is 'one of your accounts' and references wa_list_accounts, which provides useful context but doesn't add significant new semantics 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 clearly states the verb 'List' and the resource 'channels one of your accounts follows', and specifies the returned fields (JID, name, subscriber count). It is distinct from siblings like wa_list_accounts and wa_list_groups.

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 tool is for listing channels for a specific account, and the parameter description clarifies the account_id comes from wa_list_accounts. It doesn't explicitly state when not to use it versus alternatives, but the context is clear enough for an agent to select 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=true, so the description only needs to add context beyond that. It does: it reveals that include_pictures triggers lookups on WhatsApp, caps results at 10 per page, and is slower. It also clarifies the data source is the linked phone's saved contacts. This goes beyond what annotations alone convey, though it does not cover every possible edge case.

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

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

Four sentences with no filler. The core purpose is front-loaded, the alternative is named, and the include_pictures caveat is compressed into a single useful sentence. Every sentence contributes to correct selection or invocation.

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 an output schema present, return-value documentation is unnecessary. The description covers tool selection (wa_search_contacts alternative), downstream use (wa_send_message), parameter behavior (include_pictures page cap and speed), and scoping (per-account, phone-linked contacts). Nothing an agent needs to call it 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 the schema already documents all four parameters clearly. The description restates the include_pictures trade-off and adds the cross-tool hint to use returned phone numbers with wa_send_message, but it does not substantially add meaning beyond the parameter descriptions. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List the address book of one of your WhatsApp accounts — the contacts saved on the phone this account is linked to.' It immediately distinguishes itself from the sibling wa_search_contacts, 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 explicitly names the alternative for a different need: 'To find a specific person, use wa_search_contacts instead.' It also gives downstream guidance by saying returned phone numbers can be used with wa_send_message, and explains when to set include_pictures. This is clear, decision-relevant context.

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

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

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral detail beyond the annotations by specifying the shape of each returned item: JID, phone number, and admin flag, which helps the agent anticipate the output.

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 action is front-loaded and the second sentence efficiently conveys the output item structure 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?

For a simple read-only list operation with fully documented parameters and an output schema, the description is complete. It gives the essential semantic detail about each member item, and the readOnlyHint annotation covers the safety profile.

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 explains account_id and group_jid adequately. The description does not add parameter-specific meaning beyond what the schema provides, 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 specific verb ('List') and resource ('a group's members'), and clarifies that each item is a participant with JID, phone number, and admin flag. This clearly differentiates it from sibling tools like wa_list_groups or wa_get_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 intended use is implied by the action and resource: to list members of a specific group. However, it does not explicitly state when to choose this tool over alternatives or provide any caveats, such as the need for the group_jid from wa_list_groups.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about account scoping and returned fields, but does not disclose additional behavioral traits such as ordering, pagination, or limits. This is acceptable but not rich.

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

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

A single, front-loaded sentence that states the action, the scope, and the key output fields with no filler or repetition. Every word contributes to understanding the tool.

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 with one fully described parameter, a readOnlyHint, and an output schema present, the description covers the essential context. An agent can determine what the tool returns, which account it applies to, and that it is non-destructive.

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 fully documents account_id. The tool description does not add parameter-level detail beyond the schema, 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 names a specific verb ('List'), a specific resource ('groups'), and an account-scoped denominator ('one of your accounts has joined'). It also names the output fields (JID, name, member count), which makes it easy to distinguish from siblings like wa_list_group_members or wa_list_contacts.

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 makes the intended scenario clear: list the groups a particular account has joined. It does not explicitly state exclusions or name alternative tools, but the account_id provenance in the schema ('as returned by wa_list_accounts') adds practical sequencing 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 provide readOnlyHint=true, and the description reinforces this with 'Read'. It adds useful behavioral details beyond annotations: cross-account scope, oldest-first ordering, and the pagination pattern using next_cursor. No contradictions with the annotation.

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

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

Three short sentences, each contributing: purpose and ordering, pagination mechanic, and a concrete use case. No filler or redundancy, and the most important information is 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?

With an output schema present and annotations covering read-only behavior, the description supplies everything an agent needs to call the tool correctly: scope, ordering, pagination, and when to use it. No critical gaps remain.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how to use after_cursor in conjunction with the output's next_cursor for pagination, clarifying the intended pattern more concretely than the schema alone.

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 ('Read'), resource ('messages'), and scope ('across all your WhatsApp accounts') with ordering ('oldest first'). This clearly distinguishes it from sibling list tools like wa_list_calls or wa_list_contacts.

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

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

It gives clear context: 'Use this to catch up after being notified of a new message' and explains pagination via after_cursor. However, it does not explicitly name alternative tools for fetching messages from a specific chat, so it lacks full 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 indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds key behavioral context: the QR code expires every ~20 seconds and the need to poll for status. This goes beyond the annotations and informs the agent of the time-sensitive nature of the operation.

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 redundant information. The purpose is front-loaded, followed by the return format and the immediate next step. Every clause serves a purpose, making it highly efficient.

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

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

Given the tool has no parameters and the output schema exists (though not shown), the description is complete. It covers what the tool does, what it returns (QR code), the expiry behavior, and how to proceed. An agent has everything needed 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?

With zero parameters and full schema coverage (100%), the baseline is 4. The description adds value by mentioning the return of a QR code and the pair_id, which is critical for the next step (polling). This enriches the agent's understanding of the tool's output even though the schema is empty.

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 verb+resource: 'Begin linking a new WhatsApp account.' It distinguishes itself from sibling tools like wa_pair_status (polling) and wa_unpair_account (unlinking) by specifying it initiates the pairing process and returns a QR code.

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

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

The description explicitly instructs the agent to poll wa_pair_status with the returned pair_id, establishing a clear usage sequence. It also notes the code expires every ~20 seconds, which implies the need for polling. This provides concrete guidance on how to use the tool 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?

Beyond annotations, the description explains non-obvious behavior: while state is 'qr', each call returns a new image, so the agent should show the latest one. This aligns with idempotentHint=false and adds meaningful operational detail without contradicting the readOnlyHint=true annotation.

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

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

The description is two sentences long, front-loaded with the tool's purpose, and then provides the essential state behavior. Every sentence earns its place with no filler or repetition.

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

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

Given the single parameter, output schema, and annotations, the description covers the main lifecycle: polling while 'qr', showing the latest image, and recognizing readiness once 'paired'. It doesn't mention possible error/expired states, but the output schema likely captures those, so the description is still highly usable.

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 pair_id fully as 'the pair_id returned by wa_pair_account' with 100% coverage. The description refers to the pairing context but does not add meaningfully new parameter-level semantics, 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 clearly states the tool checks the status of a pairing started with wa_pair_account. It also distinguishes itself from related tools: wa_pair_account starts the pairing, while wa_list_accounts shows accounts after they become paired.

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 lifecycle context: use it after wa_pair_account to poll the pairing state, and stop once the state becomes 'paired', at which point wa_list_accounts becomes relevant. It is not an explicit 'when not to use' statement but it provides enough contextual guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds the admin prerequisite, which is a meaningful behavioral constraint beyond the annotations. However, it doesn't disclose what happens on failure (e.g., partial promotion if some members are invalid) or whether the operation is reversible.

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 with zero waste. The core action is front-loaded, and the prerequisite is stated in the second sentence. 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 3-parameter tool with 100% schema coverage and an output schema present, the description is nearly complete. The admin prerequisite is the key contextual fact, and it's included. The only minor gap is not describing the output/return behavior, but the output schema likely covers that.

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 are already documented in the schema. The description adds no additional parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate 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 states a specific verb ('Promote') and resource ('group members to admin'), which clearly distinguishes it from sibling tools like wa_demote_participants and wa_add_participants. It doesn't explicitly name the sibling it contrasts with, but the action 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?

The description gives a clear prerequisite ('The account must be a group admin'), which is useful context for when to use the tool. However, it doesn't explicitly state when not to use it or mention alternatives like wa_demote_participants for the reverse operation. The prerequisite implies usage context but doesn't fully guide selection among siblings.

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 provide no safety or idempotency hints (all false), so the description carries the burden. It discloses the core behavior (add or remove a reaction) and the empty-reaction nuance. However, it does not mention potential limitations like the channel restriction (which is only in the schema) or any side effects beyond the action itself.

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 primary action is front-loaded, and the secondary removal behavior is stated efficiently. 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?

With a complete schema (100% parameter coverage) and an output schema present, the description only needs to cover the essential behavior. It does that, including the removal nuance. It could mention the channel limitation, but that is already captured in the schema, so the description is sufficiently complete 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?

The schema covers all parameters with 100% description coverage, so the baseline is 3. The description adds no extra parameter-level detail beyond what the schema already states; the only extra nuance (empty reaction removal) is also present in the reaction parameter's description.

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's function: reacting to a WhatsApp message with an emoji, and explicitly mentions the removal behavior with an empty reaction. The verb 'react' and resource 'WhatsApp message' are specific, distinguishing it from siblings like wa_send_message or wa_edit_message.

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

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

The description implies usage (when you want to react to a message) but provides no explicit guidance on when to use this tool versus alternatives. It mentions the empty-reaction removal case, which is a specific usage guideline, but does not discuss exclusions or direct the agent to sibling tools for other actions.

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 destructiveHint annotation already flags mutating behavior, and the description adds important behavioral context: the acting account must be a group admin. This is meaningful auth-related information beyond what the schema or annotations state.

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 with no filler. The core action and identifier formats come first, followed by the admin prerequisite. Every word adds relevant 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?

For a destructive mutation tool, the description covers the action, target, accepted identifiers, and required permission. An output schema exists, so explaining return values is unnecessary. It is essentially complete for the 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 coverage is 100%, with each parameter already documented with format and provenance (E.164/JID, ...@g.us from wa_list_groups, account from wa_list_accounts). The description mostly restates the members format, adding little semantic value 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?

Names a specific verb ('Remove') and specific resource ('participants from a WhatsApp group'), and explains the two accepted member identifier forms. This clearly distinguishes it from sibling tools like wa_add_participants, wa_demote_participants, and wa_delete_group.

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 clearly states when the tool applies: removing members from a WhatsApp group. It also gives a key prerequisite, that the account must be a group admin, which helps the agent decide whether this tool can be used in a given context. It does not name alternative tools explicitly, but the use case 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?

Beyond the readOnlyHint annotation, it discloses the pagination limit (10 with include_pictures) and the potential latency (half a minute), which is valuable for the agent to manage user expectations. No contradiction with the readOnlyHint.

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 paragraph with clear, dense information. It front-loads the main purpose and matching behavior. Some redundancy with the schema for parameter details but acceptable given the added 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 output schema exists and annotations cover read-only safety, the description fully addresses what an agent needs: the search scope, matching rules, pagination behavior, and the performance cost of including pictures. Nothing obvious is missing for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the matching specifics (case-insensitive, ignoring punctuation) and the interplay between include_pictures and limit, which goes slightly beyond the schema, but the schema already covers each parameter individually.

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?

It clearly states the action (find contacts), the specific account context, and the matching criteria. It distinguishes itself from wa_list_contacts by focusing on search rather than listing all contacts.

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

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

It gives clear context for when to use this tool (searching by name or number) and mentions the alternative wa_list_accounts for identifying the account. It doesn't explicitly exclude alternatives but the context is strong 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?

Beyond the minimal annotations, the description exposes critical behavioral traits: queued messages may still arrive and must not be resent, refused messages haven't been sent and retry guidance depends on the reason, and attachment caption behavior. This is essential for safe agent invocation.

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 and front-loaded: it opens with the action, then covers attachment variants, and finishes with status semantics. Every clause adds distinct value, and there is no redundant filler.

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

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

Given the tool's complexity (12 parameters, multiple attachment types, non-trivial status handling), the description covers all essential aspects: size limits, caption rules, status meanings, and retry guidance. Prerequisites like account_id are described in the schema, and the output schema exists for return values.

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

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

The input schema already has 100% coverage with detailed descriptions for every parameter, including size limits and caption behavior. The description adds grouping (text vs. image/document/audio) but no significant new parameter-level semantics beyond the schema.

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

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

The description states a specific verb and resource ('Send a WhatsApp message') and enumerates the supported modalities (text, image, document, audio) with size limits. This fully differentiates it from sibling tools like wa_edit_message or wa_delete_message.

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

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

It provides clear operational guidance: how to interpret the returned statuses ('sent', 'queued', 'refused') and explicitly warns not to resend on 'queued'. It does not explicitly mention alternative tools or when not to use this tool, but the usage context is strong.

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 this is a mutating, non-idempotent operation. The description adds value by clarifying the semantic effect of the boolean (true = admin-only, false = everyone posts), which goes beyond the schema's generic 'new value for this setting'. No contradiction 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?

A single, well-structured sentence that front-loads the action and immediately explains the parameter semantics. No redundant words or filler, making it efficient and easy to parse.

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 three-parameter toggle tool with a clear output schema, the description covers the functional behavior completely. It explains the effect, the parameter meaning, and leaves nothing essential for an agent to call it correctly. The schema handles parameter descriptions, and the output schema covers the response format.

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

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

With 100% schema coverage, the baseline is 3. The description adds meaningful semantics for the 'enabled' parameter by explaining what true and false do, which is not fully covered by the schema. The other two parameters are adequately documented in the schema as returned by list functions, so no further explanation needed.

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 (restrict) and the resource (WhatsApp group) with the specific setting (admin-only messages). It distinguishes itself from sibling tools like wa_set_group_name and wa_set_group_locked by focusing on the announce-only behavior, and explicitly explains the two states of the enabled parameter.

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

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

The description implies usage by explaining the enabled parameter's effect, making it clear when to use this tool (to toggle announce-only). It does not explicitly name alternatives or state when not to use it, but the context of sibling tools and the precise wording make the intended use obvious.

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 (which already indicate a non-read, non-idempotent mutation), the description adds two useful behaviors: the admin restriction and that an empty description clears it. This enriches the agent's understanding without contradicting annotations.

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

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

Two sentences with no filler. The primary action is stated first, and the conditional usage note follows immediately. 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 three-parameter tool with full schema coverage and an output schema, the description covers purpose, a key usage condition, and a parameter behavior. Nothing an agent needs to invoke it 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?

The schema already covers all three parameters with descriptions (100% coverage), so baseline is 3. The description adds value by noting that 'empty clears it' for the description parameter, which is not in the schema. This is a meaningful semantic addition.

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 ('Set a WhatsApp group's description') and is clearly distinct from sibling tools like wa_set_group_name, wa_set_group_announce, and wa_set_group_locked. 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 includes a relevant usage condition ('If the group restricts settings changes to admins, the account must be one'), which guides when the tool can be used. It doesn't explicitly name alternatives or say when not to use it, but the purpose is so clear that contrast with siblings is implicit.

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 indicate this is a non-read-only, non-destructive mutation. The description adds useful behavioral context by defining what enabled=true and enabled=false actually do to the group settings. It doesn't discuss permissions or side effects, but the disclosed behavior goes beyond what annotations and schema 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?

A single, well-structured sentence that front-loads the action and includes every essential behavioral detail without filler. It is compact yet informative, earning its place with 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?

This is a simple three-parameter toggle operation; the description, combined with fully documented schema parameters and an output schema, gives an agent everything needed to invoke it correctly. Nothing important is missing for this level of complexity.

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 extra semantic value by explicitly mapping enabled=true to 'admins only' and enabled=false to 'every member,' which is more meaningful than the schema's generic 'the new value for this setting.'

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 verb ('Restrict') and a precise resource ('a WhatsApp group's settings'), and clarifies exactly which settings are affected: name, description, and photo. This cleanly differentiates it from sibling tools like wa_set_group_name or wa_set_group_description, which mutate individual fields rather than lock them.

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

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

The description implies when to use the tool: when an agent wants to toggle whether group settings are admin-only or open to all members. However, it does not explicitly name alternative tools or state when not to use it, so the usage guidance is inferred 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 indicate this is a mutating operation (readOnlyHint=false, destructiveHint=false). The description adds a useful behavioral detail beyond annotations: the admin permission requirement under group restrictions. It does not enumerate failure modes or side effects, but the added permission context is genuinely informative.

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 first sentence front-loads the exact action and resource, and the second sentence adds a relevant condition. 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 three-parameter mutation tool with full schema coverage, clear annotations, and an output schema, the description is complete. It covers what the tool does and the key prerequisite, and the input schema covers all parameter details.

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 schema already explains each parameter: the max 25-character name, the @g.us JID provenance from wa_list_groups, and the account provenance from wa_list_accounts. The description itself adds 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 opens with 'Rename a WhatsApp group', giving a specific verb and resource. This clearly distinguishes it from sibling tools like wa_set_group_description, wa_set_group_announce, and wa_set_group_locked. The admin caveat adds relevant context without obscuring the core purpose.

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

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

It is clear this tool is for renaming a group, and the description provides a meaningful precondition: the account must be an admin if the group restricts settings changes. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to select it 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 mark the tool as non-read-only, non-idempotent, and non-destructive. The description adds the key behavioral trait that calls are fire-and-forget with no delivery confirmation, which the agent cannot infer from annotations. This is valuable context beyond the structured fields.

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

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

Two sentences, front-loaded with the purpose and ending with the important caveat. No filler words, every clause earns its place.

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

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

The tool has an output schema, so return values need no description. The description covers the two behaviors, the state values, the conditional relevance of chat, and the fire-and-forget nature. Together with the 100%-covered schema, an agent has everything needed to call 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%, and the schema already documents all three parameters, including the conditional requirement for chat. The description reinforces the semantics by explaining the two modes and the state values, but adds no new parameter-level information 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 uses specific verbs 'Announce' and 'set' with clear resources: typing state to a chat, and account presence online/offline. It enumerates the exact state values and distinguishes the two operational modes. No other sibling tool covers presence, so it's unambiguously differentiated.

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

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

The description implies usage: when you need to broadcast a typing indicator or change account presence. It doesn't explicitly mention alternatives or exclusions, but no sibling tool serves this function. The fire-and-forget caveat tells the agent not to expect a confirmation, which is a usage-relevant constraint.

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 set false flags, so the description carries the burden. It discloses critical behaviors: the signing secret is shown only once and must be stored, calling again replaces the endpoint and issues a new secret, and it enables push-based delivery. 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?

Three sentences, each purposeful: purpose and benefit, the one-time secret warning, and replacement behavior. No filler, front-loaded with the main intent.

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

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

The description covers the essential behavioral aspects: why to use it, the critical secret handling, and the replacement behavior. With an output schema present, it need not explain return values. It is sufficiently complete for a tool with only two parameters.

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 url and events already described (e.g., url must be publicly reachable, events default to message.inbound). The description adds no extra parameter-level details; the secret is an output, not a parameter. 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 ('Register an HTTPS endpoint') and its purpose (receive inbound WhatsApp messages as they arrive), and explicitly contrasts with polling wa_list_messages, distinguishing it from a common alternative. The resource and verb are specific, and it is unambiguous what the tool does.

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 clear use case: use this instead of polling when you want push notifications. It also notes that calling again replaces the endpoint, implying when to reuse. It does not explicitly mention when to use wa_delete_webhook or wa_enable_webhook, but the primary context is well covered.

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 operation is non-read-only and non-idempotent; the description adds useful behavioral detail by stating it 'Reports who was unblocked' with number, name, and country. It does not mention error paths or reversal via re-blocking, but it does not contradict the annotations.

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

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

Two focused sentences with no filler; the action is front-loaded and the return-behavior sentence is the only extra detail.

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

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

For a two-parameter tool with annotations and an output schema, the description supplies the core semantics, account scope, and report behavior. It could add explicit error or repeated-call handling, but nothing essential for invoking the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description does not add parameter-level detail. One caveat: the schema's jid property says 'the contact to block' instead of 'unblock', a typo the description should have corrected, and this prevents a higher score.

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: 'Unblock a previously blocked contact on one of your WhatsApp accounts.' It clearly distinguishes itself from siblings like wa_block_contact by stating it reverses a prior block, and it promises a concrete report of the unblocked contact.

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 'previously blocked contact' gives a clear precondition: use this only when unblocking an existing blocked contact, not for creating blocks. It does not explicitly name alternatives such as wa_block_contact or wa_list_blocked, so it stops short of full when/when-not 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?

Beyond the annotations (destructiveHint=true), the description specifies exactly what changes: sending/receiving stops immediately, message history is kept, and reconnection requires a fresh pairing. It also adds the important consent requirement before invoking the destructive 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?

Four short sentences, each carrying essential information: action, immediate effect, data preservation, and user-consent requirement. No filler or redundant phrasing.

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 one simple parameter, a fully documented schema, an existing output schema, and annotations covering mutation/destruction, the description provides all needed context. It even covers the post-condition (re-pairing required) and the necessary user-consent gate.

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 account_id parameter is already well documented as 'the account to disconnect, from wa_list_accounts'. The tool description adds no additional parameter-level detail, 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 verb ('Disconnect'), the resource ('a WhatsApp account from this service'), and the immediate functional effect ('stops sending and receiving'). It clearly distinguishes this tool from the sibling wa_pair_account by explaining that reconnecting requires pairing again.

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: this is the disconnect operation, and it explicitly instructs the agent to ask the user before calling due to the disruption. It does not explicitly name wa_pair_account as the alternative, but the re-pairing note implies the counterpart tool.

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