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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the specific return values, confirming the safe read-only nature and providing behavioral context beyond annotations.

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

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

Three short sentences, each adding value: purpose, returned data, and usage. No unnecessary words, front-loaded with the action.

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 no parameters and comprehensive annotations, the description is sufficiently complete. It tells what it returns and a use case. It could mention error handling but not necessary for a getter.

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

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

There are zero parameters, and the description explicitly states 'No parameters required,' which is helpful. Per rubric, baseline is 4 for no 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 verb 'Get information' and specifies the resource (authenticated WhatsApp account). It lists the specific fields returned (phone number, display name, WhatsApp ID), distinguishing it from siblings like send or delete 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 provides a clear use case: 'Use this to verify which account is connected.' It does not mention alternatives or when not to use, but the context is sufficient for a simple read-only tool.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the description adds value by specifying the return fields (status, phone, enabled: false). However, it does not disclose other behavioral traits like side effects or prerequisites.

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

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

The description is extremely concise: a one-line purpose statement followed by structured Args and Returns sections. Every sentence is necessary and well-organized.

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

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

With a single parameter fully documented in the schema, annotations present, and no output schema needed, the description is complete. It explains the tool's action, input format, and output 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% with a description and pattern for the phone parameter. The description adds an example and format clarification ('digits only, no @, no spaces'), but this largely overlaps with 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 verb 'Disable' and the resource 'auto-reply with audio transcription', along with the scope 'for a contact'. This distinguishes it from sibling tools like whatsapp_auto_reply_enable and whatsapp_auto_reply_list.

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

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

No explicit guidance on when to use this tool vs alternatives. There is no mention of when not to use it or references to enable/list siblings. The usage is only implicitly understood from the name.

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?

Describes the scoping behavior (contact/phone-scoped, follows JID transitions) and idempotent nature (implied). Annotations already set idempotentHint=true and destructiveHint=false; description adds valuable context beyond these.

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

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

Well-structured with summary, then detailed behavior, Args/Returns sections. Slightly verbose with the JID transition explanation, but all sentences add value. Front-loaded main 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?

Completely describes behavior, parameter, and return value. Without output schema, the Returns section covers needed info. Sibling tools context makes it stand out.

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?

Adds meaning beyond schema: specifies format 'Phone number digits only, no @, no spaces' with example, and advises looking up contact first. Schema coverage is 100%, but description enhances usability.

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 'Enable auto-reply with audio transcription for a contact.' Verb 'enable', specific resource 'auto-reply transcription', and scope 'for a contact' distinguish it from sibling tools like disable, list, etc.

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

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

Explicitly notes when to use: 'When the contact sends a voice note, the transcription is sent back as a quoted reply automatically.' Also excludes groups: 'DM only — voice notes in groups are never auto-replied even if a member is flagged.' Advises lookup via whatsapp_list_contacts first.

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 value beyond the annotations by explaining the name resolution logic (Google Contacts with WhatsApp fallback) and the exact fields returned. Annotations already indicate read-only, non-destructive, idempotent behavior, so the description complements them well.

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

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

The description is concise with two sentences: the first states the purpose and name resolution, the second details the return structure. 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 parameterless tool, the description is sufficiently complete. It explains the output structure, though it might be missing details like sorting or pagination, but those are not critical for this query.

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

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

There are no parameters, so the baseline is 4. The description adds no parameter information, which is appropriate given the empty input 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 lists contacts with auto-reply enabled, using a specific verb ('list') and resource ('contacts with auto-reply'), and distinguishes from sibling tools like whatsapp_auto_reply_enable and whatsapp_list_contacts.

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

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

While the purpose is clear, the description does not explicitly state when to use this tool versus alternatives, such as when to use whatsapp_list_contacts instead. The usage context is implied but not directly addressed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds context by explaining the return structure (chat and messages objects) and that the output is human-readable. No contradictions exist. While it doesn't go beyond what annotations provide for safety, it adds value in output transparency.

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

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

The description is highly concise with no wasted words: a one-sentence purpose, a one-sentence usage note, and clearly formatted Args and Returns sections. Every sentence serves a purpose, making it easy for an agent 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?

Despite lacking an output schema, the description provides a detailed textual description of the return value (chat info and messages with sender, body, timestamp, type). This fully compensates for the missing schema, and the tool's simplicity (2 parameters) means no further information is needed.

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

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

