wazap-mcp

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation5/5
Every tool targets a distinct resource or action: message gets are split into chat history, recent catch-up, single-message detail, and search, while contact discovery is separated from contact detail and refresh. The descriptions repeatedly call out the exact niche of each tool, so an agent should not mistake one for another.
Naming Consistency4/5
Nearly all tools follow a clean lower-case verb_noun pattern: list_chats, send_media, manage_group, forward_message, download_media. The only real outlier is the 'learn' meta-tool, and the mixture of read_messages/get_recent_messages/get_message uses two different verbs for message retrieval, so it is not perfectly uniform.
Tool Count4/5
24 tools is at the high end, but each maps to a distinct WhatsApp capability rather than being a near-duplicate of another. The added meta-tools learn and get_status are justified for a session-based MCP server, so the count feels slightly heavy yet appropriate for the domain.
Completeness4/5
The tool surface covers the core messaging lifecycle: receive, search, download, transcribe, send, edit, react, forward, delete, and both chat and group administration. Missing operations like blocking a contact or directly replying with a quoted message are peripheral and can be worked around, but they prevent a perfect score.
Average 4.3/5 across 24 of 24 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the core safety profile is covered. The description adds that it sends a 'map pin to a chat' and that labels are optional, but it does not disclose side effects such as the message appearing in history or possible failure behavior. Given the annotation coverage, what is added is modest but acceptable for a simple send 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?
A single sentence that is front-loaded and free of redundancy. It communicates the resource ('map pin'), the destination ('chat'), and the optional precision ('optionally labelled') efficiently. 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 that there is no output schema, the description does not explain return values or errors, but for a simple action like sending a location pin this is less critical. All required operational parameters are documented in the schema, and the description covers the essence of what the tool does. It is adequate but leaves the agent to infer what happens after a successful send.
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 every parameter in detail. The description adds the idea that name and address are optional ('optionally labelled'), which is useful but also inferable from the required fields list. The value added beyond the schema is minimal, which fits the baseline of 3.
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 states a specific verb and resource: 'Send a map pin to a chat'. It clearly identifies what the tool does and distinguishes it from other send family tools through the 'map pin' concept. However, it does not explicitly name a sibling it is not, so it stops short of full 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 implies a use case (sharing a location as a map pin) but gives no guidance about when to prefer this tool over send_media or send_message, nor when not to use it. There are no exclusions, alternatives, or contextual cues beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context (return type and usability as chat_id) beyond the read-only/idempotent annotations, but it does not specify the exact return format (e.g., array vs object), sorting, or pagination. Annotations already cover safety, so this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence conveying all essential information without redundancy. It is well-structured and easy to parse.
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?
The description covers the purpose, matching semantics, and return value. It does not mention error conditions or edge cases (e.g., no results), but for a simple search tool, the information provided is sufficient to use the tool correctly in most scenarios.
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 already provides descriptive parameter explanations (query as name fragment or phone number, limit as max results). The description adds no additional semantic detail beyond what the schema offers, so it meets the baseline for full 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 tool's purpose: finding contacts by name or phone number, and specifies the matching behavior (substring vs digit match). It also mentions the returned value (contact_id usable as chat_id), making it distinct from search-related siblings like search_messages.
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 you need to look up a contact), but does not explicitly compare with alternatives or state when not to use it. Given the tool's name and clear purpose, it's evident, but a direct 'use this for contact lookup' would strengthen guidance.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds helpful detail about the returned contact information but does not disclose operational behaviors such as edge cases, error conditions, or data staleness.
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 one compact sentence that front-loads the purpose and then lists the exact returned fields. Every word contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, one-parameter tool with rich annotations and no output schema, the description and schema together fully cover what the agent needs. The return-field enumeration compensates for the missing output schema.
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%, and the schema already explains that contact_id comes from search_contacts or list_chats or a phone number. The description adds no behavioral or formatting detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific get operation for one contact and enumerates the returned fields. Saying "one contact" distinguishes it from search-based or multi-resource sibling tools like search_contacts and get_group_info.
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 intended use is implied by "Full details for one contact," but the description does not explicitly state when to use this tool versus alternatives such as search_contacts, list_chats, or get_group_info. There are no exclusions or routing conditions.
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?
The description adds value beyond annotations by disclosing that the linked account becomes owner and that each participant returns a status (ok, invite_needed, or failed). This explains behavioral outcomes and per-participant results, which the annotations (readOnlyHint=false, idempotentHint=false, etc.) do not cover. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and efficiently conveys the owner assignment and participant statuses. Every sentence earns its place with no redundant information.
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 there is no output schema, the description explains return values via participant statuses and mentions owner assignment. However, it does not clarify whether the group is created if all participants fail, or if the operation is atomic, leaving some edge-case ambiguity. Overall, it is fairly complete for a creation tool.
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 provides full descriptions for both parameters (name and participant_ids), so the description adds no additional parameter-specific meaning. It only restates that the tool takes a name and participants, which is already covered by the schema. Baseline of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a WhatsApp group with a name and participants, and specifies that the linked account becomes owner. This distinguishes it from siblings like manage_group, which likely handles existing groups. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as manage_group or send_message. The purpose is clear enough to infer creation, but there is no guidance on when not to use it or when to prefer another tool for similar operations.
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?
The annotations already capture readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the meaningful behavioral fact that the recipient sees the message marked as forwarded, which an agent cannot infer from the schema or annotation flags. It also implies the original message remains untouched.
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 sentences, both earning their place. The first states the core action, and the second conveys a notable user-facing behavior. There is no repetition of schema details, no filler, and the key object and destination are front-loaded.
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 two-required-parameter operation without an output schema, the description adequately covers the action, the destination chat, and the primary observable outcome ('marked as forwarded'). A slightly more complete description might mention what happens on success or that only chat ID and message ID are needed, but nothing critical appears 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?
Both parameters are already fully documented in the JSON schema with high specificity: message_id gets an explanation of its origin and an example, and to_chat_id gets a clear 'Destination chat' label. Since schema description coverage is 100%, the description bears no additional parameter burden, and the baseline 3 applies.
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 uses a specific action verb ('Forward') a clear resource ('an existing message') and a target ('another chat'). The detail that the recipient sees it marked as forwarded is a distinctive behavior that differentiates it from siblings like send_message and edit_message, even though no sibling is named.
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 does not explicitly tell an agent when to choose this over alternatives, nor does it name send_message or edit_message as alternatives. It implies usage by stating it applies to 'existing messages', and the schema's message_id description references read_messages / search_messages, but that guidance is in the schema, not the main description.
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?
Annotations already carry the full safety profile (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false), so the bar for added disclosure is lower. The description contributes return-content context (quoted message, reactions, media metadata) beyond annotations but says nothing about failure behavior, authorization, or chat-scoping constraints. This is adequate given the strong 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?
A single well-structured sentence that front-loads the core function, then enumerates content scope, then routes usage to sibling tools. Every clause earns its place; there is no filler or repetition of title content.
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 single-parameter read-only retrieval tool with fully documented schema and rich annotations, the description explains what the return payload contains (quoted message, reactions, media metadata) even in the absence of an output schema. The usage context is explicit. Only minor gaps like invalid-ID behavior or chat scope remain, but nothing essential to invoking it correctly is 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% — the message_id parameter is fully documented with type, minLength, and a concrete example ('false_4072...@s.whatsapp.net_3EB0...'). The description adds no parameter detail beyond what the schema provides, so the baseline 3 for high coverage 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 uses a specific retrieval verb anchored to a concrete resource ('The complete message behind a message_id') and enumerates exactly what's included: the quoted message, reactions, and media metadata. It clearly differentiates from siblings by framing this as the deep-dive tool that follows search_messages/read_messages, so an agent can distinguish it without opening schemas.
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?
Explicit guidance — 'Use it after search_messages or read_messages when you need the context around a single message' — names the preceding tools and the exact condition that selects this tool. It lacks an explicit when-not-to-use statement, but the conditional phrasing makes the intended workflow unambiguous.
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?
The description explicitly exposes the two possible behavioral outcomes—adding a reaction or removing one via empty string—which goes beyond the annotations. It does not discuss auth or transform side effects, but the annotations already signal readOnly false and idempotent false, so this is adequate for the simple 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 sentence that front-loads the core action, immediately covers the edge case of removal, and uses no extra words. Every element is meaningful and directly useful to the agent.
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 simple two-parameter tool, full schema coverage, and annotations, the description is nearly complete. It might have benefited from a brief note on expected behavior or limitations, but nothing essential for successful invocation is 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?
The input schema already documents both parameters comprehensively, including message_id provenance and the empty-string behavior for emoji. The description adds no significant new parameter meaning beyond restating this, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('add an emoji reaction') and resource ('a message'), and also covers the inverse case ('pass an empty string to remove'). This distinguishes it from sibling message tools like delete_message or send_message, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is clear from the description, but there is no explicit guidance about when this tool should be used over siblings such as edit_message or send_message, and no exclusionary conditions. The usage is implied rather than directly stated.
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?
Annotations already show readOnlyHint=false and destructiveHint=false, so the mutation nature is captured. The description adds critical behavioral context: the cannot-read-votes limitation and the need to ask user for outcomes. It also implies sending is immediate and non-idempotent, but the openWorldHint=true is not addressed. The insight about votes not being readable is a valuable addition beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes the key caveat about votes. It could be slightly more structured but is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description covers the essential usage context. The only gap is that it doesn't explicitly state the interaction with the user (e.g., after sending, wait for user report), but the description implies it. The output is not relevant since there is no output schema. The tool is complete for its purpose.
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 all parameters are well-documented in the schema. The description does not add extra semantic detail beyond what the schema provides, which is acceptable. The multi_select parameter is clear from the schema, and the description does not need to restate it.
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 'Send a poll to a chat' is specific with a clear verb and resource, distinguishing send_poll from send_message and send_media. It also clarifies the interaction model (participants vote in WhatsApp) which is unique to this tool.
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 does not explicitly mention when not to use it vs alternatives, but it clearly states the polling context. It could have named a sibling like send_message as an alternative, but the purpose is clear enough for an agent to select send_poll when a poll is needed. No explicit exclusions in the description, but the 'ask the user to report outcome' implies a limitation.
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?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds valuable context by noting that mark_read sends read receipts and that mute_hours defaults to 8, which are behavioral specifics not captured in the annotations. While not exhaustively detailing side effects for every action, it provides meaningful extra insight beyond the structured metadata.
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, compact sentence that starts with the core verb 'Change the state of a chat' and immediately lists all supported actions. There is zero fluff, and every word adds value. For a tool with multiple enumerated actions, this is an optimally concise format.
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 simplicity and the completeness of the schema (100% param coverage) and annotations, the description covers the essential information an agent needs to call it correctly. It does not mention return values, but there is no output schema, so that is not required. Minor gaps like behavior on already-archived chats or edge cases are not necessary for 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 all three parameters (action, chat_id, mute_hours) are already documented with descriptions and constraints. The description reiterates the mute_hours default (8) and notes 'only used by mute', but this duplicates schema information. It adds no new semantic meaning beyond the schema, so the baseline 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 tool's purpose: 'Change the state of a chat' and enumerates the specific actions (archive/unarchive, pin/unpin, mute/unmute, mark_read/mark_unread). This is a specific verb+resource pairing that distinctly separates it from sibling tools like manage_group or send_message. The title 'Manage a WhatsApp chat' further reinforces the scope, making it easily distinguishable.
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 implies when to use this tool by listing the supported actions, so an agent can infer it handles any chat state change (archive, pin, mute, read status). It does not explicitly name alternatives or state when not to use it, but the action list is comprehensive and self-explanatory. Given that no sibling tool covers these specific operations, the context is clear enough.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior, which lowers the burden. The description adds meaningful behavioral context beyond annotations: search is case-insensitive, operates only on locally synced messages, and cannot access unsynced phone messages. This is useful, non-redundant disclosure.
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 no fluff. The core verb and scope are front-loaded, and the limitation is stated in a single additional sentence. Every word earns its place.
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-only search tool with clear annotations and fully documented parameters, the description covers purpose, scope, case-insensitivity, and the key limitation. It does not describe the exact result shape or ordering, but the title and tool name make the return concept clear, and no output schema exists to contradict this.
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 coverage is 100%, so the baseline is 3. The description adds value by clarifying query semantics (case-insensitive matching) and chat scoping (all chats or one chat), which maps directly to the optional chat_id parameter. This goes beyond what the schema states.
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 states a specific verb and resource: case-insensitive text search over locally held WhatsApp messages, scoped to all chats or one chat. It also clarifies a key limitation (cannot reach unsynced messages), which helps distinguish it from read_messages and other message-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need text search across messages, optionally filtered by chat. However, it does not explicitly contrast this with sibling tools like read_messages or get_recent_messages, nor does it state when an alternative should be preferred.
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?
Annotations already provide readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the mutation and non-idempotency profile. The description adds important constraints (maximum 100 MB and exactly one of file_path/url) but does not disclose other behavioral details such as what happens when both sources are provided or what result is returned after a successful send. That keeps it at baseline plus.
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?
Three short, front-loaded sentences: first sentence states what and from where, second gives the exclusivity invariant, third gives the size cap. No filler words or repeated information from parameters.
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 tool with six parameters and no output schema, this description provides the essential usage context: media types, source origin, exclusivity, and size limit. The chat_id, caption, and flags are clearly described in the schema, so the description does not need to repeat them. It only leaves out optional or edge-case behavior that is still inferable.
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 already documents each parameter. The description adds cross-cutting meaning: exactly one of file_path/url and a 100 MB size cap, which are not visible in any single parameter description. This goes beyond the schema and helps the agent avoid an invalid call.
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 names a specific verb ('Send') and a precise resource ('an image, video, audio file or document'), which clearly distinguishes it from text-focused sibling tools like send_message, send_poll, and send_location. It also gives concrete source options (local path or public URL), making the scope unmistakable.
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 clearly states context for use: media messages from a local file or URL, with size and exclusivity constraints. However, it does not explicitly name alternatives or say 'use this when sending media, not text', so an agent must infer the distinction from the word 'image/video/audio/document.'
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?
The description adds meaningful behavioral context beyond the annotations: results are grouped by chat, and system notices are excluded by default so the counts reflect actual conversation content. That's important, non-obvious behavior an agent needs to know before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the most important information: what the result looks like and the main use case. The phrasing 'summaries are conversation' is slightly awkward, but it does not undermine clarity.
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, the description covers purpose, grouping behavior, the default exclusion of system notices, and the main lazy use case. There is no output schema, so a bit more return-value explanation could be useful, but the description's core value is strong.
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 already has 100% parameter coverage, including useful descriptions for types, hours, filter, and include_system. The tool description adds no new parameter-level detail beyond reinforcing the effect of include_system, so a baseline 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 action and scope: it returns everything that happened recently, grouped by chat. It also explicitly contrasts itself with the alternative approach of combining list_chats and read_messages, making its purpose and differentiating position unmistakable.
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 provides concrete guidance on when to choose this tool: use it as the catch-up tool instead of calling list_chats plus read_messages per chat. It also identifies a specific behavior modifier (pass include_system) for when the caller needs WhatsApp's system notices, which helps the agent decide whether default behavior is sufficient.
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?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds the ordering behavior ('most recently active first') and enumerates the fields each chat returns, providing useful context beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a compact field list. The core action and purpose are front-loaded, and the field list is directly useful without verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool, the description is complete: it states what it lists, the ordering, the purpose, and the returned fields. The schema handles parameter details, and the field list effectively replaces an output schema. No critical information is 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%; both 'limit' and 'filter' already have descriptions including defaults and constraints. The tool description does not add any extra meaning for parameters, so it stays at the baseline of 3.
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?
States a specific verb ('List') and resource ('conversations'), with a clear ordering ('most recently active first') and a defined purpose ('discover chat_id values the other tools need'). This distinguishes it from siblings like search_contacts or get_message without ambiguity.
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?
Explicitly says to use it to discover chat_id values needed by other tools, which gives clear context. It does not explicitly exclude alternatives or mention when not to use it, but the purpose is specific enough. Sibling tools like search_contacts focus on contacts, not chats, so the distinction is implicit but clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds crucial real-world context: the message is actually sent from the user's account, there is no undo, and confirmation is advised for sensitive content. This goes beyond the annotations, which only indicate it's a write 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?
Two concise sentences with the primary action stated first and the safety warning following. No fluff, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send-text tool, the description covers the essential purpose and the most important caveat (no undo). It doesn't need to explain return values since there's no output schema, and the annotations cover the technical write semantics.
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 already provides descriptions for all parameters (100% coverage). The tool description does not add additional parameter context beyond what is in the schema, so it remains at baseline.
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?
Clearly states the action 'Send a text message', specifying the resource (text message) and distinguishing from media or poll sending. The verb and object are explicit.
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 indicates the tool is for sending text messages but does not explicitly contrast with sibling tools like send_media or send_poll. It provides a cautionary note about confirming sensitive content, which offers some usage guidance but not clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations' destructiveHint=true, the description discloses that the retraction is "visible to everyone in the chat" (blast radius), that only the linked account's own messages are eligible (auth/permission limitation), and the 2-day time window. These are exactly the kinds of concrete behavioral details — what gets destroyed and under what constraints — that the annotations' booleans cannot express. No contradiction exists between the warnings and the readOnlyHint=false/destructiveHint=true flags.
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?
Three tightly written sentences, each earning its place: the operation itself, the destructive warning with user-confirmation protocol, and the constraints. The most critical safety information ("DESTRUCTIVE") is front-loaded immediately after the verb, exactly where an agent will see it before calling the tool.
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 2-parameter destructive operation with no output schema, the description covers all essential call-time knowledge: side effects (visible to all), pre-conditions (own message, within 2 days), and user-consent requirements. The only minor gap is that it doesn't describe error behavior or what happens with the default for_everyone=false when a user expects a private delete — but the schema annotation largely covers that.
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 coverage is 100% — both message_id and for_everyone are fully documented with provenance guidance and semantic clarifications (e.g., "WhatsApp supports no other kind of delete here"). The description adds no parameter-specific meaning beyond the schema, but per the baseline rule, 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?
"Retract a message" is a specific verb-plus-resource that unambiguously states a delete operation, reinforced by the title "Delete a WhatsApp message." The description is clearly distinct from siblings like edit_message or forward_message because the DESTRUCTIVE warning and visibility consequence leave no doubt this is a removal, not a modification, operation.
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 gives explicit exclusions — "only works on messages the linked account sent" (privilege constraint) and "only within 2 days of sending" (temporal constraint) — which tell an agent when not to attempt deletion. It also includes workflow guidance ("confirm with the user first"). However, it doesn't name alternatives like edit_message for cases when the 2-day window has passed, which would elevate it to a 5.
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?
The annotations already indicate this is a mutating, non-idempotent operation. The description adds the important 15-minute time constraint and the fallback behavior when that constraint is exceeded, which meaningfully helps the agent predict outcomes.
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 sentences with no wasted words. The first sentence states the core action, and the second delivers the critical time constraint and alternative action.
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 two-parameter mutating tool, the description covers the action, the prerequisite, the key platform limitation, and the fallback. It does not specify exact failure behavior or return value, but those are not essential for calling this tool correctly.
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 'text' and 'message_id' already described. The description reinforces that text is the replacement and that the message must have been sent by the linked account, but it does not add significant parameter detail beyond the schema.
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 states a specific action and resource: 'Replace the text of a message the linked account sent.' This clearly distinguishes editing from sibling tools like send_message, delete_message, and react_to_message.
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 gives an explicit usage condition: editing is only allowed within 15 minutes of sending. It also tells the agent what to do otherwise: 'after that send a correction instead,' which points toward send_message.
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?
The description highlights that 'leave' is destructive and requires a new invite to rejoin, and that all actions except leave require admin privileges. These details go beyond the annotations (destructiveHint true) to explain specific consequences. It does not mention other potential side effects (e.g., removing a member), but the admin check note adds 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 compact and well-organized as a bulleted list of actions with their parameters. It avoids superfluous prose and front-loads the core purpose, making it easy to scan. No redundant information is present.
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 complexity (multiple actions, admin requirements, destructive leave), the description covers the essential operational aspects: action list, parameter associations, admin prerequisite, and a specific warning about leave. It does not describe output formats or error handling, but no output schema exists, and those are not always required.
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 description maps actions to required parameters (e.g., add/remove need participant_ids, set_subject needs value), which the schema does not specify per action. This adds essential cross-referencing that helps the agent construct correct calls. The schema already describes each parameter individually, so the description supplements rather than repeats.
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 'Administer a group' and enumerates specific actions (add, remove, promote, etc.), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like manage_chat or create_group by focusing exclusively on group management operations.
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 actionable usage guidance, such as calling get_group_info first to verify admin status. It implicitly tells when to use this tool (for group membership and settings management) but does not explicitly contrast with alternatives like manage_chat or send_message. The action list makes the appropriate use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details beyond the annotations: it handles four media types, returns small images inline for inspection, saves to disk, and fails with MEDIA_UNAVAILABLE when media has expired. This meaningfully supplements the readOnly/idempotent/destructive hints.
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?
Three concise sentences in a logical order: primary action, inline return nuance, and failure mode. Every sentence earns its place without redundancy or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's behavior, error case, and side effects. Combined with complete schema parameter descriptions and safety annotations, an agent has all necessary information to invoke it correctly for any supported media type.
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?
Parameter documentation is already complete in the schema (100% coverage). The description adds no parameter-specific meaning beyond what the schema provides, but it does add useful context about inline image return and the error condition. A baseline of 3 is appropriate for full 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 uses a specific verb ('Download'), names the exact resource (photo/video/audio/document attached to a message), and states the destination (disk on the machine running wazap). This clearly distinguishes it from siblings like send_media and get_message, which target different operations.
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 gives clear context for when to use the tool: when a message has media that should be saved or viewed. It does not explicitly name alternatives or exclusions, but the schema's 'has_media=true' hint and sibling names make the intended use apparent. There are no misleading usage signals.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description need not repeat those. It adds important behavioral details: participant list capped at 500, participant_count always true total, and invite link only when admin. This is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads key details, and adds a clear call-to-action. Every sentence provides useful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only info tool with one parameter and rich annotations, the description covers all necessary aspects: what it returns, edge cases (participant limit, invite link condition), and guidance on usage. Nothing essential is 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?
The input schema already fully describes the group_id parameter with format and example. The description does not add additional meaning for the parameter itself, so baseline 3 is appropriate given 100% 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 it returns details of a WhatsApp group, enumerating specific fields (name, description, owner, creation date, admin status, participant list). It is distinct from sibling tools like list_chats and manage_group.
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?
Explicitly instructs to call this before manage_group, noting that most group actions need admin rights. It provides clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: caching, subsequent display of the transcript as [voice message · 0:42], searchability via search_messages, provider-dependent pricing and data handling, the 10-call-per-minute cap, and the TRANSCRIBE_UNAVAILABLE error with explicit do-not-retry guidance.
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 and follows with dense, useful operational facts. Every sentence earns its place: caching, side effects on messages, searchability, cost, rate limits, and the error case. It is detailed but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description gives enough information about the returned behavior (text), plus caching, upstream and API side effects, when results appear in other tools, and how to handle failure. An agent has what it needs to call this correctly and reason about outcomes.
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%, and the schema already explains message_id and language. The description reinforces that calling with the same message is useful because of caching, but it does not add substantive parameter-level meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by stating a specific verb and resource: turning a voice note or audio message into text. It also explains the post-transcription behavior in read and search tools, which clearly distinguishes this from siblings like download_media or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It makes the intended use clear: transcribe voice/audio messages into text. It also provides strong cost, caching, rate-limit, and error-retry guidance. It does not explicitly name alternative tools or conditions that would rule this tool out, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent; the description adds valuable behavior beyond that: default ordering, backwards pagination semantics, and the fact that wazap may query the phone for older history with a noticeable delay. This contextualizes side-channel behavior and latency without contradicting any annotation.
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 compact, front-loaded with the core operation, and every sentence provides distinct value: ordering, default behavior, and pagination delays. No filler or reduntant restatement.
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?
The description covers the key non-obvious behavior (pagination, phone lookup, delay) and does well given the annotations and full schema. The only gap is that it does not describe the returned messages shape since there is no output schema, but an agent can largely infer it from the tool's purpose.
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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how `before` is meant to be used (the oldest message_id already held) and that reading will fetch newer history from the phone when the local store runs out. This adjusts to 4.
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 names a specific action ('Read messages') and resource ('from one chat'), and states ordering as 'oldest to newest.' It also explains the default behavior with and without `before`, which distinguishes this from single-message or search-based sibling tools.
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 gives an explicit usage condition: omit `before` for the most recent messages, or pass the oldest message_id you already have to page further back. It also warns about a phone-side delay. It does not name alternatives like get_recent_messages or search_messages, so implicit rather than explicit tool-selection guidance.
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?
The description adds 'never touches WhatsApp' and 'takes no arguments,' which reinforce and extend the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The 'never touches WhatsApp' claim is a meaningful behavioral assurance beyond the abstract readOnly hint — it tells the agent this is safe with zero side effects. Consistent with all annotations, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, and the most critical usage instruction ('Read this FIRST') is front-loaded in the first clause. The second sentence packs the full content scope efficiently. For a zero-parameter reference tool, this is the ideal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a zero-parameter documentation tool. It covers when to use it (first, before anything else), what it delivers (tools guide, id formats, workflows, message shape, error codes with remediation), and side effects (none). The absence of an output schema is immaterial since the tool's output is itself the guide it returns, which is described in sufficient detail.
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?
With zero parameters, the baseline is 4 per the rubric. The description confirms 'takes no arguments,' which matches the empty input schema. Nothing further is needed for parameter semantics since there are no parameters to document.
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 states a specific purpose: returning a guide covering tool usage, id formats, workflows, message shape, and error codes. This clearly distinguishes it from the 21 action-oriented sibling tools (send_message, delete_message, etc.), none of which are documentation tools. The verb 'Returns' plus the concrete content list make the purpose unmistakable.
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 opening sentence — 'Read this FIRST, before any other WhatsApp tool' — gives explicit, unambiguous usage ordering. It tells the agent exactly when to invoke this tool relative to all siblings. No alternatives are named because none exist; this is the only documentation tool among the set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns with these. It adds valuable behavioral context beyond annotations: the meaning of different connection states ('connected' means the tools work, 'not_linked' means login is needed), the interpretation of sync state, and the semantics of contacts_named: 0. This gives the agent a more accurate mental model of what to expect.
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 efficiently structured: the first sentence front-loads the core purpose and status meanings, the parenthetical clarifies what each status implies for tool availability, and the second sentence gives actionable invocation triggers. Every detail earns its place, and no filler or redundant language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema to document return values, the description fully covers what the agent needs to know: the ranges of connection states and their actionable meanings, sync state, account identity, last activity, versions/directory, and the edge case of contacts_named=0. Given the tool's zero-parameter, diagnostic nature, the description is complete.
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 zero parameters and the schema is fully covered at 100%, so the description carries no parameter documentation burden. The baseline of 4 for zero-parameter tools applies, and the description appropriately focuses on output semantics rather than parameter details. There is no parameter information missing.
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 states a specific verb ('Check the session') and resource (WhatsApp session status), then enumerates exactly what is reported: connection status, history sync, linked account, last message time, versions, data directory, and named contacts count. It clearly distinguishes itself from the sibling tools, which are focused on contacts, messages, sending, and group operations.
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 provides explicit when-to-use guidance: call it whenever another tool reports NOT_CONNECTED, NOT_LINKED, or SYNC_IN_PROGRESS, or to confirm which account is about to be used for sending. It also maps the 'not_linked' status to a concrete user action (run `npx wazap-mcp login`), giving the agent both the trigger and the resolution path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides several behavioral details beyond the annotations: it waits up to 15 seconds, it changes nothing on WhatsApp, and it refills wazap's own contact list. It also explains the expected return values and how to interpret them. The emphasis that 'only refills wazap's own contact list' reconciles the idempotent and read-only hints rather than contradicting them.
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 compact yet complete. It opens with the main action, then adds the critical caveat that WhatsApp is unchanged, followed by usage conditions and return-value guidance. There is no filler and every sentence contributes to helping an agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description appropriately explains exactly what the return values (named_before and named_after) mean, including how to interpret when both are 0. It also covers idle timeout, side effects, and trigger conditions. For a zero-parameter refresh action, this is complete.
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 zero parameters, so there is nothing for the description to explain about input meaning. The schema coverage is already 100% and there are no parameter fields. The description focuses instead on behavior and outputs, which is appropriate. Given no parameters, the score is set to the baseline of 4.
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 verb and resource: it refetches the linked phone's address book for wazap's own contact list. It distinguishes this from simple lookups like get_contact or search_contacts by emphasizing the 'from scratch' refill action and the absence of any change on WhatsApp. The title and description work together to make the tool's intent unambiguous.
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 tells when to use this tool: when get_status reports contacts_named is 0, or when group senders show as phone numbers instead of saved contact names. It also explains how to evaluate the outcome via named_before and named_after. This gives an agent concrete criteria for selecting it over other tools.
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:

[![wazap MCP server](https://glama.ai/mcp/servers/razvangirgiz/wazap/badges/card.svg)](https://glama.ai/mcp/servers/razvangirgiz/wazap)

Score Badge

Copy to your README.md:

[![wazap MCP server](https://glama.ai/mcp/servers/razvangirgiz/wazap/badges/score.svg)](https://glama.ai/mcp/servers/razvangirgiz/wazap)

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/razvangirgiz/wazap'

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