WhatsMCP: MCP for WhatsApp

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

Annotations cover readOnly and non-idempotency, but the description adds real behavioral context: the full status lifecycle (dialing, in_progress, done, failed, no_answer, busy), the fact that summary/transcript/collected data only appear once the call has ended, and that recording_url expires after one hour — which also explains the idempotentHint=false. It does not mention auth or rate limits, but the operational detail is strong.

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 leads with the verb and resource, then lists returns without padding. 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?

An output schema exists, so the return-field enumeration is somewhat redundant, but it usefully surfaces the status enum values and the conditional availability of fields. Prerequisites and lifecycle are covered; only the sibling-tool routing is missing.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema already documents call_ref. The description adds only that the ref originates from wa_ai_call_start, which is minor redundancy; baseline 3 is appropriate.

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

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

States a specific verb (Read) and resource (AI call) and enumerates the substantive return fields, so the agent knows exactly what it retrieves. The phrase 'started with wa_ai_call_start' situates it relative to the sibling that creates calls.

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 prerequisite is implied ('started with wa_ai_call_start', call_ref 'from wa_ai_call_start'), which gives usable context. However, it never contrasts with the sibling wa_ai_list_calls or states when to prefer this single-call fetch over the list tool, so usage is only implied.

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

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

Annotations only give the flags; the description goes further by disclosing that the hangup is immediate and bilateral, that the call is left untouched if already ended (with hung_up false), and that summary/transcript/recording still arrive afterward. This is exactly the idempotency and side-effect detail an agent needs and is consistent with the idempotentHint/destructiveHint 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 tight sentences with the effect (immediate bilateral hangup) front-loaded, followed by the post-call artifact note and the no-op guard. 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?

With an output schema present, return values need no explanation, and the description still supplies the key behavioral nuance (idempotent no-op, artifacts follow). Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% with a single documented parameter, so the schema already carries the semantics. The description mentions where call_ref comes from (wa_ai_call_start or wa_ai_list_calls) but that is largely echoed in the schema text, adding little beyond 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?

Specific verb ('End/hang up') plus resource ('a live AI voice-agent call') with explicit scope: calls started via wa_ai_call_start or inbound calls an agent answered. An agent can distinguish this from wa_ai_call_start and wa_ai_call_get without opening a schema.

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

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

Clear context for when this applies (a live call, whether outbound or inbound-answered) and states the already-ended case is a no-op. It does not name a sibling alternative or an explicit when-not, but the triggering condition is unambiguous.

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

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

Annotations only carry readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description bears the full burden of behavioral disclosure. It explains the non-idempotent nature ('Returns immediately with a call_ref; the call then rings and runs on its own'), the asynchronous execution model, and the concurrency constraint ('One call at a time per number'). It also clarifies the poll-and-retrieve pattern. This adds meaningful context beyond the annotations, though it doesn't mention auth or rate limits, which are minor for this tool type.

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 but is logically ordered: purpose → parameters usage → immediate return → polling guidance → concurrency caveat. It is dense but every sentence contributes to correct invocation. It's slightly long but not padded; the front-loaded purpose and explicit polling instructions earn the length.

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 complex asynchronous tool with an output schema, the description covers the essential lifecycle: immediate call_ref, polling cadence, terminal statuses, and what the polled result contains (summary, transcript, collected data, recording link). It also flags the concurrency limitation. This is complete enough for an agent to invoke and monitor correctly, though it omits explicit error-handling guidance.

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

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

Schema coverage is 100% and the schema already describes each parameter well. The description adds valuable nuance: it clarifies that 'variables' holds per-call context that is merged over preset defaults, and that 'first_message' overrides the agent's opening line. This goes beyond the schema's basic descriptions and gives the agent a clearer mental model of how the parameters interact.

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+resource: 'Have an AI voice agent call a WhatsApp number', and immediately ties it to a preset from a sibling tool (wa_ai_list_presets). It clearly distinguishes this from the many WhatsApp messaging tools by emphasizing the voice-agent call flow and the async behavior with call_ref. An agent can tell exactly what action this performs and how it differs from siblings.

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

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

The description gives explicit operational guidance: it tells the agent to poll wa_ai_call_get every ~30 seconds until terminal statuses, explains that variables are merged over preset defaults, and warns about the one-call-at-a-time concurrency rule. It doesn't explicitly state when NOT to use this tool (e.g., when a simple message suffices), but the context makes the intended usage clear and the polling pattern is well specified.

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 real behavioral context beyond that: newest-first ordering, the meaning of 'direction' and 'from' on inbound calls, and that a call_ref from results feeds wa_ai_call_get and pagination.

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

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

Two sentences, fully front-loaded with scope and ordering first, then the follow-up directive. Every clause (direction, from, answers_inbound, call_ref) carries information an agent needs and none is redundant.

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?

An output schema exists, so return values needn't be explained, and the description supplies the filtering/ordering semantics and the transcript follow-up path. Minor gaps on rate limits or result volume handling keep it from a 5, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents 'limit' (1-100, default 25) and 'before' (prior-page call_ref). The description reinforces pagination via call_ref but adds no new syntax or constraints 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?

