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

Annotations already indicate this is a mutable, non-destructive, open-world operation. The description adds the ability to reverse (unarchive), but does not disclose other behavioral nuances like chat visibility changes or message preservation. No contradiction with annotations.

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

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

A single sentence that is concise and front-loaded with the action. Every word earns its place, and there is no 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 simple tool with two well-documented parameters and no output schema, the description plus schema is largely sufficient. It might benefit from explaining the effect of archiving (e.g., hiding from chat list), but the core functionality is covered.

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

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

Schema description coverage is 100%: both `archive` and `remote_jid` are clearly documented. The description does not add anything beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states it archives or unarchives a WhatsApp chat, with a specific verb and resource. It does not explicitly differentiate from sibling tools, but its function is unique enough among the listed siblings that confusion is unlikely.

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 this tool should be used or why it might be preferred over alternatives. The description simply states the action without offering context or exclusions.

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

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

Annotations already indicate destructiveHint=true, and the description adds the meaningful behavioral detail that blocking prevents the contact from sending messages. It also implies reversibility via unblock, which complements the 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?

Two concise sentences with the primary action front-loaded. Every word adds value, and the additional sentence clarifies the behavioral impact 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?

For a simple two-parameter tool with no output schema, the description covers the core function and effect. It could mention return values or edge cases, but given the tool's simplicity and annotations, 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 description coverage is 100%, and the schema fully explains both 'number' and 'status'. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the action (block or unblock) and the resource (WhatsApp contact), and adds a behavioral note about preventing messages. This specifically distinguishes it from sibling tools like send_text or delete_message.

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

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

The context is clear: use this tool to block or unblock a contact. No explicit alternatives are named, but the purpose is unambiguous and doesn't overlap with siblings, so the lack of when-not guidance is acceptable.

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 the return state values (open/close/connecting), which adds behavioral context beyond the annotations (readOnlyHint, openWorldHint). This is consistent with the annotations and provides useful detail about the tool's output format.

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 sentence that is front-loaded with the verb 'Check' and includes the essential scope and output. Every word earns its place, with no redundancy or unnecessary detail.

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

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

For a zero-parameter tool with no output schema, the description fully covers what the tool does and what it returns, including possible states. It is self-contained and leaves no ambiguity for an agent invoking it.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description adds no parameter semantics, but none are needed; the baseline score of 4 applies given the absence of 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 checks the connection status of a WhatsApp instance, using a specific verb and resource, and even specifies the return state (open/close/connecting). It is distinct from sibling tools, which focus on messaging, contacts, or group management.

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 usage is implied by the tool's straightforward function, but the description does not explicitly state when to use it or contrast it with alternatives. It lacks contextual guidance like 'use this before sending messages' or any exclusions, leaving the agent to infer the appropriate scenario.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful context about the return value (existence and JIDs), which helps the agent understand behavior beyond the schema. It does not go into rate limits or side effects, but those are less critical given the read-only nature.

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 function and return value. No filler or repetitive content. Every word contributes to understanding the tool.

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

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

The tool is simple with one parameter fully documented in the schema. Although there's no output schema, the description clearly states what the tool returns (existence and JIDs). This is sufficient for an agent to select and invoke the tool correctly.

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

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

The schema already fully documents the single parameter 'numbers' with format guidance and examples. The description adds no additional information about parameters; it focuses on the return value. Baseline for 100% schema coverage is 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 function: 'Verify if phone numbers are registered on WhatsApp' and specifies the output 'Returns which numbers exist and their JIDs.' This distinguishes it from sibling messaging and contact 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 its use case (pre-contact verification) but doesn't explicitly state when to avoid it or mention alternatives. Since it's a unique checking tool among siblings, the context is clear, but there's no explicit exclusion or alternative guidance.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, covering basic write and safety semantics. However, the description adds no extra behavioral context—no side effects, return value, or prerequisites—so it provides minimal value beyond the annotations.

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

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

The description is a single, clear sentence with no filler or redundancy. It concisely communicates the core function without wasting words.

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

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

With 3 parameters fully described in the schema and annotations present, the description is adequate for a simple create operation. However, no output schema exists and the description does not mention what is returned (e.g., group ID), leaving some uncertainty about the tool's complete behavior.

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

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