Schema description coverage is 100%, and both parameters have schema descriptions. The description's 'Args' section repeats the schema descriptions verbatim without adding new information. Thus, the description adds no additional semantic value beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the tool's purpose: 'Get a readable summary of recent messages in a WhatsApp chat, including sender names and timestamps.' It also distinguishes from siblings by explicitly mentioning alternatives (whatsapp_read_messages for structured data, whatsapp_search_messages for full-text search), 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 provides explicit usage guidance: 'This is optimized for readability — use whatsapp_read_messages for structured data with filtering, or whatsapp_search_messages for full-text search.' This clearly tells the agent when to use this tool versus alternatives, fulfilling the highest standard.

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, destructiveHint, idempotentHint. The description adds value by explaining return values (numberExists, contactId) and the contactId's reuse in other tools, which annotations do not cover.

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

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

The description is concise with a clear summary, usage note, and structured Args/Returns sections. Every sentence is purposeful with no fluff.

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

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

For a simple check tool with one parameter, the description covers purpose, usage context, parameter format, and return values. It could mention error handling but is largely complete given the low complexity.

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

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

Schema coverage is 100% with a parameter description. The description repeats the format example and adds a usage note, but does not add significant new semantic meaning beyond 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 'Check if a phone number is registered on WhatsApp,' using a specific verb and resource. It distinguishes itself from sibling tools that handle other WhatsApp operations like account info or messaging.

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 advises: 'Use this before sending a message to a number not yet in your address book,' providing clear context. It does not mention when not to use or alternatives, but the guidance is direct and useful.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that the tool returns groups with message counts and mutual contacts, providing additional behavioral detail beyond annotations.

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

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

The description is short, front-loaded with the purpose, and uses a clear args/returns structure. Every sentence adds value.

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

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

For a single-parameter, read-only tool with comprehensive annotations, the description is largely complete. It could optionally mention that the contact must exist, but overall it covers the key aspects.

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 fully describes the 'phone' parameter with an example. The description repeats the same information without adding new semantic meaning.

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

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

The description states 'Get social graph for a WhatsApp contact — shared groups, mutual connections', specifying the verb and resource clearly. It distinguishes from sibling tools like whatsapp_get_contact by focusing on social connections.

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 explains what the tool does and what it returns, allowing the agent to infer when to use it (when social graph info is needed). However, it does not explicitly mention when not to use it or compare to alternatives like whatsapp_list_contacts.

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

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

Annotations already indicate destructiveHint=true. The description adds that WhatsApp shows 'This message was deleted' as a placeholder, providing extra behavioral context beyond what annotations convey. No contradictions.

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

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

The description is short and uses a clear structure with an Args section. The first sentence is slightly redundant with later details, but overall efficient and front-loaded.

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

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

For a simple destructive operation with two parameters and an output confirmation, the description covers the essential behavioral and parameter details. No output schema exists, but return value is noted. Lacks mention of idempotency or rate limits, but acceptable 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?

Schema description coverage is 100%. The description adds example values for contactId and explains special handling for group JIDs, but for messageId it only repeats the schema description. Meets baseline but adds limited extra meaning.

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

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

The description clearly states 'Delete (unsend) a message from a contact's chat.' It uses a specific verb and resource, distinguishing it from siblings like whatsapp_edit_message and whatsapp_forward_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?

While it explains the action and outcome ('Removes the message for everyone'), it does not explicitly state when to use this tool versus alternatives or when not to use it. The context of destructive action is clear, but no direct comparison to sibling tools.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds valuable behavioral context: inline return for images/audio, file save path for video/documents, and potential unavailability of old media.

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?

Description is concise (5 sentences plus structured Args/Returns sections), front-loaded with purpose, and well-organized. Every sentence adds value without redundancy.

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

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

For a simple tool with 2 required parameters and no output schema, the description covers all necessary aspects: return behavior by media type, prerequisite workflow, and data persistence. Annotations cover safety constraints.

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 clear descriptions for both parameters. The description repeats similar explanations in Args section, adding no new semantic value beyond the schema.

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

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

The description clearly states the tool downloads media (image, audio, video, document) from a WhatsApp message. It distinguishes from siblings by specifying to use whatsapp_read_messages first and provides the exact verb and resource.

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

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

Explicitly instructs to use whatsapp_read_messages first to find messages with hasMedia=true, then pass contactId and messageId. Also notes that old media may not be available, guiding appropriate usage conditions.

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

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