States a specific verb and resource ('List this workspace's AI voice-agent calls, newest first') and precisely scopes what qualifies as a call: outbound calls started with wa_ai_call_start and inbound calls answered by a preset whose answers_inbound is true. This clearly distinguishes it from the sibling wa_list_calls.

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

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

Gives clear context for use and explicitly routes the agent to wa_ai_call_get with a call_ref for transcripts and recordings. It does not explicitly state when not to use this tool (e.g., vs. wa_list_calls for non-AI calls), so it falls just 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?

Annotations already cover the safety profile (readOnlyHint=true), so the bar is lower. The description adds genuinely useful behavioral context: the readiness gate (ready / not_ready_reason) that determines whether a preset is callable, and the expected_variables semantics, going beyond what the annotations declare.

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

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

Front-loaded with the purpose, then three tight clauses that each add distinct value (preset composition, call routing via wa_ai_call_start, readiness and variable semantics). No wasted sentences.

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

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

With an output schema present, the description needn't document return fields, and it doesn't waste effort doing so. It supplies everything an agent needs: what a preset is, which sibling consumes it, and the readiness condition gating usage.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter-level gaps exist.

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 (AI voice-agent presets of this workspace), and then defines what a preset actually is. It is clearly distinguishable from siblings like wa_ai_list_calls or wa_list_channels without opening any schema.

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

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

Explicitly routes the agent: the preset name is consumed by wa_ai_call_start, and it warns that only ready=true presets can call now, with not_ready_reason as the explanation. It falls just short of a 5 because it doesn't state when to prefer this over the other AI-call-adjacent siblings, but the workflow guidance is clear.

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

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

With annotations already indicating a non-read-only, non-destructive operation, the description adds the behavioral effect (prevents calls/messages), the reversibility via unblock=true, and the confirmation output (number, address-book name, country). It goes beyond the schema, though it doesn't discuss repeated-block behavior or idempotency.

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

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

Two tight sentences carry the main action, the unblock exception, and the reported outcome with no filler. The most important details are front-loaded, and there is no repetition of schema 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 3-parameter tool with full schema coverage, annotations, and an output schema, the description sufficiently covers scope, the optional unblock behavior, and what the operation reports. No essential call information is missing; account_id linkage is handled in the schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description mostly restates the same semantics for jid and unblock, adding only the natural-language context about what the result reports. This matches the baseline for fully covered schemas.

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 concrete action: block a contact on a specific WhatsApp account, with the unblock path explicitly encoded via unblock=true. It also names the effect ('can no longer call or message it') and the resource ('one of your WhatsApp accounts'), making the tool's purpose unambiguous.

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

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

The description gives clear invocation context: block when you want to stop a contact from calling or messaging, and set unblock=true to reverse a previous block. It doesn't explicitly name sibling alternatives or exclusions, but the dual-mode guidance is sufficient for correct selection and use.

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

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

Annotations are present (all false) so the description carries a lighter burden; it adds the non-obvious facts that group creation is side-effecting and returns both a JID and an invite link. It does not contradict the annotations, though it could further disclose that members are optional or mention any creation limits. Core behavioral context is provided.

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 first states the action and scope, the second states the return value and its downstream use. Essential information is front-loaded and every clause earns its place.

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

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

For a 3-parameter tool with a full output schema and annotations, the description covers purpose, return value, and downstream usage. The only gap is that 'with a name and initial members' could imply members are required, whereas the schema marks it optional, though the schema itself resolves this ambiguity.

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 three parameters in detail. The description only restates the concepts of name, initial members, and accounts without adding format, constraints, or examples beyond the schema. Baseline 3 applies.

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

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

States a specific verb ('Create'), resource ('WhatsApp group'), and scope ('from one of your accounts'). It also specifies the return value (JID and invite link), and the JID is explicitly tied to wa_send_message, which distinguishes it from siblings like wa_update_group, wa_delete_group, and wa_join_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?

Gives clear context for when to use the tool: creating a new WhatsApp group with a name and initial members. It also provides a downstream usage pointer by telling the agent to use the returned JID as wa_send_message's 'to'. It does not explicitly name alternatives or exclusions, but the create-vs-modify distinction is unambiguous within the sibling set.

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

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

Annotations already establish readOnlyHint=false and idempotentHint=false. The description adds meaningful context beyond that: submission triggers an asynchronous Meta review of unspecified latency, the result is unusable until APPROVED, and creating requires a Business (Cloud API) number. It does not, however, detail failure modes, limitations, or what the response contains.

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 purpose is front-loaded, followed by review behavior, gating, categories, and variable rules. Sentences are dense but every clause carries information. Slightly crowded, but 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?

Because an output schema exists, return values need no explanation. The description adequately covers the async review model, approval gating, category options, and variable/example conventions for a mutation tool with a rich schema. It could mention account_id sourcing or common rejection causes, but the essentials are present.

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 10 parameters thoroughly. The description reinforces variable numbering and the body_examples pairing, but adds little that the schema does not already state. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("Submit a new WhatsApp Business message template") with clear scope constraints (on Business Cloud API numbers, subject to Meta review). This cleanly distinguishes it from wa_delete_template and wa_list_templates, which handle the lifecycle stages before and after creation.

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 names two siblings with conditions: the template can be sent via wa_send_message's template option only after wa_list_templates shows it APPROVED, and it applies only to Business numbers. This is clear routing, though it doesn't state explicit exclusions or when to prefer an alternative to creating (e.g., editing an existing template).

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

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

The description openly discloses the destructive behavior beyond the annotations: it removes every other member, leaves the group, and explains that WhatsApp has no true group-delete. This adds critical context about what actually happens, which the annotations (destructiveHint) only hint at. 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?

Two sentences, no filler. The core action is front-loaded, followed by the prerequisite and an explanatory note. Every sentence contributes value.

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

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

For a destructive operation, the description fully explains the behavior, prerequisites, and rationale. The presence of an output schema covers return values. An agent has everything needed to decide when and how to invoke 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?

Schema coverage is 100%, with both parameters already well described in the input schema. The description does not provide additional parameter-specific semantics beyond what the schema offers. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Delete a WhatsApp group') and then clarifies the exact mechanism ('remove every other member and then leave'). This differentiates it from sibling tools like wa_leave_chat or wa_remove_participants by explaining the workaround behavior. The purpose is unmistakable.

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

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

The description gives a clear prerequisite ('The account must be a group admin') but does not explicitly contrast it with alternatives such as wa_leave_chat or wa_update_group. The usage context is implied through the explanation of the delete workaround, but no explicit when/when-not guidance is provided.

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

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

Annotations already declare 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 declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is already carried structurally. The description still earns credit by adding what actually gets destroyed (the single language or every language sharing that name) and the external side effect that the name cannot be reused for a period — details annotations cannot express. It omits permission requirements and failure behavior.

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

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

A single well-constructed sentence, front-loaded with the action and resource, with the scope rule and caveat appended via an em dash. Slightly dense, but every clause carries information.

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

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

With annotations covering the destructive/non-idempotent profile and an output schema present, the description only needs to cover scope and side effects — both of which it does, including the name-reuse lockout. Missing only auth/permission expectations and the not-found case, which keeps it short of a 5.

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% (all three parameters are documented), so the baseline is 3. The description restates the language-omission semantics that the schema already specifies, adding no new syntax, format, or edge-case detail beyond it.

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

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

Specific verb (Delete) plus specific resource (WhatsApp Business message template) and a stated scope boundary: one language, or every language of the name when language is omitted. This distinguishes it cleanly from wa_create_template and wa_list_templates without needing either schema.

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

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

The description communicates the operative condition (include language to delete one, omit it to delete all) and a non-obvious consequence of calling it (Meta blocks reuse of the name for a while), which is real usage context. It does not, however, point to alternatives such as listing templates first or note any preconditions, so it stops short of full when/when-not 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 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 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?

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds little behavioral context beyond the action itself, such as whether re-following is safe or likely to error, but it does not contradict the annotations and accurately implies a state-changing 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 a single, well-structured sentence that front-loads the action and then provides the key prerequisites. Every word adds value, with no redundancy or irrelevant 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 tool with fully documented parameters, annotations, and an output schema, the description is largely sufficient. It could have added explicit guidance about behaviors like duplicate follows, but the existing schema and annotations cover most of the operational context an agent needs.

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 described clearly. The description reinforces the parameters but does not add meaningful semantics 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 clearly identifies the action (Follow), the resource (a WhatsApp Channel), and the source context (from one of your accounts using its link). This distinguishes it from sibling tools like wa_join_group and wa_list_channels without ambiguity.

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

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

The description provides clear context for when to use the tool: an account must be specified and a channel link or invite key is required. It does not explicitly state exclusions or alternatives, but the operation is narrow enough that the intended usage is evident.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered; the description adds useful behavior beyond that — oldest-first ordering, that history loaded via wa_load_history is included, and that `until` is exclusive. It does not discuss pagination or message-count behavior, which is the only notable gap.

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 scoping clause is front-loaded, and each following clause carries load: the context-before-replying use, the wa_list_messages alternative, and the time-filter note. No filler sentences.

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

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

With an output schema present and annotations covering the read-only nature, the description only needs to cover invocation semantics — which it largely does (mode selection, ordering, time bounds, alternative tool). It stops short of covering limit/result-size behavior, a minor omission for a read tool.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the since/until formats and the chat/account distinction. The description restates the until-exclusivity and since/until meaning rather than adding new syntax or edge cases, so the baseline 3 applies.

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

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

Names a specific verb and resource (read recent messages for one account or one chat) and immediately scopes the two modes: account-wide vs. with `chat`. It also distinguishes itself from wa_list_messages and ties into wa_load_history, so an agent can place it among siblings without opening the schema.

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

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

Explicit routing guidance: 'Use this for context before replying; use wa_list_messages to page through everything new.' That names the alternative and the condition that selects each, which is exactly what usage guidance should do.

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 no read-only or idempotent behavior, and the description correctly implies mutation (especially with reset=true). It adds important behavior: revoking the link with reset=true and the admin requirement. However, it doesn't disclose what happens to the old link (e.g., is it invalidated immediately?) or whether the reset is reversible, but given annotations provide the baseline this is sufficient context.

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

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

The description is a single clear sentence with the essential info front-loaded. It includes the key behavioral nuance (reset) and a requirement (admin). No filler. Slightly more context could be added about return value, but it's appropriately brief.

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 with only 3 params, full schema coverage, and an output schema (though not detailed here). The description covers the primary use case and the reset option. Missing details like the shape of the invite link response are covered by the output schema. Overall, it's complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100%, and the description doesn't add much beyond the schema's own parameter descriptions. It mentions reset=true but that's already in the schema. The description does reinforce that group_jid and account_id come from wa_list_groups and wa_list_accounts, which is a subtle addition, but not significant. 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 clearly identifies the tool's purpose: to retrieve a group invite link, with an optional reset behavior. It specifies the resource (WhatsApp group) and the action (get/set invite link), and distinguishes it from siblings like wa_join_group or wa_update_group by focusing on the invite link specifically.

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

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

The description implies when to use it: when needing to obtain or reset an invite link. It doesn't explicitly mention alternatives or when not to use it, but the context is clear given the sibling list. The requirement of admin privileges is a useful usage condition, though it doesn't elaborate on scenarios like 'use this instead of wa_update_group'.

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?

Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description adds the provenance of the identifiers (webhook / wa_list_messages / wa_send_message) which is genuinely useful context, but says nothing about not-found behavior, error cases, or whether message_id is unique across accounts. With annotations covering the safety profile, 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?

Two sentences, front-loaded with the verb and resource, then the use case. Zero filler and no repetition of schema fields.

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?

Output schema exists so return values need no explanation; annotations cover safety; schema covers parameters. The description adds the one thing structured data cannot: when to reach for this tool versus paging the list. 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 coverage is 100%, so the schema already documents account_id, message_id and cursor, including the either/or relationship. The description reinforces the webhook name mapping (message_seq -> cursor) but adds little beyond the schema. Baseline 3 when schema does the heavy lifting.

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

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

States a specific verb+resource ('Fetch ONE stored message') with the two identifiers it accepts and where those identifiers come from. 'Fetch ONE' explicitly distinguishes it from the sibling wa_list_messages, which pages through history.

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

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

Gives explicit when-to-use scenarios ('read the message a webhook told you about, or the one you are about to react to, edit or delete') and an explicit when-not-to ('without paging through history'), implicitly routing to wa_list_messages for enumeration.

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 declare readOnlyHint=true, which the description matches ('Show a plan'). The description adds substantial behavior the annotations don't cover: excluded_tools means different things at number vs workspace scope, plan can be 'mixed', and a tool called without account_id requires every active number's plan to include it. This cross-tool authorization implication is exactly the non-obvious behavior an agent must be warned about.

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

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

Front-loaded with the core purpose in the first sentence, then progresses logically: scope modes, edge-case semantics, diagnostic use cases, version reporting. The ~130-word length is justified by genuinely complex dual-mode behavior; no sentence is filler. It could be tightened or split into scannable chunks, but it earns its density.

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 two invocation modes and subtle semantic shifts, the description covers purpose, both paths, edge cases ('mixed'), cross-tool authorization consequences, and concrete diagnostic scenarios. An output schema exists, so return-value documentation is already handled. An agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine interpretive value beyond the schema's single line: it explains the consequences of passing vs omitting account_id, what excluded_tools represents in each mode, and the 'mixed' plan edge case. Strong enrichment, though the schema already handles the basic optionality.

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

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

Opens with a specific verb and resource — 'Show a plan, its limits and current usage' — going well beyond the generic title 'Get Plan'. The description clarifies the scope dimension (per-number vs whole workspace), which is what separates it from every other read tool on the server. There is no ambiguity about what this tool returns.

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

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

Gives explicit scenario-based triggers: 'Call this to see why a tool answers plan_required on a given number, why wa_send_message might be refused, or how much headroom is left.' It also tells the agent exactly which invocation mode to choose based on desired scope (pass account_id vs omit it). No sibling covers plan/limit diagnostics, so no alternative needs naming.

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?

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 indicate a non-read-only, non-idempotent, non-destructive action, and the description does not contradict them. It adds little beyond the annotations—no mention of failure behavior, account pairing requirements, or membership side effects—but the action is simple and the safety profile is covered.

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

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

The description is a single front-loaded sentence with no filler. Every phrase adds meaningful context: joining, account selection, and the invite-link mechanism.

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 operation with full schema coverage, an output schema, and annotation coverage, the description is largely complete. It could mention expected success/failure behavior, but nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, with both parameters fully documented. The description restates 'invite link' and 'one of your accounts' but does not add meaning 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 states a specific verb ('Join'), a resource ('WhatsApp group'), and the mechanism ('using its invite link'), along with the account context. It is clearly distinguishable from siblings like wa_create_group and wa_leave_chat, even without naming 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 the tool is for joining an existing group via an invite link, but it gives no explicit when-to-use or when-not-to-use guidance versus alternatives such as wa_create_group or wa_leave_chat. Context is present, but exclusions are missing.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the description is not responsible for the safety profile. It adds modest context by distinguishing leaving a group from unfollowing a channel and scoping to an account, but it does not disclose side effects such as loss of membership or the need to rejoin.

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 no redundant words. Every phrase contributes: the action, the resource types, the account scoping, and the key identifier ('JID').

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 a full input schema, output schema, and destructive annotation, the description covers the operation and target sufficiently. It lacks explicit when-to-use guidance, but nothing needed to construct a correct call is missing.

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

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

Schema description coverage is 100%, and the description's mention of 'JID' and 'one of your accounts' only reinforces the parameter definitions. It adds no new meaning beyond what the input 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?

The description states a specific action ('leave' / 'unfollow') applied to a clear resource class ('group' or 'channel') and scopes it to 'one of your accounts'. This makes it immediately distinguishable from sibling tools like 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 description gives no explicit guidance about when to choose this tool over a sibling such as wa_delete_group or wa_join_group. The use case is only implied by the phrase 'leave a group or unfollow a channel', with no exclusions or conditions.

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 safety is covered. The description adds genuinely useful operational context beyond that: an account is only usable while its state is 'connected', which tells the agent how to interpret results and why a listed account may be unusable. It does not describe ordering or pagination, but with zero parameters that is a minor gap.

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, zero waste, and the highest-value fact (call this first) is front-loaded right after the purpose statement. Nothing could be removed without losing routing 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 zero-parameter list tool with a full schema and an output schema, the description covers purpose, sequencing, and the key usability constraint. The only unaddressed nuance is what 'available to you' scopes to (permissions versus pairing), which the agent might want stated explicitly.

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

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

The tool takes no parameters, so the baseline is 4. There is nothing for the description to clarify beyond the implicit scoping of 'available to you', which it does not expand on.

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) with explicit scoping ('available to you'). It is immediately distinguishable from every sibling tool, which operate on messages, groups, or calls rather than account enumeration.

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

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

