whatsmcp

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 new behavioral detail beyond them: the full status lifecycle (dialing, in_progress, done, failed, no_answer, busy), the condition that summary/transcript/data appear only 'once it has ended', and that recording_url expires after one hour. The one-hour expiry is a real operational constraint an agent must plan around.

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

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

A single dense sentence, front-loaded with the action and its prerequisite, with the return contents listed compactly. The long comma-separated list of fields makes it slightly scannable-poor, but there is no filler text.

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 description is not obligated to enumerate return values, yet it usefully flags when those values are populated and the recording URL's lifetime. What remains unaddressed is error/not-found behavior for an invalid call_ref, which would help for a status-polling 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% and the single parameter already carries the note 'from wa_ai_call_start'; the description only restates that provenance. Baseline 3 is correct since the schema does the heavy lifting and no extra syntax or format guidance is added.

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

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

States a specific verb+resource ('Read an AI call started with wa_ai_call_start') and enumerates exactly what comes back (status, summary, success judgement, collected data, transcript, recording_url). This clearly separates it from wa_ai_list_calls (enumerate) and wa_ai_call_start (create).

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 ties the tool to its prerequisite ('an AI call started with wa_ai_call_start') and implies polling via the status field, giving clear context for when to call it. It stops short of naming alternatives such as wa_ai_list_calls for bulk retrieval, so it is clear but not fully routed.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description goes further by explaining that the hangup is immediate and affects both parties, and that an already-ended call is a no-op returning hung_up false. It also notes the downstream aftermath (summary, transcript, recording still arrive), which is genuinely useful context an agent would not get from 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 short sentences, front-loaded with the core action, then scope, then edge-case behaviour. No filler or restatement of the tool name.

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 described; the description nonetheless adds the hung_up false no-op case and the post-call artifact flow. For a single-parameter tool this is fully sufficient.

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

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

There is only one parameter and schema description coverage is 100%, so the schema already documents call_ref and its provenance. The description's mention of wa_ai_call_start/wa_ai_list_calls duplicates the schema text rather than adding new meaning, 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 ('End') and resource ('a live AI voice-agent call'), and explicitly scopes it to calls started via wa_ai_call_start or answered incoming calls. This clearly separates it from wa_ai_call_start, wa_ai_call_get and wa_ai_list_calls without requiring 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?

Names the two situations where it applies (a call you started, or an incoming call an agent answered) and covers the edge case of an already-ended call. It does not name an explicit alternative or exclusion, but the context is clear enough to select it confidently.

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 cover the safety profile (not read-only, not idempotent, not destructive). The description goes well beyond by disclosing the asynchronous contract ('returns immediately with a call_ref; the call then rings and runs on its own'), the polling cadence and terminal statuses, the payload available at completion, and the per-number concurrency/cooldown limit.

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

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

Four sentences, no filler, and the ordering follows the agent's decision path: what it does, what to pass, what happens next, how to follow up, then the constraint. Every sentence carries distinct 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 an async, multi-step tool this covers the full lifecycle: trigger, immediate return, poll target with interval and stop conditions, resulting artifacts, and the rate/concurrency limitation. With an output schema present it correctly needn't restate return field shapes.

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 each of the four parameters is already documented in the schema with format and examples. The description only adds 'Pass per-call context in variables' and repeats the preset source, which the schema descriptions already say, 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 opening sentence states a specific verb and resource ('Have an AI voice agent call a WhatsApp number from one of your numbers') and pins the required input to its source ('using a preset from wa_ai_list_presets'). This cleanly separates it from siblings like wa_ai_call_get, wa_ai_call_hangup and wa_send_message without needing 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?

It gives an explicit operational flow: call this, then poll wa_ai_call_get about every 30 seconds until one of four named terminal statuses. It also names where presets come from and states the concurrency constraint ('one call at a time per number; a number that just finished a call must wait a moment'), which tells the agent when a call will be rejected.

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=false, so the description usefully adds ordering ('newest first'), the pagination direction (omit 'before' for the newest), and the meaning of the direction/from fields in results. It does not cover auth requirements or any rate/limit behavior, but the added behavioral context is substantive.

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: the first front-loads scope and ordering, the second routes the agent to the next tool. No filler, no restatement of the title, and the most decision-relevant fact (which calls are included) comes first.

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

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

