WhatsApp

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description aligns with. The description adds behavioral context: it explains that calling with no args returns a link, and that pasting a token provides session-only login. It also clarifies the token is a JWT and how to use it. However, it doesn't explicitly state that the tool is non-destructive or idempotent, but the annotations already cover that, so the description adds value beyond annotations.

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

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

The description is concise, front-loaded with the tool's purpose, and every sentence adds value. It covers the two usage modes and the token parameter without unnecessary fluff.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete enough. It explains the authentication flow, the two methods, and the token parameter. It could mention what the response looks like, but since there's no output schema, the description doesn't need to detail return values. The context is sufficient for an agent to use the tool correctly.

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

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

The schema has one optional parameter 'token' with no description, and schema description coverage is 0%. The description compensates by explaining the token parameter: it should be a JWT pasted by the user, and calling without it returns the login link. This adds meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: to authenticate an IDE agent (like Cursor) by logging in via browser and obtaining an access token. It distinguishes itself from siblings like 'connect' and 'marketplace' by focusing specifically on authentication flow.

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

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

The description provides explicit usage guidance: it explains two methods (permanent config-based token vs session-only token), when to call with no args to get the link, and when to call with the token. It also mentions the alternative of adding the token to the server config for a permanent connection, which helps the agent decide between approaches.

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

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

The description explicitly states behavioral outcomes: when all providers are connected, returns 'authenticated:true' and empty 'pending[]'; when credentials are missing, returns a connect_url. It also explains the different URL types (toolkit-level and per-install). The annotations (readOnlyHint=true, destructiveHint=false) align with this read-only behavior, adding clarity.

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

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

The description is two sentences, each conveying a distinct scenario. It is front-loaded with the core purpose and then elaborates on conditions. No redundant information, well-structured.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is sufficient. It explains the return values' semantics and the different states. Lack of output schema is compensated by descriptive text. Minor missing: doesn't specify if the response contains additional fields, but not critical for a zero-param tool.

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

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

The tool has zero parameters and the schema description coverage is 100%, meaning there is nothing to describe. The description adds the meaning of the output fields, which is useful. A baseline of 4 is given because no parameter information is needed.

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

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

The description clearly states the tool returns connection status and URLs, with specific details about the response structure (authenticated:true, pending[], connect_url). It distinguishes itself from sibling tools like 'authenticate' which performs the connection action, whereas this tool only reports status.

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 it should be used to check connection status, and it distinguishes from 'authenticate' which would be the action tool. However, it does not explicitly state when NOT to use it or mention alternatives, though the context makes this clear.

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

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

Beyond the annotations, the description reveals important runtime behavior: invoke can execute a tool that is not installed; connect and checkout links are returned when credentials or payment are missing; writes require owner/admin; and search/describe returns installed_in_toolkit vs installed_in_workspace flags. This paints a realistic, actionable model of the tool's side effects.

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

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

The text is dense and deliberately structured around the core flow, then the one-off vs permanent distinction, then the prompt library. It is front-loaded with the purpose and covers all major behaviors in one continuous narrative, but it is a wall of text without breaks or bullets, which makes it a bit harder to scan quickly.

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

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

Given the tool has no parameter docs, no output schema, and handles a complex set of actions, the description is remarkably complete. It explains the discovery/run flow, authentication and billing exceptions, write permissions, installed-status distinctions, and the prompt library, including return links and behavior. This is enough for the agent to drive the tool correctly in normal and edge cases.

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

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

With 0% schema description coverage and 23 parameters, the description must carry most of the semantics. It does that for the central action flow by explaining what each action does (e.g., describe returns the full MCP profile, invoke runs a tool one-off), and it mentions prompt variables and shareable links. However, several less-common fields (immediate, tier_slug, report_context, cancel_reason, etc.) remain undocumented and require inference.

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 unambiguously establishes what the tool is and does: it is the mcp.ai marketplace, the catalog and execution entry point for MCP tools, plus the prompt library. It references the specific action flow (search, describe, install, invoke) and distinguishes itself clearly from the many WhatsApp sibling tools.

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

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

The description explicitly says when to use invoke versus install, when to use list_tools, and what report_bug and request_mcp are for. It also explains that writes require workspace owner/admin, and it contrasts begin preferred for temporary one-off executions with permanent installation, which gives the agent practical guidance for choosing between 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 readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the basic safety profile. The description adds the useful behavioral detail that a conversation array should be included for reproduction, but it does not explain what happens after the report is submitted.

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

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

The description is two short sentences, front-loaded with the core purpose, and every sentence adds value. No filler or redundant 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?

For a simple three-parameter feedback tool, the description covers the primary action and the key reproduction guidance. It is somewhat incomplete because it omits the meaning of the required message parameter and does not describe expected outcomes, especially since no output schema is provided.

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 0%, so the description must compensate. It explains the conversation parameter ('recent messages for reproduction') but does not clarify the required message parameter or the context parameter, leaving a significant gap.

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

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

The description clearly states the tool's purpose: report a bug, missing feature, or feedback. It is specific about the action and resource, and it is distinct from all sibling WhatsApp/configuration tools.

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

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

The description gives clear context for when to use the tool by enumerating bug reports, feature requests, and feedback. It does not explicitly mention when not to use it or name alternatives, but no obvious alternative exists among the siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing this as a safe, non-mutating read operation. The description adds that the tool reports platform and adapter versions, which is consistent with annotations, but provides no additional behavioral context such as response format or potential caveats.

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

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

The description is a single short sentence that conveys complete meaning without filler. It front-loads the action ('Show') and resource, making it immediately scannable and efficient.

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

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

For a zero-parameter, read-only version-info tool with no output schema, the description is fully adequate. It tells the agent exactly what information will be presented and leaves no ambiguity about usage.

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

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