The schema covers all parameters with descriptions (subject, description, participants), so the description adds no new meaning. It merely says 'with specified participants,' which is already explicit in the schema. 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 creates a new WhatsApp group with specified participants, using the specific verb 'create' and resource 'WhatsApp group.' This distinguishes it from sibling tools like update_group_subject or find_group, which have different purposes.

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 when a new group is needed: 'Create a new WhatsApp group' provides clear context. It does not explicitly mention exclusions or alternatives, but the presence of sibling update tools makes the intended use reasonably evident, though not explicitly stated.

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

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

Annotations already flag the tool as destructive and not read-only. The description adds valuable context: deletion is 'for everyone' (affects the entire chat), only works for self-sent messages, and has a time limit. This goes beyond annotations and warns about the limited applicability, though it doesn't detail failure modes or reversibility.

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 (two sentences) and front-loaded, immediately stating the purpose. The second sentence adds necessary constraints without extraneous detail. Every word contributes value.

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

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

For a simple destructive tool with three clearly documented parameters and no output schema, the description covers the essential behavioral aspects: scope of deletion (everyone), eligibility (own messages), and time constraint. It is complete enough for an agent to decide when to invoke it, though it does not specify error handling or return values, which are not required given the 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 already covers all three parameters (remote_jid, message_id, from_me) with clear descriptions, resulting in 100% schema coverage. The description adds no new parameter-specific semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool deletes a WhatsApp message for everyone in the chat, using the specific verb 'delete' and the resource 'message'. It distinguishes from siblings like update_message and mark_as_read by indicating the action and scope (for everyone), and it further clarifies that only messages sent by the user are eligible.

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 constraints: it only works for messages you sent and within a time limit. This clearly signals when the tool is applicable and when it should not be attempted. It does not name alternatives, but the context of siblings (e.g., update_message) and the constraints are enough to guide the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the admin privilege requirement, which is valuable authorization context that annotations do not cover. It does not describe error behavior or edge cases, but for a simple read-only tool this is adequate.

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

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

Two concise sentences with no redundant wording, front-loading the core action. Every word is purposeful, making it highly scannable.

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

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

For a one-parameter read-only tool with strong annotations, the description covers the purpose and authorization requirement. The parameter is fully documented in the schema, and the return value is implied by the description. It lacks explicit error-case details but is sufficient for this simplicity.

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

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

Schema coverage is 100% and the parameter is clearly documented with an example in the schema. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb 'Get' and resource 'invite link/code for a WhatsApp group', clearly distinguishing it from sibling 'send_group_invite' (which sends invites) and other group tools. The purpose is immediately 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 states 'Requires admin privileges', providing a clear precondition and implicitly indicating when not to use (non-admin context). However, it does not explicitly mention alternative tools or provide when-to-use guidance beyond the basic purpose.

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

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

The readOnlyHint and destructiveHint annotations already establish the safety profile. The description adds minor context about return content ('name, status, etc.') but does not disclose any additional behavioral traits such as rate limits, authentication requirements, or failure modes. It is consistent with annotations.

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

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

The description is one succinct sentence that front-loads the verb and resource, includes an example of the return content, and contains no fluff. Every word earns its place.

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

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

For a simple read-only tool with one fully documented parameter and strong annotation coverage, the description is nearly complete. It could be slightly more explicit about differentiating from fetch_profile_picture, but the provided information suffices for correct 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?

Schema coverage is 100%, so the description does not need to repeat parameter details. The one parameter 'number' is fully described in the schema. The description adds no further semantic depth beyond the schema, matching the baseline for full coverage.

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

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

The description uses the specific verb 'Fetch' and identifies the resource as 'WhatsApp profile information of a contact', further clarifying by listing fields ('name, status, etc.'). This clearly differentiates it from siblings like fetch_profile_picture, which targets the avatar.

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 use case (retrieving profile info) but provides no explicit guidance on when to use this tool versus alternatives like fetch_profile_picture or check_whatsapp_numbers. The context is clear but lacks explicit exclusions or named 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return type (URL) but does not explain behavior for edge cases like missing profile pictures or invalid numbers. With annotations present, 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?

The description is a single sentence that immediately states the purpose, with no redundant words or filler. It is concise and front-loaded, earning full marks for efficiency.

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

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