Gives unambiguous when-to-use guidance: 'Call this first: every other wa_ tool needs an account_id from here.' This is an explicit ordering prerequisite that routes the agent correctly against 30+ 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, and the description adds valuable behavioral detail: each entry contains number, optional saved name, and country, and that WhatsApp provides no block date. This goes beyond the structured fields and helps set agent expectations about the data shape and limitations.

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

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

Three sentences with no wasted words. The main action is front-loaded, the return entry details are compactly listed, and the date limitation is stated as a meaningful constraint rather than filler.

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

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

For a simple one-parameter read operation with a readOnly annotation and an output schema present, the description fully equips an agent to invoke the tool correctly. It explains what the response will contain and what it will not contain, leaving no critical gap.

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

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

With schema description coverage at 100%, the schema already fully documents account_id as 'the account whose blocklist to read, as returned by wa_list_accounts'. The description adds no parameter-specific 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 states a specific verb ('List'), a clear resource ('every contact one of your accounts has blocked'), and the account-scoping. It is immediately distinguishable from sibling tools like wa_list_contacts and wa_list_accounts by the blocked-contact focus.

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 establishes the context: reading the blocklist for a specific account, and the account_id parameter references wa_list_accounts. It does not explicitly name alternatives or when-not-to-use it, but the intended use is unambiguous and the sibling set makes the distinction evident.

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

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