The tool has zero parameters, so per the rubric a baseline of 4 applies. The description correctly avoids mentioning parameters since none exist, and the empty input schema needs no further elaboration.

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 resource ('current MCP platform and adapter versions'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like toolkit_info or whatsapp tools by naming exactly what version info is displayed.

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 clear usage context: call this tool when you need version information about the MCP platform and adapters. It does not explicitly name alternatives or exclusions, but the simplicity of the tool and its obvious purpose make this unnecessary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=False. The description adds valuable context about what 'toolkit state' includes, going beyond the annotations to specify the scope of returned data. No contradictions found.

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

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

A single, well-structured sentence that front-loads the purpose and enumerates the key output components. No redundant words or filler.

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

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

The tool is simple: zero parameters, no output schema, and annotations cover safety. The description explains exactly what will be returned, making it fully complete for an agent to know what to expect.

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?

No parameters exist, so the baseline is 4. The description correctly implies the tool requires no input and focuses on output, so there is nothing to compensate for.

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

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

The description clearly states the tool returns the current toolkit state and lists specific components (installed MCPs, connection status, accounts, catalog tool counts). This is a specific verb+resource combination that distinguishes it from the many WhatsApp-specific sibling tools.

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

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

The description implies use for inspecting overall toolkit/connection status but does not explicitly state when to prefer this over alternatives like show_version or whatsapp_list_accounts. It lacks clear exclusions or alternative guidance, so it is adequate but not proactive.

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

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

The description adds little beyond the annotations: it says 'Change a chat's state' but does not explain side effects, reversibility, permissions, or the meaning of the missing 'action' parameter. The annotations (readOnlyHint=false) are consistent with a mutation, but the description fails to disclose what actually happens or what the '[Flattened action: archive]' note means.

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 text is brief and front-loaded with the main verb, but the structure is muddled: it mixes a general action list with a cryptic note about a flattened action. The 'action:' list reads like a parameter specification but is not backed by the schema, creating confusion rather than concise clarity.

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 3 parameters, missing output schema, and many related sibling tools, the description is incomplete. It does not explain how to specify an action (since no action parameter exists in the schema), what duration_secs is for, or how this tool relates to the dedicated archive/unarchive/mute/pin tools, making it hard for an agent to invoke correctly.

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

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

The schema lists 'account', 'chat_jid', and 'duration_secs' with no descriptions, and the description only mentions 'chat_jid' as required (already declared in schema). It introduces an 'action' concept that is not present in the schema, and does not explain 'duration_secs' or 'account', leaving parameter meaning unclear.

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 it changes a chat's state and lists specific actions (archive/unarchive, pin/unpin, mute/unmute), which gives some clarity. However, the tool name 'whatsapp_chat_archive' and the note '[Flattened action: archive]' conflict with the broader scope, and it does not distinguish itself from the many sibling tools that cover the same individual actions.

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

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

No guidance is provided on when to use this tool versus alternatives like whatsapp_chat_mute, whatsapp_chat_pin, or whatsapp_chat_unarchive. The only hint is 'Requires chat_jid', which is a prerequisite already present in the schema, not a usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds value by listing the exact metadata fields returned, which helps the agent understand the output. It does not contradict annotations, and although it doesn't discuss errors or authentication, it provides useful context beyond structured data.

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

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

The description is a single, front-loaded sentence with no redundancy. It lists essential details efficiently, achieving maximum clarity with zero wasted words.

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

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

For a simple read-only metadata tool with two parameters and no output schema, the description adequately covers purpose, required input, and returned fields. It omits the optional 'account' parameter and does not discuss edge cases (e.g., invalid chat_jid), but given the tool's simplicity, it is sufficiently complete.

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

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

Schema coverage is 0% because description only mentions chat_jid ('Requires chat_jid'), which is already marked required in schema. It adds no format or meaning, and completely ignores the optional 'account' parameter. Thus, it adds minimal value beyond the schema.

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

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

The description clearly states 'Get metadata for a single chat' and enumerates specific fields (subject/name, archive/pin/mute state, unread count, timestamps). This distinguishes it from siblings like whatsapp_chats (listing) and mutation tools (archive/mute/pin).

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

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

The description implies use for a single chat, contrasting with whatsapp_chats for listing, but does not explicitly mention alternatives or when not to use. It provides the prerequisite of chat_jid, giving clear context, though no explicit exclusions or alternative tool references.

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

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

Annotations already mark readOnlyHint false, so the agent knows it's a write, but the description adds no context about mute duration, default behavior, reversibility, or side effects. 'Requires chat_jid' merely restates the schema's required field. No behavior beyond the structured metadata is disclosed.

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

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

The description is short but not effective: the first sentence is generic filler and the action list is misleadingly broad. The bracket 'Flattened action: mute' is metadata, not user-facing guidance. The only useful clause is 'Requires chat_jid,' which duplicates 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?

For a 3-param mutation tool with no output schema, this description omits the essential mute behavior, duration semantics, and account context. It reads like a generic template rather than a complete tool contract. An agent cannot confidently invoke this tool correctly from the description alone.

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 0%, and the description doesn't compensate: it only repeats that chat_jid is required. account and duration_secs are completely unexplained, especially duration_secs which is essential for a mute operation. This gives the agent no parameter semantics beyond field names/types.

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 says 'Change a chat's state' and lists archive/unarchive, pin/unpin, mute/unmute, but it never states that this specific tool mutes a chat. The bracket note 'Flattened action: mute' is the only mute-specific signal. It does not distinguish from sibling tools such as whatsapp_chat_archive or whatsapp_chat_pin.

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 when-to-use guidance is provided; it doesn't say to prefer this for muting instead of archive/pin/etc. The generic action list could mislead an agent into thinking this tool can perform multiple state changes. No alternatives or exclusions are mentioned.

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

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

The description discloses no side effects, idempotency, or potential errors. It does not mention that pinning changes chat ordering or that unpinning might be needed for reversal. The annotations do not add behavioral detail.

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

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

The description is succinct but misleading due to the enumeration of multiple actions. It attempts to be structured but sacrifices clarity for brevity.

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

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

The description lacks essential context: it does not specify that the tool is for pinning, does not explain the response or side effects, and leaves parameter usage undefined. It is incomplete for a straightforward action.

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 description only mentions chat_jid as required but does not explain its meaning or the roles of 'account' and 'duration_secs'. Since the schema has no descriptions, the description fails to clarify parameter semantics.

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

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

The description says 'Change a chat's state' and lists multiple actions (archive/unarchive, pin/unpin, mute/unmute), but the tool name is 'pin' and the schema lacks an action parameter. This ambiguity makes it unclear that the tool specifically pins a chat.

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

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

The description merely states 'Requires chat_jid' without explaining when to use this tool versus sibling tools like whatsapp_chat_unpin or whatsapp_chat_archive. It provides no context for selection or prerequisites beyond a required parameter.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds that it's sorted by most recent activity, which is useful behavioral information. However, it doesn't mention default limits, pagination, or what fields are returned. Since annotations carry the safety burden, this is adequate but not rich.

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

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

Two sentences, action-first, no fluff. Efficiently communicates the core purpose. Perfectly concise.

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

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

For a simple list tool, the description covers the purpose but omits parameter behaviors, output format, and any nuances like whether archived chats are included by default. Since there's no output schema, the description should at least hint at what the list contains. It doesn't.

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

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

The input schema has 3 parameters (limit, account, archived) with no descriptions. The description does not mention them at all. Schema coverage is 0%. The description should explain what these parameters do, especially 'account' and 'archived' which are non-obvious. This is a major gap.

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

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

The description clearly states the tool's function: 'List WhatsApp chats' with the additional detail that both individual and group chats are includedcars and sorted by most recent activity. It uses a specific verb (List) and resource (WhatsApp chats), distinguishing it from siblings like whatsapp_groups or whatsapp_contacts_list.

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

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

The description implies usage for listing all chats but does not explicitly state when to use this vs alternatives like whatsapp_groups or whatsapp_contacts_list. It gives context (lists both individual and group) but no exclusions or when-not-to-use guidance. A clear 'use this for the chat overview' would push it higher.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description explains what the tool does but doesn't add meaningful behavioral context beyond the annotation flags. It doesn't say what happens on failure, whether it's idempotent in practice, or the effect of the mute_unarchive flag mentioned in the original WhatsApp API.

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 plus a flattened action block. Efficient, though the 'flattened action' annotation introduces some redundancy with the action list mentioned in the first sentence.

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

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

For a tool with 3 params and no output schema, the description covers the basic purpose but leaves gaps. The flattened action [unarchive] is useful context, but the parameter semantics and behavioral caveats are insufficiently documented.

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 0% with 3 parameters, and the description adds no parameter-level detail beyond implying chat_jid is required. The description mentions 'Requires chat_jid' which is helpful, but gives no guidance on account, duration_secs, or how to control the action.

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 'Change a chat's state. action: archive/unarchive, pin/unpin, mute/unmute. Requires chat_jid.' which clearly indicates it's a state-change tool. However, the description is generic and doesn't specifically call out 'unarchive' until the flattened action. It's clear but could be more specific about what unarchiving does.

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

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

The description implies the tool handles multiple state changes, but doesn't explicitly distinguish when to use this versus siblings like whatsapp_chat_archive. It doesn't explain the routing logic (how the system decides which action to take) or when a caller would choose this specific unarchive tool over others.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds only 'Change a chat's state' and 'Requires chat_jid', which largely restates the mutation nature and a parameter requirement. It does not disclose effects, reversibility, permissions, or how unmute interacts with mute duration. There is no contradiction, but the added behavioral context is minimal.

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

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

The description is short, but it wastes space on a generic action list and a machine-readable '[Flattened action: unmute]' tag. It could be replaced with a single specific sentence like 'Unmute a WhatsApp chat identified by chat_jid.' The structure is not optimized for the specific tool and includes redundant information.

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

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

For a 3-parameter tool with no output schema and no enum constraints, the description is inadequate. It does not explain the operation's effect, prerequisites beyond chat_jid, or parameter meanings. The generic action list makes it difficult for an agent to know exactly what will happen when invoking this 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 0%, so the description needed to explain chat_jid, account, and duration_secs. It only says 'Requires chat_jid,' which duplicates the schema's required field. It does not explain what a JID is, what account refers to, or that duration_secs is likely irrelevant for unmute (it belongs to mute).

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

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

The description opens with a generic 'Change a chat's state' and lists multiple actions (archive/unarchive, pin/unpin, mute/unmute) before noting '[Flattened action: unmute]'. It does not explicitly state 'Unmute a WhatsApp chat' as the tool's sole purpose, relying on the tool name and the flattened tag for disambiguation. This is more specific than a tautology but still vague and not clearly differentiated from sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives like whatsapp_chat_mute or whatsapp_chat_unarchive. The description mentions 'Requires chat_jid' as a prerequisite but does not explain that this tool is specifically for unmuting or how it relates to mute. The sibling list includes many similar chat-state tools, increasing the need for explicit usage guidance that is absent.

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

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

The annotations already signal a non-read-only action, and the description adds only the vague phrase 'Change a chat's state.' It does not disclose what unpinning does, whether it is reversible, what response to expect, or any permission requirements. No contradiction with annotations is present.

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 text is short, but the generic action list and the '[Flattened action: unpin]' bracket are boilerplate rather than focused tool guidance. It is concise in length yet not appropriately structured for the reader's actual 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?

This is a mutating tool with 3 parameters and no output schema, but the description omits return behavior, the meaning of duration_secs, account handling, and the precise effect of unpinning. The available description is too incomplete for reliable selection and invocation.

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

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

Schema description coverage is 0%, so the description must add meaning, but it only repeats 'chat_jid' and ignores 'account' and 'duration_secs' entirely. The parameter names remain unexplained, especially the WhatsApp-specific chat_jid identifier.

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 says 'Change a chat's state' and lists archive/unarchive, pin/unpin, mute/unmute, which is generic rather than a specific 'Unpin this chat' statement. The '[Flattened action: unpin]' hints at the tool's role, but it does not clearly differentiate this tool from the sibling state-change 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?

There is no guidance on when to use this tool versus alternatives like whatsapp_chat_pin, whatsapp_chat_archive, or whatsapp_chat_mute. The only usage note is 'Requires chat_jid,' which is already reflected in the schema's required field.

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

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

Annotations already indicate read-only and idempotent, so the description adds crucial behavioral details: the configuration value is never returned in full, only a masked preview, and it specifies an authorization condition. This goes beyond structured data and helps agents understand side effects and constraints.

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

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

The description is a single, information-dense sentence followed by a short permission note. It is front-loaded with the main purpose, avoids redundancy, and every clause adds value—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 simple read-only getter with no output schema or parameters, the description covers all necessary aspects: what is shown (proxy settings), how it's shown (masked preview), permission requirements, and scope (per connected number). It is sufficiently complete for an agent to invoke and interpret the result.

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

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

With zero parameters, the schema provides no parameter semantics. The description adds value by clarifying that the tool operates across all connected numbers and returns per-number settings, which is essential given the lack of input parameters. Baseline of 4 is appropriate as no param details are needed.

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

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

The description clearly states the verb 'Show' and the resource: 'editable-after-connect settings per connected number', specifically the proxy (proxy_url). It distinguishes itself from the sibling config_set by focusing on retrieval and masking, making its purpose unambiguous.

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

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

The description provides clear context on when to use this tool (to view current proxy settings) and notes the permission requirement ('Owner/admin or the connection owner'). It doesn't explicitly compare to alternatives like whatsapp_config_set, but the context is sufficient for a read-only getter.

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

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

The description explicitly states that it's a change operation (mutation) and explains the side effect: 'The new value applies on the next (re)connection; the live session cache is invalidated so the next tool call uses it.' This is transparent about the behavior and timing, and does not contradict the annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is succinct and well-organized. It conveys all necessary information without fluff, using clear separations for parameter explanations. It earns full marks for conciseness and structure.

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

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

Given the tool's simplicity, the description covers purpose, parameters, behavior, and usage guidance comprehensively. There is no output schema, but for a config setter, the description is sufficiently complete for an agent to use it correctly.

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

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

The description explains both parameters: 'account' is clarified as which number to target (id/wa_jid, phone, or label; omit if only one is connected), and 'values' is detailed with an example structure and semantics for clearing the proxy with an empty string. This goes beyond the raw schema, providing essential context for correct usage.

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

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

The description clearly states the tool's purpose: changing an editable-after-connect setting on a connected number without re-pairing. It explicitly identifies the currently supported field (proxy_url) and its purpose, distinguishing it from other tools like config_get.

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

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

The description provides when to use the tool (to change proxy settings on a connected number) and includes practical guidance (recommended to avoid IP bans). It also explains the effect of setting an empty string to clear the proxy, and notes that the value applies on next connection, covering usage nuances.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so no safety concerns need to be added. The description adds useful behaviors such as default limit of 50 and substring matching for query, which go beyond annotations. However, it does not explain what happens on missing JID, pagination behavior beyond the limit, or the relationship between the two listed actions and the flattened action note, leaving gaps in behavioral understanding.

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

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

The description is brief and front-loaded with the core purpose, followed by concise action definitions. However, the cryptic '[Flattened action: get]' note is unclear and disrupts the flow, introducing confusion rather than clarity. Minimal waste otherwise.

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

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

The tool has no output schema, so the description should describe return values, but it only vaguely mentions 'full contact info' for get. It lacks details on list response structure, error conditions, pagination, and the meaning of `account`. The flattened action note and the existence of a dedicated list tool are not reconciled. Overall, the description is insufficient for an agent to reliably select and invoke the tool in various scenarios.

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?

Since schema description coverage is 0%, the description must explain parameters. It does clarify `query` (substring on name/phone), `limit` (default 50), and `jid` (used for get). However, it fails to explain the `account` parameter and does not clearly state how parameters select between list and get actions. The '[Flattened action: get]' note implies jid is used, but the list action also needs query/limit, leaving the parameter-action mapping ambiguous.

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

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

The description clearly states the tool reads WhatsApp contacts and lists two primary actions (list and get). However, it does not distinguish itself from the sibling tool `whatsapp_contacts_list`, which presumably performs the same list operation, creating ambiguity about the tool's unique purpose. The flattened action note further muddies the intended operation.

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 mentions that list and get are available but provides no guidance on when to use this tool versus the closely named `whatsapp_contacts_list`. It also fails to explain when each action should be chosen (e.g., get when you have a JID, list for search), and the flattened action note suggests only get may be active, without clarifying how to invoke the list functionality.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, which the description aligns with by saying 'Read'. The description adds behavioral details beyond annotations: the query is a substring on name/phone and the default limit is 50. No contradictions, and these extras enhance transparency.

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

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

The description is concise, using two sentences plus a structured list of actions and a flattened action note. It avoids redundancy and conveys essential information efficiently without unnecessary verbosity.

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

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

Given the tool is a list action, the description covers the core functionality (reading contacts, searching, default limit) and aligns with annotations. It does not explain the return format (no output schema present), but it omits details like the 'account' parameter. Overall, it is sufficiently complete for a list operation, though not exhaustive.

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

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

The schema has no parameter descriptions, and the description only partially explains the parameters. It clarifies 'query' (optional, substring on name/phone) and 'limit' (default 50), but 'jid' and 'account' remain unexplained. Since coverage is below 50% and the description fails to compensate for all parameters, the score is low.

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

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

The description clearly states the tool reads WhatsApp contacts and explicitly lists two actions (list and get), with the flattened action being 'list'. It distinguishes from the 'get' action which provides full info by JID, and mentions searching with an optional query, making the purpose specific and unambiguous relative to siblings like whatsapp_contacts_get.

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

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

The description implies usage by stating 'search across contacts' and mentions 'get: full contact info by JID', which hints at when to use this tool vs the get variant. It also notes the default limit of 50, providing pagination guidance. However, it does not explicitly contrast with other sibling tools (e.g., chats, groups) but the context is sufficient.

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

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

Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds that 'the connected account must be a group admin for most actions,' which is useful context, but it does not describe the side effects of creating a group (e.g., new group created, members added) or any error conditions.

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

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

The description is fairly concise but includes a redundant list of all group management actions (create, leave, update, etc.) when only the create action is relevant. This adds noise, though it is not overly verbose.

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

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

The description falls short on completeness for a create operation. It does not mention expected outcomes, return values (e.g., group ID), or how parameters like 'participants' are used (e.g., adding members). The admin note is helpful but insufficient for full understanding.

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

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

The schema has no descriptions, and the description only lists parameter names in a shorthand format (e.g., { name, participants[] }). It maps 'name' and 'participants' to the create action, but does not explain their types, constraints, or how they are used beyond the literal names. This is partial coverage.

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

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

The tool name and the '[Flattened action: create]' note clearly indicate the primary purpose is to create a WhatsApp group. However, the description lists multiple group management actions (leave, update, etc.) which could confuse, though the flattened action disambiguates.

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

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

The description does not explicitly state when to use this tool versus sibling tools like whatsapp_group_manage_leave or whatsapp_group_manage_update. It only mentions admin requirements, which applies to most actions, not specific selection guidance.

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

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

The description provides no details on side effects, request outcomes, or return values. For example, it does not explain whether 'revoke' invalidates existing invite links or how 'approve' affects pending requests. Without annotations to cover these aspects (readOnlyHint false, destructiveHint false), the description carries the full responsibility but remains incomplete and potentially misleading given the tool's name versus its described scope.

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

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

The description is a dense block of text covering multiple actions, which is not concise for a tool that likely has a single intended purpose. It front-loads a general admin requirement but then sprawls into unrelated actions, making it hard to parse. The critical invite_link action is buried in the middle, and the final note adds confusion rather than clarity.

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

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

Given the tool's name, the context is incomplete: it does not focus on invite link management, nor does it explain how to obtain or revoke links, or how to handle requests. There is no output schema, so the description should specify return values, which it does not. The tool appears redundant given the existence of sibling tools, and the description fails to clarify its unique role.

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

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

The input schema has 9 parameters with 0% description coverage. While the description lists parameter names for each action (e.g., 'name, participants[]' for create), it does not explain their meaning or constraints. Only 'invite' is partially described as 'invite code or full invite link'. The description does not compensate for the schema's lack of documentation, leaving many parameters ambiguous.

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 lists five distinct actions (create, leave, update, invite_link, join, requests) while the tool name suggests it is specifically for invite_link management. This broad scope fails to distinguish it from sibling tools like whatsapp_group_manage_create, whatsapp_group_manage_join, etc., and does not clearly state that the tool is actually for invite link operations. The final note '[Flattened action: invite_link]' is ambiguous and does not resolve the confusion.

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 mentions that the connected account must be a group admin for most actions, which is a useful prerequisite. However, it does not explain when to use this tool versus the dedicated sibling tools for each action, such as whatsapp_group_manage_create for creating groups. There is no explicit guidance on alternative tools or when to choose this composite tool.

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

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

The description does add some behavioral context beyond annotations: it describes the group-administrator requirement and enumerates available action/parameter combinations. However, it does not disclose side effects, return shape, whether joining is idempotent, or how errors like invalid/expired invite are handled. Annotations already mark readOnly/destructive/idempotent hints as false, so the description carries a moderate burden and only partially fulfills 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?

The action-list format is compact and scannable, but the description spends most of its length on actions that are not actually the flattened action. For the join tool, the create/leave/update/invite_link/requests entries are excessive, though the final '[Flattened action: join]' note helps orient the reader.

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

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

The tool has 9 optional parameters, no output schema, and sparse annotations, so the description needs to provide more complete operational context. It fails to explain return values, required parameters, handle behavior, or account selection. The admin note and action mapping are helpful, but for a complex multimode tool this is not enough for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate; it partially does by mapping invite to 'invite code or full invite link,' and by listing group_jid, req_action, link_action, etc. in the action bullets. However, the 'account' parameter is unexplained, no parameters are marked required, and there is no per-field parameter documentation beyond the terse action notation.

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 includes 'join: { invite } (invite code or full invite link)' and ends with '[Flattened action: join]', so the intended action is identifiable. However, it leads with the broad phrase 'Group lifecycle/admin' and lists multiple unrelated actions (create, leave, update, invite_link, requests), making the tool's precise purpose ambiguous compared to its name and sibling tools.

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

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

There is no explicit guidance on when to use this tool versus the many sibling group-management tools, such as whatsapp_group_manage_create, whatsapp_group_manage_leave, or whatsapp_group_manage_invite_link. The only usage-related note is 'the connected account must be a group admin for most actions,' but it does not explain whether that applies to joining via invite, nor does it specify prerequisites or 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 exist (readOnlyHint=false, destructiveHint=false) and the description adds context about admin requirements for 'most actions'. However, the description does not clarify what 'leave' specifically does (e.g., does it require admin? it shouldn't since leaving your own group is usually allowed for any member). The admin note says 'for most actions' which is ambiguous—does leave fall under that? No contradictions with annotations, but ambiguity about the actual behavior persists.

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

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

The description front-loads the admin requirement note but then presents a multi-action catalog when the tool is clearly meant for one action (leave). The '[Flattened action: leave]' marker at the end is cryptic and unexplained. The description would be more concise if it focused on the leave action and parameters actually relevant to it.

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

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

With no output schema/info, no required parameters, and a confusing multi-action catalog, the description is incomplete. An agent cannot determine what a 'leave' invocation returns, whether it's reversible (can you rejoin?), or how the 'leave' action maps to the actual group_manage API. The tool's name says 'leave' but the description covers the whole CRUD surface—this mismatch creates real risk of misuse. The description doesn't explain what the return value or side effects look like.

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 0% and there are 9 parameters with 0 required. The description provides parameter lists per action (e.g., leave: {group_jid}) but lacks critical information: no guidance on which parameters are required for leave (presumably group_jid), which parameters apply to other actions, what format participants/invite should take, or how the pre-bound action 'leave' interacts with all these parameters. An agent cannot confidently determine what parameters to provide for a leave operation.

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 lists a 'leave' action with a group_jid parameter, which clearly identifies the primary function. However, the description is heavily diluted by documenting multiple other actions (create, update, invite_link, join, requests) that are not the primary purpose of this tool. The '[Flattened action: leave]' note is confusing - if the tool is pre-bound to 'leave', why document other actions at all?

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 mentions 'the connected account must be a group admin for most actions' which is helpful context, but does not clearly state when to use this specific leave tool vs sibling tools like whatsapp_group_manage_create, whatsapp_group_manage_invite_link, etc. The multi-action format suggests it's a catch-all tool, but there's no guidance on when to choose this vs the dedicated sibling tools that exist for create/update/join/requests/invite_link.

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

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

The description reveals only the admin requirement and lists actions, but it does not disclose side effects (e.g., revoking an invite link, rejecting users, leaving a group). It also contradicts the annotations: destructiveHint=false while the description includes 'leave', 'revoke', and 'approve'/'reject' actions, which are clearly state-changing/destructive operations. This is an annotation contradiction.

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

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

The description is compact and front-loaded with a brief purpose line and bulleted action signatures. It avoids fluff and is reasonably scannable, but the inclusion of multiple unrelated actions in a tool named 'requests' and the cryptic '[Flattened action: requests]' line hurt clarity. It is appropriately sized but not well structured for its actual purpose.

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

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

This is a complex multi-action tool with 9 parameters, no output schema, and minimal annotations. The description fails to explain how action dispatch works, what the return format is, what errors or edge cases exist, or how this tool relates to the numerous sibling group-management tools. For an agent to use it safely and correctly, much more context is required.

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

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

The description provides action-specific parameter sets and optionality markers, covering most schema properties (name, participants, group_jid, description, link_action, invite, req_action, users). However, it never explains how the agent selects between the listed actions—there is no 'action' parameter in the schema. The 'account' parameter is also undocumented. With 0% schema coverage, the description needed to compensate more fully for these critical gaps.

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 appears to be for a general group lifecycle/admin tool, listing create, leave, update, invite_link, join, and requests. However, the tool name is specifically 'whatsapp_group_manage_requests', and separate sibling tools exist for most of these actions. This makes the tool's actual scope ambiguous and fails to distinguish it from siblings; the '[Flattened action: requests]' note adds further confusion rather than resolving it.

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

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

The only usage guidance is the prerequisite that the connected account must be a group admin for most actions. No guidance is given on when to use this combined tool versus the separate sibling tools (e.g., whatsapp_group_manage_create, whatsapp_group_manage_leave), nor when to choose the requests action over other actions.

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

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

With no helpful annotations beyond false hints, the description carries the burden of disclosing side effects but only lists actions. Leaving groups, revoking invite links, and rejecting requests are consequential administrative actions, yet the description does not explain their effects, irreversibility, or per-action permission 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?

The bulleted action list is compact and scannable, but the overall structure confuses because it describes all lifecycle actions in a tool named 'update'. The '[Flattened action: update]' note is jargon and undermines clarity.

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 multi-action tool with 9 parameters and no output schema, this description is incomplete: it does not explain return values, error behavior, which specific permissions each action needs, or how the 'account' parameter is used. The admin prerequisite is the only meaningful contextual detail.

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

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

The schema has 0% description coverage, but the action blocks add meaning by grouping parameters per action, marking optional fields with '?', and explaining enum values like link_action and req_action. It also clarifies that 'invite' accepts a code or full link, though it omits the 'account' parameter.

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 calls this 'Group lifecycle/admin' and lists many actions, but the tool name is 'whatsapp_group_manage_update' and sibling tools already cover create, leave, join, invite_link, and requests. The closing '[Flattened action: update]' is cryptic and does not clearly distinguish this tool from its siblings.

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

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

It provides useful contextual guidance by noting the connected account must be a group admin for most actions. However, it never explains when to prefer this tool over the sibling-specific group management tools, nor does it say which actions require admin.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context with '(live)' indicating real-time data and explicitly enumerates the returned participant attributes, going beyond the structured annotations.

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

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

Two tight, front-loaded sentences convey action, output shape, and input origin without redundancy. Every clause earns its place, and there is no filler or repetition of annotation metadata.

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 listing tool, the description covers input semantics, live behavior, and return fields sufficiently well, especially given strong annotations. The main gap is the undocumented 'account' parameter, which prevents a perfect completeness score.

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

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

With 0% schema description coverage, the description must compensate for both parameters. It does explain group_jid well (format and source), but the 'account' parameter is entirely undocumented, leaving agents to guess its purpose or required values.

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

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

The description uses a specific verb ('List') and resource ('members of a WhatsApp group'), clearly distinguishing it from mutation siblings like whatsapp_group_participants_add/remove. It also specifies the return fields (JID, phone, admin flag), making the tool's purpose concrete and unambiguous.

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

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

The description provides useful context: it requires group_jid in the format '…@g.us' sourced from whatsapp_groups. However, it does not explicitly state when to choose this tool over alternatives like whatsapp_chat_metadata or whatsapp_group_manage_update, nor does it mention exclusions.

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

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

The description states that the action 'add' invites users and requires admin rights, giving some idea of side effects (an invite is sent). It does not clarify whether the operation is idempotent, what happens if a number is already a member, or if it affects the group in other ways. It also doesn't indicate any destructive effects, which is consistent with the 'add' action.

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

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

The description is relatively concise and covers the main points in a few lines. However, it includes an extraneous 'Flattened action: add' label that seems like an artifact and lists all possible actions, which is redundant for a tool specifically named 'add'. Structurally, it is a single paragraph without clear separation of different aspects.

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

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

The description does not explain two of the three parameters and omits any information about return values or errors. It provides context about the admin requirement and user limit, but lacking parameter coverage leaves the tool incomplete for an agent to use correctly without additional assumptions.

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 the 'users' parameter is explained (as phone numbers or JIDs, 1–50 items). The 'account' and 'group_jid' parameters are never described, leaving their purpose ambiguous. Since the schema provides no descriptions, the tool description fails to clarify these essential 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?

The description clearly states that the tool manages WhatsApp group participants and lists possible actions (remove, promote, demote, add). However, the tool name specifically says 'add', while the description enumerates all actions, which could confuse an agent about which exact operation this tool performs. The admin requirement is mentioned clearly.

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 specifies the prerequisite (must be group admin) and the input format (1–50 phone numbers or JIDs). It does not provide explicit when-to-use guidance relative to sibling tools (e.g., use this for adding members, not removing), though the name hints at it. There is no mention of error handling or edge cases.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, but the description does not add much beyond that. It mentions the admin requirement and the action types, but does not disclose potential side effects (e.g., whether demoting is reversible, if it affects group state) or any rate limits. With annotations present, the bar is lower, but the description could add more context about what happens when demoting.

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

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

The description is concise, with two sentences plus a flattened action note. It front-loads the purpose and includes key details about users format. The '[Flattened action: demote]' is a bit redundant but not harmful. No wasted words.

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

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

Given the tool has 3 parameters, no output schema, and low schema coverage, the description provides some essential info (admin requirement, user format, action list) but lacks details on group_jid and account parameters, and does not describe return values or error conditions. It is adequate but not complete for a tool with this complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'users' accepts 1-50 phone numbers (+E164) or JIDs, which adds meaning. However, it does not explain 'group_jid' or 'account' parameters, leaving them undocumented. The description partially compensates but leaves gaps for two of three 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 clearly states the tool manages WhatsApp group participants with specific actions (remove, promote, demote, add) and the flattened action is 'demote'. It distinguishes from siblings like whatsapp_group_participants_add, promote, and remove by specifying the demote action, though it could be more explicit that this tool is specifically for demoting admins.

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 mentions the connected account must be a group admin, which is a key prerequisite. It lists the actions but does not explicitly state when to use this tool versus the sibling tools for add/promote/remove. The flattened action 'demote' implies usage, but no explicit alternatives or exclusions are given.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, which are not contradicted. The description adds the admin requirement and the action semantics, but doesn't disclose potential side effects like rate limits or whether actions are reversible. It's adequate but not rich.

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

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

The description is concise and front-loaded with the purpose. The '[Flattened action: promote]' suffix is a bit cryptic but doesn't waste space. It's efficient.

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

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

Given the tool has 3 params, no output schema, and no annotations beyond basic hints, the description covers the main actions and input format. However, it doesn't explain the 'account' parameter or the exact format of group_jid, and the '[Flattened action: promote]' is unclear. It's adequate for a simple tool but leaves some gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'users' (phone numbers or JIDs) and 'action' (though action is not in the schema properties, it's mentioned in the description). It doesn't explain 'group_jid' or 'account' beyond their names, but the description's mention of group admin and users provides some context. Baseline 3 is appropriate.

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

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

The description clearly states the tool manages WhatsApp group participants and lists the four actions (remove, promote, demote, add) with their effects. It distinguishes from siblings by naming the specific actions, though the tool name already implies 'promote'.

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

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

It provides clear context: the connected account must be a group admin, and it specifies the input format (1-50 phone numbers in E164 or JIDs). It doesn't explicitly say when to use this vs. the sibling tools like whatsapp_group_participants_add or demote, but the action parameter covers that.

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=false, but the description describes removing participants from a group, which is inherently destructive. This contradiction is a serious issue. No other behavioral details (e.g., irreversibility, permissions beyond admin) are disclosed.

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

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

The description is verbose and includes irrelevant actions, complicating the actual single-purpose tool. The 'Flattened action' line is confusing and not a natural part of the description. It lacks clear organization.

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

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

For a mutation tool with no output schema and minimal annotations, the description omits critical details like what happens after removal (e.g., irreversible?), error conditions, or response format. It only covers admin requirement and user list format.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'users' (1-50 phone numbers or JIDs) but leaves 'group_jid' and 'account' undefined. This is insufficient for proper usage.

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 lists multiple actions (remove, promote, demote, add) despite the tool being specifically for removal (per name and 'Flattened action: remove'), making the purpose ambiguous and misleading. It doesn't clearly state that this tool only removes participants.

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

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

Only mentions a prerequisite (group admin) and user count range, but does not explain when to use this tool versus the dedicated sibling tools for add, promote, and demote. It also incorrectly suggests the tool can perform other actions.

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

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

Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is established. The description adds useful detail about what fields are returned and that groups are scoped to the account, but it does not disclose pagination, account identifier expectations, or potential empty 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?

The description is one sentences short and front-loaded. It gives the core action and result in a compact, readable em dash phrase with no redundant wording.

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

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

For a simple read-only list operation, the description is largely complete: it identifies the resource, the scope, and the returned fields. The annotations already cover side-effect/destructive aspects. It is slightly shy of full completeness due to missing any notes on account handling or result limits.

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 0%, so the description carries the burden of explaining the 'account' parameter. It does indicate that the account is the one whose groups are the listed entity, but it does not explain the expected format, optionality, or behavior when omitted.

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 precisely states the operation ('List WhatsApp groups'), the scope ('the account belongs to'), and the returned fields ('subject, jid, participants count, owner'). This makes it clearly distinct from sibling tools like whatsapp_group_members or whatsapp_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 guidance is provided about when to choose this tool over related alternatives such as whatsapp_chats or whatsapp_group_members. There is no mention of when not to use it, prerequisites, or alternative tools.

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

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

Full disclosure of side effects: best-effort, throttling (60s cooldown), timeouts, partial results, connection requirements, and the fact it may take up to a minute. Annotations only say not read-only, but description goes far beyond.

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 well-organized with bullet-like status descriptions. A bit long, but every sentence adds critical caveats about throttling, timeouts, and partial results. Slightly verbose but earns its length.

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

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

Very complex tool: throttling, timeouts, partial results, dependence on phone, linkage to whatsapp_messages and whatsapp_history_coverage. Description covers all return statuses, retry guidance, prerequisites, and expected behavior. Exceptionally 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 has 0% coveragehol. Description explains chat_jid implicitly but does not describe count, account, or requests. The default count=50 is hinted by

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

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

The description clearly states the tool's purpose: requesting older messages from the phone to extend what whatsapp_messages can read. It explicitly contrasts it with whatsapp_messages and whatsapp_history_coverage, making the tool's niche obvious and distinct from sibling tools.

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

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

Provides explicit when-to-use (check whatsapp_history_coverage first, only when oldest_ts isn't far enough), when-not-to-use (don't retry in loops, wait 60s), and how to interact with related tools (whatsapp_messages with pagination). Clear exclusions and sequencing.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds value beyond those by clarifying the data source is the LOCAL message archive and by exposing the per-chat coverage fields and status, which helps the agent understand what the report represents.

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

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

Two sentences, with the main purpose front-loaded and the optional parameters compactly listed. Every clause adds useful information and there is no filler, fluff, or repetition of the schema enum/default.

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?

Even without an output schema, the description names the key output fields and explains how the report is used for pagination and backfill decisions. It is reasonably complete for a simple coverage/status tool, though a bit more detail on 'account' and 'status' values would make it fully self-contained.

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 0%, so the description must compensate. It covers the semantics of query (name/JID filter), kind, limit, and chat_jid, but omits the 'account' parameter entirely and gives no detail on how kind/limit interact with the results. The compensation is partial rather than complete.

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

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

The description opens with a specific verb and resource: 'Show how far back the LOCAL message archive reaches per chat' and even lists the returned fields (oldest_ts, newest_ts, message_count, status). It clearly distinguishes this from sibling tools by framing it as a coverage/pagination-boundary report rather than message retrieval or archive mutation.

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

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

The description gives explicit usage context: 'Use it to find pagination boundaries for whatsapp_messages and to decide whether to pull more with whatsapp_history_backfill.' It names the related tools and the decision workflow, though it does not explicitly state when not to use it or name direct 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 read-only, idempotent, and non-destructive behavior. The description adds transparency by specifying the exact data returned, which goes beyond the annotations. No contradictions.

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

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

The description is concise and directly conveys the essential information. It uses a clear format with an em dash to list returned fields, making it highly efficient without unnecessary words.

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

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

The description covers the tool's purpose and return fields, but does not explain the 'account' parameter or any prerequisites (e.g., authentication). Given the low complexity and minimal schema, it is mostly complete but lacks parameter context.

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

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

The input schema includes a single 'account' parameter of type string without any description. The tool description does not explain its purpose (e.g., filter, identifier, optional), leaving the parameter semantics ambiguous.

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

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

The description clearly states the tool's purpose: listing WhatsApp accounts paired to the install. It also specifies the fields returned (wa_jid, phone, label, proxy status, account status), making it highly specific and easy to distinguish from sibling tools.

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

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

The description implicitly indicates when to use the tool (when you need to list paired WhatsApp accounts) and there is no ambiguity among siblings. However, it does not explicitly compare with alternatives or mention any prerequisites, but given uniqueness, it is adequate.

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

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

Annotation Contradiction: the description describes deletion, and the tool name is whatsapp_message_delete, but annotations declare destructiveHint=false. This is a serious inconsistency. The description does add useful context like for_everyone defaulting to true and 'your msg' prerequisite, but the contradiction undermines trust and transparency.

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

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

The bullet formatting is readable, but the content is not appropriately scoped: it includes forward and edit actions that do not belong in a delete tool, plus the odd 'Flattened action: delete' note. The vague introductory phrase and extra action blocks make the description longer and more confusing than necessary.

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

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

The description covers the core delete behavior, the for_everyone distinction, and bulk deletion, which is useful for a 7-parameter tool with no output schema. But it omits account parameter semantics, what the response/return value is, any error or permission context, and how the action is determined given the listed multiple actions. This is a partial but not complete description.

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

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

The schema has 0% description coverage, so the description carries the burden. It adds meaningful semantics for chat_jid, message_id, for_everyone, to, text, and message_ids, including a default value for for_everyone. However, the account parameter is not explained, and the forward/edit action blocks add ambiguity about which parameters actually apply to the flattened delete action.

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 does identify a delete action with clear semantics ('delete for everyone (your msg) or just for you') and mentions bulk support, but the opening phrase 'Manage a message you can act on' plus listing forward and edit actions obscures the fact that this is a delete-specific tool. It does not distinguish itself from the sibling whatsapp_message_forward and whatsapp_message_edit 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?

There is no explicit guidance about when to use this tool rather than siblings. The description actually lists forward and edit as actions, implying they belong here, while sibling tools exist for those operations. Bulk support is mentioned but there is no guidance on when to use message_ids versus single message_id.

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?

There is a clear annotation contradiction: the description includes a destructive 'delete' action, but the annotations set 'destructiveHint: false'. Additionally, the description mentions bulk support via 'message_ids' without clarifying scope or side effects, and the edit action's limitations are only partially disclosed ('recent text 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?

The description is structured with bullet points but includes redundant information (delete and forward actions that have dedicated tools) and an odd 'Flattened action: edit' note. It is not as concise as it could be, though it avoids excessive verbosity.

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

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

The description lacks essential context such as expected return values, side effects, error conditions, and how the bulk mode works. It also does not explain the relationship between the three listed actions and the actual tool behavior, leaving the agent without a complete picture of when and how to invoke the tool correctly.

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

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

The description explains some parameters (e.g., 'for_everyone', 'to', 'text') but omits 'account' entirely and does not clarify how 'message_ids' interacts with the required 'message_id'. It also fails to specify which parameters trigger which action, leaving the mapping between actions and inputs unclear.

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 the vague verb 'Manage' and lists three distinct actions (delete, forward, edit) under a tool named 'whatsapp_message_edit', making the primary purpose ambiguous. It fails to clearly state that this tool is specifically for editing messages, especially given dedicated sibling tools for delete and forward.

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

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

No explicit guidance on when to use this tool versus the dedicated 'whatsapp_message_delete' and 'whatsapp_message_forward' tools. The inclusion of delete and forward actions in the description could mislead an agent into using this tool for those unrelated operations.

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

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

There is a clear annotation contradiction: the description describes deleting messages 'for everyone' and editing messages, which are destructive/mutating operations, while annotations declare destructiveHint=false. The description also does not explain what happens after forwarding, authenticity/account requirements, or retry/idempotency concerns.

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 action list is compact and scannable, but it spends valuable space on delete and edit behaviors when the tool name and 'Flattened action: forward' indicate this tool is specifically for forwarding. A single focused forward-focused description would be clearer and more concise.

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 7-parameter mutation tool with no output schema and minimal annotations, this description still omits prerequisites, account semantics, valid chat JID formats, return behavior, failure modes, and how bulk execution behaves. Combined with the annotation contradiction, it does not provide enough reliable context for correct tool invocation.

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

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

With 0% schema description coverage, the action shorthand adds useful meaning for chat_jid, message_id, to, text, for_everyone default true, and message_ids bulk support. However, the account parameter is not explained, and it is unclear which action-specific parameters still apply after the 'Flattened action: forward' instruction.

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 contains a concrete forward action ('forward ... to another chat'), but it is buried inside a generic 'Manage a message you can act on' list that also describes delete and edit. The extra 'Flattened action: forward' note helps, but the overall purpose remains ambiguous and not clearly differentiated from sibling delete/edit tools.

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

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

It provides no explicit guidance on when to use this tool versus whatsapp_send_text, whatsapp_message_delete, or whatsapp_message_edit. Instead, the description actually lists delete and edit as behaviors of this same tool, which increases confusion about which sibling to use and when.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about local-only data and pagination behavior, which goes beyond annotations. However, it doesn't detail the return format or error cases, but given the annotations, this is sufficient.

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

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

The description is concise, front-loaded with the main purpose, and every sentence adds value. It efficiently covers usage, pagination, and related tools without fluff.

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

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

The tool has 7 parameters and no output schema, but the description covers the essential usage and pagination. It references related tools for coverage and backfill, which helps the agent understand the broader context. It could mention the limit parameter or return format, but overall it's complete enough for a list operation.

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 0%, so the description must compensate. It explains the key parameters: chat_jid (required, from whatsapp_chats), before/after for pagination, and order for sorting. It doesn't explain limit, since, or account, but the core semantics are covered. Given the low schema coverage, this is a strong effort.

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

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

The description clearly states the tool lists messages in a chat from local history, with a specific verb and resource. It distinguishes from siblings by noting it only returns locally synced messages and referencing related tools for coverage and backfill.

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 explains when to use this tool (list messages from local history), how to paginate (before/after with timestamps), and when not to use it (to see archive coverage or pull older messages, use whatsapp_history_coverage and whatsapp_history_backfill). This provides clear context and 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 indicate readOnly=false and destructiveHint=false, which aligns with the mutation described. The description adds behavioral context (e.g., omit message_id to mark all unread) and mentions a requirement (chat_jid), going beyond annotations without contradiction.

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

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

The description is compact and direct, two sentences with no redundant information. It efficiently conveys the operation and key parameters.

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

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

The description is sufficient for the tool's simplicity. It covers the operation, required/optional parameters, and bulk behavior. No output schema exists, so return values are not expected. Error handling isn't mentioned, but this is acceptable given the tool's scope.

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 descriptions are absent, but the description explains chat_jid (required), message_id (optional, marks up to), and message_ids (bulk). The 'account' parameter is not explained, so coverage is partial but covers the core semantics.

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

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

The description clearly states the action: 'Mark messages as read in a chat.' This is specific and distinguishes from sibling tools like whatsapp_send_text or whatsapp_message_delete.

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

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

Provides clear usage details: requires chat_jid, optional message_id to mark up to a specific message or omit to mark all unread, and bulk support via message_ids. It doesn't explicitly compare to alternatives but the intent is evident.

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

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

The description adds some behavioral context by listing create and vote actions, and noting bulk support via message_ids. However, it does not clarify the 'flattened action' ambiguity, nor does it explain side effects, prerequisites (e.g., authentication), or what happens after a poll is created. Since annotations provide no hints (all false), the description carries the full burden and falls short.

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

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

The description is brief and well-structured with clear bullet points for actions. It efficiently conveys a considerable amount of information in a compact format. However, the '[Flattened action: create]' line adds unnecessary confusion and could be clarified, slightly reducing the structure's clarity.

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

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

Given the tool has 8 parameters, no output schema, and no annotation hints, the description is insufficient. It fails to explain the purpose of the 'account' parameter, does not resolve the create/vote ambiguity, and provides no guidance on return values or side effects. The bulk support mention is helpful but does not compensate for the overall lack of context.

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

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

The description adds meaning to several parameters by grouping them under actions: create uses to, name, options[] (with the 2–12 constraint), and selectable_count; vote uses chat_jid, message_id, and options[]. This is helpful, but parameters like 'account' and 'message_ids' are only partially addressed (message_ids mentioned in bulk support, account ignored). With 0% schema description coverage, this partial compensation is insufficient for full clarity.

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

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

The description states the tool can 'Send a poll or vote on one,' which is a clear dual-purpose statement. However, the subsequent '[Flattened action: create]' note introduces ambiguity by suggesting only the create action is active, contradicting the earlier mention of voting. This confusion, especially given the existence of a sibling tool whatsapp_poll_vote, makes the purpose less clear.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that voting could be handled by the separate whatsapp_poll_vote tool, nor does it explain when to use the create vs vote actions within this tool. The only usage hint is 'Bulk support: accepts message_ids for batched execution,' which is a capability note, not a usage guideline.

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

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

The description adds useful context beyond annotations: it defines create and vote parameter sets and mentions bulk execution via message_ids. However, it leaves key behaviors unexplained, such as how the action is selected (since the input schema has no action field), whether vote replaces or appends a prior vote, and what account-related parameters do. It does not contradict the annotations, but the transparency is incomplete.

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

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

The description is compact, front-loaded with the core action, and organized into clear action blocks plus a bulk note. Each line adds information. The '[Flattened action: vote]' line is cryptic but not verbose, so the overall structure is efficient.

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

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

Given 8 parameters, no output schema, and minimal annotations, the description is not complete enough for confident invocation. It omits account semantics, action selection, required-field enforcement, and return behavior, and it conflicts with the sibling poll-create tool. This is a complex dual-action tool where the description leaves important operational gaps.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it does explain options (2–12), option texts as selection values, chat_jid/message_id for voting, and message_ids for bulk. Yet it omits the 'account' parameter entirely and fails to clarify how to choose create vs. vote when the schema has no action parameter and only 'options' is required. This is helpful but insufficiently precise.

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 says 'Send a poll or vote on one' and lists create/vote actions, so it names a verb and resource. However, the '[Flattened action: vote]' note conflicts with the create action, and the sibling tool whatsapp_poll_create creates ambiguity about whether this tool should ever be used to create polls. It does not clearly distinguish itself from the sibling create tool.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The description mentions bulk support and action parameter shapes, but does not explain when to choose this tool over whatsapp_poll_create or how a voting flow should start (e.g., needing an existing poll message). No alternatives or exclusions are 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 are all false and provide no info, so the description carries the burden. It discloses two key behaviors: empty emoji removes the reaction, and bulk execution is supported. It does not mention side effects like visibility or permissions, but these are not dramatic for a reaction tool. The added behaviors go beyond the schema and annotations, warranting a 4.

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

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

The description is extremely concise—two sentences—and front-loads the primary action. Every sentence adds value: the first states the core function plus removal, the second notes bulk. No redundant or promotional language.

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 5 parameters, 2 required, no output schema, and minimal annotations, the description covers the essential behaviors (react, remove, bulk) and identifies required inputs. It lacks details on the emoji format and account parameter, but the tool is relatively simple. Given the complexity, it is fairly complete, earning a 4.

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 0%, so the description must compensate. It explains the required pair (chat_jid, message_id) and the bulk parameter (message_ids), but does not explain emoji (though its purpose is evident from the description) or account. Partial coverage, hence a 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?

The description clearly states the tool's purpose: 'React to a message with an emoji' and includes the removal case via empty emoji. It references the specific resource (message) and distinguishes it from siblings like whatsapp_message_edit or whatsapp_send_media by focusing on reactions.

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

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

It provides explicit usage context: requires chat_jid + message_id, and mentions bulk support via message_ids. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an agent to know when this tool applies. Slightly below a 5 due to missing exclusion statements.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it returns matches with context, and mentions the optional scoping, which adds some value beyond annotations. No contradiction.

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

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

The description is two sentences, front-loaded with the core purpose, and includes only essential info. No filler or redundancy.

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

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

For a 4-parameter tool with no output schema, the description gives a basic overview but omits details on result format, ordering, pagination, and the account parameter. Annotations cover safety, but the description leaves several gaps that an agent would need clarified.

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 0%, so the description must explain parameters. It only explains chat_jid ('optional... to scope') and implicitly suggests query is the search term, but limit and account are left unexplained. This is insufficient given the lack of schema descriptions.

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

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

The description clearly states the tool performs full-text search across stored messages using SQLite FTS5, which distinctly separates it from sibling tools like whatsapp_messages (listing) or whatsapp_chats. It includes the optional chat_jid scoping, giving specific verb+resource clarity.

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

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

It implies usage for searching message content, and mentions optional chat_jid for scoping, which helps the agent decide when to use it. However, it doesn't explicitly contrast with alternatives like whatsapp_messages or provide exclusions, but the purpose 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?

The description focuses on input syntax, not behavior. It does not disclose likely side effects, delivery guarantees, error conditions, or authorization requirements. Annotations provide only generic false hints, so the description must carry the transparency burden but does not.

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

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

The description is compact and well-structured with clear action blocks, making it easy to scan. The closing '[Flattened action: media]' is cryptic and adds marginal value, but overall the description earns its length.

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

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

The description covers most input parameters and the important address-format nuance, but it omits the `account` parameter, offers no return/error expectations, and provides no post-send behavioral detail. Without annotation or output schema support, this leaves meaningful gaps for the agent.

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

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

With schema coverage at 0%, the description adds critical meaning: explains the `to` format, enumerates `type` values, gives the media source alternatives (media_url | media_base64), and optional fields like caption/filename/mimetype/reply_to. It misses describing the `account` parameter entirely.

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

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

The description clearly states 'Send a WhatsApp message (text or media)', identifying the verb and resource. It differentiates text vs media action shapes but does not explicitly distinguish this from the sibling whatsapp_send_text tool, despite overlapping text-sending capability.

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

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

It provides concrete usage guidance for address formats ('JID' vs plain phone) and for groups ('always use the <id>@g.us JID — get it from whatsapp_groups'). However, it gives no guidance on when to choose this tool over whatsapp_send_text or other 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 convey write/non-idempotent/non-destructive traits, and the description adds useful mode details: reply_to support, media_url/base64 alternatives, and group JID requirement. It does not disclose delivery/error behavior or account selection semantics, but these are not contradicted by annotations.

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

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

The description is well-structured with an opening line, typed action blocks, and a focused note on group JIDs. The 'Flattened action: text' trailing note adds little value and could confuse, preventing a 5.

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

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

This is a 10-parameter write tool with no output schema and heavy sibling overlap, yet the description omits account semantics, expected return/error behavior, and any relation to whatsapp_send_media. It covers input syntax but is not complete enough for an agent to confidently distinguish invocation contexts.

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

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

With 0% schema description coverage, the description compensates well by defining the `to` format, text/media action shapes, optional reply_to, and media parameters. It fails to explain the `account` parameter, which is one of ten fields, leaving a small but meaningful gap.

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

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

The description clearly states a specific action ('Send a WhatsApp message') and differentiates text vs media modes via an Actions block. However, it does not distinguish this tool from sibling whatsapp_send_media, which appears to cover similar media functionality.

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

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

The description gives useful context for the `to` parameter (JID vs plain phone, group JIDs from whatsapp_groups) and shows when text vs media actions apply, but it never says when to prefer this tool over whatsapp_send_media or whatsapp_messages_write. Guidance is implied by the inline action schemas rather than explicit tool-selection rules.

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

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

The description adds useful behavioral context beyond the annotations: it states the tool connects live and may take 20–60s, and it discloses the return shape ({ messages_stored }). Annotations already declare readOnlyHint=true and idempotentHint=true, so the bar is lower; the added latency and return info are valuable supplementary details.

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

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

The description is information-dense, front-loading the purpose with a clear action and then providing usage guidance, latency, and return value. It is slightly verbose (four sentences) but every sentence conveys essential information, keeping it relatively concise for the amount of context it delivers.

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

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

Given the tool's moderate complexity (sync operation, one parameter), the description covers usage timing, latency, and return value. However, it fails to explain the 'account' parameter or mention prerequisites (e.g., authentication via authenticate/connect). This omission reduces completeness, as agents may not know how to supply a valid account.

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

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

The single parameter 'account' is completely undocumented—schema description coverage is 0%. The tool description never mentions the parameter, its expected format, or how to obtain valid values (e.g., from whatsapp_list_accounts). This is a significant gap that forces the agent to guess.

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

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

The description clearly states the tool refreshes local WhatsApp data (messages, groups, contacts) into the local store. It goes beyond a simple verb+resource statement by specifying the scope (recent messages, groups/contacts lists). It does not explicitly differentiate from the closely related sibling whatsapp_history_backfill, so it loses a point.

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

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

Explicitly instructs when to call it: 'BEFORE reading (chats/groups/messages/contacts/search) when results look stale or empty' and provides concrete examples (right after connecting, or an account that hasn't synced recently). It does not mention alternatives or when not to use it, but the context is clear enough for most scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful context by specifying the owner/admin permission requirement and detailing the returned fields, including the 'empty = all' semantics for subscribed events.

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

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

The description is a single, well-structured sentence that front-loads the core action and then lists the key returned fields. Every clause adds useful information without redundancy.

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

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

With no output schema, the description compensates by enumerating the response contents (URL, subscribed events, include_result, available_events) and giving concrete examples of event names. This is complete for a simple, parameterless read-only tool.

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

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

The tool has zero parameters, so parameter-level semantics are not applicable. The description adds value by explaining what the response will contain, which is the relevant semantic information for this parameterless getter.

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 clearly identifies the resource ('this WhatsApp install's outbound webhook'), then enumerates the exact fields returned. It also distinguishes itself from the sibling whatsapp_webhook_set by being the read counterpart.

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

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

The description makes the tool's purpose and context clear by stating it retrieves webhook configuration and that it is owner/admin only. It does not explicitly mention when not to use it or name alternatives, but the get/set sibling relationship makes the use case obvious.

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

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

Annotations give no hints on permissions or side effects, but description explicitly states 'Owner/admin only' and explains that subscribing to whatsapp.* makes the daemon hold live connections, which is key behavioral context. It also notes https-only, no-localhost, and include_result default. This adds real value beyond 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?

Well-structured with bullet-like segments and clear separation of set vs remove modes. Slightly verbose in the events explanation, but every sentence carries necessary info. No fluff.

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

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

Covers permissions (owner/admin), URL constraints, event semantics, side effects of live connection, and removal mode. Missing explicit return value description, but for a set operation the absence is acceptable. With no output schema, a note on what the tool returns would make it 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 0% and params are just types. The description explains every parameter: url (https only, not localhost), events (examples, [] for all), include_result (default true), secret (optional/reserved), remove (boolean to remove). Also clarifies the relationship between url and remove. This is exemplary parameter documentation.

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

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

The description clearly states the tool sets or removes an outbound webhook for a WhatsApp install, with owner/admin-only access. It explicitly distinguishes from the sibling tool whatsapp_webhook_get by focusing on the set/remove mutation side.

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

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

Provides explicit when-to-use instructions: passing `url` sets, `remove: true` (or empty url) removesched. It also mentions prerequisites (owner/admin only) and refers to whatsapp_webhook_get for available events. Clear contexts and mode distinction.

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