For a simple one-parameter, read-only tool with no output schema, the description adequately states the task and result (URL). It could mention behavior when no profile picture exists, but overall the essentials are covered given the tool's simplicity.

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

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

The input schema covers 100% of parameters with a detailed description of the 'number' parameter, including an example. The description adds no further parameter-level semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool fetches a profile picture URL for a WhatsApp contact, using a specific verb and resource. However, it does not differentiate from the sibling tool 'fetch_profile', which likely returns more general profile information, so it misses the opportunity to distinguish itself.

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 fetch_profile. The description merely states the function without any context on use cases, prerequisites, or 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?

With readOnlyHint and destructiveHint annotations already indicating a safe read operation, the description adds value by specifying that the tool returns chat metadata including last message and unread count. It does not contradict any annotations, but also doesn't disclose potential limitations like pagination or open-world variability, though those are partially covered by openWorldHint.

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 consists of two short, information-dense clauses: the core function and a preview of the returned data. Every part serves a purpose, with no filler or redundant repetition of schema information.

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

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

Given the tool's simplicity (no parameters, no output schema) and the presence of readOnlyHint, the description adequately covers the essential behavior and return type. The mention of 'last message, unread count, etc.' gives the agent a useful expectation, though a structured output schema would have made it more 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?

The tool has zero parameters, so the description need not explain any argument semantics. According to the rubric, a 0-parameter tool receives a baseline score of 4, which is appropriate here since there is nothing more to clarify.

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 specific verb 'List' with the resource 'WhatsApp chats/conversations', making the tool's function immediately clear. It distinguishes itself from sibling tools like find_contacts and find_messages by targeting chat-level metadata, which leaves no ambiguity about its scope.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_groups or find_messages. It simply states what the tool does without mentioning exclusions, prerequisites, or contexts where other tools would be more appropriate.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the scope of results (all vs. filtered by JID) but does not disclose additional behavioral nuances like pagination, ordering, or partial field returns. With annotations bearing the safety burden, the description adds some but not rich behavioral context.

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

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

The description is a single, focused sentence and a half: 'Search WhatsApp contacts. Returns all contacts if no filter is provided, or a specific contact by JID.' Every word earns its place, with no filler or redundant phrasing.

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

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

The tool is simple: one optional parameter, no output schema, and annotations covering safety. The description explains both modes and the parameter's semantics, fully covering the tool's behavior. No additional context is necessary 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?

Schema description coverage is 100%, as the only parameter filter_id is thoroughly documented with an example JID and instruction to omit for all contacts. The description does not add any information beyond what the schema already provides, so it meets the baseline but does not enhance understanding.

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

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

The description clearly states the tool's function: 'Search WhatsApp contacts.' It further specifies the scope (all contacts vs. a specific contact by JID), which distinguishes it from sibling tools like send_contact that generate contact cards rather than search the contact list. The verb 'search' and resource 'WhatsApp contacts' are specific 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 clear context for when to use the tool: 'Returns all contacts if no filter is provided, or a specific contact by JID.' This implies the primary use cases. However, it does not explicitly mention exclusions or alternatives, such as 'use fetch_profile for profile details' or 'do not use for sending contacts,' so it does not reach the level of fully exploring when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds 'detailed information' but does not specify what fields are returned or behavior on missing JID. With strong annotation coverage, this is acceptable and does not contradict annotations.

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

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

The description is a single, front-loaded sentence containing only essential information. No filler, no redundancy, and it immediately communicates the tool's core function.

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 lookup with one well-documented parameter and no output schema, the description is complete. The tool's role among siblings (e.g., group_participants for participants) makes it clear that 'detailed information' means group metadata, not participant lists. No additional context is necessary.

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

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

Schema coverage is 100% for the single required parameter group_jid, described as 'Group JID (e.g. 120363012345678901@g.us)'. The description simply says 'by JID', which adds no meaning beyond the schema, so baseline 3 applies.

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

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

The description uses a specific verb ('Get') with a specific resource ('detailed information about a specific WhatsApp group') and identifies the lookup key ('by JID'). This clearly distinguishes it from sibling tools like list_groups or group_participants, which serve different purposes.

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

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