Annotations only declare readOnlyHint and idempotentHint, so the description carries the rest and does well: it discloses oldest-first ordering, the cursor/has_more pagination loop, and that until is exclusive. It does not state rate limits or scope/permission requirements, which keeps it short of a 5.

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

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

Three tight sentences, zero filler, and the scoping/ordering fact is front-loaded before pagination and filtering details. Every sentence adds a distinct operational instruction.

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 needn't restate return fields; it instead covers ordering, pagination, and time-window semantics. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents limit, since, until, account_id, and after_cursor in detail. The description's only parameter-level additions (until exclusivity, cursor paging) are already present in the schema, so the baseline 3 applies.

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

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

States a specific verb and resource — 'Read call history across your WhatsApp accounts' — plus the ordering (oldest first), so an agent immediately knows what it returns. It does not, however, disambiguate from the similarly named sibling wa_ai_list_calls, leaving the agent to infer the difference.

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

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

Gives concrete usage context: page with after_cursor, loop until has_more is false to export the entire history, and narrow the window with since/until. There is no explicit when-not or named alternative, but the operational guidance is clear.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds the scoping detail that results are limited to channels the specified account follows, but it discloses no additional behaviors such as pagination, rate limits, or prerequisites beyond the schema's account_id reference.

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 entire description is one front-loaded sentence that states the operation, scope, and returned fields without filler. 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 one-parameter read-only list with an output schema, the description and schema provide enough to select and invoke the tool correctly. It is slightly less complete only because it does not explicitly route the agent away from other list tools or mention edge cases.

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

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

