The WSAPI WhatsApp MCP Server enables LLMs to interact with WhatsApp through a comprehensive API gateway (80+ tools), covering messaging, contact management, group operations, chat control, and account administration.
Messaging
Send text (with mentions, replies, forwarding), images, videos, audio, voice/PTT messages, documents, stickers, locations, and contact vCards
Send links with rich previews (title, description, thumbnail)
React to messages with emojis, edit or delete messages, mark as read/delivered/played, and star/unstar messages
Contact Management
Retrieve, create, and update contacts
Get profile pictures and business profiles
Subscribe to contact presence updates
Group Management
List all groups, create new groups with participants, retrieve group info, and update group names
Chat Management
List or retrieve specific chats
Set chat presence (typing, recording, paused)
Archive/unarchive and pin/unpin chats
Session & Instance Control
Check session status, get QR codes or pairing codes for login, logout, and restart the instance
Get/update instance settings (name, description, pull mode) and generate new API keys
Account Profile Management
Retrieve account info and update display name, profile picture, presence status, and status message
Integration & Filtering
Works with Claude Desktop and Claude Code via the Model Context Protocol (MCP)
Load only specific tool categories or individual tools to reduce context window usage
Provides comprehensive WhatsApp functionality through the WSAPI service, enabling AI assistants to send messages, manage contacts and groups, handle chat operations, set presence status, manage account settings, and perform session management including QR code login and device pairing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WSAPI WhatsApp MCP Server send a message to John saying I'll be there in 10 minutes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for WSAPI - the WhatsApp API Gateway. Enables LLMs to send messages, manage contacts and groups, handle communities and newsletters, post status updates, and more through WhatsApp.
For comprehensive documentation, see the WSAPI MCP Server guide.
Note: This project is not affiliated with, associated with, or endorsed by WhatsApp or Meta.
Node.js >= 20.19.0
WSAPI account with API credentials (wsapi.chat)
Add to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"wsapi": {
"command": "npx",
"args": ["@wsapichat/mcp-server"],
"env": {
"WSAPI_API_KEY": "your_api_key_here",
"WSAPI_INSTANCE_ID": "your_instance_id_here",
"WSAPI_ENABLED_CATEGORIES": "messaging,contacts"
}
}
}
}claude mcp add wsapi -- npx @wsapichat/mcp-server \
--env WSAPI_API_KEY=your_api_key_here \
--env WSAPI_INSTANCE_ID=your_instance_id_here \
--env WSAPI_ENABLED_CATEGORIES=messaging,contactsRelated MCP server: MCP WPPConnect Server
The server exposes 80+ tools across 12 categories. To reduce context window usage, you can filter which tools are loaded using environment variables.
Load only messaging and contact tools:
WSAPI_ENABLED_CATEGORIES=messaging,contactsAvailable categories: messaging, contacts, groups, chats, session, users, communities, newsletters, status, calls, media
Load only specific tools:
WSAPI_ENABLED_TOOLS=whatsapp_send_text,whatsapp_send_image,whatsapp_get_contactsUse categories as a base set and add individual tools from other categories:
WSAPI_ENABLED_CATEGORIES=messaging
WSAPI_ENABLED_TOOLS=whatsapp_get_contacts,whatsapp_get_chatsIf neither variable is set, all tools are loaded.
Variable | Required | Default | Description |
| Yes | - | Your WSAPI API key |
| Yes | - | Your WSAPI instance ID |
| No |
| WSAPI base URL |
| No | (all) | Comma-separated tool categories to load |
| No | (all) | Comma-separated tool names to load |
| No |
| Logging level (error, warn, info, debug) |
git clone https://github.com/wsapi-chat/wsapi-mcp
cd wsapi-mcp
npm install
cp .env.example .env # Edit with your credentials
npm run build
npm startMIT - see LICENSE for details.
Archive or unarchive a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| archived | Yes | Archive or unarchive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states 'archive or unarchive' without mentioning side effects, state changes (e.g., hiding from list), or prerequisites. A state-changing tool should convey more.
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?
Extremely concise (one sentence), which is efficient. However, it could be slightly more descriptive without becoming verbose. No structural issues.
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 parameters and no output schema, the description is functional but lacks context on what archiving entails (e.g., visibility, notifications). Among many siblings, more context would help 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%, so baseline is 3. The description adds no meaning beyond the schema; it essentially restates the action. No additional parameter constraints or formats are explained.
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 archives or unarchives a chat, using specific verbs and resource. It distinguishes from sibling tools like delete_chat or mute_chat by specifying the toggle 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?
No guidance on when to use this tool over alternatives (e.g., mute vs archive, or how it differs from clear/delete). The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block a contact.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Contact JID to block |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral traits beyond the name. The agent gets no information about side effects, permissions, reversibility, or what happens after blocking.
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 (three words), which is appropriate for a simple operation. However, it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates state, the description lacks essential context about effects (e.g., whether messages are hidden, whether the action is reversible). Given no output schema, more explanation 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?
The input schema covers 100% of the parameter with a description ('Contact JID to block'), and the tool description does not add any additional meaning beyond that. Baseline score 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 'Block a contact.' is a specific verb+resource that clearly indicates the action, and it distinguishes this tool from its sibling 'whatsapp_unblock_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 no guidance on when to use this tool, what prerequisites are needed, or when to consider alternatives like unblock. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check multiple phone numbers at once to see if they are registered on WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| phones | Yes | List of phone numbers to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It fails to disclose whether the operation is read-only, any side effects, or the structure of the response. Minimal behavioral context beyond the stated purpose.
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 sentence, front-loaded with action and resource. No redundant words. Could benefit from a little structure but remains 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?
Simple tool with one parameter, but no output schema and no description of return format. Adequate for a basic check but missing information on what the agent receives back.
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 'phones' is described as 'List of phone numbers to check'. The description adds no further meaning beyond the schema, so 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?
Description clearly states the verb 'check', the resource 'multiple phone numbers', and the outcome 'see if they are registered on WhatsApp'. It distinguishes from sibling 'whatsapp_check_user' which likely handles single numbers.
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 vs the single-number sibling, no limits on batch size, rate limits, or number format prerequisites. The description does not help the agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a phone number is registered on WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number (e.g. 1234567890) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral details. It only states the purpose, lacking information on side effects, error handling, or return format. The non-destructive nature is implicit but not explicit.
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, concise and to the point. It is appropriately front-loaded but lacks structure (e.g., no examples or output hints).
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 simplicity of the tool (one parameter, no output schema), the description is minimally viable. However, it omits important context like return values, error cases, or session requirements, which reduces 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?
Though schema coverage is 100%, the tool description does not add any meaning beyond the schema. The parameter 'phone' is not elaborated or contextualized in the description, providing no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if a phone number is registered on WhatsApp' clearly states the action (check) and target (phone number registration). It is specific and differentiates from siblings like whatsapp_bulk_check_users and whatsapp_get_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?
No guidance on when to use this tool compared to alternatives, such as the bulk version for multiple numbers. No prerequisites or context (e.g., session required) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all messages from a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks disclosure of behavioral traits (e.g., reversibility, permissions, impact on media) for this destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence, but could be expanded with more context without losing conciseness.
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 potentially destructive tool with no output schema and minimal annotations, the description lacks completeness (e.g., consequences, irreversibility).
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 for the single parameter 'chatId', so description adds no extra meaning; 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 'Clear all messages from a chat' uses a specific verb 'clear' and resource 'all messages from a chat', clearly distinguishing it from siblings like 'delete_chat' and '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?
No guidance on when to use this tool versus alternatives such as 'delete_chat' or 'delete_message', nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new WhatsApp community.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Community name | |
| participants | No | Initial participant JIDs | |
| approvalMode | No | Join approval mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Create a new WhatsApp community' without mentioning side effects, permissions, or what the tool does beyond creation (e.g., does it automatically add the creator? Are there limits?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Could be considered too terse but is efficient for a simple creation 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?
No output schema, and description does not explain return value (e.g., community ID or status). Missing details about what the agent can expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds no extra meaning beyond what's in the schema (e.g., does not clarify approvalMode values or format of JIDs).
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 ('Create') and the resource ('WhatsApp community'), which is specific and distinct from sibling tools like 'whatsapp_create_group' or 'whatsapp_create_community_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'whatsapp_create_group' or 'whatsapp_create_community_group'). The description lacks context about prerequisites or expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new sub-group inside a community.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| name | Yes | Group name | |
| participants | No | Participant JIDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on prerequisites, participant handling, authorization needs, or response behavior, which are critical for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 6 words, efficient and front-loaded; every word contributes to the 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 no output schema and no annotations, the description is too minimal—fails to explain prerequisites, return values, or behavioral implications of parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters; description adds no extra meaning beyond what is already in 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 action (Create) and the resource (sub-group inside a community), distinguishing it from siblings like whatsapp_create_group which creates a standalone group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for creating a sub-group in a community, but provides no explicit when/when-not guidance or mentions of alternatives like whatsapp_link_group_to_community.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a WhatsApp contact.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Phone number or JID of the contact | |
| fullName | Yes | Full name of the contact | |
| firstName | No | First name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It merely states 'Create or update,' which is a basic hint of write operations, but fails to describe required permissions, side effects (e.g., overwriting existing contacts), or whether updates are partial or full replacements.
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 at 3 words, front-loading the core purpose. It is efficiently structured but could benefit from a bit more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool that creates/updates contacts. It lacks information about return values (e.g., the updated contact object), error handling, and the distinction between create and update behavior. The absence of output schema further amplifies the need for descriptive 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?
The input schema covers 100% of parameters with individual descriptions, so the description adds no extra meaning beyond the schema. The baseline is 3, and the description does not elaborate on how parameters interact (e.g., if 'firstName' is optional and what happens when omitted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create or update a WhatsApp contact,' which is a specific verb and resource. It is distinct from sibling tools like 'whatsapp_get_contact' or 'whatsapp_block_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 no guidance on when to use this tool versus alternatives such as 'whatsapp_get_contact' or 'whatsapp_sync_contacts.' It does not mention prerequisites, when not to use it, or any context for creation vs. update scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new WhatsApp group.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name | |
| participants | Yes | Participant JIDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as destructive effects, authentication requirements, or side effects. It simply states the action without any additional 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 concise sentence with no wasted words, though it may be overly terse for some contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information on return values, error handling, prerequisites, and how it fits with sibling tools, making it incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters, so the description adds minimal value beyond what the schema already provides. 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 explicitly states the action 'Create' and the resource 'WhatsApp group', which is specific and distinguishes it from sibling tools like 'whatsapp_leave_group' or 'whatsapp_get_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new newsletter/channel.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Newsletter name | |
| description | No | Newsletter description | |
| picture | No | Base64-encoded profile picture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions needed, or the state of the newsletter after creation. It only states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the key action and resource. It is concise but could be slightly expanded for clarity without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does not explain what the tool returns or any post-creation behavior. It is incomplete for a creation 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 input schema has 100% coverage with descriptions for all three parameters. The description adds no additional meaning beyond what is already in the schema, so 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 'Create' and the resource 'newsletter/channel', distinguishing it from sibling tools that create other resources like groups or communities. However, it is minimal and could be more specific.
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 over alternatives like creating a group or community. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed. The description does not clarify whether deletion is permanent, reversible, or requires special permissions. With no annotations provided, the description carries the full burden but fails to convey critical 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?
At two words, the description is under-specified. While brevity is valued, it sacrifices informational value. A single sentence could have added needed context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a deletion tool. It does not mention irreversibility, impact on messages, or any confirmation steps. Given the simplicity of the tool (one parameter, no output schema), more context is needed for safe 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% with a clear parameter description ('Chat JID'). The description adds no additional meaning beyond the schema, 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 'Delete a chat' clearly states the action and resource. It is a specific verb+resource pair, distinguishing it from siblings like 'clear_chat' which clears messages without deleting the chat. However, it does not elaborate on scope or effects.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., when to delete vs archive or clear), and no prerequisites or caveats are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a message for all participants.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | ID of the message to delete | |
| chatId | Yes | Chat JID | |
| senderId | Yes | Message sender JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral context, yet it only states the action without disclosing important details such as authorization requirements, time limits, or effects on other participants.
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, but it lacks necessary depth. While concise, it does not fully earn its place due to missing critical 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 absence of an output schema and the presence of three required parameters, the description is incomplete as it omits behavioral constraints, prerequisites, and expected outcomes.
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% coverage with descriptions for all three parameters, so the description does not need to add more. 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 'delete' and the resource 'message', and specifies the scope 'for all participants', which distinguishes it from the sibling tool 'whatsapp_delete_message_for_me'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'whatsapp_delete_message_for_me', nor are there any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a message only for yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | ID of the message to delete | |
| chatId | Yes | Chat JID | |
| senderId | No | Message sender JID | |
| isFromMe | No | Whether the message was sent by you | |
| timestamp | No | Message timestamp (ISO 8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait (delete only for yourself), but with no annotations, it lacks details on permissions, reversibility, or impact on other participants. It provides minimal transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No unnecessary words or details.
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 having 5 parameters (2 required) and no output schema, the description is too brief. It lacks information on how to obtain the parameter values, any side effects, or the result of the operation, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains all parameters. The description adds no extra meaning or usage hints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (message), and specifies the scope (only for yourself), which distinguishes it from the sibling 'whatsapp_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?
No guidance is provided on when to use this tool versus 'whatsapp_delete_message' or other alternatives. The description does not mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a previously posted status update.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | Status message ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'delete' without disclosing traits like irreversibility, ownership requirements, or effects on followers.
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 sentence, concise and to the point, but could add brief usage context without increasing length significantly.
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?
Simple tool with one param and no output schema; description covers basic purpose but lacks error handling, message ID source, and behavioral 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% and description adds no extra meaning beyond 'Status message ID' as already documented.
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 'delete' and the resource 'status update', distinguishing it from siblings like whatsapp_delete_message which targets chat 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 guidance on when to use this tool over alternatives (e.g., other delete tools) or prerequisites (e.g., ownership of the status, time constraints).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download media by ID. Use the media.id field from incoming message events.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Media ID from a received message event |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'download', implying a read operation, but does not explicitly confirm safety (read-only, no side effects). Lacks details on authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded action verb and clear parameter source.
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 1-param tool with no output schema, the description adequately explains usage. Could mention the output type (binary) but not critical given the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by specifying 'media.id from incoming message events' beyond the schema's generic description. This aids correct invocation.
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 'Download media by ID' with a specific verb and resource. Distinguishes itself from siblings by its unique 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?
Specifies to use the media.id field from incoming message events, providing clear context. No explicit alternatives or when-not-to-use, 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.
Edit a previously sent text message.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | ID of the message to edit | |
| to | Yes | Chat JID | |
| text | Yes | New text content (max 4096 characters) | |
| mentions | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'edit' without specifying side effects, limits (e.g., max edits, time window), or confirmation that it updates the original message.
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 sentence, front-loaded with essential information: verb and resource. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a mutation tool with no output schema or annotations. Lacks details on constraints (e.g., message age, edit count), which are critical 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?
The input schema has descriptions for all parameters, but the tool description adds no extra meaning. Given the 60% schema coverage signal, the description doesn't compensate for any missing parameter details.
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 'Edit a previously sent text message' clearly states the action (edit) and resource (previously sent text message), distinguishing it from sending or deleting 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 usage guidelines provided: no context on when to use vs alternatives (e.g., deleting and resending), no prerequisites, no conditions for editing (e.g., time limit, ownership).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush cached history sync messages. Returns 202 Accepted, then asynchronously publishes cached history sync messages as events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the async nature and return code, but omits whether the operation is destructive, idempotent, or has side effects on other data. Critical safety information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and then explain the async behavior. 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 no output schema and no parameters, the description provides the key behavioral aspects (flush, async, events). However, it lacks context about side effects, repeatability, and what happens to the cache post-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 has zero parameters and 100% coverage, so schema already fully documents parameters. Description adds no parameter info, which is acceptable; baseline is 4 for 0-param 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 uses the specific verb 'flush' and clearly identifies the resource as 'cached history sync messages', which uniquely distinguishes it from sibling tools like archive, block, or clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to flush cached history, but provides no guidance on when to use it versus alternatives or any prerequisites. No explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of all blocked contacts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the action 'Get' with no mention of read-only nature, response format, or any side effects. This is insufficient for a tool with no 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 short sentence, which is concise and front-loaded. However, it is extremely minimal; a slightly more structured or informative description would be better, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, and the operation is straightforward (retrieving a list), the description is nearly complete. It lacks mention of what the list contains (e.g., contact IDs), but for a simple tool it is 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?
The input schema has 0 parameters, so schema description coverage is 100%. Per guidelines, baseline is 4 when there are no parameters. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'list of all blocked contacts', clearly indicating the tool's function. It distinguishes from siblings like 'whatsapp_block_contact' (block operation) and 'whatsapp_get_contacts' (all 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?
No usage context is provided. The description does not advise when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For a retrieval tool, it should clarify that it is read-only and does not filter by other criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description gives no behavioral details: no mention of side effects, data returned, permissions, or network usage. The agent lacks insight into tool 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?
Single sentence, no redundancy. Efficient but at the expense of completeness; slightly more context would improve without harming conciseness.
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 1-parameter getter without output schema, the description is minimally adequate but lacks detail on what information is returned and how to obtain the chat ID.
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%, baseline 3. Description adds no extra meaning beyond the schema's 'Chat JID' for chatId.
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 and resource: 'Get information about a specific chat.' Distinguishes from siblings like whatsapp_get_chat_business_profile and whatsapp_get_chat_picture by being generic, but could explicitly differentiate.
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 (e.g., get_chat_business_profile) or prerequisites (e.g., how to obtain chatId). Missing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business profile for a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a one-line description, the tool offers no insight into behavioral traits like required permissions, error conditions, or whether the chat must belong to a business account. The description carries the full burden but fails to disclose any such information.
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—a single sentence with no superfluous text. It is front-loaded with the purpose, but the brevity may come at the cost of completeness.
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 simplicity (one parameter, no output schema, no annotations), the description is insufficient. It lacks information about return values, error cases, and prerequisites, making it incomplete for an agent to reliably use the 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 schema covers the sole parameter 'chatId' with description 'Chat JID', achieving 100% coverage. The tool description adds no extra meaning about the parameter 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?
The description clearly states 'Get business profile for a chat', which specifies the action and resource. It differentiates from siblings like 'whatsapp_get_chat' or 'whatsapp_get_user_profile' by focusing on business profiles, but does not elaborate on what constitutes a business profile.
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 such as 'whatsapp_get_chat' or 'whatsapp_get_user_profile'. There is no mention of prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get chat profile picture.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavior like read-only nature, authentication needs, or what happens if no profile picture is set.
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, achieving high conciseness.
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 low complexity with one parameter and no output schema, the description is too minimal. It does not explain the return value (e.g., URL or binary), which is essential for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema describes 'chatId' as 'Chat JID'. The description adds no additional meaning 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 'Get chat profile picture' clearly states the action and resource. It distinguishes from siblings like whatsapp_set_chat_picture and whatsapp_get_group_picture, but lacks detail on what format the picture is returned in.
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 vs alternatives or prerequisites. For example, it doesn't mention whether it works for groups or if the chat must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all WhatsApp chats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It lacks disclosure of read-only nature, pagination, return format, or any behavioral constraints beyond 'get list'.
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 superfluous words. It is appropriately 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?
While the description is adequate for a simple list operation with zero parameters, it omits details like whether archived chats are included, output format, or any filtering capabilities. More context would improve agent decision-making given the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the input schema, and the description adds no parameter info. Per guidelines, 0 parameters yields a baseline of 4.
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 'Get list of all WhatsApp chats.' uses a specific verb ('Get') and resource ('list of all WhatsApp chats'), clearly distinguishing it from siblings like 'whatsapp_get_chat' which targets a single chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., whatsapp_get_chat for a specific chat). The description provides no context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get community info.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Get community info' without mentioning that the operation is read-only, idempotent, requires authentication, or what fields are returned. This is insufficient for an agent to understand implications.
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 (3 words) and front-loaded. While it is not verbose, it could benefit from slightly more detail (e.g., scope of 'info'). Nevertheless, it avoids 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 no output schema and a single required parameter, the description is too minimal. It does not explain what 'community info' includes, error handling, or how it differs from retrieving a community via other means. This is inadequate for an agent to confidently use the 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 input schema has 100% coverage via parameter description ('Community JID'), so the schema already defines the parameter. The description adds no additional meaning beyond the schema, earning a baseline score of 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 'Get community info.' clearly states the action (get) and the resource (community info), distinguishing it from more specific sibling tools like `whatsapp_get_community_invite_link` or `whatsapp_get_community_participants`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., `whatsapp_list_communities` for all communities, or `whatsapp_get_community_participants` for participants). The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get community invite link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of disclosing behavioral traits. It does not specify that this is a read-only operation, that it requires an existing community, or that it may fail if the community has no invite link. No mention of permissions, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only six words with one verb and one noun. While it is short and front-loaded, it could be slightly more informative without adding significant length (e.g., 'Returns the current invite link for the community with the given JID'). However, it is not verbose and earns a 4.
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 absence of an output schema, the description should at least mention what the tool returns (e.g., the invite link string). It also lacks context on how the returned link differs from reset links or how to use it. For a simple tool, it is functional but incomplete.
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% description coverage for the single parameter 'id' (Community JID), so the description adds no extra meaning. According to the rubric, the baseline is 3 when coverage is high, and the description does not provide additional clarification 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 action ('Get') and the resource ('community invite link'), making the purpose immediately understandable. It distinguishes from sibling tools like 'whatsapp_get_group_invite_link' by specifying 'community'. However, it could be slightly more precise by indicating that it returns the invite link, but the current phrasing is adequate.
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 'whatsapp_reset_community_invite_link' or 'whatsapp_join_group_with_invite'. It also does not mention prerequisites (e.g., admin privileges) or context for using the returned link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get community participants.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior; only 'Get community participants' provides no details on pagination, authentication, side effects, or return 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?
Single sentence is concise and front-loaded, but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a retrieval tool with no output schema; fails to explain what participants are returned or how to obtain the JID.
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 'id' described as 'Community JID', but description adds no extra meaning beyond 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?
Clearly states verb 'Get' and resource 'community participants', distinguishing from siblings like 'whatsapp_get_group_participants' by name, but lacks explicit differentiation in description.
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 vs alternatives such as 'whatsapp_get_community' or 'whatsapp_get_group_participants', and no prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get community sub-groups.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic action. It does not state that the tool is read-only, what the return type is, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of three words, which is extremely concise and front-loaded. However, it lacks any supporting context.
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 nature of the tool (one parameter, no output schema), the description provides the essential purpose but leaves out details about the return value or structure, making it minimally 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 one parameter with a description 'Community JID'. Since schema coverage is 100%, the baseline is 3. The description does not add additional meaning 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 action 'Get' and the resource 'community sub-groups', which is specific and distinguishes it from sibling tools like 'whatsapp_get_community' and 'whatsapp_list_communities'.
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, such as when retrieving community information or listing communities. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific WhatsApp contact.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Contact JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states 'Get information', implying a read operation, but lacks details on error handling, authentication, or effects if the contact ID is invalid.
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, but it is under-specified. It could benefit from additional detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (1 required param) and no output schema, the description is minimally sufficient but does not explain output format or edge cases. Could be improved.
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 'id' with description 'Contact JID'. The description adds no further meaning, 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 clearly states the verb 'Get' and the resource 'information about a specific WhatsApp contact', which distinguishes it from the plural variant 'whatsapp_get_contacts'. However, it could be more explicit about what specific information is returned.
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 like 'whatsapp_get_contacts' or 'whatsapp_check_user'. No prerequisites (e.g., contact existence) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all WhatsApp contacts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only indicates a read operation by implication but does not state that it is read-only, whether it requires authentication, rate limits, or what happens if there are no contacts.
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 unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is minimally adequate. However, it could mention the return format or any limitations, but it is not severely lacking.
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, and schema description coverage is trivially 100%. According to the rules, 0 parameters warrants a baseline of 4.
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 ('Get list') and the resource ('all WhatsApp contacts'). It is a specific verb+resource combination that distinguishes from siblings like 'whatsapp_get_contact' (singular) and 'whatsapp_create_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?
No guidance is provided on when to use this tool vs alternatives such as 'whatsapp_sync_contacts' or 'whatsapp_get_contact'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific group.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the high-level purpose without disclosing return format, side effects, or any behavioral traits. With no annotations, the description carries full burden but is insufficient.
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 sentence, no wasted words. However, it is so brief that it sacrifices informative value, but it is still appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple tool, the description is too minimal. It does not explain what 'information' is returned, nor does it provide context relative to the many sibling tools.
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 covers 100% of parameters with description of 'id' as 'Group JID'. Description adds no extra meaning beyond 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?
Description clearly states the action (get) and the resource (information about a specific group). It distinguishes from siblings like whatsapp_get_groups (plural) and whatsapp_get_group_info_from_link (via link).
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 vs alternatives. Among many group-related tools (e.g., whatsapp_get_group_participants, whatsapp_get_group_invite_link), the description provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview group information from an invite code without joining.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Invite link code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read-only operation, but lacks details on error handling (e.g., invalid invite code), rate limits, or any side effects. The behavior is generally clear but not fully transparent.
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 superfluous words. Every token contributes to the purpose and context. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description adequately conveys the tool's purpose but does not specify what information is returned (e.g., group name, picture, participant count). For a preview tool, listing returned fields would improve 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?
The single parameter 'code' is fully described in the schema with 100% coverage. The description adds 'without joining' context but does not enhance parameter 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 'Preview group information from an invite code without joining.' clearly states the action (preview), resource (group info from invite code), and adds key context (without joining), effectively distinguishing it from similar tools like whatsapp_join_group_with_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for preview before joining, but does not explicitly state when to use this tool versus alternatives (e.g., whatsapp_get_group or whatsapp_join_group_with_link). No direct guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get group invite link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It fails to mention that the tool likely requires admin privileges or that it returns a string link. It also does not indicate if the link is pre-existing or generated on demand.
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 unnecessary words. It is front-loaded and efficiently conveys the core 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 the tool's simplicity and the presence of sibling tools, the description is adequate but lacks details about return value, permission requirements, and potential failure modes. It does not fully equip an agent to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is described as 'Group JID' in the schema, which is acceptable but not explanatory. The description does not add any further semantic value beyond the schema, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get group invite link' uses a specific verb and resource, clearly indicating the tool's purpose. It is easily distinguishable from sibling tools like whatsapp_get_community_invite_link and whatsapp_reset_group_invite_link.
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. For instance, it does not differentiate from whatsapp_get_group_info_from_link or explain when to use this over creating a link via group settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get group participants.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a read-like operation without disclosing behavioral details such as whether it requires permissions, if it returns blocked participants, or if it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, which is efficient for a simple tool. It front-loads the purpose without unnecessary elaboration.
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 output schema, the description does not hint at the return value (e.g., list of participant JIDs or contact objects). This omission leaves the agent uncertain about the output 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?
The input schema covers the 'id' parameter with description 'Group JID', but the tool description adds no additional meaning beyond the schema. It does not explain what a JID is or how to obtain 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 'Get group participants' clearly indicates the tool retrieves participants of a group, matching its name. However, it does not differentiate from sibling tools like 'whatsapp_get_group' or 'whatsapp_get_group_info_from_link'.
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. For instance, it doesn't mention that to get group metadata one should use 'whatsapp_get_group' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pending join requests for a group.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic operation without disclosing behavioral traits such as what happens when there are no requests, authentication requirements, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and additional context. It is not front-loaded with key information beyond the basic 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 simplicity of the tool, the description is somewhat adequate but omits important context like return format (no output schema) and edge cases, making it incomplete for agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameter adequately. The description adds no extra meaning beyond what is in the schema, resulting in a 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 clearly states the action 'Get pending join requests for a group' with a specific verb and resource. It distinguishes from siblings like 'whatsapp_update_group_requests' and 'whatsapp_get_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., being an admin), and no when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all WhatsApp groups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get list', implying read-only, but does not mention any prerequisites, error states, or what 'all groups' means (e.g., does it include archived groups?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool that returns a list. It does not specify what data is returned (e.g., names, IDs, participant counts) or any limitations. Given no output schema, more context 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?
There are no parameters, so the description cannot add meaning beyond the schema. Baseline for 0 parameters is 4, and the description is accurate.
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 (Get) and the resource (list of all WhatsApp groups). It is specific and directly conveys the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like whatsapp_get_group (single group) or other listing tools. The agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get own WhatsApp profile info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get', implying a read-only operation, but does not disclose any behavioral traits such as authentication requirements, rate limits, or what exactly the profile info contains. For a simple retrieval, this is minimally adequate but lacks depth.
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 five words, conveying the tool's purpose without any extraneous information. Every word is necessary and contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, and the operation is a simple read, the description is complete. It tells the agent exactly what the tool does, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% trivially. The description adds meaning by specifying 'own WhatsApp profile info', indicating what the output represents. According to guidelines, 0 parameters baseline is 4, and the description provides sufficient context.
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 'Get own WhatsApp profile info' uses a specific verb ('Get') and resource ('own WhatsApp profile info'), clearly distinguishing it from sibling tools like 'whatsapp_get_user_profile' which would retrieve another user's profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one's own profile, but lacks explicit guidance on when to use this versus alternatives like 'whatsapp_get_contact' or 'whatsapp_get_chat'. The context is clear, but no exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get newsletter info by JID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Newsletter JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'Get' which implies read-only, but fails to disclose any behavioral traits, return value structure, or permissions required.
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 sentence, no wasted words. Front-loaded with key 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?
Minimal but adequate for a simple retrieval tool with one parameter. Lacks details on what 'info' includes, but acceptable given no output schema and 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 parameter description 'Newsletter JID'. The description adds 'by JID' which reinforces but does not extend beyond 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?
Description clearly states verb 'Get', resource 'newsletter info', and method 'by JID', distinguishing it from siblings like whatsapp_get_newsletter_by_invite (uses invite key) and whatsapp_list_newsletters (retrieves all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., using JID vs invite link). Agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get newsletter info by invite code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Newsletter invite code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It implies a read operation but does not confirm no side effects, required permissions, or return 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?
Extremely concise single phrase. No wasted words, but could be improved with a full sentence for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimal but covers the basic purpose. Missing details like what fields are returned or limitations.
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 schema already describes the 'code' parameter as 'Newsletter invite code'. Description adds no extra meaning beyond repeating 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?
Description clearly states verb 'Get' and resource 'newsletter info' and method 'by invite code'. This distinguishes it from 'whatsapp_get_newsletter' which likely uses a different identifier.
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 alternatives, but the description implies usage when you have an invite code. Missing guidance on when not to use or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pairing code for WhatsApp login.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number (7-15 digits) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as side effects or state consumption (e.g., pairing codes may be single-use). The description only states the basic action, omitting critical 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 concise sentence with no unnecessary words or repetition. It is appropriately short for a simple 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?
Despite the simple tool design, the description lacks essential context: it does not explain what a pairing code is, how it relates to login, or how it differs from QR codes. Given the existence of sibling QR code tools, more completeness 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?
The input schema provides a clear description for the 'phone' parameter ('Phone number (7-15 digits)'), and the tool description adds no additional meaning beyond that. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'pairing code' for 'WhatsApp login', but it does not differentiate this tool from siblings like 'whatsapp_get_qr_code', which also serves login 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?
No guidance is provided on when to use this tool versus alternatives (e.g., QR code tools). The agent has no basis to choose between similar login-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current privacy settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, or what happens if settings are unavailable. Minimal 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 a single, clear sentence with no extraneous words. It is perfectly concise 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?
Given no parameters and no output schema, the description is adequate but lacks detail about the return value or any side effects. It could mention what 'privacy settings' entails or that it retrieves all current settings.
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, so the input schema provides all necessary information. The description adds no parameter details, but since schema coverage is 100%, a baseline of 4 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 'Get' and the resource 'privacy settings'. It distinguishes from the sibling tool 'whatsapp_set_privacy_settings' which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it is implied for retrieval only, no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get QR code text string for WhatsApp login.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the primary behavior (getting QR code text for login) but omits any details about prerequisites, side effects, or authentication context. Acceptable for a simple getter but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. Every word is necessary, wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is adequate. It explains the purpose and return format (text string for login). Could mention usage context (e.g., scanning) but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (baseline level 4 per instructions). The description adds value by specifying that the output is a text string for login, clarifying the return type beyond the 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 action (Get) and the resource (QR code text string for WhatsApp login). It distinguishes from the sibling tool 'whatsapp_get_qr_code_image' by specifying 'text string' versus image.
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. The sibling 'whatsapp_get_qr_code_image' exists, and the description does not explain when to choose text over image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get QR code PNG image for WhatsApp login.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks disclosure of output format (e.g., base64, blob), size, or any side effects. No annotations provided to fill gaps. Minimal insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. No unnecessary words. Perfectly sized for the simplicity of 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?
With no output schema, the description should clarify what the tool returns (e.g., base64 string, binary). It only says 'PNG image' without specifying the response format, leaving ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, and schema coverage is 100%. Baseline score of 4 applies as description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'QR code PNG image', and purpose 'for WhatsApp login'. It effectively distinguishes from sibling 'whatsapp_get_qr_code' by specifying the image format.
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 versus 'whatsapp_get_qr_code' or prerequisites like needing to be logged out. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current WhatsApp session status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states it retrieves status, with no disclosure of side effects, authentication context, or what 'status' entails (e.g., connected, disconnected).
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 extraneous words. It is appropriately sized for the tool's simplicity.
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, no output schema, and a simple purpose, the description is adequate but lacks details on possible status values or what the output indicates. Could be 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 input schema has zero parameters, and schema description coverage is 100%. With no parameters, the description does not need to add parameter information; baseline is 4.
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' and the specific resource 'current WhatsApp session status'. It is distinct from the many sibling tools, none of which deal with session status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the purpose is self-explanatory (checking session status). The description does not mention prerequisites or 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.
Get status broadcast privacy settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It only states 'Get' (read operation) without mentioning read-only nature, no side effects, or any prerequisites. The description adds minimal value beyond the name.
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 extraneous words. Every part is necessary and 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 the tool has no parameters and no output schema, the description is sufficient for a simple retrieval operation. However, it could optionally mention what the settings contain (e.g., who can see status) for more 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 has zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter meaning. A baseline score of 4 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 'Get' and the resource 'status broadcast privacy settings'. It distinguishes this tool from 'whatsapp_get_privacy_settings', which likely retrieves general privacy settings, making the purpose 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 instead of alternatives like 'whatsapp_get_privacy_settings' or 'whatsapp_set_privacy_setting'. The usage is implied but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profile info for a specific user by phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number (e.g. 1234567890) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states 'Get profile info', which suggests a read operation, but does not mention any requirements (e.g., user must exist) or potential side effects. Annotations would help, but they are absent.
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 directly states the tool's purpose without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, no nested objects, and only one parameter, the description is adequate for a simple lookup tool. However, it lacks details on what fields 'profile info' includes, and does not explain behavior if phone is not found or if the user is not a contact.
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 one parameter (phone) with 100% schema description coverage. The description does not add meaning beyond the schema's 'Phone number (e.g. 1234567890)'. Baseline of 3 applies since schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get profile info for a specific user by phone number', which includes a specific verb, resource, and context. It distinguishes from sibling tools like whatsapp_get_contact or whatsapp_get_chat_business_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a user's profile via phone number, but does not explicitly state when to use it versus alternatives like whatsapp_check_user or whatsapp_get_contact. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept a group invite received via direct message.
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Group JID | |
| inviterId | Yes | Inviter JID | |
| code | Yes | Invite code | |
| expiration | No | Invite expiration timestamp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry the full burden. It only states 'accept a group invite' without disclosing side effects like what happens if the invite is expired or if already a member.
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 is front-loaded and efficient, though it could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutative action with no output schema. The description lacks details on prerequisites, expected outcomes, or potential failures, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool accepts a group invite via direct message, distinguishing it from similar tools like whatsapp_join_group_with_link.
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 (accepting invites from direct messages) but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join a group via invite link code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Invite link code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose behavioral traits such as authentication requirements, error handling, or side effects of joining a group.
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, front-loaded sentence with no unnecessary 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 lack of output schema and annotations, the description is insufficiently complete; it does not explain what happens upon successful join or potential errors.
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 minimal value beyond the schema's parameter description of 'Invite link code'. 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 includes a specific verb 'Join' and resource 'group via invite link code', clearly differentiating it from similar siblings like 'whatsapp_join_group_with_invite'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'whatsapp_join_group_with_invite' or prerequisites for invite link codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leave a community.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Leave a community,' failing to mention that the action is irreversible, requires membership, or affects subgroups. Minimal 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 extremely concise (3 words) and front-loaded. It could include a bit more context without becoming verbose, but it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies state (leaving a community), the description lacks details on consequences, reversibility, required permissions, or how it relates to other community operations. Incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the single parameter ('Community JID'), achieving 100% coverage. The tool description adds no additional meaning beyond the schema, so 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 'Leave a community.' uses a clear verb and resource, and is distinct from sibling tools like whatsapp_leave_group and whatsapp_delete_chat, 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?
No guidance is given on when to use this tool versus alternatives, nor are there any prerequisites or conditions mentioned. The agent receives no context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leave a group.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Leave a group' without mentioning irreversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but lacks necessary context. While concise, it could include usage notes without significant length increase.
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 low complexity, the description should disclose that leaving a group is irreversible and requires membership, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add meaning beyond the schema. The parameter 'id' is already described as 'Group JID' in 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 action 'Leave a group' with a specific verb and resource. It distinguishes from the sibling tool 'whatsapp_leave_community' by specifying 'group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as admin-only vs any member, or prerequisites like being a member.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link an existing group to a community.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| groupId | Yes | Group JID to link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action 'link' without detailing side effects, error conditions, or required permissions. Critical behavioral traits are missing.
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 superfluous words. It is front-loaded and efficient, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the tool lacks completeness. An agent needs to know if the link is reversible (there is an unlink tool), constraints on group status, and what the response indicates. The description is insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters ('Community JID' and 'Group JID to link'). The tool description adds no additional semantic value beyond what the schema provides, meeting the baseline for 100% 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 uses the verb 'link' and specifies 'existing group' and 'community', clearly stating the action and resources. However, it does not explicitly differentiate from its sibling 'whatsapp_unlink_community_group', though the name and direction are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites (e.g., group must not already be linked, community must exist), or alternatives. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all joined communities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read operation (list) but does not disclose behavior beyond that, e.g., pagination, ordering, or authentication requirements. Minimal 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?
Single sentence with no wasted words. Efficiently conveys 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 no output schema or description, the agent cannot infer the return format (e.g., array of community IDs vs objects). For a simple list tool, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist and schema coverage is 100%. Baseline for 0 parameters is 4, and the description does not need to add semantic detail beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all joined communities', distinguishing it from sibling tools like whatsapp_get_community which retrieves a single community. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_community, get_chats, or list_newsletters. Does not mention that for details of a specific community, use get_community.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all subscribed newsletters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a list operation but does not mention read-only nature, authentication needs, rate limits, or output format. This is insufficient for a tool with no metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with a single phrase. It is front-loaded with the core action and resource. While brief, it lacks any supplementary context but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and no output schema, the description is the sole source of information. It does not explain what the returned list contains (e.g., names, IDs, objects), leaving agents uncertain about how to use results. This is incomplete.
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, and the input schema is empty. The description adds no parameter info, but the baseline for 0 parameters is 4. It correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all subscribed newsletters' clearly states the verb (list) and resource (subscribed newsletters), distinguishing it from sibling tools like 'whatsapp_get_newsletter' (get single) and 'whatsapp_set_newsletter_subscription' (modify subscription).
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, such as using 'whatsapp_get_newsletter' for details on a specific newsletter. The simple phrase does not set context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logout from WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. 'Logout' implies state mutation (e.g., ending the session), but no details about consequences, whether it requires an active session, or if it can be reversed.
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 directly states the tool's purpose. It is front-loaded and contains no unnecessary 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 no parameters and no output schema, the description is largely sufficient. However, it could provide a bit more context about the effect of logout (e.g., session invalidation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). The description adds no parameter info, which is acceptable since there are none. A higher score would require more context beyond the schema, which is not necessary here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Logout') and the resource ('from WhatsApp'). It is specific and distinct from sibling tools, which cover a wide range of other WhatsApp operations.
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, such as other session management tools (e.g., get_session_status). There are no prerequisites or side effects mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a chat as read or unread.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| read | Yes | Mark as read (true) or unread (false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It only states the action (marking read/unread) without mentioning side effects, permissions required, rate limits, or what happens to notifications. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short sentence—with no redundant information. It effectively front-loads the core action. However, it could be slightly expanded to include context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two parameters, no output schema), the description provides minimal but adequate context. It does not explain the difference from the similar sibling tool or what the agent should expect as a response, leaving room for improvement.
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 provides clear descriptions for both parameters (chatId and read), covering 100% of schema documentation. The tool description adds no new information beyond the schema, so 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 marks a chat as read or unread, which is a specific verb-resource combination. However, it does not differentiate from the sibling tool 'whatsapp_mark_message_read', which marks individual messages, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'whatsapp_mark_message_read' or other chat-management tools. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a message as read.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | Message ID | |
| chatId | Yes | Chat JID | |
| senderId | Yes | Message sender JID | |
| receiptType | Yes | Receipt type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral details beyond the action. With no annotations, it fails to disclose if this is a write operation, whether it triggers notifications, or if it's reversible. The user must infer 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 a single short sentence, which is concise, but it essentially restates the tool name. It could include more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters and no output schema, the description is incomplete. It doesn't explain the effect of the 'receiptType' parameter, the expected outcome, or any prerequisites.
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 descriptions for all 4 parameters. The tool description adds no extra meaning, so it meets the baseline but does not enhance understanding of parameter roles or relationships.
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 a message as read' clearly specifies the action (mark) and resource (message). It distinguishes from sibling tools like 'whatsapp_delete_message' or 'whatsapp_star_message' by indicating a specific read-status update.
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. For example, it doesn't clarify whether this sends a read receipt or just updates local state, nor does it mention related tools like 'whatsapp_mark_chat_as_read' for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mute or unmute a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| duration | Yes | Mute duration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral aspects such as permission requirements, effect on notifications, or whether unmuting restores previous mute state. The description carries the full burden but fails to provide meaningful 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 sentence that is efficient and front-loaded. However, it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and the lack of output schema, the description is too minimal. It does not explain return values, errors, or edge cases like muting an already-muted chat.
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% coverage, describing both parameters (chatId, duration) with clear types and enums. The description adds no further semantic information; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mute or unmute a chat,' specifying the action (mute/unmute) and the resource (a chat). It differentiates from siblings like whatsapp_archive_chat or whatsapp_pin_chat by indicating a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., muting a newsletter vs. chat, or when to archive instead). Missing context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mute or unmute a newsletter.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Newsletter JID | |
| mute | Yes | True to mute, false to unmute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral details like whether muting persists or affects notifications. The description is too brief to convey any behavioral traits.
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?
Extremely concise: one sentence, four words. No unnecessary information, and it is front-loaded with 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?
For a simple mute toggle with full parameter coverage and no output schema, the description is adequate but lacks detail on behavioral implications (e.g., persistence, side effects). Could be improved.
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 already fully describes both parameters (100% coverage). The description adds no extra 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 'Mute or unmute a newsletter.' It uses a specific verb (mute/unmute) and resource (newsletter), distinguishing it from sibling tools like whatsapp_mute_chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as how it differs from muting chats or other newsletter operations. The description is minimal and provides no context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pin or unpin a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| pinned | Yes | Pin or unpin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action, lacking details on behavioral traits like limits on pinned chats, side effects, or confirmation of change.
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 at 6 words, with no wasted language. It front-loads the core action and is easy to read.
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 simplicity of the tool (2 required params, no output schema), the description is minimally adequate. However, it lacks any context about the effect of pinning, limitations, or when to use, which would be helpful for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters adequately described in the schema. The description adds no additional meaning beyond what the schema already provides, so 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 ('Pin or unpin') and the target resource ('a chat'). It is distinct from sibling tools like whataspp_archive_chat or whataspp_mute_chat, 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?
No guidance is provided on when to use this tool versus alternatives like archiving or muting. The description does not specify any context or constraints, such as the effect of pinning on chat ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pin or unpin a message in a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | Message ID | |
| chatId | Yes | Chat JID | |
| senderId | Yes | Message sender JID | |
| pinned | No | True to pin, false to unpin | |
| pinExpiration | No | Pin expiration (e.g. 24h, 7d, 30d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the basic action (pin/unpin) and does not mention permissions, error handling, side effects (e.g., unpinning an already pinned message), or rate limits. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that delivers the core purpose with no superfluous words. It is appropriately front-loaded and 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?
Given no output schema and no annotations, the description fails to provide sufficient context for safe or effective use. It does not explain expected behavior in edge cases, such as invalid IDs, or clarify that pinning is typically limited to group chats (if applicable).
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% description coverage, so all parameters are already explained. The description adds no additional meaning 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 action ('Pin or unpin') and the resource ('a message in a chat'). It effectively distinguishes from sibling tools like 'whatsapp_pin_chat' (pinning a chat) and 'whatsapp_star_message' (starring a 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 provides no guidance on when to use this tool versus alternatives, such as when to pin versus star a message, or when to pin a message versus pin a chat. It lacks any contextual or conditional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post an image status update. Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Base64-encoded image data | |
| url | No | URL of the image | |
| mimeType | No | MIME type | |
| caption | No | Caption |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden but only says 'Post an image status update' without disclosing what happens after posting, privacy or visibility, limits, 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 a single, efficient sentence that communicates the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is too brief. It fails to explain what the tool returns, error handling, or how the status update behaves (e.g., duration, audience).
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 the useful constraint 'Provide either data (base64) or url' but does not explain mimeType or caption, which are left to schema defaults.
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 (post) and the resource (image status update), and it distinguishes from sibling tools like whatsapp_post_text_status and whatsapp_post_video_status by specifying 'image'.
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 only mentions providing either data or url but gives no guidance on when to use this tool versus alternatives (e.g., vs. whatsapp_send_image) or any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a text status update (story).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Status text content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action, omitting details like whether posting replaces existing status, text length limits, or rate limits. This is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential purpose without any fluff. It is optimally concise 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 tool with one parameter and no output schema, the description is minimally adequate to convey the basic action. However, it lacks details like text constraints or behavioral traits, leaving gaps in understanding for a complete invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'text' has a basic description 'Status text content'. The tool's description adds no additional meaning beyond the schema, so 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 'Post a text status update (story)' clearly identifies the action (post), resource (text status update), and context (story). It distinguishes this tool from siblings like whatsapp_post_image_status or whatsapp_post_video_status by specifying '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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as authentication or session requirements. It does not mention that for image or video statuses, other tools should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a video status update. Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Base64-encoded video data | |
| url | No | URL of the video | |
| mimeType | No | MIME type | |
| caption | No | Caption |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds behavioral constraint (either data or URL required) beyond the schema's optional parameters, but does not disclose other behaviors (e.g., side effects, permissions, or limitations for video status). The added constraint is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. Every part contributes directly to understanding the tool's core purpose and constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema or annotations, the description is partially complete. It explains the data/url constraint but omits context about the status feature (e.g., expiry, visibility), the role of mimeType and caption, and the return value. This may leave an agent unsure about optional parameters and overall behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that data and url are alternatives and that data should be base64-encoded. This semantic link between parameters is helpful for correct invocation.
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 posts a video status update, using a specific verb and resource. It distinguishes from similar tools like whatsapp_post_image_status and whatsapp_post_text_status by specifying video, and the name includes 'status' to differentiate from send_video. However, it does not explicitly contrast with send_video or explain the status context.
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 usage condition ('Provide either data (base64) or url') but offers no guidance on when to use this tool versus alternatives like whatsapp_send_video or other status posting tools. It lacks context for selecting 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.
Reject an incoming call.
| Name | Required | Description | Default |
|---|---|---|---|
| callId | Yes | Call ID from the call event | |
| callerId | Yes | JID of the caller |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Reject an incoming call' without any details on side effects, prerequisites, or consequences.
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 very short and front-loaded, containing only necessary information without waste.
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 output schema and no annotations, the description is too minimal; it omits return values, prerequisites, and behavioral details needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described, so the description adds no additional meaning; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reject') and the resource ('incoming call'), which is specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and there are no exclusions or context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request on-demand message history for a chat. Results arrive asynchronously.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| lastMessageId | Yes | ID of the last known message | |
| lastMessageSenderId | Yes | Sender of the last known message | |
| count | No | Number of messages to request (default 50, max 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions asynchronous results, but fails to disclose how results are retrieved, error handling, or side effects. The agent is left with incomplete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, covering the core action and async nature. However, it may be too sparse for a tool with no output schema and complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and 4 parameters. The description fails to explain the async response mechanism (e.g., how to poll or receive results). The agent may not know how to properly use the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema. No clarification of 'chatId' or the required parameters is provided.
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 'Request' and resource 'on-demand message history for a chat', and mentions asynchronous delivery. However, it does not explicitly differentiate from sibling tools that might also provide message information (e.g., get_chat).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, nor any preconditions or exclusions. The term 'on-demand' implies it is for fetching fresh history, but no explicit when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset community invite link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'reset', which implies a destructive or modifying action. It does not disclose side effects, permissions required, or whether the operation is reversible. This is insufficient for safe invocation.
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 short (three words), but it fails to add value beyond the tool name. It is under-specified rather than concise, as every sentence should contribute new 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 complexity of resetting an invite link (side effects, permissions, return values) and the absence of annotations and output schema, the description is completely inadequate. It provides no context about what the action does beyond the name.
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%; the single parameter 'id' is described as 'Community JID' in the schema. The tool description adds no additional meaning, but the schema already adequately documents the parameter. 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 'Reset community invite link' simply restates the tool name without adding specific verb-resource details or differentiating from the sibling tool 'whatsapp_reset_group_invite_link'. It lacks clarity on what 'reset' precisely entails (e.g., invalidates old link, generates new one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'whatsapp_get_community_invite_link' or 'whatsapp_reset_group_invite_link'. Prerequisites (e.g., admin permissions) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset group invite link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It does not state whether this invalidates the old link, generates a new one immediately, or requires specific permissions. The agent is left guessing about the mutation's impact.
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, which is concise but overly brief for a tool with no annotations. It lacks structure (e.g., no context, no separate sections) and misses opportunities to add useful 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 simplicity (1 param, no output schema), the description still fails to cover essential context: what does resetting mean? Is it destructive? Does it produce a new link? Without annotations, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'id' documented as 'Group JID'). The tool description adds no semantic value 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 'Reset group invite link' clearly states the action (reset) and the resource (group invite link). It distinguishes well from sibling tools like 'get', 'join', and 'reset_community_invite_link' although it doesn't explicitly mention that it only applies to 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?
No guidance is provided on when to use this tool vs alternatives like getting or joining with a link. It doesn't mention prerequisites (e.g., admin rights) or scenarios (e.g., link compromised).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an audio file message. Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded audio data | |
| url | No | URL of the audio file | |
| mimeType | No | MIME type (auto-detected if omitted) | |
| mentions | No | ||
| replyTo | No | Message ID to reply to | |
| replyToSenderId | No | ||
| isForwarded | No | ||
| viewOnce | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states to provide data or url, but does not mention what happens if both are supplied, file size limits, supported formats, or potential errors. The 'auto-detected if omitted' note for mimeType is in the schema, not description.
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 very short (one sentence) and to the point, but it lacks necessary detail. It is not wasteful, but it is under-specified for a tool with 10 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description is highly incomplete. It does not explain return values, error behavior, or how to use optional parameters. Essential context for agent usage is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, meaning 5 parameters lack descriptions. The tool description adds no parameter-specific details beyond the schema. It mentions 'data' and 'url' but does not clarify their meaning or constraints. The description fails to compensate for missing 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 action and resource: 'Send an audio file message.' It also notes the two ways to provide the audio (data or url), which differentiates it from other send tools like send_image or send_document. However, it could be more explicit about context (e.g., in a WhatsApp chat).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like send_voice (which might be for voice notes). There are no exclusions or prerequisites mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a contact (vCard) message. Provide either displayName or vcard.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| displayName | No | Display name (auto-generates vCard) | |
| vcard | No | Raw vCard string | |
| mentions | No | ||
| replyTo | No | ||
| replyToSenderId | No | ||
| isForwarded | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden, but it fails to disclose any behavioral traits such as what happens if both displayName and vcard are provided, validation of vcard format, or the nature of the message delivery.
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 very short and front-loaded, conveying the core purpose in one sentence. While it could benefit from more structure, it is efficient and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description leaves major gaps. It does not explain the 'to' parameter format (JID), the behavior of optional parameters, or the return value, making it incomplete for safe 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?
With only 38% schema coverage, the description adds minimal value by mentioning displayName and vcard as alternatives. It does not explain the format required for vcard, the meaning of other parameters like mentions or replyTo, or confirm if displayName or vcard is needed beyond the mutual exclusivity hint.
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 sends a contact (vCard) message, which distinguishes it from other send_* tools like send_text or send_image. However, it does not explicitly differentiate from the similar-sounding 'whatsapp_create_contact' 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?
It provides a usage hint to 'provide either displayName or vcard', implying mutual exclusivity, but lacks explicit guidance on when to use this tool versus alternatives like send_text or 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.
Send a document file. Provide either data (base64) or url. Filename is required.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded document data | |
| url | No | URL of the document | |
| filename | Yes | Filename shown to recipient | |
| mimeType | No | MIME type (auto-detected if omitted) | |
| caption | No | Caption for the document | |
| mentions | No | ||
| replyTo | No | ||
| replyToSenderId | No | ||
| isForwarded | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description gives minimal behavioral context. Does not disclose side effects, required permissions, success/failure behavior, or rate limits. The one-line description does little to explain what happens when sending.
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?
Highly concise: two sentences, front-loads the action. No wasted words, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description is far too brief. Ignores many optional parameters (caption, mentions, etc.) and does not explain the expected behavior beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description clarifies that 'data' and 'url' are alternatives and 'filename' is required. With schema coverage at 55%, this adds some value but not enough to fully compensate for the other parameters left unexplained.
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 'Send a document file' and the resource. Distinguishes from siblings like whatsapp_send_image via naming and 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 explicit guidance on providing either base64 data or a URL, and that filename is required. However, no when/why to choose this over other sending tools beyond name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an image message. Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded image data | |
| url | No | URL of the image | |
| mimeType | No | MIME type (auto-detected if omitted) | |
| caption | No | Caption for the image | |
| mentions | No | JIDs of mentioned users | |
| replyTo | No | Message ID to reply to | |
| replyToSenderId | No | Sender JID of the replied message | |
| isForwarded | No | Mark as forwarded | |
| viewOnce | No | Send as view-once | |
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action and parameter requirement, omitting behavioral traits such as permissions needed, what happens if both data and url are provided, or side effects like overwriting existing messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the core purpose and key parameter constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description is too brief. It mentions only the image source requirement, ignoring optional parameters like caption, mentions, and replyTo, and does not describe the return value or behavior when multiple image sources are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 91%, so the schema already documents most parameters. The description adds minimal value by emphasizing the data/url requirement, but does not explain interactions or constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an image message', which is a specific verb+resource. It distinguishes from sibling tools like whatsapp_send_audio or whatsapp_send_text by specifying the media type.
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 basic guidance on how to provide the image ('Provide either data (base64) or url'), but lacks guidance on when to use this tool versus alternatives like whatsapp_send_document for images, or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a link message with optional preview.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| text | Yes | Message text (max 4096 characters) | |
| url | Yes | URL to include | |
| title | No | Link preview title | |
| description | No | Link preview description | |
| jpegThumbnail | No | Base64 JPEG thumbnail | |
| mentions | No | ||
| replyTo | No | ||
| replyToSenderId | No | ||
| isForwarded | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action and optional preview, omitting side effects, required permissions, or limitations (e.g., does the preview generate automatically?). This leaves significant ambiguity.
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 very concise (one sentence) but lacks necessary detail. It is front-loaded with the action, but the brevity results in under-specification. A bit more structure (e.g., listing key optional features) would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters (many optional) and no output schema, the description is insufficient. It does not explain message behavior like mentions, reply chain, forwarding, or ephemeral settings. For a tool with this complexity, more context 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?
The input schema already describes most parameters (55% coverage). The description hints at preview-related parameters ('optional preview') but adds no new insight beyond the schema. For parameters like mentions, replyTo, etc., no extra context is provided.
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 a link message') and mentions the optional preview feature, distinguishing it from other send tools like whatsapp_send_text or whatsapp_send_image. However, it could be more specific about what constitutes a link message versus sending a plain text with a URL.
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. With numerous sibling send tools (e.g., whatsapp_send_text, whatsapp_send_image), explicit context about when to choose send_link would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a location message.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| latitude | Yes | Latitude | |
| longitude | Yes | Longitude | |
| name | No | Location name | |
| address | No | Location address | |
| url | No | Location URL | |
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It does not mention authentication requirements, error handling, whether the location appears as a static pin or interactive map, or any side effects. The single sentence is insufficient.
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?
At four words, the description is too terse to be effectively informative. While concise, it sacrifices necessary detail, making it under-specified rather than efficiently 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 has 7 parameters and no output schema or annotations, the description is severely lacking. It does not explain what the response looks like, how location data is displayed, or any behavior for edge cases. This is incomplete for a sending action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 86% of parameters with descriptions, so the schema already explains most parameters. The description adds no additional context about parameter usage, but with high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Send a location message,' which is a clear verb+resource but lacks any differentiation from sibling send tools like whatsapp_send_image. It is essentially a tautology of the tool name without adding 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?
No guidance on when to use this tool versus alternatives such as whatsapp_send_text or whatsapp_send_link. The absence of context for selecting this location-sending tool over others leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a reaction (emoji) to a message. Send empty string to remove reaction.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | ID of the message to react to | |
| to | Yes | Chat JID | |
| senderId | No | Sender of the original message (for groups) | |
| reaction | Yes | Emoji reaction (empty string to remove) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds behavioral info (emoji reaction, empty string removal) but does not disclose side effects, permissions, or idempotency. The context is basic 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 two short sentences, front-loaded with the main action. Every word is necessary; 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 (4 params, no output schema), the description is minimally adequate. It covers the core behavior but lacks details on error handling, prerequisites, or return values. Could be more helpful.
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% (all four parameters have descriptions). The description adds no additional meaning beyond the schema, which already describes messageId, to, senderId, and reaction. 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 'Send a reaction (emoji) to a message' and 'Send empty string to remove reaction', specifying the action and resource. It distinguishes from siblings like send_text or send_image by focusing specifically on reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning removal via empty string, but does not explicitly state when to use this tool vs alternatives (e.g., star_message, send_text). No when-not or alternative comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a sticker message (WebP format). Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded sticker data | |
| url | No | URL of the sticker | |
| isAnimated | No | Whether the sticker is animated | |
| mentions | No | ||
| replyTo | No | ||
| replyToSenderId | No | ||
| isForwarded | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It only states 'send' implying mutation, but fails to disclose side effects, authorization needs, rate limits, or response behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) with no redundancy. It is efficient but under-informative for the tool's complexity.
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 output schema, no annotations, and 9 parameters with limited descriptions, the description is incomplete. It lacks details on animated stickers, reply behavior, and error handling, failing to fully equip an AI agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 44% schema description coverage, the description should compensate but only mentions 'data' and 'url' as alternatives. It adds no meaning for parameters like isAnimated, mentions, replyTo, or ephemeralExpiration, leaving most parameters semantically barren.
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 explicitly states 'Send a sticker message (WebP format)', clearly identifying the action and resource. It distinguishes from sibling tools like whatsapp_send_image by specifying the WebP format 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?
The description mentions 'Provide either data (base64) or url', giving a basic usage hint. However, it does not specify when to use this tool over alternatives, prerequisites, or exclusions, relying on implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message to a WhatsApp contact or group. Supports mentions, replies, and ephemeral expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID (user or group) | |
| text | Yes | Message text content (max 4096 characters) | |
| mentions | No | JIDs of mentioned users | |
| replyTo | No | ID of the message being replied to | |
| replyToSenderId | No | Sender JID of the message being replied to | |
| isForwarded | No | Mark as forwarded | |
| ephemeralExpiration | No | Disappearing message timer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions supported features but does not disclose behavioral traits such as sending semantics, rate limits, authentication needs, failure behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently communicating purpose and key features with 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 absence of output schema and annotations, the description covers the basic action and features but lacks detail on parameter interactions, default behaviors, constraints (e.g., character limit from schema not in description), and error handling.
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 covers all 7 parameters with descriptions (100% coverage). The description reaffirms support for mentions, replies, and ephemeral expiration but adds no new meaning 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 action (send a text message), the resource (WhatsApp contact or group), and highlights supported features (mentions, replies, ephemeral expiration), distinguishing it from sibling tools like whatsapp_send_image or whatsapp_send_audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Lacks criteria for when not to use or mention of related tools like whatsapp_send_link or whatsapp_send_location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a video message. Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded video data | |
| url | No | URL of the video | |
| mimeType | No | MIME type (auto-detected if omitted) | |
| caption | No | Caption for the video | |
| mentions | No | ||
| replyTo | No | Message ID to reply to | |
| replyToSenderId | No | Sender JID of the replied message | |
| isForwarded | No | ||
| viewOnce | No | Send as view-once | |
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the basic action and input options. It omits important behavioral details such as permissions, limits, conflicting inputs, 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?
The description is concise with two sentences, no filler, and front-loads the key 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 the tool has 11 parameters and no output schema or annotations, the description lacks detail on many parameters and does not explain return values or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by clarifying the mutual exclusivity of 'data' and 'url'. Schema coverage is 73%, but this constraint is not captured in individual 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?
The description clearly states 'Send a video message', specifying the verb and resource. It also mentions providing data or url, which distinguishes it from other send 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 no guidance on when to use this tool versus alternatives like whatsapp_send_image or whatsapp_send_audio. It only states the requirement of providing data or url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a voice message (PTT). Provide either data (base64) or url.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient JID | |
| data | No | Base64 encoded voice data | |
| url | No | URL of the voice file | |
| mimeType | No | MIME type (auto-detected if omitted) | |
| mentions | No | ||
| replyTo | No | ||
| replyToSenderId | No | ||
| isForwarded | No | ||
| viewOnce | No | ||
| ephemeralExpiration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses that the tool sends a voice message but omits behavioral traits such as required permissions, file size limits, validation of inputs, or effects on chat. Minimal 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 a single sentence, which is concise but too brief for a tool with 10 parameters and no annotations. It lacks critical information and does not front-load important details; under-specification is not efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, no annotations, no output schema), the description is incomplete. It fails to explain optional parameters, constraints (e.g., mutual exclusivity of data/url), return behavior, or prerequisites. Agents would lack guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), and the description adds value by clarifying that 'data' is base64 and 'url' is a URL, and that only one should be provided. However, it does not explain the other 6 parameters (mentions, replyTo, etc.), leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Send a voice message (PTT)', clearly indicating the action and resource. It specifies the media type (voice/PTT) but does not differentiate from sibling 'whatsapp_send_audio', which could cause confusion. Thus clear but lacks sibling distinction.
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 only advises to 'Provide either data (base64) or url', which is partial parameter guidance. It provides no context on when to use this tool over alternatives like 'whatsapp_send_audio' or 'whatsapp_send_text', nor 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.
Set disappearing messages timer for a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| expiration | Yes | Timer duration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only states the basic mutation, but no side effects, permission requirements, or behavior if the timer is already set are mentioned.
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 is efficient, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool modifies chat state but lacks explanation of immediate effects, confirmation, or how it interacts with existing timers. Given no output schema and no annotations, the description is incomplete for the tool's 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 descriptions for both parameters. The description adds no extra meaning 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?
The description clearly states the verb 'Set' and the resource 'disappearing messages timer for a chat', making the tool's purpose immediately clear. No sibling tool performs this function, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, nor any prerequisites like the chat must exist. It implies usage through the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set presence status in a chat (typing, recording, paused).
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID | |
| state | Yes | Presence state |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects (e.g., notifications triggered, state longevity) or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information. It efficiently communicates the tool's 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?
No output schema exists, and the description omits return values or confirmation of success. For a mutation tool, this is inadequate; an agent needs to know what the tool returns (e.g., boolean, void) or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions (chatId string, state enum). The description adds minimal value beyond listing the enum values already present in 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 sets presence status (typing, recording, paused) in a chat, specifying the verb 'set' and resource 'presence status in a chat'. It distinguishes from sibling tools like whatsapp_set_presence by specifying per-chat context.
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 chat-specific presence but does not explicitly guide when to use this versus alternatives like whatsapp_set_presence for global presence. No prerequisites or caveats are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set community description.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| description | No | New description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits like whether the description is overwritten, effects on existing data, or error conditions. The agent is left uninformed about the tool's 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 extremely concise with a single sentence, which is efficient. However, it sacrifices necessary detail for brevity, resulting in an underspecified but not verbose description.
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 (2 parameters, no output schema, no annotations), the description is incomplete. It fails to explain the effect of the action, required permissions, or what the return value might be, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (id as Community JID, description as New description) with 100% coverage. The description adds no additional meaning or context beyond repeating the tool's purpose, thus providing no 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 states 'Set community description,' which clearly indicates the action and resource. However, it does not differentiate from sibling tools like whatsapp_set_community_name or whatsapp_set_community_picture, missing context on what specifically is being set.
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, such as whether it should be used only after creating a community or if any prerequisites exist. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set community locked mode (only admins can edit info).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| enabled | Yes | Enable or disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It indicates a mutation operation and the effect on editing permissions, but does not mention requirements (e.g., admin rights), reversibility, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, front-loading the key information. Every word contributes meaning, 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?
Given the tool is a simple toggle with fully described parameters, the description is minimally adequate. However, it omits details like required permissions or effect on existing settings. For a simple tool, this is acceptable but not excellent.
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 both parameters (id, enabled) with descriptions. The tool description adds no additional semantic meaning beyond what is in the schema, 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 ('Set'), the resource ('community locked mode'), and the effect ('only admins can edit info'). It effectively distinguishes the tool from sibling tools like set_community_name or set_community_description.
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 (e.g., set_group_locked) or when not to use it. The description lacks context on prerequisites or scenarios for its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set community name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| name | Yes | New name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as whether the operation is reversible, if it requires admin privileges, or what happens if the name is invalid or already taken.
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 redundancy. It is efficient, though slightly terse.
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 simplicity of the tool and the schema coverage, the description is adequate but lacks context about constraints (e.g., name uniqueness) or prerequisites (e.g., community must exist). It could be more complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (id and name). The description adds no additional 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 'Set community name' clearly indicates the action (set) and the resource (community name). It is unambiguous but does not differentiate from sibling tools like 'whatsapp_create_community' which also deals with community names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, it doesn't mention that this tool is for renaming an existing community or that it requires the community to already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set community profile picture.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| data | Yes | Base64-encoded JPEG image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'set', implying mutation, but does not explain if the picture is overwritten, what the expected response is, or how invalid input is handled. This is insufficient for an agent to understand side effects or error states.
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 redundant information. It is front-loaded and efficient, earning its place without any waste.
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 setter tool, the description is minimally complete. However, it lacks information about return values (e.g., success indication) and does not mention that the action may require special permissions. Given the absence of an output schema, some context about the result would be helpful.
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% description coverage, with each parameter clearly documented (Community JID and Base64-encoded JPEG image). The tool description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'community profile picture', making the tool's purpose immediately understandable. However, it does not explicitly differentiate from similar sibling tools like 'whatsapp_set_group_picture', which could cause confusion. The specificity to 'community' helps distinguish it, but explicit differentiation would be better.
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 (e.g., when to use set_group_picture vs set_community_picture). It also fails to mention any prerequisites, such as requiring admin permissions or that the community must exist. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set group announce mode (only admins can send messages).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| enabled | Yes | Enable or disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic effect, omitting side effects, prerequisites (e.g., bot admin status), or what happens when already set. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word is useful, but it could include more context without losing conciseness.
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 having only 2 parameters and no output schema, the description lacks critical context like whether the bot needs admin privileges, the return value, or how this interacts with other group settings. The agent may make errors without this information.
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 parameters are documented. The description adds context that the boolean corresponds to announce mode, but the schema already says 'Enable or disable'. No additional meaning is provided beyond what the schema offers.
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 ('Set') and the resource ('group announce mode') and explains the effect ('only admins can send messages'). This distinguishes it from sibling tools like whatsapp_set_group_locked or whatsapp_set_group_join_approval.
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 vs. alternatives (e.g., other group settings). No mention of prerequisites or conditions, leaving the agent without context to choose correctly among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set group join approval mode (new members require admin approval).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| enabled | Yes | Enable or disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool sets the join approval mode but does not disclose potential side effects, required permissions, or impact on existing join requests.
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 is front-loaded with the verb and resource, containing no extraneous 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 (2 required params, no output schema), the description adequately conveys the purpose. It is complete for a Boolean setter, though could mention the effect on pending requests.
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?
Input schema has 100% coverage with clear descriptions for 'id' (Group JID) and 'enabled' (boolean). The description adds no further meaning beyond the schema, so 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 'Set' and the resource 'group join approval mode', with a parenthetical explanation. It effectively distinguishes from sibling tools like whatsapp_set_group_announce or whatsapp_update_group_requests.
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 or when to avoid, nor mention of alternatives like whatsapp_update_group_requests for pending requests. However, the action is straightforward and the description implies its usage for toggling join approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set group locked mode (only admins can edit info).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| enabled | Yes | Enable or disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It lacks details on reversibility, permissions required, or side effects beyond the basic effect. Minimal 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?
Single sentence, no unnecessary words, perfectly concise and front-loaded with 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?
For a simple boolean toggle tool, the description is adequately complete but could include behavioral notes (e.g., requires admin). No output schema, so returns are implicit.
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 descriptions for both parameters (id and enabled). The description adds no additional 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 clearly states the tool sets group locked mode, specifying the effect 'only admins can edit info.' It uses a specific verb and resource, and distinguishes itself from sibling tools like whatsapp_set_group_announce or whatsapp_set_group_join_approval.
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, such as when to lock versus unlock, or prerequisites like admin permissions. The description only states the action, not context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control whether only admins can add members.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| onlyAdminAdd | Yes | Only admins can add members |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It fails to mention that this tool likely requires admin privileges, what side effects occur (e.g., change in group permissions), or how the system responds to invalid inputs.
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 (one sentence, 5 words) and front-loaded. However, it may be too brief, lacking context that would fit in a short paragraph without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is incomplete. It does not explain the tool's effect on group state, error conditions, or confirmation feedback. For a mutation tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the boolean parameter. The description adds minimal value beyond restating the schema's purpose. It does not provide examples or clarify edge cases (e.g., default behavior).
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 'control' and the specific resource 'whether only admins can add members.' It distinguishes this tool from sibling tools like whatsapp_set_group_announce or whatsapp_set_group_locked by focusing on the member add permission.
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 (e.g., other group settings). It does not mention prerequisites (like admin rights) or situations where this should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set group profile picture.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| data | Yes | Base64-encoded JPEG image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must compensate. It only states the action without disclosing side effects, authorization requirements, or constraints (e.g., image format or size limits). The description adds minimal 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 concise sentence with no wasted words. The verb 'Set' is front-loaded, making the action immediately 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 the lack of annotations and output schema, the description should provide more operational context (e.g., permissions, side effects, or prerequisites). It is too sparse to fully inform an agent's decision.
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 describes both parameters (id and data) with 100% coverage. The description does not add any additional meaning or clarification beyond the schema, so it meets the baseline expectation.
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 ('Set') and the resource ('group profile picture'), making the tool's purpose unambiguous. It effectively distinguishes from sibling tools like 'whatsapp_set_community_picture' or other group settings.
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. For instance, it doesn't mention that the user needs admin permissions or that this replaces the current picture. With many sibling tools, such context is essential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe or unsubscribe from a newsletter.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Newsletter JID | |
| subscribed | Yes | True to subscribe, false to unsubscribe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action (subscribe/unsubscribe) without disclosing behavioral traits like reversibility, permissions required, or error handling (e.g., what happens if the newsletter ID is invalid).
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 sentence, no wasted words. Information is front-loaded and immediately actionable.
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 is minimally adequate. However, it lacks context about side effects (e.g., notifications) or failure scenarios, which a more complete description would include.
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 parameters have descriptions). The tool description does not add any meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('subscribe or unsubscribe') and clearly identifies the resource ('newsletter'). It distinguishes this tool from siblings like 'whatsapp_create_newsletter', 'whatsapp_get_newsletter', and 'whatsapp_mute_newsletter'.
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 does not mention prerequisites (e.g., needing a newsletter ID from 'whatsapp_get_newsletter' or 'whatsapp_list_newsletters'), nor does it specify when not to use it (e.g., if already subscribed/unsubscribed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set account presence state (available or unavailable).
| Name | Required | Description | Default |
|---|---|---|---|
| presence | Yes | Presence state |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether this affects notifications, requires authentication, or has rate limits. For a mutating tool, more transparency is needed.
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 unnecessary words. It is appropriately sized for a simple 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?
Given no output schema, no annotations, and a simple parameter, the description is minimal. It lacks context on the impact of setting presence, such as whether it overrides chat-specific presence or affects visibility to contacts.
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 properly described enum parameter. However, the description adds no additional meaning beyond what the schema already provides—it merely restates the enum values without context or usage notes.
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 'Set' and the resource 'account presence state' with the two possible values 'available or unavailable'. It is specific and distinguishes from sibling tools like whatsapp_set_chat_presence.
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 such as settinsg chat-specific presence or subscribing to presence. The description does not mention any context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a single privacy setting.
| Name | Required | Description | Default |
|---|---|---|---|
| setting | Yes | Privacy setting to update | |
| value | Yes | Privacy level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It merely says 'Update a single privacy setting' without mentioning effects, required permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail. It is not overly long, but could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about the mutation's implications. It fails to mention permissions, that settings are applied immediately, or any constraints on values per setting.
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 descriptions on both parameters. The tool description adds no additional semantic value beyond the schema, so 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 ('Update') and the resource ('privacy setting'). The tool name also helps differentiate, though no explicit sibling comparison is provided.
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 (e.g., whatsapp_get_privacy_settings to read). No context on prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Star or unstar a message.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | Message ID | |
| chatId | Yes | Chat JID | |
| senderId | Yes | Message sender JID | |
| starred | No | True to star, false to unstar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It does not explain the effect of starring (e.g., placing in a starred folder), permissions required, or whether the action is idempotent.
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 efficiently communicates the tool's purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description could still explain the concept of starring and its effects. The current description is too minimal for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for each parameter. The description adds no extra meaning beyond what is in the schema, so 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 'Star or unstar a message.' clearly states the action (star/unstar) and the resource (message), distinguishing it from sibling tools like whatsapp_pin_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?
No guidance is provided on when to star versus other actions (e.g., pin, mark as read) or any prerequisites. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to presence updates for a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| chatId | Yes | Chat JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose side effects: whether subscription persists, triggers events, or requires specific permissions. The term 'subscribe' implies ongoing behavior but no details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the core action without waste. However, given the lack of additional context, it might be too brief; a slightly longer description could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter but no output schema. The description does not mention the return value, such as a subscription ID or confirmation, nor the start of a stream. An agent would need more context 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 coverage is 100% for the single parameter 'chatId', so the description adds no additional meaning beyond the schema's 'Chat JID'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'subscribe' and resource 'presence updates for a chat', clearly indicating the action. It distinguishes from sibling tools like 'whatsapp_set_chat_presence' which sets rather than subscribes. However, it could be more specific about what 'presence updates' means.
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 such as 'whatsapp_set_presence' or 'whatsapp_get_chat'. There are no contextual hints about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a full contact sync from the WhatsApp server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'trigger a full contact sync' without mentioning potential side effects, such as overwriting local contacts, sync duration, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words. The purpose is immediately 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?
For a zero-parameter, simple tool, the description is adequate but could mention whether the sync is asynchronous, or if it requires network connectivity. Lacks any notes on output or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds value by confirming the tool requires no input. Schema coverage is 100%, meeting the baseline for empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (trigger) and resource (full contact sync from WhatsApp server), clearly distinguishing it from siblings like get_contacts or create_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?
No guidance on when to use this tool versus alternatives (e.g., get_contacts) or any prerequisites. The description lacks context for typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unblock a contact.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Contact JID to unblock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or state changes. It only states 'Unblock a contact' with no mention of what happens if the contact is already unblocked, whether it affects chat visibility, or any required authentication.
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, using a single sentence. While it lacks detail, it is not verbose and front-loads the core 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?
For a simple one-parameter tool with no output schema, the description is minimally adequate. However, it could mention that it reverses a block or that the contact must be blocked first, given the presence of a sibling block 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 input schema has 100% coverage for the single parameter 'id' with a clear description. The tool description adds no extra meaning beyond the schema, meeting the baseline threshold.
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 ('Unblock') and the resource ('a contact'), directly contrasting with the sibling tool 'whatsapp_block_contact'. It is 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 is provided on when to use this tool versus alternatives, such as when a contact is already unblocked or prerequisites like having the contact's JID. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlink a group from a community.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| groupId | Yes | Group JID to unlink |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action but does not mention permissions required, whether the operation is reversible, side effects on the group or community, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded. It contains no extraneous information, though a slightly more structured format (e.g., bullet points) could improve readability.
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 is minimally adequate. However, it lacks details on expected outcomes, error conditions, or examples, which would be helpful given the absence of 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?
Schema description coverage is 100% with descriptions for both parameters ('Community JID', 'Group JID to unlink'). The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unlink a group from a community' clearly states the action (unlink), the target (group), and the context (community). It directly corresponds to the tool name and distinguishes it from related sibling tools like 'whatsapp_link_group_to_community'.
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 (e.g., 'whatsapp_leave_group'), no prerequisites (e.g., must be admin, group must be linked), and no explicit 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove, promote, or demote community participants.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Community JID | |
| participants | Yes | Participant JIDs | |
| action | Yes | Action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description lists the four possible actions, providing core behavioral transparency. However, it does not mention side effects, permission requirements, or response behavior, which would be needed for full 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?
A single concise sentence that conveys the tool's function without unnecessary words. Could be slightly more structured but effective.
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 adequately lists the possible actions but does not explain what the tool returns or any post-conditions. For a mutation tool with no output schema, this leaves the agent uncertain about the result of 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 coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it merely restates the action enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the actions (add, remove, promote, demote) on community participants, distinguishing it from read-only sibling like whatsapp_get_community_participants and group-focused tools like whatsapp_update_group_participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines on when to use this tool versus alternatives (e.g., when to manage community vs group participants). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update group description.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| description | No | New group description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details such as permissions needed, side effects, or error conditions. For an update tool, this is insufficient.
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?
Very concise (3 words), but lacks structure and detail. While brevity is good, it sacrifices 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?
No output schema and no annotations. The description does not mention return values, success indicators, or error handling. For a mutation tool, this is incomplete.
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 adds no additional meaning beyond the schema's parameter descriptions. It does not clarify expected format or constraints for 'description'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (update) and the resource (group description). Distinguishes from sibling tools like 'whatsapp_update_group_name' and 'whatsapp_set_group_announce'.
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 vs alternatives. Does not mention prerequisites (e.g., admin rights) or context (e.g., only works for groups you belong to).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update group name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| name | Yes | New group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Update group name' without detailing side effects, required permissions, failure modes, or any impact on other state, which is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is very concise but lacks detail. It is not verbose, but it could benefit from slightly more context (e.g., 'Changes the name of an existing WhatsApp group'). It is functional but minimal.
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 absence of output schema, annotations, and the presence of many sibling tools, the description is incomplete. It does not explain return behavior, error scenarios, or prerequisites, leaving out crucial context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters ('Group JID' and 'New group name'). The description adds no additional semantics beyond what the schema already provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update group name' is extremely clear: it specifies the action (update) and the resource (group name). It distinguishes well from sibling tools like whatsapp_update_group_description and whatsapp_set_group_picture, which target different aspects of a group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., being an admin) or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove, promote, or demote group participants.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| participants | Yes | Participant JIDs | |
| action | Yes | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only lists actions without disclosing permissions, side effects, or limitations. It does not mention important behavioral traits like rate limits or required admin status.
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 unnecessary words, but it lacks structure (e.g., bullet points) that could improve readability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three required parameters and no output schema, the description is adequate but incomplete—it does not explain return behavior, error conditions, or prerequisites like group membership.
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 complete descriptions for all three parameters (100% coverage). The description adds no additional meaning beyond the schema, 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 specifies the actions (add, remove, promote, demote) and resource (group participants), distinguishing it from sibling tools like create_group or get_group_participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying participants but provides no explicit guidance on when to use this tool versus alternatives such as update_group_requests or 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.
Approve or reject pending join requests.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Group JID | |
| participants | Yes | Participant JIDs | |
| action | Yes | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action but omits details like permissions required (admin), that requests are removed after action, error conditions, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficient but arguably too terse, lacking detail that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description should provide more context about the workflow (e.g., that participants must be from pending requests, typical admin usage, success effects). It is incomplete for an agent to use autonomously.
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 descriptions for each parameter, so the baseline is 3. The tool description adds no extra meaning beyond the schema; it just restates the action. Parameters are already well-documented in 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 verb 'Approve or reject' and the resource 'pending join requests', which is specific and distinguishes it from sibling tools like whatsapp_get_group_requests (which retrieves) and whatsapp_set_group_join_approval (which sets mode).
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 given on when to use this tool versus alternatives, such as first retrieving pending requests with whatsapp_get_group_requests, or prerequisites like being a group admin. The agent is left to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update own WhatsApp profile. All fields are optional.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name | |
| status | No | Status text | |
| picture | No | Base64-encoded JPEG profile picture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'update', implying mutation, but fails to mention side effects, data constraints (e.g., picture size limits), or whether changes are immediate. For a mutation tool with no annotations, this is insufficient.
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, direct sentences with no unnecessary information. Highly concise 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?
Given the simplicity of the tool (3 optional parameters, no output schema), the description is adequate for basic use. However, it lacks behavioral details like what happens to fields not specified, and the absence of any output schema leaves the agent guessing about the response. Compared to the calibration example for update_drive (score 2), this is slightly better because all parameters are documented, but still not 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 already describes each parameter thoroughly (display name, status text, base64 JPEG picture). The description adds no extra meaning beyond stating 'all fields are optional', which is redundant given the schema has no required 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 uses the specific verb 'Update' and explicitly states the resource 'own WhatsApp profile'. It clearly distinguishes from sibling tools like whatsapp_get_my_profile and other update tools for groups/communities.
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 clarifies that all fields are optional, which helps an agent understand it can update any subset. However, it does not specify when to use this versus similar update tools like whatsapp_set_privacy_setting, nor does it mention prerequisites beyond the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With 101 tools, many have overlapping purposes (e.g., send vs. post status, multiple get/set/update tools for similar entities). While descriptions help, the sheer number creates high ambiguity, making it difficult for an agent to select the correct tool consistently.
All tools follow a strict 'whatsapp_verb_noun' pattern with consistent verb usage (get, set, send, create, delete, update). No mixed conventions (e.g., camelCase or snake_case variations). Naming is highly predictable and well-structured.
101 tools is excessive for a WhatsApp API server. The scope is reasonable, but the number far exceeds typical MCP servers (3-15 tools). Many tools are highly specialized (e.g., flush_history, subscribe_chat_presence), leading to agent decision fatigue and likely misinterpretation.
The tool set covers the full lifecycle of WhatsApp interactions: messaging, media, groups, communities, newsletters, contacts, profiles, privacy, sessions, and administration. No obvious gaps for the domain; it provides comprehensive CRUD and action capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run WhatsApp Business campaigns from any AI assistant: contacts, segments, and broadcasts.
WhatsApp CRM for AI agents: search contacts, read chats, manage the sales pipeline, send messages.
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
Give your AI agents a real WhatsApp number to send and receive messages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wsapi-chat/wsapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