The description clearly implies the use case: you need details for one known group JID. However, it does not explicitly exclude alternatives or name a sibling tool for different scenarios (e.g., list_groups for all groups), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns recent messages ordered by timestamp, which is a useful behavioral trait beyond annotations. No further details like pagination are provided, but with annotations covering safety this is adequate.

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

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

Single concise sentence, front-loaded with the core action and outcome. 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?

For a simple read tool with two well-documented parameters and a clear annotation profile, the description covers the essential behavior (what it does, scope, return order). No output schema exists, but the return statement gives a reasonable hint without needing full structure.

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

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

Schema coverage is 100%, so the schema documents both parameters. The description minimally reinforces that remote_jid identifies a specific chat but adds no new semantics for limit or JID format.

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

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

Clear verb+resource: 'Retrieve messages from a specific WhatsApp chat'. Distinguishes from sibling tools like find_chats (finds chats) and send_* (sends messages), and aligns with the read-only nature.

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?

States the context 'from a specific WhatsApp chat', implying you need a remote_jid and that this is for reading history in a known chat. Doesn't explicitly name alternatives or exclusions, but the sibling context makes it clear when to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context that temporary URLs expire, implying this tool provides a persistent base64 result, but doesn't disclose additional behaviors such as output size limits or failure modes.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains no redundant or verbiage. Every sentence earns its place, making it highly concise and 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, annotations, and full schema coverage, the description provides sufficient context: it states the purpose, offers a usage alternative, and identifies the parameter source. It doesn't explain convert_to_mp4, but the schema covers that, so the overall completeness is strong.

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

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

Schema description coverage is 100%, with both parameters already described. The description repeats the source of message_id (from find_messages results) but adds no new information about convert_to_mp4 or parameter formatting, so it contributes 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 the tool extracts media content as base64 from a WhatsApp message, using a specific verb and resource. It distinguishes itself from siblings like send_media (sending) and find_messages (searching) by focusing on the extraction/retrieval of media.

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 recommends using this tool instead of temporary media URLs, which expire quickly, and instructs to pass the message key ID from find_messages results. This provides clear context and a direct alternative, though it doesn't explicitly mention when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it lists 'all' members, but no further behavioral context such as return format, pagination, or error handling is provided. It neither contradicts nor substantially extends beyond the annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose without repetition or filler, making it highly concise and 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?

For a simple read-only list tool with one well-documented parameter and no output schema, the description is fairly complete. It tells the agent exactly what the tool does and what input is needed. It does not explicitly describe the return format, but this is a minor gap given the simplicity and the presence of read-only annotations.

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

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

The schema already provides 100% coverage for the single parameter group_jid with a clear description and example. The tool description does not add any additional meaning beyond what the schema already explains, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('all members/participants of a specific WhatsApp group'). It is immediately distinguishable from sibling tools like list_groups (which lists groups) and find_group (which finds a single group), making the purpose unambiguous.

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

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

The description implies usage: you need a specific group JID to list its participants. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it. The context is clear but the guidance is implicit rather than explicit.

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

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

Annotations already mark destructiveHint=true, and the description adds specific behavioral context: the action is irreversible and requires a new invite to rejoin. This goes beyond the annotation's generic destructive flag. No contradiction with annotations.

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

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

Two sentences with no wasted words. The first sentence states the action, the second adds essential consequence. Information is front-loaded and every word earns its place.

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

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

For a simple tool with one parameter and destructive annotations, the description covers the essential context: it states the action and the irreversible consequence (need for new invite). No output schema exists, so no return-value explanation is needed. Completeness is strong.

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

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

The input schema fully describes the single parameter group_jid, including an example format. The description adds no additional parameter-specific meaning, so it relies on the schema's 100% coverage. Baseline of 3 is appropriate.

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

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

Clearly states the action ('Leave') and resource ('a WhatsApp group'), distinguishing it from sibling tools like create_group or send_group_invite. The verb and object are specific 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?

No guidance on when to use this tool versus alternatives. It only describes the action and consequence, without any comparison to sibling tools like group_participants or create_group, nor any 'use this when' 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 and destructiveHint=false, so the safety profile is covered. The description adds the scope (groups of the connected number) but does not disclose additional behavioral details like pagination or potential incompleteness. openWorldHint=true does not seem contradicted, but no extra value is added beyond the annotation.

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

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