With an output schema present, return values need not be documented, and the description covers what remains: included call types, sort order, pagination via the previous-page call_ref, and the follow-up tool. 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 description coverage is 100% for both parameters, so 'limit' and 'before' are already fully explained in structured data; that establishes a baseline of 3. The description only loosely reinforces the cursor concept by tying call_ref to wa_ai_call_get, adding little syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('List this workspace's AI voice-agent calls'), then precisely delimits the returned set: outbound calls from wa_ai_call_start plus inbound calls answered by a preset with answers_inbound true. That definition, combined with the sibling tools named (wa_ai_call_start, wa_ai_call_get), lets an agent distinguish this from the generic wa_list_calls 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?

Gives clear routing guidance for the follow-up step: take a call_ref to wa_ai_call_get for transcript and recording. The inclusion criteria (which calls appear) are also effectively usage guidance. It stops short of explicitly contrasting with the sibling wa_list_calls, so it is strong but not fully exhaustive.

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, but the description adds real semantic context: what a preset bundles, the meaning of the ready flag, that not_ready_reason explains failures, and what expected_variables represent. This is well beyond the annotation coverage and directly informs correct downstream use.

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

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

Three sentences, front-loaded with the purpose, then the concept, then the actionable hooks into wa_ai_call_start. Every sentence 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 need not be re-documented, yet the description still clarifies the key output fields (ready, not_ready_reason, expected_variables) that drive correct behavior. Nothing essential for invoking this tool is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-parameter tool is 4, and the description reasonably spends its space on output field semantics instead.

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, so the agent understands the concept rather than just the name. It is clearly distinguishable from siblings like wa_ai_call_start, whose relationship to presets it explains.

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 routes the agent forward: 'Use a preset's name with wa_ai_call_start' and warns that 'only presets with ready=true can call now'. That is clear context for when and how to consume this tool's output, though it stops short of an explicit when-not-to-use statement.

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 fix the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuine behavioral context: the blocked contact can no longer call or message. It does not say whether the contact is notified, whether re-blocking is a no-op, or what permissions/auth the account needs, so it adds value but not full disclosure.

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

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

One front-loaded sentence states the action and the inverse mode, followed by a short clause on what is reported. Nothing is wasted, and the em dash cleanly separates the two modes.

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

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

With an output schema present, the description need not explain return values (though it usefully previews them), and all three parameters are documented. The remaining gap is operational: no mention of side effects on existing chats, reversibility guarantees, or notification behavior for a mutation tool, which keeps it from being fully complete.

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

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

Schema description coverage is 100%: jid, unblock, and account_id are all documented in the schema itself, including that unblock=true reverses the action. The description's phrasing of the toggle largely restates that, adding only the framing of block as the default mode, so baseline 3 applies.

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

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

States a specific verb (block/unblock) on a specific resource (a contact on one of your WhatsApp accounts), and explicitly covers the inverse mode via unblock=true. An agent can distinguish this from wa_list_blocked (a read) and wa_leave_chat without opening either schema.

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

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

The default mode (block) and the opt-in alternative (unblock=true) are stated clearly, which covers the main routing decision between the tool's two behaviors. It stops short of naming the sibling to use for inspecting blocked contacts (wa_list_blocked) or stating any exclusion/precondition, so it is clear context without explicit alternatives.

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

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

Annotations already declare the operation is not read-only, not idempotent, and not destructive. The description adds that it returns a JID and invite link, which is mildly useful context, but says nothing about permissions, rate limits, or failure behavior, so it adds limited value beyond 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 tight sentences with no waste, front-loading the core action and then the output usefulness. 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?

With annotations covering safety and an output schema present, the return values need not be explained, yet the description usefully ties the JID to wa_send_message. It is nearly complete for this tool, with only minor gaps in usage 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 description coverage is 100%, so the schema already documents name, members, and account_id fully. The description restates the fields at a high level ('a name and initial members') but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a precise verb (Create) and resource (WhatsApp group) with scope ('from one of your accounts') and the fields involved (name, initial members). It clearly distinguishes itself from siblings like wa_update_group, wa_join_group, and wa_delete_group.

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

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

It implicitly indicates when to use it (to make a new group), and helpfully notes the returned JID is used as wa_send_message's 'to'. But it offers no explicit when-not guidance or comparison to alternatives such as wa_join_group for entering an existing 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 declare a non-read-only, non-idempotent write operation. The description goes further by disclosing the review process, approval gating, and Business-number-only constraint, though it omits auth requirements or rate limits.

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

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

Front-loads purpose and workflow in a compact paragraph with no filler. Some sentences (categories, variable formatting) duplicate schema details, slightly reducing efficiency.

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 11-parameter schema with 100% coverage and an output schema, the description adds essential lifecycle context (review, approval gating, Business-only). It is complete enough for an agent to call correctly without consulting other sources.

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 all 11 parameters. The description repeats variable ordering and example requirements already present in the schema, adding little new semantic detail.

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 (Submit) and resource (WhatsApp Business message template) and scopes it to Meta's review on Business (Cloud API) numbers. Clearly distinguishable from siblings like wa_delete_template or wa_list_templates.

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

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

Explains the approval prerequisite ('only once wa_list_templates shows it APPROVED') and references wa_send_message, giving lifecycle context. It also notes templates apply only to Business numbers, but does not explicitly state when not to use this tool versus an alternative creation path.

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, but the description adds the two things an agent most needs: the side effect in full ('remove every other member and then leave') and the authorization requirement (admin). It also explains that no true delete exists, so the semantics are genuinely different from what the name implies.

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

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

Three short sentences, zero filler, with the destructive effect front-loaded ahead of the caveat about WhatsApp having no true delete. Every sentence carries distinct 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?

An output schema exists, so return values need no explanation. With annotations covering safety/non-idempotency and the description covering the real side effect and admin prerequisite, an agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100% and both parameters already document their format and how to obtain the values (from wa_list_groups / wa_list_accounts). The description adds no parameter-level detail, so this sits at the baseline.

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

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

States a specific verb and resource ('Delete a WhatsApp group') and immediately defines what that operation actually means in this domain: remove every other member, then leave. This distinguishes it cleanly from siblings like wa_leave_chat and wa_remove_participants, which an agent could otherwise confuse it with.

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

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

Gives a concrete precondition ('The account must be a group admin'), which is the key gate for calling it correctly. It does not explicitly name an alternative tool or say when not to use it (e.g., 'to only leave without deleting, use wa_leave_chat'), 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 declare destructiveHint=true and non-idempotent, but the description adds genuine behavioral context beyond them: it explains that this is a revocation rather than a true delete, that local copies on a peer are not removed, and that modern clients honor it. This meaningfully informs the agent about the actual effect and its limits.

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

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

Two tight sentences, front-loaded with the action and scope; the second sentence is not padding because it carries the non-obvious revocation semantics. 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. The description supplies the scope and effect semantics an agent needs; it is essentially complete for a delete tool, with only minor room to name alternatives explicitly.

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

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

Schema description coverage is 100%, so all four parameters (including the conditional 'sender' for admin group deletes) are already documented in the schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description gives a specific verb+resource ('Delete a WhatsApp message') and adds the critical scope qualifier 'for everyone', which distinguishes it from any for-me-only deletion and from siblings like wa_edit_message. An agent can identify the operation and its blast radius without opening the schema.

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

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

The 'for everyone' scope implies context for use, but the description never states when to reach for this tool versus alternatives such as wa_edit_message, nor any exclusions or prerequisites. Usage is only implied, not spelled out.

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, non-idempotent, non-read-only, so the safety profile is covered. The description goes further by disclosing a non-obvious real-world consequence: Meta blocks reusing a deleted template's name for a while, which an agent could not infer from the annotations. It stops short of stating permanence or auth requirements.

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

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

One sentence, zero filler, with the resource scope front-loaded and the language-omission rule and Meta consequence trailing as supporting clauses. 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?

With annotations covering the destructive profile, a rich schema, and an output schema handling return values, the description supplies the one thing structured data can't: the name-reuse penalty and the all-languages default. Only missing element is whether the operation is reversible.

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 name, language, and account_id. The description restates the key semantic of omitting language (all languages of the name), which mirrors the schema rather than adding new information, 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?

States a specific verb (delete) and resource (WhatsApp Business message template), scoped to a Business (Cloud API) number. It is instantly distinguishable from sibling deletes such as wa_delete_message, wa_delete_group, and wa_delete_webhook. The language-scope clause further sharpens what exactly gets removed.

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

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

Usage is implied by the verb and resource, and the language-omission rule effectively tells the agent when to pass or skip a parameter. However, there is no explicit when-to-use vs alternatives (e.g. wa_list_templates to confirm existence first) and no stated prerequisites or permissions.

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 safety profile is covered. The description adds genuinely useful behavioral context beyond that: it clarifies exactly what is destroyed (the delivery push) versus what is preserved (inbound messages remain readable). Reversibility and auth requirements are still unstated.

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, zero filler. The primary effect is front-loaded and the clarifying consequence follows immediately.

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, and annotations carry the safety profile. For a zero-param destructive toggle, the description supplies everything an agent needs: what it stops and what remains intact.

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 disambiguate. Baseline 4 applies for a zero-param 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?

States a specific action ("Stop delivering inbound messages to the configured endpoint") with a clear resource. It is unambiguous about what gets disabled. It never names the sibling tools it relates to (wa_enable_webhook, wa_set_webhook, wa_get_webhook), so differentiation is left to inference.

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 establishes the effect and distinguishes it from hard deletion ("Messages keep arriving and stay readable through wa_list_messages; only the push stops"), which implicitly tells the agent when this is safe to call. However, it gives no explicit when-to-use guidance against the sibling webhook tools or any stated prerequisites.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false but say nothing about the edit window. The description's "WhatsApp only accepts an edit within about 20 minutes" is genuine behavioral context an agent cannot get from the annotations. It stops short of describing failure modes or what happens to the original message on success.

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

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

Two short sentences, purpose first and the critical constraint second, with zero 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?

An output schema exists, so return values need not be explained, and all four parameters are documented in the schema. What remains thin is the post-window behavior and confirmation of whether the edit replaces or appends — small gaps for a low-complexity single-object 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%, and each parameter already carries its own description including provenance (wa_list_accounts, wa_send_message), so the schema does the heavy lifting. The description adds no parameter-level meaning beyond "the replacement message body" implied by "edit". Baseline 3.

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 ("Edit a WhatsApp message") and scopes it to messages "you sent", which cleanly separates it from wa_send_message, wa_delete_message, and wa_get_message without naming them. It does not explicitly point at a sibling alternative, so it falls short of a 5.

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

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

The 20-minute window is an implied usage condition, but there is no explicit when-to-use guidance and no mention of what to do instead when the window has passed (e.g. delete and resend). Usage is inferable but not stated.

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

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

Annotations declare non-destructive and idempotent, and the description builds on that with the concrete reason: the endpoint and signing secret survive the toggle, so there is no re-pairing cost. It also discloses the side effect that messages keep arriving while paused and remain readable via wa_list_messages, which is genuinely non-obvious behavior an agent could not infer.

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: what it does, why not to use the destructive alternative, and what happens to in-flight messages. No redundancy and the core guarantee is front-loaded.

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

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

With an output schema present, return values need not be described; annotations cover safety and idempotency; both parameters are fully documented in the schema. The description closes the remaining gap — reversibility and message handling during pause — leaving nothing material unstated for a two-parameter toggle.

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 `enabled` and `reason` are already documented in the schema. The description restates only the preservation guarantee for `enabled` and adds nothing about the console-visible `reason` note, so it does not exceed 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?

States a specific action pair (pause/resume delivery) on a specific resource (the configured webhook), and immediately clarifies scope: the endpoint and signing secret are untouched. It differentiates from siblings wa_delete_webhook and wa_set_webhook by naming the delete/re-create path as the wrong alternative.

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 says when to use it ('to stop deliveries temporarily') and when not to (deleting and re-creating, because that issues a new secret). The `enabled` boolean semantics are reinforced as the mechanism for choosing pause vs resume.

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

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

Annotations already disclose readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-destructive, non-idempotent write. The description adds only that the follow is scoped to a specific account and driven by a link; it says nothing about required account state, rate limits, or what happens on a duplicate follow.

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

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

A single front-loaded sentence with zero filler; the resource and the input mechanism appear immediately. Nothing could be removed without losing 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?

An output schema exists, so return values need no explanation, and the two required parameters are fully documented in-schema. What is missing is precondition context (paired/authenticated account) for a state-changing action, which is minor for such a simple tool.

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

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

Schema description coverage is 100%: account_id documents the wa_list_accounts provenance and channel_link documents both accepted formats. The description's "using its link" and "from one of your accounts" merely paraphrase that, adding no syntax or format detail beyond the schema.

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

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

The description states a specific verb (Follow) and resource (WhatsApp Channel) and the mechanism (using its link), so the operation is unambiguous. It does not differentiate itself from adjacent siblings such as wa_list_channels or wa_join_group, but no sibling performs the same action, so the risk of confusion is low.

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?

"Follow a WhatsApp Channel from one of your accounts using its link" gives no when-to-use/when-not guidance, no prerequisites (must the account be paired? must you be an admin?), and never references the sibling that lists channels or the link-acquisition step. Usage must be inferred entirely.

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

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

Annotations already declare readOnlyHint=true/idempotentHint=false, so the safety profile is covered. The description adds non-annotation value: result ordering (oldest first), the inclusion of history loaded via wa_load_history, and the filter semantics of since/until. It does not discuss pagination or result size limits, which 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?

One dense sentence that front-loads the core capability before the alternatives. Every clause carries meaning, though the em-dash branching makes it slightly harder to parse than a clean split into two 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, return values need not be described. The description covers mode selection, ordering, history inclusion, time filtering, and the alternative tool — 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%, so all five parameters are already documented in-schema, making 3 the baseline. The description restates the since/until narrowing and the exclusivity of 'until', which the schema already spells out, so it adds little beyond the structured fields.

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

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

States a specific verb (read) and resource (most recent messages / one conversation) and explains the dual mode via the optional 'chat' parameter. It explicitly differentiates itself from the sibling wa_list_messages and mentions wa_load_history for older 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 a clear when-to-use ('this for context before replying') and names the alternative with its own condition ('use wa_list_messages to page through everything new'). The routing decision is fully inferable without opening either schema.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is already conveyed. The description adds genuinely new behavioral context: the admin authorization requirement and the side effect that reset revokes the existing link before issuing a replacement, which is more specific than the schema's one-line reset note.

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

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

Two tight sentences, zero waste. The primary read behavior is front-loaded and the optional destructive branch plus its prerequisite follow immediately.

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 no explanation. With the read/reset branches, the admin prerequisite and full schema coverage, an agent has everything needed 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 description coverage is 100% and the schema already explains reset, group_jid and account_id, including where the JIDs come from. The description only restates reset's effect, adding no syntax, format or default information beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a WhatsApp group's invite link') and additionally covers the alternate reset behavior in the same sentence. An agent immediately knows this tool reads an invite link and can optionally rotate it, distinct from siblings like wa_update_group or 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 a clear precondition ('The account must be a group admin') and explains the branch condition for reset=true. It does not name an alternative tool or state when not to use it, but the context is unambiguous for this narrow operation.

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

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

Annotations cover safety (readOnlyHint=true, idempotentHint=false). The description adds behavioral context beyond them: the payload comes back as base64 and a 'refused' outcome signals no retrievable media, which tells the agent how to interpret an edge-case result.

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

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

Three short sentences, front-loaded with the core purpose and finished with the input source and the edge-case signal. 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?

With an output schema present and annotations declaring the read-only safety profile, the description need not explain return structure; it nonetheless adds base64 and the 'refused' semantic. Everything needed for a correct call 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%, so both parameters are already documented with the same sourcing hints the description repeats. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (fetch), the resource (the attachment a received message carried), the concrete media types (image/video/audio/document/sticker), and the return encoding (base64). An agent can distinguish it from wa_get_message, which handles message content rather than the attachment payload.

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?

Specifies the input source ('Use the message_id from wa_list_messages') and sets expectations for a failure case ('refused' means no retrievable media). It doesn't explicitly contrast with siblings like wa_get_message, but the context for correct invocation is clear enough.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds that this returns exactly one message and avoids pagination, but says nothing about failure behavior for an unknown message_id or cursor, or why idempotency is flagged false for what looks like a pure read.

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

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

A single dense sentence that front-loads the action and cardinality ('Fetch ONE stored message'), then supplies sources and the reason to use it. 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, the description need not describe return values, and it covers both lookup keys plus the required account. It stops short of addressing lookup failures or the relationship between message_id and cursor when both are supplied.

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 where each id comes from. The description's mention of 'by WhatsApp's message_id ... or by its cursor' restates the schema's own 'Pass this or message_id' note without adding format or precedence rules.

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 ('Fetch ONE stored message') with capitalized scope emphasis, and names the identifier sources (webhook delivery / wa_list_messages). It is immediately distinguishable from sibling wa_list_messages, which it explicitly contrasts with ('without paging 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 cases (reading the message a webhook reported, or the one you are about to react to, edit or delete) and an implicit alternative (paging history via wa_list_messages). The condition that selects this tool over listing is stated directly.

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; the description goes far beyond by disclosing aggregation semantics (excluded_tools contains only what NO active number can use), the 'mixed' plan value, and the important consequence that a tool called without account_id needs every active number's plan to include it. That is real behavioral context an agent cannot get from 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?

Purpose is front-loaded and most sentences carry unique information, but the dense run-on covering excluded_tools across both modes is somewhat tangled and repeats the account_id distinction already in 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?

With an output schema present the description need not enumerate return fields, yet it still explains the non-obvious ones (excluded_tools, plan 'mixed', server_version/server_build_date). Combined with the usage and scoping guidance, 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 coverage is 100% and the schema already says 'optional: report one line's plan; omit to report every line', so the baseline is 3. The description adds downstream meaning the schema lacks: what the returned excluded_tools and 'mixed' values imply in each mode, which is a genuine increment.

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 ('Show a plan, its limits and current usage') and immediately scopes it: per-number when account_id is passed, whole-workspace otherwise. An agent can distinguish it from sibling list tools like wa_list_accounts without opening either schema.

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

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

Explicitly names the triggering conditions: '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 states the when-to-pass vs when-to-omit rule for account_id, so both invocation modes are covered.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description adds a genuinely non-obvious behavioral caveat: an empty about or picture reflects non-sharing with this account rather than absence of the data, which prevents misreading the result. It stops short of describing rate limits or failure modes.

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

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

Two sentences, both earning their place: the first front-loads the lookup and its output fields, the second handles the one ambiguity that matters. Slightly dense in the enumeration of business fields, 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?

An output schema exists, so return-value documentation is not required, yet the description still enumerates the key fields which aids selection. Between annotations, full schema coverage, and the empty-field caveat, an agent has what it needs; only explicit alternative-tool routing is absent.

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

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

Schema description coverage is 100%, so the baseline is 3: the schema already documents 'phone' as international form and 'account_id' as sourced from wa_list_accounts. The description echoes the account-scoping idea but contributes no additional syntax or format detail beyond what the schema supplies.

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 ('Look up who a phone number is on WhatsApp') plus an explicit inventory of what is returned (registered status, public name, about, picture, business categories/hours). This clearly separates it from siblings like wa_get_chat, wa_list_contacts, or wa_list_accounts, so an agent can pick it without opening the schema.

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

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

The phrase 'from one of your accounts' implies the account-scoped lookup context and the description effectively defines the retrieve-one-peer use case, but it never states when to prefer this over wa_get_chat or wa_list_contacts, nor any preconditions. Usage is implied rather than spelled out.

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 declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no note on what happens if the account is already a member, whether the link can expire, or any rate limiting, leaving the behavioral burden on 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?

A single 14-word sentence with the action, target, source account and required input all front-loaded. Nothing is wasted and nothing needs to be skimmed for.

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, and this is a simple two-parameter mutation whose inputs are fully documented in the schema. What is missing is failure/edge-case context (already a member, invalid or expired link) that an agent would want before invoking a non-idempotent join.

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

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

Schema coverage is 100%, and both properties carry their own descriptions including the account lookup chain ('as returned by wa_list_accounts') and the accepted invite-link format. The description adds no parameter detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Join') and resource ('WhatsApp group') plus the mechanism ('using its invite link'), which separates it from wa_create_group and wa_leave_chat. It does not explicitly name a sibling it could be confused with, but the purpose is unambiguous.

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

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

Usage is implied rather than stated: the 'using its invite link' phrase tells the agent an invite link is required, which quietly routes it away from groups it already belongs to. There is no explicit when-to-use/when-not guidance or pointer to alternatives such as wa_get_group_invite_link or wa_list_groups.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is an irreversible-style mutation. The description adds nothing beyond that — it does not say whether chat history is retained, whether the action can be undone, or whether the account must be a member/admin.

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

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

A single front-loaded sentence with zero filler that covers both variants (group leave / channel unfollow) and the required key. Nothing to trim.

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, and annotations carry the safety profile. For a two-parameter mutation the description is nearly sufficient, though consequences (history retention, admin requirements, error behavior) remain undisclosed.

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 (jid, account_id) are fully documented in the schema, including the JID format and where to source values. The phrase 'by its JID' in the description adds nothing beyond the schema, 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+resource ('Leave a group or unfollow a channel') and names the exact identifier type ('by its JID'). It implicitly separates itself from wa_follow_channel (inverse action), wa_join_group, and wa_delete_group, so an agent can route correctly without opening schemas.

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

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

The description implies usage ('on one of your accounts') but never states when to choose this over wa_delete_group, wa_remove_participants, or wa_follow_channel, nor any prerequisites such as admin status. Usage is inferable but unstated.

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: an account is only usable when state is 'connected' (status 'live'), and otherwise status/what_to_do explain the failure. It does not address the idempotentHint=false flag, leaving a small 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, each earning its place: what it does, when to call it, and how to interpret the result. The critical prerequisite is front-loaded rather than buried.

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 enumerated, yet the description still explains how to read the key fields (state/status/what_to_do). Prerequisite, usability condition, and failure interpretation are all present for a zero-parameter listing tool.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The schema is closed (additionalProperties: false), so no risk of an agent inventing inputs.

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 ('List the WhatsApp accounts') and immediately distinguishes itself from siblings like wa_pair_account and wa_pair_status by establishing it as the entry point. An agent can identify its role 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?

Explicitly states when to use it ('Call this first') and why ('every other wa_ tool needs an account_id from here'), which is a concrete ordering prerequisite rather than vague guidance. It also gives the precondition for acting on a result (state 'connected').

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine payload context beyond that: entries vary in shape (name absent for unsaved contacts) and the absence of a blocked-date is explained by WhatsApp behavior rather than left as a mystery. This is useful disclosure, though pagination or result-size behavior is not addressed.

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

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

Three sentences, front-loaded with the action and scope, then the entry shape. Every sentence carries some information, though the country/name detail could be trimmed since an output schema exists. No wasted preamble.

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

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

For a simple read-only list with an output schema and full parameter documentation, the description supplies the extra behavioral nuances (missing name, no block date) an agent would otherwise infer wrongly. Little is missing beyond pagination behavior on large blocklists.

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 single account_id parameter is documented in the schema with a pointer to wa_list_accounts. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'List every contact one of your accounts has blocked.' This clearly separates it from the write-side sibling wa_block_contact and from the general wa_list_contacts. It stops short of explicitly naming those siblings, so it is clear but not fully self-differentiating.

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

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

Usage is implied by the blocklist scoping ('one of your accounts has blocked'), but there is no explicit when-to-use guidance, no mention of how it differs from wa_list_contacts, and no pointer to wa_block_contact for the write path. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description still adds real behavioral context beyond that: ascending chronological order, the cursor-termination contract ('keep going until has_more is false'), the exclusive nature of until, and the fact that each record carries answered status and duration.

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 dense sentences with no filler; the scope and ordering come first, pagination and filtering follow. Every clause carries actionable 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 an output schema present, return-value detail is unnecessary, and the description covers ordering, pagination, filtering and exclusivity adequately. The one gap is disambiguation from wa_ai_list_calls, which an agent working in this 40-tool namespace would want.

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 per-parameter formats (RFC3339, date shorthand, limit range) are already documented and the baseline would be 3. The description goes further by explaining the pagination workflow that spans after_cursor and the response's next_cursor/has_more, which is semantics the schema alone cannot express.

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 — read call history across WhatsApp accounts — and adds ordering ('oldest first'), which a plain list name would not convey. It does not, however, distinguish itself from the sibling wa_ai_list_calls, so an agent cannot tell from the text alone which of the two call-listing tools is the right one.

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

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

It gives concrete operational guidance: page with after_cursor by feeding back next_cursor until has_more is false, and narrow results with since/until. That is a clear usage pattern, but there is no explicit when-to-use or when-not-to-use statement relative to the sibling call-listing tools.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read; the description reinforces the read semantics via 'List'. It adds the scoping detail that channels are those 'one of your accounts follows', but offers no pagination, volume, or rate-limit context. The idempotentHint=false annotation is left unexplained, though the description does not contradict it.

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 moves from the action to scope to return fields with no filler. The return-field enumeration is slightly redundant given an output schema exists, but it costs little.

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

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

With an output schema present, the description need not describe return values, and annotations carry the safety profile; the required account_id is fully documented. The only gap is absence of when-to-use routing, which is minor for a simple one-parameter list 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% and the single account_id parameter is fully documented in-schema, including the wa_list_accounts cross-reference. The description adds no meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (the channels one of your accounts follows), and names the returned fields JID, name, and subscriber count. It is clear what the tool does, though it does not explicitly differentiate itself from list siblings like wa_list_contacts or the mutation sibling 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?

Usage is only implied: it is a scoped read of followed channels, and the account_id description points the agent to wa_list_accounts as the source of that ID. There is no explicit when-to-use or when-not-to-use guidance, nor any routing away from wa_follow_channel.

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?

Goes well beyond the readOnlyHint annotation by disclosing real side effects and costs: include_pictures performs external WhatsApp lookups, caps results at 10 per page, and can take half a minute. It also specifies matching scope (saved names, published name, business names, number).

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

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

Front-loads the core purpose and then layers search behavior and the include_pictures caveat; every sentence carries information. The first sentence's em-dash aside is slightly dense, but there is no filler.

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

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

With an output schema present, an accurate readOnlyHint annotation, and 100% schema coverage, the description need not explain return values. It supplies exactly the extra behavioral context an agent needs (search scope, performance tradeoff, downstream usage) 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%, so the baseline is 3, but the description adds meaning not in the schema about what query actually matches against (saved names, contact-published names, business names, number) and reinforces the include_pictures cap. It adds value but does not fully restate cursor/limit 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 and resource with precise scope: the address book of one account, i.e. contacts saved on the linked phone. It also distinguishes the 'list everything' vs 'search' mode, making it clearly different from siblings like wa_list_accounts or wa_list_blocked.

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 both modes (pass query to search, omit to list) and even a downstream workflow (use returned numbers with wa_send_message), plus when to enable include_pictures. It stops short of naming alternatives or explicit exclusions (e.g. use wa_list_blocked for blocked contacts), so not a full 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description adds useful output behavior by naming the per-participant fields (JID, phone number stored in 'name', admin flag), which goes beyond the annotations and helps an agent interpret results.

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

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

Two short sentences, front-loaded with the action and followed by the return shape. 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 simple read-only list tool with full schema coverage, annotations, and an output schema, the description supplies the key remaining context: the identity of each item and where the phone number is stored. Nothing needed to invoke the tool correctly appears 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 (group_jid, account_id) are already documented in the schema. The description adds no additional meaning about their format, sourcing, or constraints, 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 ('List a group's members') and makes the target collection unambiguous relative to sibling list tools like wa_list_groups. An agent can immediately tell this returns the participant set of one group rather than groups or 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?

No explicit when-to-use guidance, prerequisites, or alternatives are given. The purpose strongly implies usage, but the description never states when to choose this over related tools such as wa_get_chat or wa_list_contacts.

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 the useful scope detail that only joined groups are returned, plus the fields in the response, but says nothing about pagination, result limits, or behavior for accounts with no groups.

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

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

One sentence, front-loaded with the verb and scope, with the return fields appended. Nothing is padded and no sentence fails to earn 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 return values need not be explained (the description redundantly does so anyway), and annotations cover the read-only nature. For a single-parameter list tool it is essentially complete, with only pagination/volume behavior left unaddressed.

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 parameter, so the schema already documents account_id and its provenance (wa_list_accounts). The description's 'one of your accounts' is consistent but adds no syntax or format detail 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 and resource with scope: 'List the groups one of your accounts has joined,' and names the returned fields (JID, name, member count). This is clear enough to distinguish it from wa_list_group_members or wa_create_group, though it never explicitly names a sibling tool or draws the contrast.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named. The only sequencing hint ('as returned by wa_list_accounts') lives in the schema, not the description, so the agent gets no routing help from the prose.

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 cover readOnlyHint and idempotentHint. The description adds real operational context: paging via after_cursor with the returned next_cursor, 'until is exclusive', and that include_history yields storage order rather than time order. It doesn't mention rate limits or empty-result behavior, but adds meaningful value beyond the annotations.

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

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

Four compact sentences, front-loaded with the action and ordering, then paging, then filters. No filler, though the phrasing is dense and could be slightly more scannable.

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

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

Given an output schema exists and schema covers all params, the description needs only the paging model, filter semantics, and history behavior—all present. An agent has what it needs 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%, so baseline is 3. The description compensates for a gap by explicitly clarifying that since/until refer to when the message was sent and that until is exclusive—semantics that could be misread 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 states a specific verb and resource ('Read messages across all your WhatsApp accounts') plus ordering ('oldest first'). It distinguishes itself from siblings like wa_get_message and wa_load_history by describing the listing behavior and the history toggle.

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 a clear use case ('Use this to catch up after being notified of a new message') and explains cursor paging. It doesn't explicitly name an alternative tool to avoid, but the routing context is sufficient for an agent.

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

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

Annotations already declare readOnlyHint=true, and the description adds real behavioral context beyond them: the possible review statuses (APPROVED/PENDING/REJECTED) and that rejected templates carry Meta's rejected_reason. It also discloses the important limitation that templates only apply to Business numbers. What it does not address — pagination or whether results are cached — is minor for a listing tool.

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 and scope are front-loaded in the first clause, and the second sentence carries only operational guidance. It is dense and long-ish, but each clause (statuses, rejected_reason, downstream usage, scope limit) contributes information 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 single-parameter listing tool with an output schema, this description is complete: it explains what is listed, what the statuses mean, the account-type restriction, and how the result feeds wa_send_message. Nothing needed to invoke or use the tool is missing.

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

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

Schema coverage is 100% and the sole account_id parameter is fully documented in the schema, including that it comes from wa_list_accounts. The description restates the Business-account constraint but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the WhatsApp Business message templates') scoped to 'one of your Business (Cloud API) numbers', and the mention of review status and rejected_reason makes clear what comes back. An agent can distinguish it from wa_create_template and wa_delete_template 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 forward: use an APPROVED template's name/language with wa_send_message's template/template_language for conversations outside the 24-hour window, and pass the variables count as template_variables in order. It also states a scope exclusion — 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?

Annotations only declare readOnly=false, idempotent=false, destructive=false; the description goes well beyond by disclosing that the phone must be online, that it usually answers within seconds, that loaded messages never trigger webhooks, that they surface only with include_history=true, and that they count against the plan's history window.

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 most important constraint (phone must be online) is front-loaded and each sentence carries distinct information about behavior, retention, and prerequisites. It is somewhat dense at five sentences but none is 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, return values need not be explained. The description covers prerequisites, latency expectation, webhook/visibility side effects, and retention, which is everything 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 description coverage is 100%, so the schema already documents chat (phone number or group JID) and count (1-500, default 50). The description adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb+resource: ask the account's phone for older messages in one conversation and store them. The phrase 'before the oldest one stored here' precisely delimits it from wa_list_messages, and it points to wa_get_chat for reading the result, so an agent can distinguish it from siblings 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?

Gives clear context for use ('page back' older history) and a prerequisite ('a conversation needs at least one stored message'), plus the read-back workflow via wa_get_chat. It stops short of stating when NOT to use it versus alternatives, but the routing is largely explicit.

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

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

Annotations only cover the mutation/safety profile (readOnly=false, idempotent=false, destructive=false); the description adds the timing semantics that matter operationally — QR re-arms ~every 20 seconds, phone code lasts a few minutes, and state transitions to 'paired'. It also discloses that import_history loads ~two months of recent messages.

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?

Dense but earns its length: the QR-first instruction and the branch condition are front-loaded, and every clause carries actionable detail. It reads as one long paragraph, so light structural friction remains, but there is no filler.

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

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

With an output schema present, return values need not be restated, yet the description still tells the agent what comes back (QR PNG, pair_code, pair_id) and what to do next. For a multi-step pairing flow this is effectively complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine conditional meaning: phone is only for the single-device case and yields an 8-character pair_code, while omitting it produces a QR PNG; import_history controls history loading. Format guidance (+52 998 123 4567) is repeated from the schema but the decision logic is new.

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 ('Begin linking a new WhatsApp account') and is clearly delineated from siblings wa_pair_status (polling) and wa_unpair_account (teardown). An agent can identify the tool's role 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 says 'ASK FIRST' and then branches on device context: QR when another screen can scan, phone code when only one phone exists. It also names the follow-up tool (wa_pair_status) and the selection criterion, leaving nothing to inference.

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

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

Goes beyond the readOnlyHint/idempotentHint annotations by explaining the state machine (qr / code / paired) and the notable behavior that a fresh image is returned on each call — which is precisely why the tool is non-idempotent despite being a read. It could still note polling cadence or what happens on an expired/invalid pair_id.

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

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

Three short sentences, front-loaded with the core action, then state-by-state guidance, then the terminal condition. 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?

An output schema exists, so return-value documentation is unnecessary; the description instead supplies the state-transition semantics an agent needs to drive the polling loop and present results to the user. Nothing essential is missing.

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

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

Schema description coverage is 100% and the single pair_id parameter is already documented as coming from wa_pair_account, so the description adds no meaning 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+resource (check a pairing) and ties itself directly to the sibling that starts the flow (wa_pair_account). An agent can immediately distinguish this polling tool from wa_pair_account 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?

Places the tool clearly in the pairing workflow (after wa_pair_account, before the account appears in wa_list_accounts) and tells the agent what to do per state. It does not name when-not-to-use or a competing tool, but for a status-polling tool the usage context is explicit.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds real context beyond that: an empty reaction deletes a previously sent reaction, and only your own reaction can be removed. It does not say whether reacting twice replaces the prior emoji, which would clarify the idempotency hint.

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, and the primary action is front-loaded before the less common removal path. Every clause carries information an agent needs.

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

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

With an output schema present the return shape needn't be explained, and the schema carries the chat/sender/account_id constraints. The description is nearly complete for a small mutation tool; the only gap is the absence of any note on the channel limitation or on what happens to an existing reaction when a non-empty one is sent.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including the empty-string removal semantics for 'reaction' and the group-only 'sender' rule. The description's mention of the empty reaction merely duplicates the schema, adding no format or constraint 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?

The description names a specific verb and resource (react to a WhatsApp message with an emoji) and adds the inverse operation (removing a reaction via an empty value). It is unambiguous on its own, but it never references the nearby siblings wa_send_message, wa_edit_message, or wa_delete_message, which handle adjacent message mutations.

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

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

Usage is implied rather than stated: you call it when you want to add a reaction, and the second sentence covers the removal case. There is no explicit 'use this instead of X when Y' routing, and the channel-message restriction that would steer the agent away lives only in the schema, not the description.

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, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the admin-privilege requirement, which is not in the annotations. It does not disclose behavior on invalid members, partial failures, or whether removal is reversible, so it adds only modest value.

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

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

Two sentences, zero filler, with the action stated first and the privilege precondition second. Nothing is padded or repeated.

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 full schema and an output schema present, the description only needs to cover purpose, precondition, and routing. It covers purpose and precondition well; the remaining gap is the absence of sibling routing against wa_update_participants, which is a minor but real omission for a mutation 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%, with each parameter documented (members format, group JID form, account reference), so the baseline is 3. The description's 'by phone number or JID' merely restates what the members schema already specifies.

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 ('Remove members from a WhatsApp group') plus the accepted identifier forms (phone number or JID). It is clearly distinguishable from list-oriented siblings like wa_list_group_members, but it never names the closest sibling, wa_update_participants, which also mutates group membership.

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 one real precondition — 'The account must be a group admin' — which is genuinely useful context. However, it offers no when-to-use vs. wa_update_participants or wa_leave_chat guidance, and no exclusions or failure conditions, leaving the agent to infer which membership tool to pick.

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

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

Annotations already declare this is a write operation that is not read-only and not idempotent, so the safety profile is covered. The description adds real behavioral context: the report is emailed to the team along with the workspace and the sender's address, and a reply reaches the person by email. It also imposes a privacy constraint on what may be included. It stops short of describing anything about submission limits or duplicate handling.

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 sentence, followed by routing, behavior, authoring guidance and a privacy caveat, each carrying distinct information. It is dense but not padded; the only mild redundancy is that content guidance for bugs appears in both the description and 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?

An output schema exists, so return values need not be explained. The description covers purpose, exclusion, delivery mechanics with recipient context, authoring guidance, and a privacy guardrail — everything an agent needs to call this correctly and safely.

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 baseline is 3. The description goes beyond the schema by prescribing message content for a bug ('what was done, what happened, what was expected and any error text') and reinforcing the authorship rule, which meaningfully shapes how the message and title fields should be filled.

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

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

States a specific verb and resource ('Send a bug report, feature request or feedback about WhatsMCP to the WhatsMCP team') and explicitly distinguishes itself from the nearest sibling, wa_send_message. An agent can route between the two without opening either schema.

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

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

Gives explicit triggering conditions ('when the person asks to report a problem, suggest a feature or leave feedback') plus a clear when-not ('not to contact a WhatsApp user — that is wa_send_message'). It even specifies how to author the input ('write it in the person's words').

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 say it is non-read-only, non-idempotent, non-destructive; the description goes well beyond them by explaining the sent/queued/refused status semantics and the critical warning not to resend a 'queued' message, which directly operationalizes the idempotentHint=false signal. It also discloses per-attachment size limits and caption 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?

One dense passage, front-loaded with the core action, then attachment modes, then the template rule, then status handling. Nothing is wasted, though the long em-dash chain makes it heavier to scan than a bulleted structure would be.

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 tool with an output schema, the description covers the risky areas an agent must know: template exclusivity, attachment limits, and result-status interpretation. Return-value shape is correctly left to the output schema, though template_variables usage could have been illustrated more concretely.

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 parameter descriptions already document sizes, mime types, caption behavior, and template semantics, so the description largely restates what the schema provides. It adds the useful grouping of the three attachment modes and the 'text and attachments are ignored when template is set' interaction, but no syntax beyond that. 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?

Specific verb (Send) plus resource (WhatsApp message) with the full modality space enumerated: text, image, document, audio, and template. It is immediately distinguishable from siblings like wa_edit_message or wa_react 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 clear conditional guidance: use 'template' for Business/WABA numbers and as the only way to start a conversation or message outside the 24-hour window. It does not explicitly name sibling alternatives (e.g. wa_edit_message for corrections), so it stops just short of the top band.

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 non-read-only, non-idempotent, non-destructive, so the safety profile is covered; the description adds real behavioral context with 'Fire-and-forget: there is no delivery confirmation,' telling the agent not to expect a verifiable result. It does not mention rate limits or whether state resets automatically.

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

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

Two sentences, no filler, with the dual-mode purpose front-loaded and the fire-and-forget caveat earning its place as a distinct behavioral 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?

Given an output schema exists, the description needn't describe returns; combined with 100% schema coverage it conveys modes, the chat precondition, and the lack of confirmation. Nothing needed to invoke this 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 description coverage is 100%, so all three parameters are already documented, including the composing/paused vs available/unavailable split and the chat-required condition. The description repeats the same value mapping rather than adding syntax or format detail, so baseline 3 applies.

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

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

Names a specific verb (announce/set) and resource (presence of an account or typing state in a chat), and enumerates the exact mode values. An agent can tell exactly what this tool does relative to siblings like wa_send_message, which actually delivers content.

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

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

Explains the two operating modes and the conditional requirement that chat is needed for composing/paused but ignored for available/unavailable. No explicit alternatives are named, but no sibling overlaps, so the guidance 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?

Goes well beyond the annotations: it discloses that the previous photo is unrecoverable, that the image is center-cropped to a square and downscaled to 640x640 'as WhatsApp stores it', and that contacts may keep seeing the old photo until their app refreshes. This irreversibility and propagation context is exactly what destructiveHint=true alone cannot 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?

Front-loads the core action, then presents the replace/remove branches, then the irreversible and propagation caveats — each sentence carries new information with no filler.

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

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

For a destructive mutation with full annotation coverage, an output schema, and complete parameter docs, the description supplies everything the agent still needs: both operation modes, irreversibility, image normalization, and eventual-consistency behavior.

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

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

Schema description coverage is 100%, so the parameter contract is already documented, and the description largely restates the image_base64 constraints (formats, 5 MiB cap, crop/scale). It adds only marginal meaning (why the crop happens), 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?

States a precise verb+resource ('Change the profile photo') and scopes it to 'one of your own WhatsApp accounts', making it unmistakable against siblings like wa_get_profile or wa_set_presence. An agent can identify both the action and the target 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?

Clearly lays out the two modes of use — pass image_base64 to replace, or remove=true to delete — with the constraint that image_base64 must be omitted when removing. It stops short of naming exclusions (e.g., other accounts, alternative tools) or prerequisite conditions such as the account being paired.

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=false, idempotentHint=false, destructiveHint=false; the description goes further by disclosing the one-time signing secret and the replace-and-rotate-secret behavior on repeat calls, which is real operational context. It stops short of covering auth/permission requirements or rate limits, so a 4 rather than 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, front-loaded with the core action and the poll-avoidance rationale, then the two consequences (secret shown once, replacement rotates it). No filler.

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

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

For a two-parameter tool with an output schema, the description covers the action, the side effects, and the critical one-time-secret warning. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% — both 'url' (must be publicly reachable https://) and 'events' (defaults to message.inbound) are already documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Register an HTTPS endpoint to receive inbound WhatsApp messages') and immediately clarifies the motivation relative to a sibling ('so you do not have to poll wa_list_messages'). An agent can distinguish this from wa_get_webhook, wa_delete_webhook, and wa_enable_webhook 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?

Gives clear context for when to use it (receive inbound messages instead of polling) and warns that re-invoking replaces the existing endpoint. It does not explicitly route the agent between the sibling webhook tools (wa_enable_webhook, wa_delete_webhook), which keeps it 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 declare destructiveHint=true, but the description goes well beyond them by disclosing the immediate effect on sending/receiving, that message history is preserved, and that re-connection requires re-pairing the phone. This is exactly the extra context an agent needs for a destructive 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?

Four short sentences, each carrying distinct information (effect, timing, history retention, recovery cost, caution), with the destructive action front-loaded. 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?

An output schema exists, so return values need no explanation, and the description covers the safety-relevant behavior for a one-parameter destructive tool. Nothing needed 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?

Only one parameter and the schema already documents it fully (100% coverage), including its provenance from wa_list_accounts. The description adds no further parameter detail, 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 ('Disconnect a WhatsApp account from this service') and its effect, cleanly distinguishing it from the sibling wa_pair_account via the re-pairing note. An agent can tell immediately what this 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?

Gives a clear precondition and caution ('ask the user before calling this') and frames the re-connection cost that motivates care. It stops short of explicitly naming when-not to use it or pointing to an alternative tool, but the context 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?

Explicitly discloses that changes are not atomic – WhatsApp applies each change separately and on refusal the 'applied' field lists what took effect first. That is substantive behavioral context beyond readOnlyHint=false/idempotentHint=false/destructiveHint=false, and it also states the admin authorization requirement.

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

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

Three sentences, front-loaded with what changes, then how to invoke, then the failure semantics. Dense and mostly waste-free, though the enumerated field list partially duplicates the schema's own documentation.

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

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

For a mutation tool with a full output schema, the description covers the mutation target, the partial-application failure mode, and the admin precondition. Nothing an agent needs to invoke it correctly is missing, and return values are left to the output schema.

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

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

Schema description coverage is 100%, so all six parameters are already documented in more detail than the description provides (e.g., the schema's locked text mentions the photo and member behavior). The description restates name/description/locked/announce semantics without adding format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (change) and resource (a WhatsApp group's settings) and enumerates exactly which settings: name, description, locked, announce. This distinguishes it from wa_update_participants (membership) and wa_create_group (creation) without the agent needing to open the schema.

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

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

Gives invocation guidance ('Pass only the fields to change; several can change in one call') and a precondition ('If the group restricts settings to admins, the account must be one'). It never names an alternative tool or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context the annotations do not: the account must be a member (and admin for private groups) for add, and an admin for promote/demote, which is real authorization guidance for a mutation tool.

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 three actions and their effect, followed by prerequisites and the explicit alternative. Every clause earns its place with zero redundancy.

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

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

With an output schema present there is no need to describe return values, and annotations cover the safety profile. Between the description's permission requirements and the fully documented schema, an agent has everything needed to invoke this mutation 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 all four parameters (including the action enum-like values and members format) are already documented in the schema. The description restates the action values and member addressing (phone/JID) but adds no syntax or format detail 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+resource ('Add members to a WhatsApp group') and enumerates the three supported actions (add/promote/demote) with their distinct meanings, so the agent can tell exactly what the tool does. It explicitly names the sibling wa_remove_participants as the tool for the opposite operation, cleanly differentiating it from other group tools.

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

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

Gives explicit prerequisites per action: adding requires the account to be a member (and admin for private groups), while promote/demote require admin. It also states when NOT to use the tool ('To remove members, use wa_remove_participants'), routing the agent to the correct alternative.

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