Schema coverage is 100% and account_id is already described as 'the account whose channels to list, as returned by wa_list_accounts.' The description adds no further parameter-level meaning beyond the general phrase 'one of your accounts,' 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 ('List'), names the resource ('channels'), and defines the scope ('one of your accounts follows'). It also lists the returned fields, making it clearly distinguishable from sibling list tools like wa_list_contacts and wa_list_accounts.

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 indirectly indicates when to use it—when you need the channels a specific account follows—and the schema notes the account comes from wa_list_accounts. However, it gives no explicit comparison to sibling list tools or any 'use instead' guidance, so usage context is only implied.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: include_pictures triggers a WhatsApp lookup that caps the page at 10 and slows performance, affecting pagination and latency. This is extra context that helps the agent 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 tight, with four sentences each carrying distinct information. It front-loads the core purpose, then covers query behavior, output usage, and the include_pictures caveat in order of importance. No filler or redundancy.

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

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

For a list tool with an output schema, the description covers the essential operational aspects: what it returns, how to filter, and a key performance tradeoff. It doesn't need to spell out return fields since the output schema exists. It could mention cursor pagination, but that is documented in the schema, so the context is complete for practical use.

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

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

Schema coverage is 100%, so all parameters are described. The description adds meaning beyond the schema by explaining that query matching checks saved names, published names, business names, and numbers—going deeper than the schema's 'name or number' phrasing. It also explains the tradeoff of include_pictures, which the schema only states as a cap and speed note. This adds genuine value.

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

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