The description is a single, clear sentence with no redundant words. It is front-loaded with the action and resource, making it easy to parse.

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

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

For a simple listing tool with one optional parameter and strong annotations, the description is sufficient. It states the exact scope of results, and no output schema exists so return values are not required. It covers all necessary context without 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?

The input schema has only one boolean parameter (get_participants) with a clear description, achieving 100% schema coverage. The tool description does not add any further meaning about parameter usage or effect, so it meets the baseline but does not enhance it.

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

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

The description clearly states the action ('List') and the resource ('all WhatsApp groups the connected number participates in'), which is specific and distinguishes this from sibling tools like find_group or group_participants by emphasizing enumeration of all groups.

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

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

The description implies use when you need to enumerate all groups the connected number is in, but it does not explicitly contrast with alternatives such as find_group for searching or group_participants for a specific group. No when-not guidance is provided.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the nuance that only specific messages are affected, which is useful, but it does not disclose effects like read receipts or reversibility. It neither adds rich context nor contradicts 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 a single sentence of nine words, front-loaded with the action and object. Zero 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 low-complexity tool with two fully documented parameters and annotations covering safety, the description is complete. It would benefit from noting whether marking as read has side effects on chat state, but overall it sufficiently defines the 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 100%, with both remote_jid and message_ids having clear descriptions. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description 'Mark specific messages as read in a WhatsApp chat' uses a specific verb ('mark') with a clear object and context. It distinguishes the tool from siblings like update_message or delete_message by specifying the read-state action.

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

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

The description implies usage when marking messages as read, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. With sibling tools like update_message, the description lacks guidance on differentiation.

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 and destructiveHint=false, aligning with the send operation. The description adds the public URL constraint but does not disclose behavioral nuances like the simulated recording delay or message delivery semantics. It does not contradict annotations.

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

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

One sentence with the essential verb and resource front-loaded, followed by a key constraint. No 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?

The tool is simple, schema covers parameters, and annotations cover safety. The description captures the core purpose and the crucial public URL requirement. It could mention the delay parameter's effect, but for a basic send tool 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 description coverage is 100%, so each parameter already has meaning. The tool description adds no additional parameter context beyond the schema, so baseline 3 is appropriate.

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

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

States 'Send a WhatsApp audio message (voice note)' with a specific verb and resource, distinguishing from siblings like send_media by specifying voice note format. The additional requirement of public URL clarifies scope.

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

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

Provides a prerequisite (public URL) but does not explicitly state when to use this over send_media or other siblings. The context implies it's for voice notes, but 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context—it does not mention typing simulation (the delay param), formatting constraints, or any side effects. The description merely restates the tool's purpose and provides no new behavioral transparency beyond the annotations.

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

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

The description is a single sentence with no wasted words. It front-loads the core action ('Send') and the resource ('WhatsApp contact card'), making it highly efficient.

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

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

For a simple send operation, the description is complete enough. The schema covers parameter details, and annotations cover safety. The description lacks no critical information for basic use, though it could mention the delay parameter's role in typing simulation, but that is already documented in the schema. Minor gaps prevent a perfect 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?

The input schema provides 100% description coverage for all four parameters, including the meaning of delay, number, contact_name, and contact_phone. The description adds no additional parameter details beyond what the schema already specifies, so the baseline of 3 applies.

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

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

The description 'Send a WhatsApp contact card (vCard) to a phone number' uses a specific verb ('send') and identifies a clear resource ('contact card (vCard)') and recipient ('phone number'). It clearly distinguishes this tool from siblings like send_text, send_audio, and send_location.

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 sharing a contact card but does not explicitly state when to use it over alternatives or provide exclusions. The sibling tool list includes many send_* tools, but the description does not compare against them directly, leaving usage guidance implied rather than explicit.

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

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

Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds the channel ('via WhatsApp') and the nature of the payload ('invite link'), but does not disclose potential side effects like requiring admin rights, number validity, or message limits. This is minimal but non-contradictory.

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 sentence with 12 words. It is front-loaded with the action verb and includes all essential elements without extraneous detail or repetition of schema 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 simple send operation with full schema coverage and annotations, the description is sufficient. It clearly communicates the action, and given no output schema, it need not explain return values. The tool's complexity is low, and the description covers it adequately.

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

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

