WAHA MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as waha_send_message for text versus waha_send_media for files. However, some overlap exists, like waha_get_chat_picture and waha_get_contact_profile_picture, which could cause minor confusion in selection, but descriptions help clarify the target (chat vs. contact).
Naming Consistency5/5
All tool names follow a consistent waha_verb_noun pattern, using snake_case throughout. This predictability makes it easy for agents to understand and navigate the toolset without naming conflicts or style variations.
Tool Count2/5
With 52 tools, the count is excessive for a WhatsApp automation server, leading to potential overwhelm and redundancy. A more focused set of 15-25 tools would better cover the domain without unnecessary complexity, as many operations could be consolidated (e.g., multiple group admin tools).
Completeness5/5
The toolset provides comprehensive coverage for WhatsApp interactions, including CRUD operations for chats, groups, contacts, and messages, along with advanced features like presence management and media handling. No obvious gaps are present, ensuring agents can handle full workflows without dead ends.
Average 3.2/5 across 52 of 52 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't specify whether this requires admin permissions, whether the invite code is reusable or time-limited, what format the link returns in, or if there are any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Get group invite link'), with zero wasted language. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the invite link returns in (URL, code, expiration details), whether special permissions are needed, or how this differs from related group tools. Given the complexity of group management operations and the lack of structured documentation elsewhere, the description should provide more contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'groupId' clearly documented as 'Group ID (format: number@g.us)'. The description doesn't add any additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get group invite link' clearly states the verb ('Get') and resource ('group invite link'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'waha_revoke_group_invite_code' or 'waha_get_group_info', which could cause confusion about when to use this specific tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'waha_revoke_group_invite_code' (which likely removes invite codes) and 'waha_get_group_info' (which might include invite information), there's no indication of when this specific 'get' operation is appropriate versus other group-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action without behavioral details. It doesn't disclose whether this requires admin permissions, affects group visibility, has rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the essential action and target, though this brevity comes at the cost of completeness. Every word earns its place by directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and 2 required parameters, the description is incomplete. It doesn't explain what the tool returns, error conditions, permissions needed, or how it differs from similar group management tools. The 100% schema coverage helps with parameters but doesn't compensate for other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond what the schema provides about 'groupId' and 'description'. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update group description' clearly states the action (update) and target (group description), but it's vague about scope and doesn't differentiate from sibling tools like 'waha_update_group_subject' or 'waha_set_group_info_admin_only'. It specifies what resource is modified but lacks detail about what aspect of the group is affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_update_group_subject' or 'waha_set_group_info_admin_only'. The description doesn't mention prerequisites, permissions, or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the effect ('Archived chats are hidden from the main chat list') but doesn't mention whether this action is reversible (though 'waha_unarchive_chat' exists as a sibling), requires specific permissions, has side effects, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the action and its effect. Every word earns its place, and it's front-loaded with the core purpose, making it efficient and easy to parse without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like reversibility, permissions, error conditions, or response format. While the schema covers the single parameter well, the overall context for safe and effective use is insufficient given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'chatId' fully documented in the schema as 'Chat ID (format: number@c.us)'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive a chat') and the resource ('chat'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_delete_chat' by specifying the effect ('hidden from the main chat list') rather than deletion. However, it doesn't explicitly contrast with 'waha_unarchive_chat' or other chat management tools, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_delete_chat' or 'waha_unarchive_chat'. The description mentions the outcome ('hidden from the main chat list') but doesn't specify use cases, prerequisites, or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action without disclosing behavioral traits. It doesn't mention whether blocking is reversible, what permissions are required, how it affects chat functionality, or what happens to existing messages. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's appropriately sized for a simple action and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the consequences of blocking, potential errors, or what the tool returns. Given the complexity of a blocking operation in a messaging context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'contactId' parameter with its format. The description doesn't add any meaning beyond what the schema provides, such as explaining where to find the contactId or what happens if an invalid ID is provided. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Block') and resource ('a contact'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'waha_unblock_contact' or explain what 'blocking' means in this context (e.g., preventing messages from that contact).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'waha_unblock_contact' or other contact management tools. The description lacks context about prerequisites (e.g., the contact must exist) or typical use cases for blocking contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks registration status but doesn't reveal critical traits: whether it's a read-only operation, potential rate limits, authentication requirements, error handling (e.g., for invalid numbers), or what the output looks like (e.g., boolean or detailed response). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return value (e.g., true/false or error messages), behavioral aspects like safety or performance, or usage context. Given the complexity of checking WhatsApp registration, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'phone' parameter clearly documented. The description adds no additional parameter details beyond the schema, such as format constraints (e.g., international prefix) or examples. Given the high schema coverage, the baseline score of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if phone number is registered on WhatsApp.' It specifies the verb ('check') and resource ('phone number'), making the function unambiguous. However, it doesn't explicitly differentiate from siblings like 'waha_get_contact' or 'waha_get_all_contacts', which might also involve contact verification, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a WhatsApp account), exclusions, or compare it to sibling tools like 'waha_get_contact' for more detailed contact info. This lack of context leaves the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a group but fails to mention critical behavioral aspects: required permissions (e.g., admin rights), side effects (e.g., notifications to participants), error conditions (e.g., invalid participant format), or what happens on success (e.g., returns group ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core action ('Create a new WhatsApp group') and avoids unnecessary elaboration. This efficiency makes it easy for an agent to parse and understand the tool's purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a mutation (creating a group) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), error handling, and return values. While the schema covers parameters, the overall context is insufficient for safe and effective use by an AI agent, especially given the complexity of group creation in messaging platforms.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('name' and 'participants') documented in the schema. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints (e.g., name length limits, participant validation rules). Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new WhatsApp group'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_join_group' or 'waha_update_group_subject' by specifying creation rather than modification or joining. However, it doesn't explicitly contrast with all siblings, such as 'waha_get_groups' (read vs. write), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin rights or valid participants), exclusions (e.g., not for updating existing groups), or direct comparisons to siblings like 'waha_join_group' for joining existing groups. This lack of contextual advice leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove' implies a destructive mutation, but it doesn't specify whether this requires admin permissions, if the action is reversible, what error conditions might occur, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like permission requirements, side effects, error handling, or response format. For a tool that modifies group state, more behavioral details are needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'groupId' documented as 'Group ID (format: number@g.us)'. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and resource ('group profile picture'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'waha_set_group_picture' (which sets the picture) and 'waha_get_group_picture' (which retrieves it). However, it doesn't explicitly mention that this is a WhatsApp-related operation, though the 'waha_' prefix provides some context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), when deletion is appropriate, or what happens after removal (e.g., reverts to default). With sibling tools like 'waha_set_group_picture' available, explicit differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions 'pagination' without details on rate limits, permissions, or response format. It doesn't disclose whether this is a read-only operation, what happens on errors, or if it requires authentication, which is inadequate for a tool with potential data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all contacts') and includes a key behavioral trait ('with pagination'). There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on return values, error handling, authentication needs, or how pagination works in practice, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying pagination through 'limit' and 'offset', which is already clear from the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all contacts') and resource ('contacts'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'waha_get_contact' (singular) or 'waha_get_chats', which suggests it could be more specific about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_get_contact' or 'waha_check_contact_exists'. There's no mention of prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, requires specific permissions, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'about/status text' means in this context, what format it returns (e.g., plain text, structured object), or any prerequisites. Given the lack of structured data elsewhere, the description should provide more context about the operation and its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). The schema fully documents the single required 'contactId' parameter with its format. Since schema coverage is high, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('contact's about/status text'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'waha_get_contact' or 'waha_get_contact_profile_picture' that also retrieve contact information but different attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'waha_get_contact' (which might return broader contact info) or 'waha_get_presence' (which might include status). The description assumes the user knows they specifically need the 'about/status text' without explaining its relationship to other contact data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool retrieves a URL but doesn't disclose behavioral traits such as whether it requires specific permissions, if it's cached (implied by the 'refresh' parameter but not explained), rate limits, or what happens if the contact has no picture. This leaves significant gaps for an agent to understand the operation fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the core purpose. There is no wasted language, and it efficiently communicates the essential action without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that retrieves data (with no output schema) and no annotations, the description is incomplete. It doesn't explain the return value (e.g., URL format, error cases), behavioral aspects like caching or permissions, or how it differs from sibling tools. This leaves the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('contactId' and 'refresh') with descriptions. The description adds no additional meaning beyond what's in the schema, such as explaining the format of the URL returned or the implications of the 'refresh' parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'contact's profile picture URL', making the purpose specific and understandable. However, it doesn't distinguish this tool from similar siblings like 'waha_get_chat_picture' or 'waha_get_group_picture', which also retrieve profile pictures but for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 example, it doesn't mention when to use 'waha_get_contact' (which might include profile info) or 'waha_get_chat_picture' versus this tool. The description lacks 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.
Behavior2/5
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 it 'gets' information without disclosing behavioral traits like read-only nature, potential rate limits, authentication needs, or what 'detailed information' entails. It's minimal and leaves critical aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get detailed information'). There's no wasted verbiage, making it appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'detailed information' includes, potential errors, or behavioral constraints, leaving gaps for a tool that likely returns structured data about groups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'groupId' parameter with its format. The description adds no additional meaning beyond implying it's for a 'specific group', which aligns with the schema but doesn't provide extra context like examples or usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('detailed information about a specific group'), making the purpose understandable. It distinguishes from siblings like 'waha_get_groups' (which lists groups) by focusing on a single group, though it doesn't explicitly name this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_get_groups' or 'waha_get_group_participants'. The description implies usage for a specific group but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it 'lists' members without disclosing behavioral traits. It doesn't mention whether this requires specific permissions, rate limits, pagination behavior, or what format the output takes (e.g., list of contacts with details). For a read operation with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too minimal. It doesn't explain what 'members' means (e.g., are they contacts with specific attributes?), doesn't mention potential limitations or errors, and provides no context about the return format. Given the lack of structured data, more descriptive content would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'groupId' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the structured schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all members') and resource ('in a group'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_get_group_info' or 'waha_get_groups' by focusing specifically on participants, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While the name implies it's for retrieving group participants, there's no mention of prerequisites, limitations, or comparison to similar tools like 'waha_get_group_info' which might also provide participant data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'filtering and pagination options' but doesn't disclose key behaviors: whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like (e.g., list of objects with fields). For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all groups') and adds essential qualifiers ('with filtering and pagination options'). There's zero waste—every word contributes to understanding the tool's scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like safety (read-only vs. destructive), authentication needs, or output structure, which are critical for an agent to use it correctly. While concise, it lacks the depth needed for a tool with multiple options and no structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds minimal value beyond implying filtering (via 'exclude' parameter) and pagination (via 'limit'/'offset'), but doesn't explain semantics like what 'exclude' fields are available or default behaviors. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all groups') and resource ('groups'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_get_group_info' (single group details) and 'waha_get_groups_count' (count only) by emphasizing comprehensive listing with filtering/pagination. However, it doesn't explicitly contrast with 'waha_get_chats' which might also list group chats, leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when filtering/pagination is needed, nor does it reference sibling tools like 'waha_get_group_info' for single group details or 'waha_get_groups_count' for just a count. Without this context, an agent might misuse it for simpler tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action. It doesn't disclose behavioral traits such as whether joining requires authentication, if it's idempotent (e.g., joining an already-joined group), potential rate limits, error conditions (e.g., invalid code), or what happens on success (e.g., group added to chats).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized for a simple tool with one parameter and is front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It lacks details on behavioral context (e.g., side effects, error handling) and what the tool returns, leaving gaps that could hinder an AI agent's correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'code' parameter with examples. The description adds no additional meaning beyond implying the parameter is required for joining, which is already clear from the schema's required field. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Join') and resource ('a group'), specifying it uses 'invite code/link'. It distinguishes from siblings like 'waha_create_group' (creating new groups) and 'waha_leave_group' (leaving groups), but doesn't explicitly contrast with other group-related tools like 'waha_get_group_invite_code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention prerequisites (e.g., needing an invite code), exclusions (e.g., cannot join if already a member), or when to choose other tools like 'waha_create_group' for new groups or 'waha_get_group_invite_code' to obtain codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Leave') which implies a mutation, but doesn't disclose any behavioral traits: no mention of permissions required, whether the action is reversible, rate limits, error conditions, or what happens upon success. This leaves critical gaps for an agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the core action and resource with zero wasted words. Every element earns its place, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what happens after leaving (success indicators, error responses), doesn't mention side effects, and provides no behavioral context. The agent would be left guessing about important aspects of tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'groupId' fully documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Leave') and resource ('a group'), making the purpose immediately understandable. It distinguishes itself from siblings like 'waha_remove_group_participants' (which removes others) and 'waha_join_group' (the opposite action), though this differentiation isn't explicitly stated in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to be a member first), consequences (e.g., losing access to group messages), or when to choose this over similar tools like 'waha_remove_group_participants' for self-removal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits like whether this is a mutation (implied by 'Mark'), if it requires specific permissions, what happens on failure, or if there are side effects like notifications. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and has zero wasted words. It efficiently conveys the purpose without redundancy or unnecessary detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It doesn't explain what the tool returns (e.g., success/failure status), error conditions, or behavioral nuances. For a tool that likely alters chat state, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'chatId' fully documented in the schema. The description adds no additional meaning about the parameter beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark a chat as unread') and the effect ('adds an unread indicator to the chat'), which is specific and unambiguous. However, it doesn't explicitly differentiate from its sibling 'waha_mark_chat_read', though the naming makes the distinction obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_mark_chat_read' or other chat management tools. It lacks context about prerequisites, such as whether the chat must exist or be accessible, or any constraints on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and effect but omits critical details: whether pinning requires specific permissions (e.g., admin rights in groups), if it's reversible (implied by 'waha_unpin_message' sibling), rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the core purpose and effect without any wasted words. It is front-loaded with the main action, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (pinning messages) with no annotations and no output schema, the description is incomplete. It lacks information on permissions, side effects, error handling, and return values, which are crucial for safe and effective tool invocation. The schema covers parameters well, but behavioral aspects are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the input schema (e.g., 'Chat ID (format: number@c.us)', 'Pin duration in seconds (default: 86400 = 24 hours)'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pin a message') and resource ('in a chat'), with a brief explanation of the effect ('Pinned messages appear at the top of the chat'). It distinguishes from siblings like 'waha_unpin_message' by specifying the opposite action, though not explicitly. However, it lacks explicit sibling differentiation, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing admin rights in a group chat), exclusions, or comparisons to similar tools like 'waha_star_message' (which might bookmark rather than pin). Without such context, the agent lacks clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions the two input methods (URL or base64) but doesn't disclose important behaviors like: whether this is a synchronous or asynchronous operation, what happens if the audio file is too large, whether there are rate limits, what permissions are required, or what the typical response looks like. 'Send' implies a write operation, but no safety warnings or side effects are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The first sentence states the core purpose, the second adds technical detail about input methods. However, it could be more front-loaded by mentioning the exclusive choice between fileUrl and fileData upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after sending (success/failure indicators), doesn't mention authentication requirements, doesn't warn about potential side effects (like message delivery notifications), and provides no context about WhatsApp-specific constraints. The description leaves too many behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions URL or base64 options (implied by fileUrl/fileData parameters) and specifies 'audio/voice messages' (implied by mimetype). No additional semantic context about parameter relationships or usage patterns is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send audio/voice messages') and target ('to a WhatsApp chat'), with specific media type mentioned. It distinguishes from generic 'send_media' by focusing on audio, but doesn't explicitly differentiate from other messaging tools like 'send_message'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'send_media' or 'send_message'. The description mentions support for URL or base64 data, but this is technical implementation detail rather than usage context. No mention of prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'send' implies a write operation, it doesn't disclose whether this requires specific permissions, whether it's synchronous/asynchronous, what happens on failure, or any rate limits. The description lacks crucial behavioral context for a messaging operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a straightforward tool and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a messaging tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after sending (success/failure indicators), whether the location appears as a map preview, or any WhatsApp-specific behaviors. Given the complexity of messaging operations and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send location coordinates') and target ('to a WhatsApp chat'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like waha_send_message or waha_send_contact, which also send content to WhatsApp chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when location sending is appropriate versus sending text messages, media, or contacts, nor any prerequisites or exclusions for using this functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions support for URL or base64 data but doesn't disclose file size limits, rate limits, authentication requirements, error handling, or what happens on success (e.g., returns message ID). For a media-sending tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying media types and input methods concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error cases, or behavioral constraints, leaving the agent with insufficient context to use the tool effectively beyond basic parameter filling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds minimal value by mentioning URL or base64 support, which aligns with fileUrl and fileData parameters but doesn't provide additional context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send media files') and target ('to a WhatsApp chat'), specifying supported media types and input methods. It distinguishes from sibling tools like waha_send_message by focusing on media rather than text, though it doesn't explicitly contrast with waha_send_audio which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 waha_send_message or waha_send_audio, nor does it mention prerequisites, error conditions, or typical use cases. It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions the return values (message ID and delivery timestamp), but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or whether the message is sent immediately/asynchronously. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste—first states the action, second states the return. It's appropriately sized and front-loaded with the core purpose. Could be slightly improved by integrating return info into first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about permissions required, side effects (e.g., chat updates), error handling, and behavioral constraints. The return values are mentioned but not detailed (e.g., format of timestamp).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format details for chatId beyond '@c.us', character limits for text). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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') and target ('to a WhatsApp chat'), making the purpose immediately understandable. It distinguishes from siblings like waha_send_audio or waha_send_media by specifying 'text message', but doesn't explicitly differentiate from all messaging siblings (e.g., waha_edit_message).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 waha_send_media for non-text content, waha_edit_message for corrections, or waha_react_to_message for reactions. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Set or update group profile picture,' implying a mutation operation, but doesn't disclose critical behaviors: whether it requires admin permissions, what happens to the existing picture, if there are file size/format constraints, or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Set or update group profile picture.') that front-loads the core purpose with zero wasted words. It immediately conveys the action and resource without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on permissions, side effects, error handling, and what the tool returns (e.g., success confirmation or error). Given the complexity of modifying group settings in a messaging platform, more context is needed to use this tool effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three parameters (groupId, fileUrl, fileData). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the mutual exclusivity of fileUrl and fileData or format requirements. Given the high schema coverage, the baseline score of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set or update') and resource ('group profile picture'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'waha_delete_group_picture' and 'waha_get_group_picture' by focusing on modification rather than deletion or retrieval. However, it doesn't explicitly differentiate from other group-related tools like 'waha_update_group_subject' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., admin permissions), when not to use it, or how it relates to similar tools like 'waha_update_group_subject' for other group attributes. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is to 'set' presence, implying a mutation, but doesn't disclose effects (e.g., whether it's visible to others, requires specific permissions, or has rate limits). No information on error conditions or response format is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and enumerates the possible presence values. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, permissions), error handling, and what the tool returns. Given the complexity of setting presence in a chat context, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (chatId format, presence enum values). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the context of 'chatId' or nuances of presence states. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set your own presence status') and specifies the resource (presence status with specific values: online, offline, typing, recording, or paused). It distinguishes from siblings like 'waha_get_presence' by indicating it's a setter, but doesn't explicitly differentiate from other presence-related tools like 'waha_subscribe_presence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid chatId), exclusions, or compare it to similar tools like 'waha_get_presence' or 'waha_subscribe_presence'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action but doesn't mention permissions required, side effects (e.g., whether starring is visible to others), error conditions, or what happens on success/failure. For a mutation tool, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or response format. Given the complexity of modifying message states, more context is needed to help the agent use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (chatId, messageId, star). The description doesn't add any semantic context beyond what's in the schema (e.g., format details or usage examples), so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('star or unstar') and resource ('a message'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'waha_pin_message' or 'waha_react_to_message', which are related message interaction tools, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing chat and message IDs), compare to similar tools like 'waha_pin_message', or specify use cases for starring vs. unstarring. This leaves the agent with minimal 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Subscribe to presence updates,' implying a continuous or event-driven operation, but fails to specify whether this is a long-running connection, how updates are delivered (e.g., via callbacks or streams), what happens on errors, or if there are rate limits. This leaves critical behavioral aspects unclear for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action ('Subscribe to presence updates') and specifies the target ('for a chat'), making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a subscription tool (which likely involves ongoing updates or event handling), the description is insufficient. No annotations are provided to clarify behavior, and there's no output schema to indicate what the tool returns (e.g., a subscription ID, confirmation, or error). This leaves the agent with significant gaps in understanding how to invoke and handle this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'chatId' clearly documented as 'Chat ID (format: number@c.us)'. The description doesn't add any additional meaning beyond this, such as examples or constraints on valid chat IDs. With high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Subscribe to') and resource ('presence updates for a chat'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'waha_get_presence' or 'waha_get_all_presence', which appear to be read operations rather than subscription-based ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'waha_get_presence' or 'waha_get_all_presence'. There's no mention of prerequisites, such as needing an active connection or specific permissions, or when this subscription might be preferable to one-time presence checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 action. It doesn't disclose behavioral traits such as whether this requires specific permissions, if it's reversible, what happens on success/failure, or any rate limits. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately front-loaded and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after unpinning (e.g., success response, error cases), doesn't mention dependencies (message must be pinned), and provides no behavioral context. The tool name and description suggest it modifies chat state, but crucial details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (chatId and messageId) with their formats. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unpin') and resource ('a message in a chat'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'waha_pin_message' beyond the obvious opposite action, missing an opportunity to clarify the relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While the action is straightforward (unpinning), there's no mention of prerequisites (e.g., the message must be pinned first), error conditions, or contextual constraints like chat type limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Change' implies a mutation operation, but it doesn't specify whether this requires admin permissions, if changes are reversible, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format. While the schema covers parameters well, the overall context for safe and effective use is insufficient for a tool that modifies group data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (groupId and subject). The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the target resource ('group name/subject'), making the purpose immediately understandable. It distinguishes this from sibling tools like waha_create_group or waha_update_group_description by focusing specifically on the group subject/name. However, it doesn't specify that this is for WhatsApp groups (though implied by context), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), when not to use it, or how it differs from related tools like waha_set_group_info_admin_only or waha_update_group_description. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get contact information' but doesn't disclose behavioral traits such as required permissions, rate limits, error handling (e.g., for invalid IDs), or what 'contact information' includes (e.g., name, phone). For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get contact information by ID.' It is front-loaded with the core action and resource, with zero wasted words. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on return values (what 'contact information' entails) and behavioral context. For a basic retrieval tool, it meets the bare minimum but leaves room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'contactId' documented as 'Contact ID (format: number@c.us)'. The description adds no additional meaning beyond this, as it only repeats 'by ID' without elaborating on format or constraints. With high schema coverage, the baseline is 3, and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get contact information by ID' clearly states the verb 'Get' and resource 'contact information', specifying retrieval by ID. It distinguishes from siblings like 'waha_get_all_contacts' (which lists all contacts) and 'waha_check_contact_exists' (which verifies existence without returning details), though it doesn't explicitly mention these distinctions. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid contact ID), exclusions (e.g., not for bulk retrieval), or direct comparisons to siblings like 'waha_get_all_contacts' or 'waha_check_contact_exists'. Usage is implied by the name and description alone, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it retrieves a URL but doesn't disclose what happens if the group has no picture (returns null/error?), authentication requirements, rate limits, or whether it's a read-only operation (implied by 'Get' but not explicit). The description adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It directly states the tool's purpose without unnecessary elaboration, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no output schema and no annotations, the description is minimally adequate. It covers the basic purpose but lacks details on return format (e.g., URL structure, error cases) and behavioral context. Given the low complexity, it's passable but leaves gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add any meaning beyond what's in the schema (e.g., doesn't explain format of the URL returned or when to use refresh). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('group profile picture URL'), making the purpose immediately understandable. It distinguishes itself from siblings like waha_get_chat_picture (for individual chats) and waha_set_group_picture (for setting pictures), though it doesn't explicitly mention these distinctions in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing group ID), when to use refresh parameter, or how it differs from similar tools like waha_get_group_info (which might include picture info). Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Unblock a contact' implies a mutation operation, but it doesn't specify permissions required, side effects (e.g., if the contact can message again), or error conditions (e.g., if the contact isn't blocked). This leaves significant gaps for an agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Unblock a contact.') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., reversibility, auth needs), usage context, and expected outcomes. For a tool that modifies contact status, more information is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'contactId' clearly documented as 'Contact ID to unblock (format: number@c.us)'. The description doesn't add parameter details beyond the schema, but with high coverage and only one parameter, a baseline of 4 is appropriate as the schema adequately explains the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unblock a contact' clearly states the verb ('unblock') and resource ('a contact'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_block_contact' by indicating the opposite action. However, it lacks specificity about what 'unblock' entails in this context (e.g., removing from a blocked list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the contact must be blocked first), exclusions, or related tools like 'waha_block_contact' for context. Usage is implied from the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the admin privilege requirement, which is useful context, but fails to describe other critical behaviors such as whether the operation is idempotent, what happens if participants already exist in the group, error conditions, or the response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that are front-loaded with the core action and a key prerequisite. Every word earns its place, with no redundant or unnecessary information, making it efficient and easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficiently complete. It lacks details on behavioral outcomes (e.g., success/failure responses, side effects), error handling, and how it integrates with sibling tools like 'waha_get_group_participants' for verification. For a tool that modifies group membership, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('groupId' and 'participants'), including their formats. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints on participant limits. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add member(s) to a group') and identifies the resource ('group'), making the purpose immediately understandable. It distinguishes from siblings like 'waha_remove_group_participants' by specifying addition rather than removal, though it doesn't explicitly mention all alternatives like 'waha_promote_group_admin' for different group management functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Requires admin privileges,' which indicates a prerequisite for invocation. However, it doesn't explicitly guide when to use this tool versus alternatives like 'waha_create_group' for initial group setup or 'waha_join_group' for self-joining, leaving usage somewhat implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the admin privilege requirement, which is useful, but lacks details on effects (e.g., whether demotion is reversible, if participants retain group access, error conditions, or rate limits). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero wasted words, front-loading the core action and following with a critical prerequisite. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on return values, error handling, side effects, and how it differs from related tools like 'waha_promote_group_admin'. For a tool that modifies group permissions, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (groupId and participants). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or validation rules. Baseline 3 is appropriate when the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove admin privileges') and target ('from participant(s)'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'waha_promote_group_admin' beyond the opposite action, missing a direct comparison that would earn a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires admin privileges'), which gives some context for when to use it, but it doesn't specify when to choose this tool over alternatives like 'waha_remove_group_participants' or clarify scenarios where demotion is appropriate versus removal. This provides implied but incomplete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention potential side effects, rate limits, authentication needs, or what 'subscribed presence information' entails. This leaves significant gaps for an AI agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a no-parameter tool and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 minimally adequate but lacks depth. It doesn't explain what 'presence information' includes, how it's formatted, or how it relates to other presence tools, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline expectation. No extra credit is given since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'all subscribed presence information', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'waha_get_presence' or 'waha_set_presence', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites (e.g., needing to subscribe first with 'waha_subscribe_presence'), nor does it explain how this differs from 'waha_get_presence' or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get total number of groups,' which implies a read-only operation, but doesn't mention any behavioral traits like whether it requires authentication, has rate limits, returns a simple integer or structured data, or if it's cached. This leaves significant gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get total number of groups.' It's front-loaded with the core action and resource, with zero wasted words. This is optimally concise for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks context. It doesn't explain what 'groups' refer to (e.g., WhatsApp groups), the return format (e.g., integer count), or any prerequisites. For a tool with no structured fields to rely on, more completeness would be beneficial, though it's not entirely misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose. A baseline of 4 is applied since the schema fully covers the absence of parameters, and the description doesn't add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get total number of groups' clearly states the verb ('Get') and resource ('total number of groups'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'waha_get_groups' (which likely lists groups with details) or 'waha_get_group_info' (which gets info about a specific group), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't specify if this is for quick counting versus detailed listing with 'waha_get_groups', or if it's preferred for performance reasons. Without such context, users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the admin privilege requirement, which is useful, but fails to describe other critical behaviors such as whether the promotion is reversible, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the action and a key requirement. Every word earns its place, and it's front-loaded with the core purpose, making it efficient and well-structured without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral outcomes, error handling, or return values, which are crucial for an agent to use this tool effectively. The admin requirement is helpful but doesn't compensate for other missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (groupId and participants) with formats. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Promote participant(s) to group admin') and specifies the resource ('group'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'waha_demote_group_admin' beyond the opposite action, missing a direct comparison that would earn a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires admin privileges'), which provides some context for when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives like 'waha_demote_group_admin' or other group management tools, leaving usage somewhat implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the admin privilege requirement, which is valuable context. However, it doesn't describe what happens after removal (e.g., whether participants are notified, if removal is reversible, error conditions for invalid participants, or rate limits). For a destructive mutation tool, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loaded with the core action. Every word serves a purpose: the first sentence states what the tool does, and the second adds critical context about permissions. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about return values (e.g., success confirmation or error details), side effects, error handling, and how it differs from similar tools. The admin requirement is noted, but other critical behavioral aspects are missing, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (groupId and participants) with their formats. The description adds no additional parameter information beyond what's in the schema, such as examples of valid group IDs or participant arrays. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove member(s) from a group') and identifies the resource ('group'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'waha_leave_group' (which removes the current user) or 'waha_demote_group_admin' (which changes permissions rather than removing participants), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one explicit usage guideline ('Requires admin privileges'), which is helpful for understanding prerequisites. However, it offers no guidance on when to use this tool versus alternatives like 'waha_leave_group' or 'waha_demote_group_admin', nor does it specify scenarios where removal is appropriate versus other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states the action is a 'send' operation (implying mutation) but doesn't disclose permissions needed, rate limits, whether it's idempotent, error conditions, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and includes all essential elements (what, where, how). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after sending (e.g., returns message ID, success status), error handling, or behavioral constraints. The 100% schema coverage helps, but the overall context for safe/effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., no examples beyond the basic vCard mention, no clarification on chatId formats beyond '@c.us'). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Send contact card(s)'), resource ('to a WhatsApp chat'), and format ('using vCard format'). It distinguishes this tool from siblings like waha_send_message or waha_send_media by specifying the unique contact-sharing functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., chat must exist), exclusions, or compare it to similar tools like waha_send_message for text or waha_send_media for files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool's action but doesn't mention whether this operation requires specific permissions, if it's reversible, what happens to unread counts, or any side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly convey the tool's purpose and parameter options. Every word earns its place, and the information is front-loaded with the core action stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides basic purpose but lacks important context about behavioral implications, error conditions, or what constitutes success. While the schema covers parameters well, the overall context for safe and effective use is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds marginal value by mentioning the two optional parameters ('number of recent messages' and 'time range in days'), but doesn't provide additional semantic context beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark messages in a chat as read') and specifies the resource ('chat'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'waha_mark_chat_unread' by specifying the opposite action, though it doesn't explicitly mention this distinction in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'number of recent messages or time range in days', suggesting when to apply different parameters. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'waha_mark_chat_unread' or clarify prerequisites beyond the required chatId parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Unarchive a chat') and effect ('Moves the chat back to the main chat list'), but doesn't cover critical behavioral aspects such as required permissions, whether the operation is reversible, error conditions, or rate limits. This leaves significant gaps for an agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, direct sentences with zero waste. It front-loads the purpose and efficiently explains the outcome, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It covers the basic action and effect but lacks details on behavioral traits, error handling, or return values. However, the high schema coverage for the single parameter provides some compensation, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'chatId' parameter clearly documented. The description doesn't add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain where to find the chatId or format nuances), so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unarchive a chat') and the effect ('Moves the chat back to the main chat list'), providing a specific verb and resource. It distinguishes itself from the sibling 'waha_archive_chat' by being the inverse operation, though it doesn't explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a chat needs to be restored from an archived state, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., when to unarchive vs. other chat management tools) or any prerequisites. The context is clear but lacks detailed exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns that this is a 'destructive operation that cannot be undone,' which is crucial for a deletion tool. However, it doesn't mention permissions, side effects, or what 'completely' entails (e.g., if it affects messages or participants).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. The first sentence states the purpose, and the second provides a critical warning, making every sentence earn its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of annotations or output schema, the description is moderately complete. It covers the core action and warning but misses details like permissions, error cases, or confirmation requirements, which could help the agent use it safely in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (chatId), so the schema already documents its type and format. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a chat completely') and specifies the resource ('a chat'), which distinguishes it from sibling tools like waha_archive_chat or waha_clear_chat_messages. However, it doesn't explicitly differentiate from waha_delete_message, which might cause some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 waha_archive_chat or waha_clear_chat_messages. It mentions the operation is destructive but doesn't specify use cases or prerequisites, leaving the agent without contextual decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool edits messages and has a usage constraint (bot-sent messages only), but lacks details on permissions, rate limits, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Edit a sent message in a chat. Only works for messages sent by the bot.' It's front-loaded with the core purpose and includes a critical constraint without unnecessary words. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 5 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and a key constraint, but lacks details on behavior, error handling, or return values. For a tool that modifies data, this leaves gaps in understanding how to use it effectively, though it's not entirely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters (chatId, messageId, text, linkPreview, linkPreviewHighQuality) with descriptions. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Edit a sent message in a chat.' It specifies the verb ('Edit') and resource ('a sent message'), and distinguishes it from siblings like waha_delete_message or waha_send_message. However, it doesn't explicitly differentiate from waha_react_to_message or waha_pin_message in terms of message modification types, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'Only works for messages sent by the bot.' This is a specific usage constraint. However, it doesn't mention alternatives (e.g., waha_send_message for new messages) or when not to use it (e.g., for messages sent by others), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the default limit and return fields, but lacks critical details such as whether this is a read-only operation, if it requires specific permissions, how pagination works with offset, or any rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and return fields, the second specifies the default limit. It is front-loaded with essential information and avoids redundancy, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and return fields but lacks details on behavioral aspects (e.g., safety, pagination, permissions) and output structure. It is adequate for a simple read operation but incomplete for a tool with 4 parameters and potential complexity in WhatsApp messaging contexts, leaving the agent with gaps in understanding full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (chatId, limit, offset, downloadMedia) with their types, defaults, and descriptions. The description adds minimal value by mentioning the default limit of 10 messages, which is already in the schema, but does not provide additional context like format examples for chatId or implications of downloadMedia. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get messages'), resource ('from a specific WhatsApp chat'), and scope ('Returns message content, sender, timestamp, and status'), distinguishing it from siblings like waha_get_chats (which lists chats) or waha_get_contact (which retrieves contact info). It specifies the exact data returned, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving messages from a chat, but does not explicitly state when to use this tool versus alternatives like waha_get_chats (for chat metadata) or waha_get_contact (for contact details). No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns that the operation is 'destructive' and 'cannot be undone,' which is crucial for a mutation tool. However, it lacks details on permissions needed, rate limits, or what 'clear' entails (e.g., whether it affects media files or just text).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the purpose and a critical warning. It is front-loaded with the core action, and every word earns its place without redundancy or fluff, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of annotations or output schema, the description is partially complete. It covers the high-risk aspect but misses details like response format, error conditions, or side effects. For a mutation tool with no structured safety hints, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'chatId' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Clear all messages') and the target resource ('from a chat'), which is specific and unambiguous. It clearly distinguishes this from sibling tools like waha_delete_message (single message deletion) or waha_delete_chat (entire chat deletion), establishing a unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., chat must exist), compare to similar tools like waha_delete_chat, or specify contexts where clearing messages is appropriate versus other actions. The warning implies caution but doesn't offer usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states this is a 'destructive operation and cannot be undone,' which is crucial context for a mutation tool. However, it lacks details on permissions needed, rate limits, or what happens if the message doesn't exist. The warning is valuable but incomplete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides a critical behavioral warning. It's front-loaded with the core action and efficiently communicates essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is minimally complete. It covers the purpose and a key warning but lacks details on permissions, error conditions, or response format. Given the complexity of deletion operations, more context would be beneficial, but it's adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (chatId and messageId) clearly documented in the schema with format details. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete a specific message') and resource ('from a chat'), distinguishing it from sibling tools like waha_clear_chat_messages (which deletes all messages in a chat) and waha_edit_message (which modifies rather than removes). The verb 'delete' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 waha_edit_message for corrections or waha_clear_chat_messages for bulk removal. It mentions the operation is 'destructive and cannot be undone,' but this is a behavioral warning rather than usage context. No explicit when/when-not instructions or sibling comparisons are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds valuable context beyond the input schema by specifying the caching behavior ('Uses 24-hour cache by default'), which is a key operational trait not captured in the schema. This helps the agent understand performance and data freshness implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: a single sentence that states the core purpose, followed by a second sentence adding crucial behavioral context. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no annotations and no output schema, the description provides adequate context about caching behavior. However, it doesn't describe the return value format (e.g., URL structure, error conditions), which would be helpful given the lack of output schema. The description is complete enough for basic use but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (chatId format, refresh default). The description adds no additional parameter semantics beyond what's in the schema, but doesn't need to compensate for gaps. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the profile picture URL') and resource ('for a chat'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'waha_get_contact_profile_picture' or 'waha_get_group_picture', which serve similar functions for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context through the mention of '24-hour cache by default' and the 'refresh' parameter, suggesting when to use the cache vs. fresh data. However, it lacks explicit guidance on when to choose this tool over similar sibling tools (e.g., waha_get_contact_profile_picture for contacts vs. chats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the auto-subscription behavior, which is valuable beyond basic functionality. However, it lacks details on permissions needed, rate limits, error conditions, or what the return format looks like (e.g., structured data or simple status).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and adds the auto-subscription detail without waste. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers the tool's purpose and a key behavioral trait (auto-subscription), but lacks details on return values, error handling, or prerequisites. For a tool with 1 parameter and 100% schema coverage, it's adequate but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the chatId parameter. The description doesn't add any meaning beyond what's in the schema (e.g., it doesn't clarify format beyond 'number@c.us' or provide examples). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get online/offline/typing status') and resource ('for a chat'), distinguishing it from sibling tools like waha_get_all_presence (which gets presence for all contacts) and waha_set_presence (which sets presence). It precisely defines what the tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool by mentioning 'Auto-subscribes if not already subscribed,' which implies it's for monitoring a specific chat's presence. However, it doesn't explicitly state when not to use it or name alternatives like waha_get_all_presence for broader monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the admin privilege requirement, which is crucial behavioral context. However, it doesn't mention other traits like whether the old link becomes invalid immediately, if there are rate limits, or what the output looks like (no output schema). It adds some value but misses key details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states the action, the second adds critical context (admin requirement). It's front-loaded with the core purpose, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It covers the admin requirement but lacks details on behavioral outcomes (e.g., what happens to the old link, response format). For a tool that modifies group access, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'groupId' parameter fully. The description doesn't add any meaning beyond what's in the schema (e.g., it doesn't explain format constraints or examples). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revoke current invite link and generate a new one') and the resource ('invite link'), distinguishing it from siblings like 'waha_get_group_invite_code' (which retrieves) and 'waha_get_group_join_info' (which checks). It uses specific verbs ('revoke', 'generate') rather than vague terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context for when to use this tool ('Requires admin privileges'), indicating it's for group administrators. However, it doesn't specify when not to use it or name alternatives (e.g., vs. 'waha_get_group_invite_code' for viewing), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates this is a mutation tool (toggle action) and specifies an important prerequisite (admin privileges), but doesn't describe what happens when toggled, whether changes are reversible, or any rate limits/error conditions. It provides basic but incomplete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core functionality, the second provides crucial prerequisite information. No wasted words, well-structured, and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate basic information about purpose and prerequisites. However, it doesn't describe what the tool returns, what happens on success/failure, or provide complete behavioral context. Given the complexity of group permission management, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents both parameters (groupId format and adminsOnly meaning). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Toggle whether only admins can send messages') and identifies the resource (group messaging permissions). It distinguishes from siblings like 'waha_set_group_info_admin_only' by focusing specifically on message-sending permissions rather than general group info settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Requires admin privileges'), indicating it's for administrators managing group permissions. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools for related group management tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the default limit and return fields, which adds useful context, but doesn't cover aspects like rate limits, authentication needs, error conditions, or whether the operation is read-only (implied by 'Get' but not explicit). It adequately describes core behavior but lacks comprehensive operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return details and default limit, all in two efficient sentences. Every element earns its place with no redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is reasonably complete. It covers purpose, output fields, and a key behavioral detail (default limit), but lacks information on error handling, pagination beyond offset, or how 'recent' is defined. For a read operation with good schema coverage, this is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds value by mentioning the default limit (10 chats), which complements the schema's default value, but doesn't provide additional semantic context beyond what's already in the schema. Since parameters are well-covered, a baseline score above 3 is justified due to the added default clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get overview of recent WhatsApp chats') and resource ('WhatsApp chats'), distinguishing it from sibling tools like waha_get_contact or waha_get_messages. It specifies the scope ('recent') and output format ('chat ID, name, last message preview, and unread count'), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving chat overviews but provides no explicit guidance on when to use this tool versus alternatives like waha_get_groups or waha_get_all_contacts. It mentions a default limit but doesn't clarify prerequisites or exclusions, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the admin privilege requirement, which is a key behavioral trait, but lacks details on other aspects like rate limits, error conditions, or what happens to existing settings. It does not contradict annotations, so no contradiction flag is raised.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by a prerequisite, with zero wasted words. Every sentence earns its place by providing essential information efficiently, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with admin requirements), no annotations, and no output schema, the description is reasonably complete. It covers the purpose and prerequisites but could improve by mentioning potential side effects or response format. However, it provides enough context for basic usage without being overly sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the parameters (groupId and adminsOnly). The description does not add any additional semantic meaning beyond what the schema provides, such as explaining parameter interactions or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Toggle'), the resource ('group info'), and the effect ('only admins can edit'), distinguishing it from siblings like waha_set_group_messages_admin_only or waha_update_group_subject. It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Requires admin privileges,' which indicates when to use it based on permissions. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as waha_set_group_messages_admin_only for different settings, leaving some guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it can add reactions and remove them by sending an empty string. However, it doesn't mention permissions needed, rate limits, or what happens if the message doesn't exist. For a mutation tool, this leaves gaps in understanding potential side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the primary action, and the second adds crucial removal functionality. It's front-loaded with the main purpose and efficiently covers both use cases without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple mutation tool with 2 parameters, the description is adequate but incomplete. It covers the basic action and parameter nuance but lacks details on error handling, return values, or system constraints. For a tool that modifies data, more context on behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the 'reaction' parameter's special case (empty string removes reaction), which isn't obvious from the schema alone. This extra semantic detail compensates slightly, but it doesn't explain format beyond examples like '👍', so it's not a full 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add an emoji reaction to a message') and distinguishes it from siblings by mentioning removal functionality. It uses precise verbs ('Add', 'remove') and identifies the resource ('message'), making its purpose unambiguous compared to other messaging tools like waha_send_message or waha_edit_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (to add or remove reactions) but doesn't explicitly mention when not to use it or name alternatives. It implies usage for reaction management without comparing to other tools like waha_star_message, which might serve different purposes. This is helpful but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the key behavioral trait of being a read-only operation that doesn't join the group, which is essential context. However, it doesn't mention potential limitations like rate limits, authentication requirements, or what specific information is returned, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, perfectly front-loaded sentence that conveys all essential information with zero waste. Every word earns its place, making it highly efficient and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description provides adequate context about purpose and usage. However, without annotations or output schema, it lacks details on return values and potential behavioral constraints, which could be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter 'code'. The description adds no additional parameter semantics beyond what the schema provides (e.g., format examples, edge cases). With high schema coverage, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get group information') and resource ('from invite link'), and distinguishes it from siblings like 'waha_join_group' by explicitly noting 'without joining'. This provides precise differentiation from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('from invite link without joining'), which clearly differentiates it from alternatives like 'waha_join_group' for actually joining or 'waha_get_group_info' for getting info from already-joined groups. This provides perfect contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![waha-whatsapp-mcp MCP server](https://glama.ai/mcp/servers/seejux/waha-whatsapp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/seejux/waha-whatsapp-mcp)

Score Badge

Copy to your README.md:

[![waha-whatsapp-mcp MCP server](https://glama.ai/mcp/servers/seejux/waha-whatsapp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/seejux/waha-whatsapp-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seejux/waha-whatsapp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server