The description clearly states the verb and resource: 'List or search the address book of one of your WhatsApp accounts'. It distinguishes this from other list tools (wa_list_calls, wa_list_messages) by focusing specifically on contacts saved on the phone. It also ties the output to a concrete next step with wa_send_message, reinforcing the tool's purpose.

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

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

It provides clear context about what the tool operates on—contacts saved on the linked phone—and mentions using the returned numbers with wa_send_message. However, it does not explicitly contrast with sibling tools like wa_list_group_members or wa_list_blocked, nor does it state when not to use it. Still, the usage context is clear enough for an agent to know when to pick this tool.

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

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

Annotations declare readOnlyHint=true, so the description correctly adds value by detailing the exact output fields (JID, phone number in 'name', 'admin' flag) without contradicting the read-only nature. It doesn't disclose potential limitations like pagination, but for a simple list operation this is sufficient.

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

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

Two concise sentences that front-load the purpose and immediately describe the output format. No redundant phrasing; 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 list tool with an output schema available, the description covers the essential output structure and the operation's intent. There are no significant gaps for an agent to invoke it correctly.

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

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

Schema description coverage is 100% and both parameters are already documented in the schema (including the note that they come from wa_list_groups and wa_list_accounts). The description adds no new parameter information, so baseline 3 is appropriate.

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

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