Schema coverage is 100%, so each parameter is already described. The description adds no extra meaning beyond saying 'specified phone numbers', which mirrors the schema. Baseline of 3 applies as the description does not enhance parameter understanding.

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

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

The description uses a specific verb ('Send') and resource ('group invite link') with clear recipients ('specified phone numbers') and channel ('via WhatsApp'). This distinguishes it from sibling tools like send_text or fetch_invite_code, making the purpose unambiguous.

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

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

The description states what the tool does but provides no guidance on when to use it vs alternatives. It doesn't mention prerequisites (e.g., valid WhatsApp numbers, group admin permission) or suggest using check_whatsapp_numbers or fetch_invite_code when appropriate.

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

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

The description merely restates the core action without adding behavioral context beyond what annotations already declare. It does not disclose any behaviors such as how the location pin is rendered, whether confirmation occurs, or any rate limits or dependencies, despite annotations indicating a write operation (readOnlyHint=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 a single, concise sentence that front-loads the main action and recipient. Every word contributes, with no redundant or filler content.

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

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

The tool is relatively simple, and the schema covers all parameters. However, the description does not explain how a location pin is generated from latitude/longitude or how the optional name/address are used. With no output schema, a bit more context about expected behavior (e.g., whether coordinates are required and how the pin appears) would improve completeness, but the current level is minimally adequate.

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

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

Schema description coverage is 100%, so the schema fully documents every parameter. The description adds no additional meaning beyond what the schema provides, which aligns with the baseline score of 3 for high coverage.

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

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

The description clearly states the specific action ('Send a WhatsApp location pin') and the target ('to a phone number'), distinguishing it from sibling tools that send other media types like text, audio, or media. The verb and resource are specific 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 no guidance on when to use this tool versus alternatives like send_media or send_text. It does not mention any conditions, prerequisites, or exclusions, leaving the agent without context for choosing this tool over 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 indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the useful constraint that the media URL must be publicly accessible, but it does not disclose other behavioral details such as error handling, file size limits, or state changes.

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: the first sentence gives the purpose and scope, the second adds the critical prerequisite. No redundant or filler content.

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

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

For a 6-parameter tool with full schema coverage and no output schema, the description plus schema are sufficient. It covers the main purpose, media types, and the key constraint. Minor details like file size limits or supported formats are not mentioned but are not essential.

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

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

The input schema provides 100% description coverage for all six parameters, including captions, file names, and enum values. The description adds no new parameter semantics beyond reinforcing the public URL requirement, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action (send), the resource (WhatsApp media message), and specifies media types (image, video, or document), which distinguishes it from sibling tools like send_audio and send_text.

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 a prerequisite (publicly accessible URL) and the media type enum implies when to use this tool, but it does not explicitly state when to prefer this over alternatives or provide exclusions. No direct comparison to sibling tools is given.

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

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

Annotations already cover the basic safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false). The description does not add any behavioral context such as delivery semantics, potential delays, side effects, or failure conditions, offering no value beyond the structured annotation fields.

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

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

The description is a single concise sentence with no wasted words. It is appropriately short for a simple action, though the lack of any additional context makes it slightly under-specified, preventing a perfect score.

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 annotations and complete schema, the description is minimally adequate. However, without an output schema, it does not disclose return behavior or success/failure indicators, and it omits any mention of prerequisite conditions (e.g., WhatsApp connectivity), leaving some context 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 coverage is 100% with detailed descriptions for all five parameters (e.g., number format, options count, max_selections default). The description itself adds no parameter information, but the schema carries the full burden, meeting the baseline for high schema coverage.

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

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

The description clearly identifies a specific action (send) and resource (WhatsApp poll) with a recipient. While it does not explicitly differentiate from sibling tools like send_text or send_media, the term 'poll' is a distinct WhatsApp message type, providing enough specificity.

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, nor does it mention exclusions, prerequisites, or alternatives. It simply states the action, leaving the agent to infer usage from the name alone.

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, so it is known to be a mutation; the description adds the context of presence types but omits 'available' and 'unavailable', which may represent global presence rather than chat-specific typing indicators. It does not contradict annotations.

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

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