Adds behavioral info: 'WhatsApp shows an "edited" label on the message after editing.' Annotations already declare idempotentHint=true and nondestructive, but description enriches with user-visible effect.

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

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

Four sentences, front-loaded with purpose, each sentence adds value. Could be slightly tighter but still 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?

Includes return info ('confirmation with edited message ID'), sufficient given no output schema. Coverage is adequate for a simple edit tool.

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

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

Schema coverage is 100%, so description repeats parameter info without adding extra meaning. Meets baseline for high coverage.

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

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

Description starts with 'Edit a previously sent text message,' clearly stating verb (edit) and resource (message). Distinguishes from siblings like send, delete, forward.

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

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

States 'Only works on messages you sent (fromMe=true),' providing a clear condition. No explicit alternatives or when-not usage, but context is clear.

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

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

Annotations (readOnlyHint=false) confirm this is a write operation. The description adds behavioral context: the forwarded message labels itself, preserves attribution, and returns a confirmation with the new message ID. No contradictions with annotations.

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

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

The description is concise (3 short paragraphs) and well-structured: a one-sentence purpose, a line about labeling, and bullet-like parameter explanations. No redundant 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 2-param tool, the description covers all essential aspects: purpose, parameter sourcing, expected label behavior, and return value. No output schema is needed given the simple confirmation format.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful guidance beyond the schema: how to obtain contactId (via whatsapp_list_contacts) and messageId (from whatsapp_read_messages), and explains the ID format and stability across @c.us↔@lid flips.

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

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

The description clearly states the tool's purpose: 'Forward a message from one chat to another contact.' This is a specific verb+resource pair that distinguishes it from sibling tools like whatsapp_send_text (sends new message) or whatsapp_delete_message (deletes 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 explains what forwarding does (shows 'Forwarded' label, preserves attribution) but does not explicitly state when to use this tool vs alternatives like sending a new message or editing. Usage context is implied rather than explicit, lacking when-not-to-use guidance.

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

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

Annotations indicate readOnly and safe behavior. The description adds behavioral specifics: return shape depends on kind (person vs group) and lists included fields. 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 extremely concise with a clear structure: a one-line summary, bullet-style return details, and an args section. No wasted words.

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

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

Given the simple single-parameter tool and lack of output schema, the description fully covers what the tool does, return shapes, and how to find the input. No missing 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?

Schema coverage is 100% with a description for contactId. The description enriches this by showing example formats and referencing a sibling tool to look up the ID, adding context beyond the schema pattern.

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 title and description clearly state the tool retrieves details for a single contact (person or group) by stable id. It distinguishes itself from siblings like 'whatsapp_list_contacts' by specifying it returns detailed info for one contact.

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

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

The description provides guidance on how to obtain the contactId via 'whatsapp_list_contacts' and gives format examples. It implies usage for getting detail after listing, but does not explicitly state when not to use (e.g., for listing multiple contacts).

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

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

Beyond the annotations (idempotent, non-destructive), the description details behavior: filename extraction for chat name, contact matching/creation, and duplicate skipping. It also lists return fields, which is not in the output schema. No contradictions with annotations.

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

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

Every sentence earns its place. The description is organized with paragraphs, a bullet list for file format, and clear 'Args' and 'Returns' sections. No redundancy or fluff.

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

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

Given the tool's complexity (handling ZIP/TXT, contact matching, idempotency), the description covers all essential aspects. The output schema is absent but the return fields are listed in the description. The sibling set is addressed by the unique purpose.

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%, but the description adds meaning: explains filePath is an absolute path, chatName is an optional override, and describes how the chat name is extracted. This enriches the schema's short descriptions.

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

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

The description uses a specific verb ('Import') and resource ('WhatsApp chat export file'), clearly stating it inserts messages into the message store. It distinguishes from siblings like 'whatsapp_read_messages' and 'whatsapp_send_text' by being the only tool for backfilling historical exports.

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 advises using the tool to 'backfill historical messages from WhatsApp's 'Export Chat' feature.' It notes it only inserts new messages, implying it's not for overwriting. While no direct alternatives are named, the sibling list makes the context clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds value by noting that profile picture URLs may expire, describing the return structure including nullable fields, and specifying pagination behavior.

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

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

The description is front-loaded with the purpose, uses bullet points for return fields, and is overall concise with no wasted words. Every sentence provides necessary 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, the description covers purpose, parameters, return structure, and usage guidance. It lacks an explicit output schema but compensates with a detailed textual description. The absence of error handling details is minor.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the output structure (id, name, picture, lastMessage, lastMessageAt) and how to use the returned chat ID in other tools. This contextualizes the parameters' purpose.

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

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