The description states a specific verb ('List'), a clear resource ('a group's members'), and specifies the output items (participant with JID, phone number in 'name', and 'admin' flag). This clearly distinguishes it from siblings like wa_list_groups (lists groups) and wa_list_contacts (lists 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 implies usage for retrieving members of a specific group but does not explicitly state when to use it versus alternatives, nor any exclusions. It relies on the schema's reference to wa_list_groups for context, but no direct guidance is provided.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is established without the description. The description adds the useful constraint that only groups the account has joined are returned, but it does not disclose pagination, ordering, or error behavior. This is acceptable given the annotations, though not deeply 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 sentence that front-loads the verb and resource, includes the scope and output fields, and contains zero filler. It is as concise as possible while still being informative.

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

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

For a tool with only one parameter, an output schema, and read-only annotations, the description covers the core purpose and output details. It omits minor information like pagination or sorting, but the simplicity of the tool and presence of an output schema make this sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the account_id parameter is already well-documented in the schema as 'the account whose groups to list, as returned by wa_list_accounts'. The description adds no extra parameter semantics beyond echoing 'one of your accounts', so the baseline of 3 applies.

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

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

The description clearly states the action ('List'), the resource ('groups'), and the exact scope ('one of your accounts has joined'). It also names the returned fields (JID, name, member count), which distinguishes it from sibling tools like wa_list_group_members that list members rather than 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 usage context by specifying 'one of your accounts' and naming the account_id in the schema, but it does not explicitly state when to use this tool versus alternatives like wa_create_group or wa_update_group. There is no exclusion or mention of alternative tools, leaving some inference required.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description goes beyond that with real behavioral context: chronological ordering, the next_cursor round-trip pattern, the exclusivity of 'until', and the fact that include_history switches a page to storage order rather than time order.

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 tight sentences, front-loaded with purpose and ordering, then paging mechanics, then the use case, then filters. No sentence is filler and no structured field is redundantly restated.

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?

An output schema exists, so return shape need not be described, and annotations cover the read-only safety profile. Ordering, pagination, filtering, and the history-mode caveat are all present, leaving nothing an agent needs 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 coverage is 100%, so the baseline is 3, but the description adds value the schema does not: it explains the cursor-passing loop for after_cursor and the ordering consequence of include_history. It does not restate the since/until formats, which is fine because the schema already documents them.

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

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

States a specific verb and resource ('Read messages across all your WhatsApp accounts') plus an ordering guarantee ('oldest first'). It is clearly distinguishable from sibling wa_get_message (single message) and other wa_list_* tools without opening the schema.

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

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

Gives a concrete triggering context ('Use this to catch up after being notified of a new message') and explains the paging workflow. It never names a competing sibling (e.g. wa_get_message or wa_get_chat) as an alternative, so it stops short of full when-not 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 readOnlyHint=true, so the safety profile is covered; the description adds the scoping constraint (Business/Cloud API numbers only, not linked-device numbers) and what the result carries (review status and Meta's rejected_reason for rejections). It doesn't add detail on pagination or rate limits, but the added behavioral context is meaningful.

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

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

Purpose is front-loaded in the first clause, followed by output statuses, then downstream usage, then scope restriction. Dense but every sentence carries information; slightly long-winded in packing return values and usage into one run-on structure.

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

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

An output schema exists, so return format needn't be spelled out, yet the description still names the key status values and the rejected_reason field. Combined with the scope restriction and the hand-off to wa_send_message, an agent has everything needed to call this 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% and the description's only parameter-related statement ('of one of your Business (Cloud API) numbers') aligns with the schema's account_id description pointing to wa_list_accounts. Baseline 3 is appropriate since the schema already carries the parameter 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?

States a specific verb (List) and resource (WhatsApp Business message templates) scoped to Business (Cloud API) numbers, and enumerates the returned status values (APPROVED, PENDING, REJECTED with rejected_reason). This clearly separates it from siblings like wa_create_template and wa_delete_template without needing to open their 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?

Explicitly routes the agent downstream: use an APPROVED template's name/language with wa_send_message's template/template_language to start a conversation or message outside the 24-hour window, and pass the 'variables' count as template_variables in order. It also states the negative scope condition — templates apply only to Business numbers, not personal linked-device numbers.

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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds important behavior: loaded messages never trigger webhooks, require include_history=true in wa_list_messages, and are kept for the plan's history window. It also discloses the online-phone requirement and expected response time.

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

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

The description is front-loaded with the core action and follows with tightly relevant operational details. Every sentence adds useful information: prerequisites, how to read results, webhook behavior, retention, and the paging precondition.

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?

An output schema exists, so return values need not be explained. Combined with the rich schema, annotations, and description details, the definition tells an agent what the tool does, when it can run, what it changes, and how to retrieve the loaded messages.

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 chat, count, and account_id are already documented in the schema. The description adds only relationship context, such as reading with the same chat, rather than syntax, ranges, or defaults beyond what the schema provides.

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

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

The description states a specific action: ask the account's phone for older messages in one conversation, before the oldest stored message, and store them. It clearly distinguishes this from listing current messages by noting that loaded history appears in wa_list_messages only with include_history=true.

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 prerequisites: the phone must be online, and the conversation must already have at least one stored message. It also routes the agent to wa_get_chat with the same chat to read the loaded result, and explains how loaded history surfaces in 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?

Annotations indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description carries the burden of explaining side effects. It discloses that the QR code expires every ~20 seconds, that the tool returns a pair_id, and that import_history controls whether phone history is loaded. It doesn't explicitly state that this is a state-changing operation, but the description's language ('Begin linking') and the QR-code flow make the non-read-only nature clear.

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 sentences, each serving a distinct purpose: stating the action, explaining the QR code expiration and polling flow, and clarifying the optional parameter. It is front-loaded with the core purpose and avoids redundancy with the 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?

The description covers the essential flow: initiating pairing, receiving a QR code, polling via wa_pair_status, and the import_history option. It doesn't mention what happens after successful pairing or any error cases, but given the output schema exists and the sibling wa_pair_status handles status, the description is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents import_history. The description adds value by explaining the behavioral consequence of import_history ('whether this pairing loads the phone's recent messages as history'), which goes beyond the schema's description. It doesn't detail the exact format of the boolean, but the schema covers that.

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

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

The description clearly states the tool's function: 'Begin linking a new WhatsApp account' and specifies the output (QR code PNG). It distinguishes itself from the sibling wa_pair_status by explaining that this tool initiates the pairing while wa_pair_status polls for status/current 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 tells the agent when to use this tool (to start linking) and directs it to wa_pair_status for polling the QR code and checking when the account is linked. It also explains the optional import_history parameter's purpose, giving clear context for usage.

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?

Explains the non-idempotent behavior (new QR image each call) and the state transition to 'paired', which aligns with idempotentHint: false and readOnlyHint: true. Adds context beyond annotations about how the tool behaves across successive calls.

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 adding essential information (purpose, QR behavior, paired outcome). Front-loaded with the core verb and resource; no wasted words.

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

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

With an output schema present to define return values, the description covers the complete usage flow: starting point, polling behavior, and terminal state. It even ties to the sibling list tool, so 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?

The schema already describes pair_id as 'the pair_id returned by wa_pair_account' with 100% coverage. The description repeats this origin without adding new detail, so it meets the baseline but provides little additional meaning.

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

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

States a specific verb 'Check' and resource 'pairing started with wa_pair_account', clearly distinguishing from siblings by referencing the initiating tool and the resulting list tool. 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?

Gives clear context: use it after wa_pair_account to poll pairing state. It also indicates when to transition to wa_list_accounts once paired. It does not explicitly state when not to use it, but the workflow is evident.

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

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

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Remove members' aligns with those. The description adds valuable context beyond annotations by specifying the admin requirement, which is a critical behavioral precondition. It does not contradict annotations.

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

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

The description is two concise sentences, front-loaded with the action and scope, and the admin requirement is placed at the end. There is no redundant or verbose content, and every word 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?

Given the output schema exists and the annotations cover the destructive nature, the description is largely sufficient for an agent to invoke the tool correctly. It covers the core action and the admin requirement. A minor gap is that it does not mention what happens if a member is not found or if the operation is irreversible, but destructiveHint implies permanence, so this is not a critical omission.

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 description coverage is 100%, with each parameter already explained (e.g., members as phone numbers/JIDs, group_jid and account_id as returned by list tools). The description does not add any additional parameter meaning, so it meets the baseline but does not enhance the schema information.

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 ('Remove'), a specific resource ('members from a WhatsApp group'), and the method ('by phone number or JID'). It distinguishes this tool from siblings like wa_delete_group (deleting the group) and wa_update_participants (which likely handles adding/removing), so an agent can easily identify its specific role.

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 key prerequisite ('The account must be a group admin') which helps an agent know when this tool is applicable. However, it does not explicitly name alternatives (e.g., wa_update_participants) or state when not to use this tool, leaving some ambiguity for an agent choosing among participant-related 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 only declare it is a non-readonly, non-idempotent, non-destructive write. The description goes well beyond that by decoding the returned status values ('sent' delivered, 'queued' accepted but unconfirmed — do NOT resend, 'refused' nothing sent with a reason) and by disclosing the size ceilings per attachment type. This is exactly the operational context an agent needs to avoid duplicate sends.

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

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

Front-loaded with the core action, then attachment variants, then template rules, then status semantics — a sensible information hierarchy. It is a long single passage with heavy em-dash nesting, which costs some readability, but every clause carries a distinct fact.

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 15-parameter mutation tool with a rich schema and an existing output schema, the description covers the remaining judgment calls: which attachment to use and its limits, when template is mandatory, and how to interpret the result. Nothing needed 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 coverage is already 100%, so the baseline is 3, but the description adds cross-parameter semantics the per-property schema does not state in one place: text becomes the image/document caption but is ignored when template is set, audio has no caption, and the attachment options are alternatives rather than additive. That coherent framing earns a point 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?

States a specific verb (send) and resource (WhatsApp message) and enumerates supported variants (text, image, document, audio, template). It is immediately distinguishable from siblings like wa_edit_message, wa_react, or wa_delete_message, which also operate on messages but do different things.

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

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

Gives clear conditional guidance: use template for Business/WABA numbers to start a conversation or message outside the 24-hour window, and explains the mutually exclusive attachment paths. It never names an alternative sibling tool or states an explicit 'do not use this when…', so it stops short of a 5.

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

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

Annotations already 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 already indicate mutation and destructiveness, but the description goes beyond them by disclosing that the image is center-cropped to a square and scaled to at most 640x640, that the previous photo cannot be restored, and that contacts may see the old photo for a while due to caching. These are valuable behavioral details not present in structured metadata.

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 four sentences, each serving a distinct purpose: stating the action, explaining the replace path with transformation details, explaining the remove path, and disclosing consequences. There is no filler or repetition.

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

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

For a 3-parameter tool with an output schema, the description covers the two usage modes, constraints (format, size, scaling), and non-obvious effects (irreversibility, eventual consistency). Nothing an agent needs to call 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 adds contextual meaning beyond the schema by clarifying that the photo is what every contact sees and by highlighting the irreversible consequence of replacing/removing it. This enriches the parameter definitions without contradicting 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: "Change the profile photo of one of your own WhatsApp accounts — the picture every contact sees." It clearly distinguishes the tool from siblings like wa_get_profile and wa_set_presence by scoping it to one's own account profile photo.

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

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

The description provides clear context for when to use the tool: changing one's own profile photo, with two explicit invocation modes (pass image_base64 to replace, or remove=true to delete). It does not explicitly name alternatives or exclusions, but no sibling tool performs this function, so the context is sufficient.

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?

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.

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

Beyond the annotations, the description reveals important behavioral details: partial updates are supported, changes are applied separately by WhatsApp, and on a refusal the 'applied' field lists which changes took effect. This is useful, non-obvious behavior that the annotations alone do not convey.

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

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

The description is four sentences with no filler. It front-loads the primary purpose, then gives usage guidance, a prerequisite, and an important behavioral note. Every sentence contributes information an agent needs.

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

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

Given the tool's six parameters and output schema, the description covers purpose, which fields to change, the admin prerequisite, and the partial-application behavior. It is complete enough for a correct invocation without needing to consult external documentation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that optional parameters should only be passed when they need changing and that several parameters can be combined in one call. This partial-update semantic is not fully evident from 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 starts with a specific verb and resource ('Change a WhatsApp group's settings') and enumerates the exact settings it can modify: name, description, locked, and announce. This clearly differentiates it from siblings like wa_update_participants or wa_create_group, so an agent can select it correctly.

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 explicit usage context: pass only the fields to change, multiple fields can be changed in one call, and admin status is required when the group restricts settings. It does not name alternative tools for exclusion, but the guidance is clear enough for when this tool should be invoked.

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

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

Annotations are present (readOnlyHint=false, destructiveHint=false), so the description's additional permission prerequisites and the explicit statement that removal is out of scope add behavioral context beyond the structured annotations. It could mention idempotency or multi-member partial-failure behavior, but with annotations already declaring it non-destructive, the coverage is adequate.

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, no filler. The action set and the sibling exclusion are front-loaded, and prerequisites and removal routing appear in the final clause. 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 mutating participant tool, the description covers purpose, permissions, action mapping, and the sibling for removal. An output schema exists, so return-value behavior need not be spelled out; the remaining context an agent needs is present.

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%; each parameter already has clear descriptions including the exact action enum and members format. The description restates the action semantics but does not add materially new parameter-level meaning, so the 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?

Description opens with concrete verbs and targets: 'Add members... (action=add)', 'make members admins (action=promote)', 'make admins ordinary members again (action=demote)'. It explicitly names the sibling wa_remove_participants for removal, so an agent can disambiguate without opening schemas.

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

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

It provides explicit prerequisites per action ('Adding needs the account to be a member... promote and demote need an admin') and explicitly instructs when to use the alternative: 'To remove members, use wa_remove_participants.' No ambiguity remains about when this tool is appropriate.

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