The description is a single concise sentence that front-loads the action, resource, and examples with no redundant phrasing. Every word contributes to understanding.

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?

As a simple tool with two parameters and no output schema, the description provides a basic understanding, but it lacks nuance about the meaning of 'paused', the difference between chat-specific presence and global availability, and expected return behavior. Annotations and schema compensate, but the description alone is not fully complete.

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

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

Schema description coverage is 100% for both parameters, so the schema fully documents 'number' and 'presence'. The description adds examples of presence values but does not clarify the full enum or differentiate between typing indicators and availability, though the schema covers this.

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: sending a presence/typing indicator to a WhatsApp chat, with specific examples (composing, recording, paused). This distinguishes it from sibling tools like send_text or send_media, which handle different message types.

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 indicating typing/recording/paused status, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. There is no mention of when not to use it, such as for global availability changes.

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 openWorldHint=true, covering the basic safety profile. The description adds no behavioral context beyond the obvious action, such as whether the reaction can be removed or how it interacts with existing reactions. It is adequate but unhelpful beyond the annotations.

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

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

The description is a single clear sentence with no redundant words. It wastes no tokens and is easily digestible.

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

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

For a simple tool with three fully documented parameters and annotations covering the operation type, the description is sufficiently complete. It doesn't explain return values, but no output schema exists, and the action is straightforward. Lacks any mention of edge cases (e.g., invalid message ID), but these are not essential for basic use.

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

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

Schema description coverage is 100%, with each parameter clearly documented (e.g., emoji description mentions empty string to remove). The description itself adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly states the action (react) and the resource (specific WhatsApp message) with a distinctive tool purpose. It differentiates from siblings like send_text or send_media by specifying 'react' with an emoji, which is a unique behavior.

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

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

No guidance is provided on when to use this tool vs alternatives. The description merely states the action without mentioning context, prerequisites, or exclusions (e.g., 'Use this instead of send_text to add a reaction'). This is a clear gap.

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

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

Annotations already indicate a write operation (readOnlyHint: false) and non-destructiveness (destructiveHint: false). The description adds the constraint that the sticker URL must be publicly accessible and PNG/WebP recommended, which is useful behavioral context. However, it doesn't disclose other behaviors like typing simulation delay or error handling.

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

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

Two short sentences with no redundancy; the core purpose is front-loaded and the additional constraint about the URL is directly relevant. Every sentence earns its place.

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

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

For a simple send operation, the description and schema cover the essentials: parameters, purpose, and key constraint. It lacks explicit differentiation from send_media and doesn't mention response behavior, but given the straightforward nature and good schema, it's mostly 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?

The input schema has 100% parameter coverage with descriptions for number, sticker_url, and delay. The description only reiterates the URL accessibility requirement already present in the schema, adding no significant meaning beyond the structured fields.

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

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

The description clearly states 'Send a WhatsApp sticker' – a specific verb and resource. It distinguishes itself from sibling tools like send_media or send_audio by explicitly naming the sticker purpose and the URL requirement.

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 context that this tool sends stickers and that the URL must be publicly accessible, but does not explicitly state when to prefer this over send_media or mention exclusions. Usage is implied rather than clearly bounded.

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

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

Annotations already indicate a non-read-only, non-destructive operation with open-world side effects. The description adds no additional behavioral context beyond the obvious act of sending, such as rate limits, delivery guarantees, or error behavior. This meets the baseline but doesn't enrich the agent's 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 a single, clear sentence with no wasted words. It front-loads the action and resource, making it immediately understandable.

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 straightforward send tool, the description combined with rich schema annotations gives a clear picture. However, without an output schema, it doesn't explain what the response contains, and it lacks explicit usage guidance. Still, the tool's simplicity and available annotations make it reasonably complete.

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

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

The input schema covers all parameters with descriptions (100% coverage). The tool description adds no extra meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Send'), the resource ('a WhatsApp text message'), and the destination ('to a phone number'). It distinguishes itself from sibling tools like send_audio or send_media by specifying 'text message'.

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

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