The description clearly states the tool lists recent WhatsApp chats with last message preview and profile pictures, using a specific verb and resource. It distinguishes from siblings like whatsapp_list_contacts (contacts) and whatsapp_read_messages (reading after getting ID).

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

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

The description explicitly tells when to use this tool: 'Use the chat ID from results to read messages with whatsapp_read_messages.' It provides clear context for a typical workflow, though it doesn't explicitly exclude alternatives like whatsapp_search_messages.

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

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

Annotations already indicate read-only, non-destructive, idempotent. Description adds behavioral details about ID formats, name resolution fallback, and pagination, which is valuable beyond annotations.

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

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

Description is well-structured with Args and Returns sections. It is concise but thorough, though slightly verbose in explaining ID formats and fallbacks.

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 4 parameters, no output schema, and strong annotations, the description fully explains return structure, ID usage, pagination, and filtering options. No 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 has 100% description coverage, so description adds only marginal value for parameters. It explains the kind enum and output context, but the schema already provides clear parameter descriptions.

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

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

Title and description clearly state the tool lists WhatsApp contacts (people and groups). Description distinguishes from siblings like whatsapp_list_chats and whatsapp_get_contact. Uses specific verbs and resource 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?

Description explicitly explains how to use returned IDs for chat-targeting tools, but doesn't state when not to use or alternatives. Still provides clear usage context.

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

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

Annotations indicate idempotent, destructive=false, readOnly=false, openWorld=true. The description adds important context: removal via empty string and return confirmation. No contradictions.

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

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

Three concise paragraphs: first sentence states purpose, second gives special behavior, third explains args. Every sentence is necessary and no fluff.

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

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

Given 3 required parameters, no output schema, the description covers all necessary aspects: purpose, parameter usage, special cases, and references to sibling tools for lookup. An agent can correctly invoke this tool.

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

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

Schema coverage is 100%, but the description adds value by explaining the empty string removal for reaction and providing examples for contactId format. It also ties contactId and messageId to lookup tools.

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 'React' and resource 'WhatsApp message', and distinguishes from siblings like delete or edit. It also specifies the empty string behavior for removing reactions, which is unique.

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

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

Provides clear context on how to use the tool (e.g., refer to whatsapp_list_contacts and whatsapp_read_messages), and mentions the empty string for removal. However, it does not explicitly contrast with alternatives like whatsapp_send_text or whatsapp_edit_message.

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 do not indicate readOnlyHint but description explains the markAsRead parameter (side effect). It also describes return fields and the 'hasMore' flag. No contradictions with annotations.

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

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

The description is structured with a summary paragraph then bullet lists for args and returns, making it readable. A bit lengthy but well-organized.

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 11 parameters and no output schema, the description covers each parameter and outlines return fields. Examples and usage tips enhance completeness.

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

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

Schema coverage is 100%, but description adds extra context for contactId (phone digits, group JID, format survival) and return fields, providing 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 'Read messages from a specific WhatsApp chat,' specifying the action and resource. It also distinguishes from siblings like whatsapp_search_messages and provides context on returned fields.

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 advises using message IDs from results for reacting or replying, and mentions looking up contactId via whatsapp_list_contacts. While it doesn't explicitly state when not to use this tool, the context is clear.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true. Description adds case-insensitive search, Portuguese/unicode support, and notes that sender_name may be null. This provides value beyond annotations.

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

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

Description is well-structured with summary, Args, and Returns. Front-loaded with key purpose. Slightly lengthy but clear.

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 high parameter count (9) and no output schema, description fully explains each parameter, return structure, and behavioral traits (case-insensitivity, null sender_name). Complete for agent use.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats schema parameter descriptions almost verbatim, adding only case-insensitivity note and return format. Minimal added value.

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

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

Title and description clearly specify the tool searches WhatsApp messages with full-text, date, sender, and type filters. It distinguishes from siblings like whatsapp_list_chats and whatsapp_read_messages.

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

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

No explicit when-to-use or when-not-to-use instructions. Usage is implied through description, but no alternatives 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 indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), which the description confirms by describing a send operation. The description adds transparency about rate limit delays and the CORE tier limitation, which goes beyond the annotations. No contradictions.

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

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

The description is well-structured with clear sections for purpose, constraints, parameter details, and returns. It is efficient but not overly terse. Some information (e.g., parameter descriptions) partly duplicates schema, but overall it is concise and front-loaded with the main 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?

The description covers input, behavior (rate limit, tier restriction), and output (status, messageId, contactId). Since there is no output schema, the description fills that gap. It also references sibling tools for lookup, making the context complete for a simple send 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 coverage is 100%, so the description partially overlaps with schema. However, the description adds value by explaining that contactId 'survives @c.us↔@lid flips' (not in schema) and clarifying replyTo's purpose. The schema already defines types and constraints, so the description enriches parameter understanding.

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

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

The description clearly states the action ('send'), the resource ('text message'), and the target ('contact (person or group)'). It distinguishes itself from sibling tools by specifying 'CORE tier supports text messages only', implying that other tools handle media. It also provides context for finding contact IDs via whatsapp_list_contacts.

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

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

The description gives clear usage context: send text messages, not media. It mentions rate limit delay, and provides guidance on how to obtain contactId and replyTo from other tools. It does not explicitly state when not to use, but the purpose is well-defined, and siblings like whatsapp_forward_message or whatsapp_download_media imply alternative use cases.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details beyond the annotations, such as the possible status values ('WORKING', 'STOPPED') and the meaning of each return field, which helps agents understand exactly what the tool reveals.

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

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

The description is extremely concise, consisting of two short sentences and a structured list of return values. Every sentence adds value: the first states the purpose, the second explains when to use it, and the list clarifies the output. No redundancy or fluff.

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

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

Given the tool's simplicity (no parameters, no output schema required), the description is fully complete. It explains the purpose, the scenario for use, and details the output fields with expected values. An agent can invoke this tool without any additional clarification.

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 no parameters (input schema is empty), and the description explicitly states 'No parameters required.' According to guidelines, 0 parameters earns a baseline of 4, and the description correctly confirms this, leaving no ambiguity.

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

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

The description clearly states the tool's purpose: 'Check if the WhatsApp session is connected and working.' It specifies the resource (WhatsApp session) and the action (check status), and lists the return values (status, phone, name) which distinguish it from siblings like sending or listing messages.

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 usage context: 'Use this to verify connectivity before sending messages.' It explains when to use the tool but does not explicitly mention when not to use it or suggest alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing the return structure (totals, top lists, null name for groups) and suggesting whatsapp_get_contact for group lookups. No contradictions with annotations.

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

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

The description is concise and well-structured, starting with a summary sentence followed by bullet points for return fields. Every sentence adds value without redundancy or wordiness.

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 there is no output schema, the description adequately explains the return values including totals, activity counts, top chats, and top contacts. It notes that group names may be null, providing useful context. Minor gap: not specifying the timeframe for 'this week' but overall complete for a simple stats tool.

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

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

The tool has zero parameters, so schema coverage is 100%. The description explicitly states 'No arguments needed,' which adds clarity. No additional parameter information is necessary.

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 provides an overview dashboard of WhatsApp activity including message totals, top chats, top contacts, and breakdowns. It uses specific verbs ('Overview dashboard') and resource ('WhatsApp activity'), and distinguishes from siblings like whatsapp_chat_summary and whatsapp_list_chats.

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

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

The description explicitly states 'No arguments needed,' making when to use clear. It provides context for the dashboard overview but does not explicitly mention when not to use or name alternatives among siblings. However, the zero-parameter nature makes usage 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?

The description discloses server-side transcription via Speaches/Whisper and the optional reply behavior, which aligns with annotations (readOnlyHint=false, destructiveHint=false). No contradictions, and it provides useful context beyond annotations.

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

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

The description is concise, front-loaded with the main purpose, and structured with Args/Returns sections. Every sentence adds value, 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?

Given the moderate complexity and full parameter coverage, the description adequately explains the tool's behavior, including optional reply and language detection. It lacks error handling or input validation details, but is otherwise complete.

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

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

Schema coverage is 100%, but the description adds value by clarifying the format for contactId (phone digits or *@g.us) and the default for replyWithTranscription. It enhances understanding beyond the schema descriptions.

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

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

The description clearly states the verb 'Transcribe' and the resource 'WhatsApp audio', specifying it converts voice messages to text. It distinguishes from sibling tools by being the only transcription tool.

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

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

The description explains what the tool does but does not explicitly state when to use it or when not to, nor does it mention alternatives. Usage context is implied through parameter descriptions but lacks clear guidance.

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