The description clearly implies this tool is for sending text messages, which differentiates it from media and poll siblings. It provides enough context for an agent to know when to use it, though it lacks explicit exclusions or alternative recommendations.

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 and destructiveHint=false, covering the operation's safety profile. The description adds the admin privilege requirement, which is useful auth context, but it does not disclose any additional behavioral traits such as side effects or return behavior. This is moderate value beyond what annotations provide.

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

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

The description is concise and front-loaded: one sentence for purpose and one for the prerequisite. Every word contributes, and there is no redundant or vague content.

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

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

For a simple two-parameter update tool, the description provides the essential purpose and a key precondition. However, there is no output schema, and the description does not mention what happens on success or failure, nor any side effects (e.g., notifications to group members). It is adequate 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?

The input schema documents both parameters (group_jid and description) with complete descriptions, and schema coverage is 100%. The tool description adds no additional meaning or examples beyond the schema, so it does not compensate for any missing schema information.

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

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

The description clearly states the specific action ('Update the description') and resource ('WhatsApp group'), which distinguishes it from sibling tools like update_group_subject and update_group_picture. The verb is precise and the scope is unambiguous.

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

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

The description provides clear context by stating it requires admin privileges, implying it should only be used by authorized users. However, it does not explicitly name alternatives or explain when not to use this tool compared to other group update tools, but the purpose is straightforward.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds the meaningful operational requirement of admin privileges, which is valuable context beyond what annotations provide. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence that conveys both the action and key prerequisite. There is no redundancy or extra information that could distract from the core 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?

Given the tool's simplicity (two clearly documented parameters, no output schema), the description is reasonably complete. It covers the purpose and the critical admin requirement. A mention of what happens after update or response format would improve completeness, but it is not essential for effective use.

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

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

The input schema covers both parameters (group_jid and image_url) with descriptive text, so schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema already provides, warranting the baseline score.

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

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

The description specifically identifies the action (Update) and resource (profile picture of a WhatsApp group). It clearly differentiates from sibling tools like update_group_description and update_group_subject. There is no ambiguity about what this tool does.

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

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

The description clearly states a prerequisite (requires admin privileges), giving the agent context for when this tool is applicable. However, it does not explicitly mention alternatives or when not to use this tool, leaving a minor gap in usage 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 adds an important behavioral requirement ('Requires admin privileges') beyond what the annotations already state. Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), and the description aligns with this, adding auth context 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?

Two short sentences, front-loaded with the core purpose, immediately followed by the key requirement. No redundant phrasing or filler, making it highly scannable and informative.

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

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

For a simple update operation with two parameters and no output schema, the description covers the essential aspects: what it does and a critical prerequisite. It lacks details on return values or error handling, but these are not critical for this straightforward mutation.

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

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

The input schema provides 100% coverage with descriptions for both parameters (subject and group_jid). The description does not add extra meaning beyond what the schema already contains, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('Update') and the resource ('name/subject of a WhatsApp group'), with a specific verb and object. It also distinguishes from sibling tools like update_group_description and update_group_picture by focusing solely on the group subject.

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 a key prerequisite (admin privileges) but gives no explicit guidance on when to use this tool versus alternatives like update_group_description. There are no exclusions or alternative tool references, so usage context is only implied by the name and sibling list.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not need to restate that. It adds the important constraint about editing only one's own messages, but does not disclose other potential behaviors such as error handling, limitations on editing media messages, or that the text parameter replaces existing content entirely.

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 contains no redundant information. Every word earns its place, making it highly efficient and scannable.

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

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

For a simple mutation tool with three well-described parameters and no output schema, the description provides sufficient context: it explains what the tool does, the fromMe constraint, and implicitly that only text content can be changed (via the text parameter). Minor gaps such as media handling or failure scenarios do not significantly impact completeness for this simple 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?

The input schema covers all three parameters with clear descriptions (text, message_id, remote_jid), achieving 100% schema description coverage. The tool description adds no additional semantic detail beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Edit' and the resource 'previously sent WhatsApp message', making the tool's purpose immediately obvious. The constraint 'Only works for your own messages (fromMe: true)' adds scope and distinguishes it from sending new messages or deleting existing ones.

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 that this tool is for editing previously sent messages, and explicitly notes the fromMe restriction, which serves as an exclusion. However, it does not explicitly mention when to use this tool instead of siblings like delete_message or send_text, leaving some guidance implicit.

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