mcp-wacli

by grrek

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between list_chats and list_groups (both list entities), and between search_messages and list_messages (both retrieve messages). The descriptions clarify the differences, but an agent might occasionally confuse them.
Naming Consistency5/5
Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., download_media, group_leave, search_contacts). There are no deviations in naming conventions across all 27 tools.
Tool Count3/5
With 27 tools, the count feels heavy for a WhatsApp CLI toolset. While it covers many features, it borders on being overwhelming and could be streamlined without losing core functionality.
Completeness5/5
The toolset provides comprehensive coverage for WhatsApp operations, including authentication, messaging, group management, contact handling, media, and syncing. There are no obvious gaps; it supports full CRUD-like workflows for the domain.
Average 3.3/5 across 27 of 27 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 status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the action but doesn't disclose whether this is reversible, requires specific permissions, affects group notifications, or what happens upon success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps.
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 appropriately brief with two sentences: one stating the purpose and another documenting the parameter. It's front-loaded with the core action. However, the 'Args' formatting is slightly redundant since it repeats the parameter name.
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 side effects, error conditions, or return values. Given the complexity of leaving a group (which may have permissions or notifications implications), 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 description includes an 'Args' section that documents the single parameter 'jid' as 'Group JID', adding meaning beyond the schema (which has 0% description coverage). However, it doesn't explain what a JID is, its format, or where to find it, leaving some ambiguity.
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 WhatsApp group'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'group_join' or 'group_participants_remove' which also involve group membership changes.
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. The description doesn't mention prerequisites (e.g., needing to be a current member), exclusions, or how this differs from similar tools like 'group_participants_remove' (which removes others).
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 ('Add participants') but doesn't mention critical behavioral aspects such as required permissions (e.g., admin rights in the group), rate limits, error conditions (e.g., if users are already members), or what happens on success/failure. This leaves significant gaps for safe and effective use.
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 appropriately sized and front-loaded, with the core purpose stated first ('Add participants to a WhatsApp group.') followed by parameter explanations. There's minimal waste, though the 'Args:' section could be integrated more smoothly. Overall, it's efficient and easy to scan.
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 (adding users to a group) with no annotations and no output schema, the description is incomplete. It lacks information on permissions, error handling, return values, and differentiation from sibling tools. This makes it inadequate for reliable agent use without additional context or trial-and-error.
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 0%, so the description must compensate. It adds basic semantics by explaining that 'jid' is the 'Group JID' and 'users' are 'List of phone numbers or JIDs to add', which clarifies the parameter types beyond the schema's generic string/array. However, it doesn't provide format details (e.g., JID structure, phone number format) or constraints, leaving some ambiguity.
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 ('Add') and resource ('participants to a WhatsApp group'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'group_join' or 'group_participants_remove', which would require more specific language about adding external users versus joining oneself or removing participants.
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 'group_join' (for joining oneself) or 'group_participants_remove' (for removing participants). It lacks context about prerequisites (e.g., needing admin permissions) or exclusions, 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 action ('Rename') which implies a mutation, but doesn't disclose critical behavioral traits: whether this requires admin permissions, if there are rate limits, what happens on success/failure, or if the change is reversible. The description is minimal and lacks necessary 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient with zero wasted words. However, the parameter documentation could be better integrated rather than presented as a separate 'Args:' section, and the overall brevity comes at the cost of completeness.
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, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, permission requirements, or operational constraints. Given the complexity of group management operations, this minimal description leaves too many unanswered questions for effective tool 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 0%, so the schema provides no parameter documentation. The description adds basic semantic meaning by explaining that 'jid' is the 'Group JID' and 'name' is the 'New group name', which clarifies what each parameter represents. However, it doesn't provide format details (e.g., JID structure, name length limits) or validation rules, leaving significant gaps.
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 ('Rename') and resource ('a WhatsApp group'), making the purpose immediately understandable. It distinguishes this tool from other group-related tools like group_info, group_join, or group_leave by specifying the rename action. However, it doesn't explicitly differentiate from all siblings beyond the obvious action 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. It doesn't mention prerequisites (e.g., needing admin permissions), when renaming is appropriate, or what happens if the JID is invalid. There's no comparison to other group management tools like group_participants_add or group_participants_remove.
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 discloses the 'best-effort' nature, hinting at potential unreliability, but lacks critical behavioral details: whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output looks like (e.g., message format, pagination). For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. There's no wasted text, but the structure could be improved by integrating the parameter details more seamlessly or adding a bit more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool for retrieving historical data), no annotations, no output schema, and low schema coverage, the description is incomplete. It misses key details like output format, error handling, or dependencies (e.g., device status). This makes it inadequate for the agent to fully understand how to use the 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 description adds minimal semantics beyond the input schema: it explains that 'chat' is a 'Chat JID to backfill history for', which clarifies the parameter's purpose. However, with 0% schema description coverage and only one parameter, the baseline is 4, but the description doesn't fully compensate by detailing format (e.g., JID structure) or constraints, so it scores slightly lower.
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: 'Request older messages for a chat from your primary device (best-effort).' It specifies the verb ('request'), resource ('older messages'), and target ('chat'), distinguishing it from siblings like 'list_messages' or 'show_message'. However, it doesn't explicitly differentiate from 'search_messages' or 'message_context', which could also retrieve messages, 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 minimal guidance: it implies usage for retrieving historical messages from a specific chat, but offers no explicit when-to-use advice, prerequisites (e.g., device connectivity), or alternatives (e.g., using 'list_messages' for recent messages). Without such context, the agent might struggle to choose this tool appropriately among siblings.
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 context. It states the action is destructive (removal) but doesn't clarify permissions needed, whether the change is reversible, what happens if no alias exists, or any side effects. 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter section. 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.
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, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral outcomes, error conditions, return values, and integration with sibling tools, 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 0%, but the description adds basic meaning for the single parameter 'jid' by identifying it as 'Contact JID'. However, it doesn't explain JID format, examples, or constraints beyond what's implied, leaving gaps in parameter 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') and target ('a local alias from a contact'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling 'set_contact_alias' (which likely adds/modifies aliases), 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?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., contact must exist, alias must be set), exclusions, or when to choose this over other contact management tools like 'refresh_contacts' or 'show_contact'.
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 shows contact details but doesn't mention whether this is a read-only operation, what permissions are required, what happens if the JID is invalid, or the format of the returned details. For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args:' section. It's efficient with minimal waste, though the parameter explanation could be slightly more detailed to improve clarity without sacrificing brevity.
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 read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what details are returned, error conditions, or how this tool relates to siblings like 'search_contacts'. For adequate contextual understanding, more information 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 description adds value by explaining the 'jid' parameter with an example format ('573001234567@s.whatsapp.net'), which the schema (with 0% description coverage) does not provide. However, it doesn't clarify what a JID is, how to obtain it, or validate it, leaving some semantic gaps. With low schema coverage, this partial compensation earns a baseline score.
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 with a specific verb ('Show') and resource ('details of a single contact'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_contacts' or 'refresh_contacts', which would require a 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 like 'search_contacts' or 'list_chats'. It lacks context about prerequisites (e.g., whether the contact must exist in the system) or exclusions, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool shows details but doesn't specify what details are included (e.g., sender, timestamp, content, metadata), whether it requires authentication, if it's read-only or has side effects, or how errors are handled (e.g., for invalid IDs). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first followed by parameter explanations. The two-sentence structure is efficient, though the parameter section could be more integrated. There's no wasted text, but it could benefit from slightly richer context without losing conciseness.
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 (a read operation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like return values, error conditions, or authentication needs, which are critical for an agent to use the tool effectively. The minimal parameter info and absence of usage guidelines further reduce 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 description adds minimal semantics beyond the input schema, which has 0% description coverage. It clarifies that 'message_id' identifies the message and 'chat' specifies the chat JID where the message is located, but doesn't explain format (e.g., string patterns), examples, or constraints. With low schema coverage, this provides some value but doesn't fully compensate for the lack of schema 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 clearly states the tool's purpose with 'Show details of a single message,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'list_messages' (which lists multiple messages) and 'message_context' (which provides context around a message). However, it doesn't explicitly mention how it differs from 'show_chat' or 'show_contact,' which might also display message details indirectly.
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 message ID and chat JID), compare it to siblings like 'list_messages' for browsing or 'message_context' for surrounding messages, or specify use cases (e.g., for detailed inspection vs. quick lookup). This leaves the agent to infer usage from the purpose 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 'update local DB', implying a write operation, but doesn't specify if this requires specific permissions, the nature of the update (e.g., overwrite, merge), or potential side effects like rate limits. This is inadequate for a tool that performs both fetch and update actions.
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 appropriately sized with two sentences: one stating the purpose and action, and another detailing the parameter. It's front-loaded with the main function, but could be slightly more structured by separating usage notes from parameter info. Overall, it's efficient with minimal waste.
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 fetching from WhatsApp and updating a DB, with no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., what group info is fetched), error handling, or the update process's impact. This leaves significant gaps for an AI agent to understand the tool fully.
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 adds significant value beyond the input schema, which has 0% description coverage. It explains the 'jid' parameter as 'Group JID' with an example format ('120363001234567890@g.us'), clarifying its meaning and usage. This compensates well for the schema's lack of documentation, though it doesn't cover all possible semantic nuances.
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 with a specific verb ('Fetch') and resource ('live group info from WhatsApp'), and it distinguishes from siblings like 'list_groups' or 'show_chat' by focusing on detailed information for a specific group. However, it doesn't explicitly differentiate from 'show_chat' which might also retrieve group details, 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 like 'list_groups' (for listing groups) or 'show_chat' (which might show chat info including groups). It mentions updating a local DB, but doesn't specify prerequisites (e.g., authentication status) or when not to use it, leaving usage context unclear.
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 checking three capability areas but doesn't disclose what the tool actually does behaviorally: whether it runs tests, returns status reports, performs repairs, requires specific permissions, has side effects, or produces actionable output. 'Run diagnostics' is vague about the actual behavior and results.
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 - a single sentence that efficiently communicates the core function. Every word earns its place: 'Run' (action), 'wacli diagnostics' (target), and the three specific areas to check. No wasted words or unnecessary elaboration.
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 diagnostic tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'run diagnostics' entails operationally, what format the results take, whether it's interactive or automated, or what happens after diagnostics complete. The agent lacks crucial information about how to interpret and use this tool's output.
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 with 100% schema description coverage. The description doesn't need to explain parameters, and it appropriately doesn't mention any. It focuses on what the tool does rather than parameter details, which is correct for a parameterless tool.
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: 'Run wacli diagnostics' with specific areas to check (store, authentication, search capabilities). It uses a specific verb ('Run') and identifies the diagnostic target ('wacli'), but doesn't explicitly differentiate from sibling tools like 'auth_status' or 'sync_once' that might overlap with some diagnostic functions.
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, appropriate contexts, or exclusions. With siblings like 'auth_status' that might check authentication specifically, there's no indication of when to choose the comprehensive diagnostic tool over more targeted ones.
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 'Import/refresh' which implies a write operation, but does not specify permissions needed, data overwriting behavior, rate limits, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
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 unnecessary words. It is front-loaded and wastes no space, 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, no output schema, and the tool's complexity as a data import/refresh operation, the description is insufficient. It lacks details on what 'refresh' entails (e.g., overwriting, merging), success/failure indicators, or side effects, making it incomplete for safe and 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 schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information and focuses on the tool's purpose.
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 ('Import/refresh') and the resource ('contacts from the WhatsApp session store into local DB'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'search_contacts' or 'show_contact', which handle contacts differently, so it misses 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 such as 'search_contacts' or 'sync_once'. It lacks context on prerequisites, timing, or exclusions, leaving usage unclear beyond the basic action 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?
No annotations are provided, so the description carries the full burden. It states the action ('send') but lacks critical behavioral details: whether this requires prior authentication (e.g., via auth_status), rate limits, error conditions (e.g., invalid number), or what happens on success/failure. 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 highly concise and well-structured: a clear purpose statement followed by bullet-like parameter explanations. Every sentence earns its place, with no redundant or vague language. It's front-loaded with 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?
Given the tool's complexity (a mutation with no annotations, no output schema, and 2 parameters), the description is incomplete. It covers parameters well but misses behavioral context (e.g., authentication needs, side effects, error handling). For a WhatsApp messaging tool, this leaves the agent with insufficient information to use it reliably.
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 adds meaningful semantics beyond the schema. The schema has 0% description coverage (just titles 'To' and 'Message'), but the description explains 'to' as 'Recipient phone number (e.g. '573001234567') or JID' and 'message' as 'Text message to send', including an example format. This compensates well for the low 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 tool's purpose: 'Send a text message via WhatsApp.' It specifies the verb ('send') and resource ('text message'), and distinguishes it from sibling tools like send_file. However, it doesn't explicitly differentiate from other messaging tools (though none exist in siblings), so it's not a perfect 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 doesn't mention prerequisites (e.g., authentication status), compare with send_file for file messages, or specify context like group vs. individual messaging. The agent must infer usage from the purpose 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 default output directory ('wacli media dir'), which adds useful context, but lacks critical details: it doesn't specify file formats, error handling (e.g., if media is missing), permissions needed, or whether the operation is read-only or modifies data. For a download 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 well-structured and front-loaded, starting with the core purpose followed by parameter details. Every sentence earns its place: the first states the action, and the subsequent lines efficiently clarify each parameter without redundancy. It's appropriately sized for a tool with three parameters and no annotations.
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 (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well but lacks output details (e.g., what is returned, success/error responses) and behavioral context like error conditions or side effects. This makes it adequate for basic use but insufficient for robust agent operation without additional inference.
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 0%, so the description must compensate, which it does effectively. It explains all three parameters: 'message_id' and 'chat' are clearly defined with their roles, and 'output' is described with its optional nature and default behavior. This adds meaningful context beyond the bare schema, though it could benefit from examples (e.g., format for 'chat JID').
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 ('Download media') and resource ('from a WhatsApp message'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'send_file' or 'show_message' by focusing on retrieval rather than sending or displaying. However, it doesn't explicitly differentiate from potential similar tools like 'list_messages' beyond the download action.
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 message with media), exclusions (e.g., not for text-only messages), or comparisons to sibling tools like 'show_message' for viewing content without downloading. Usage is implied through parameter descriptions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this lists chats 'from local DB', which implies read-only behavior and potential data freshness concerns, but doesn't specify whether this requires authentication, what happens if the DB is empty, or if there are rate limits. For a read operation with zero annotation coverage, this leaves significant 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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value: the first establishes the tool's function, and the two parameter lines provide essential usage details. No wasted words 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?
Given no annotations and no output schema, the description covers the basic purpose and parameters adequately but lacks important context. It doesn't explain return format (e.g., chat objects with fields), error conditions, or data source limitations. For a 2-parameter read tool with no structured metadata, this is minimally viable but incomplete.
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 adds meaningful context for both parameters beyond the schema, which has 0% description coverage. It explains that 'query' filters chats by name and 'limit' sets a maximum return count with a default of 50. This compensates well for the lack of schema descriptions, though it doesn't detail query syntax or limit constraints.
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 'list' and resource 'WhatsApp chats from local DB', making the purpose immediately understandable. It distinguishes from siblings like list_groups (which lists groups) and list_messages (which lists messages), though it doesn't explicitly mention this distinction. The description is specific but could be more precise about 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 when to use list_chats vs. show_chat (for a single chat) or list_groups (for group chats only), nor does it specify prerequisites like authentication status. Usage context is implied but not 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 data source ('local DB') but lacks critical details: it doesn't specify if this is a read-only operation, what permissions are required, how results are formatted, or if there are rate limits. For a tool with no 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 highly concise and well-structured, with a clear purpose statement followed by a bullet-point list of parameters. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral context (e.g., read/write nature, error handling) and usage guidelines, which are important for a tool interacting with a local database in a multi-tool environment.
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 adds meaningful context for both parameters beyond the schema, which has 0% description coverage. It explains that 'query' is an 'Optional search string to filter groups' and 'limit' sets 'Max results (default 50)', clarifying their purposes and default values, effectively compensating for the schema's lack of 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 tool's purpose with a specific verb ('List') and resource ('WhatsApp groups from local DB'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_chats' or 'show_chat', which might also retrieve chat-related data, 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 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 sibling tools like 'list_chats' or 'show_chat', nor does it specify prerequisites such as authentication status or data availability in the local DB, leaving the agent without contextual usage cues.
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 mentions 'recent' messages but doesn't define what 'recent' means (e.g., time window). It also lacks details on permissions needed, rate limits, pagination behavior, or what happens if no filters are applied. The description is too vague 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' section. Every sentence earns its place with no redundant information, making it 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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters well but lacks behavioral context (e.g., output format, error handling). Without annotations or output schema, more detail on what the tool returns 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?
The schema description coverage is 0%, but the description compensates well by explaining all four parameters in the 'Args' section. It adds meaning beyond the schema by specifying date formats (YYYY-MM-DD or RFC3339) and default values (limit default is 50). However, it doesn't clarify what 'chat JID' is or provide examples, leaving some ambiguity.
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: 'List recent WhatsApp messages with optional filters.' It specifies the verb ('List'), resource ('WhatsApp messages'), and scope ('recent'). However, it doesn't explicitly differentiate from sibling tools like 'search_messages' or 'show_message', 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 sibling tools like 'search_messages' (which might offer different filtering capabilities) or 'show_message' (for single messages), nor does it specify prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it mentions the search functionality, it doesn't describe important behavioral aspects like whether this is a read-only operation, what the return format looks like, whether results are paginated, or if there are rate limits. For a search tool with zero annotation coverage, this leaves significant 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 and well-structured: a clear purpose statement followed by parameter explanations in a simple format. Every sentence earns its place with no wasted words, 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 moderate complexity (search with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context and output information that would be helpful for an AI agent. It meets the minimum viable threshold but has clear gaps.
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 0% schema description coverage, the description compensates well by explaining both parameters: 'query' as the search term and 'limit' with its default value of 50. This adds meaningful context beyond the bare schema, though it doesn't specify format details like query syntax or limit constraints.
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: 'Search WhatsApp contacts by name or phone number.' This specifies the verb (search), resource (WhatsApp contacts), and scope (by name or phone number). However, it doesn't explicitly differentiate from sibling tools like 'show_contact' or 'refresh_contacts', 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 like 'show_contact' (for specific contacts) or 'refresh_contacts' (for updating contact lists). It only describes what the tool does, not when it's appropriate or when other tools might be better suited.
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 shows details but does not specify what details are included, whether it requires authentication, if it's read-only, or any error conditions. This leaves significant gaps for a tool that presumably fetches data.
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 purpose in the first sentence, followed by a concise parameter explanation. It uses minimal words effectively, with no redundant information, 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 low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter semantics but lacks behavioral details like return format or error handling, which are important for a data-fetching tool in this context.
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 only one parameter and 0% schema description coverage, the description compensates by explaining the 'jid' parameter with examples (e.g., '573001234567@s.whatsapp.net' or '...@g.us' for groups). This adds meaningful context beyond the bare schema, though it could specify format constraints more explicitly.
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: 'Show details of a single chat.' It specifies the verb ('show') and resource ('chat'), but does not distinguish it from sibling tools like 'show_contact' or 'show_message' beyond the resource type, which is why it doesn't get a 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 sibling tools like 'list_chats' for browsing or 'show_contact' for contact details, nor does it specify prerequisites or exclusions for 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Remove') but doesn't mention critical aspects like required permissions (admin status), whether removal is reversible, rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Both sentences earn their place, though the parameter section could be slightly more integrated (e.g., 'Removes specified users from a WhatsApp group using the group JID and user identifiers').
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, no output schema, and 2 required parameters, the description is incomplete. It lacks information about return values, error handling, permissions, and side effects, leaving the agent with insufficient context to use the tool safely and 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 description explicitly lists both parameters (jid, users) and provides semantic clarification: 'jid' is the 'Group JID' and 'users' are 'List of phone numbers or JIDs to remove'. With 0% schema description coverage, this adds substantial value beyond the bare schema, though it could specify format examples (e.g., phone number format).
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 ('Remove participants') and resource ('from a WhatsApp group'), distinguishing it from sibling tools like group_participants_add, group_participants_promote, and group_participants_demote. It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 group_leave (for self-removal) or group_participants_demote/promote (for role changes). It lacks context about prerequisites (e.g., admin permissions) or exclusions, leaving 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 full burden for behavioral disclosure. It states the action ('promote') but doesn't cover critical aspects like required permissions, whether the operation is reversible, error conditions (e.g., if users aren't in the group), or rate limits. This leaves significant gaps for safe and effective use.
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 in the first sentence, followed by a structured 'Args' section. Every sentence earns its place by providing essential information without 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.
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 with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, reversibility), error handling, and return values, which are critical for an admin-promotion operation in a messaging platform context.
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 0%, so the description must compensate. It adds meaningful context by explaining that 'jid' is a 'Group JID' and 'users' are 'List of phone numbers or JIDs to promote', clarifying the nature and format of inputs beyond the bare schema. However, it doesn't specify exact JID/phone number formats or validation rules.
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 ('Promote participants to admin') and resource ('in a WhatsApp group'), distinguishing it from sibling tools like group_participants_demote and group_participants_remove. It uses precise terminology that directly communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 group_participants_demote or group_participants_add. The description lacks context about prerequisites (e.g., user permissions, group ownership) or scenarios where promotion is appropriate, leaving usage decisions to inference.
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 action ('Send') but doesn't describe what happens on success/failure, rate limits, authentication requirements, file size limits, or whether the operation is synchronous/asynchronous. The description is minimal 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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value: the first establishes context, and each parameter line provides necessary semantic information without redundancy. It's appropriately sized for a 5-parameter tool.
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 file-sending tool with no annotations and no output schema, the description covers basic purpose and parameters adequately but lacks important context about behavioral aspects (success criteria, error handling, limitations). It's minimally viable but has clear gaps in operational transparency.
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 provides clear semantic explanations for all 5 parameters beyond the schema's 0% coverage. It explains 'to' as recipient phone/JID, 'file_path' as server path, 'caption' as optional text, 'filename' as display name with default behavior, and 'mime' as type override. This compensates well for the schema's lack of descriptions.
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 with specific verb ('Send') and resource ('a file via WhatsApp'), and distinguishes it from sibling tools like 'send_message' by specifying file types (image, video, audio, document). It provides immediate clarity about what the tool does.
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 'send_message' (for text) or 'download_media' (for receiving files). It mentions WhatsApp context but doesn't specify prerequisites, error conditions, or appropriate scenarios for file versus message sending.
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 without disclosing behavioral traits. It doesn't mention whether this is a persistent change, if it requires specific permissions, what happens on invalid JID, or if there are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter documentation. The two-sentence structure is efficient, though the parameter documentation could be integrated more smoothly rather than as a separate 'Args:' section.
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, no output schema, and 2 parameters at 0% schema coverage, the description is insufficient. It doesn't explain what happens on success/failure, whether the change is reversible, or how to verify the alias was set. The minimal information provided leaves too many operational 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?
The description explicitly lists both parameters with brief explanations ('Contact JID', 'Alias to set'), adding meaning beyond the schema which has 0% description coverage. However, it doesn't provide format details (e.g., JID structure, alias length limits) or examples, leaving significant gaps in parameter understanding.
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 ('Set a local alias'), the resource ('for a contact'), and distinguishes it from its sibling 'remove_contact_alias' by specifying the opposite operation. It uses precise language that leaves no ambiguity about what the tool does.
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 usage context by mentioning 'local alias (nickname)', suggesting it's for personal labeling rather than system-wide changes. However, it doesn't explicitly state when to use this versus alternatives like 'show_contact' or 'search_contacts', nor does it mention prerequisites like contact existence.
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 ('demote') but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error conditions, or rate limits. 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 front-loaded with the core purpose in the first sentence, followed by parameter explanations. Every sentence earns its place with zero waste, making it highly 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?
Given this is a mutation tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It lacks information about permissions, side effects, return values, and error handling, which are critical for safe tool invocation.
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 0%, so the description must compensate. It explains both parameters: 'jid' as 'Group JID' and 'users' as 'List of phone numbers or JIDs to demote', adding meaningful context beyond the bare schema. However, it doesn't specify format details (e.g., JID structure).
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 ('demote'), target resource ('admin participants in a WhatsApp group'), and scope (admin participants only). It distinguishes from siblings like group_participants_promote (opposite action) and group_participants_remove (different outcome).
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 demoting admin participants, but doesn't explicitly state when to use this vs alternatives like group_participants_remove or prerequisites (e.g., needing admin rights). It distinguishes from promote but lacks comprehensive 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 full burden for behavioral disclosure. While it indicates this is a read operation ('Show'), it doesn't describe what information is returned, whether it requires specific permissions, or what the response format looks like. The description is minimal and lacks important 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 a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point.
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 zero-parameter tool with no output schema, the description provides basic purpose but lacks important context about what authentication status information is returned. Given the complexity is low (no parameters), the description is minimally adequate but could benefit from specifying what 'status' includes (e.g., authenticated, token expiry, user identity).
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct for this case. Baseline for zero parameters is 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 action ('Show authentication status') and target resource ('current wacli session'), distinguishing it from all sibling tools which focus on messaging, contacts, groups, or system operations rather than authentication status.
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 (checking session authentication) but doesn't explicitly state when to use this tool versus alternatives or what prerequisites might exist. No guidance is provided about when not to use it or what alternatives might be available.
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 implementation details (FTS5/LIKE fallback) and default values (limit default 50), but doesn't cover important aspects like rate limits, authentication requirements, pagination behavior, error conditions, or what the return format looks like. For a search tool with 7 parameters and no output schema, this leaves significant gaps.
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 well-structured with a clear purpose statement followed by parameter explanations in a consistent format. Every sentence earns its place, though the parameter explanations could be slightly more concise. The information is front-loaded with the core functionality 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?
Given the tool's complexity (7 parameters, search functionality), lack of annotations, and no output schema, the description is incomplete. While it excellently documents parameters, it misses crucial behavioral context like return format, error handling, performance characteristics, and how results are structured. For a search tool without output schema, describing the return format would be particularly important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all 7 parameters. Each parameter gets a concise explanation that adds meaning beyond the schema's titles, including optionality indicators, format requirements (YYYY-MM-DD or RFC3339 for dates), enumerated values (image|video|audio|document for media_type), and default values (limit default 50).
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 performs 'Full-text search across WhatsApp messages' with specific implementation details (FTS5 if available, LIKE fallback). It distinguishes itself from sibling tools like 'list_messages' by focusing on search functionality rather than listing, and from 'search_contacts' by targeting messages instead of contacts.
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 through parameter explanations (e.g., 'Optional chat JID filter'), but doesn't explicitly state when to use this tool versus alternatives like 'list_messages' or 'show_message'. It provides some guidance through parameter semantics but lacks explicit comparison with sibling 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 the full burden of behavioral disclosure. It describes the three-step process (connect, fetch, exit) which is helpful, but lacks critical details: it doesn't specify what 'sync' entails beyond fetching messages, doesn't mention authentication requirements, error handling, rate limits, or what happens to existing messages. For a tool with no annotations, 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 structured and concise. The first sentence states the core purpose, followed by a clear bullet-point list explaining each parameter. Every sentence earns its place with no wasted words. The information is front-loaded with the main purpose 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?
Given 3 parameters with 0% schema coverage and no annotations or output schema, the description does a good job explaining parameter semantics but falls short on overall completeness. It doesn't explain what 'sync' means operationally, what types of messages are fetched, how results are returned, or error conditions. For a tool with no structured metadata, the description should provide more behavioral context.
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 provides clear semantic explanations for all three parameters beyond what the schema offers (which has 0% description coverage). It explains that 'refresh_contacts' refreshes contacts from session store, 'refresh_groups' refreshes joined groups live, and 'download_media' downloads media in the background during sync. This adds meaningful context that the schema's boolean types and titles don't provide.
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 with specific verbs and resources: 'Sync messages once (connect, fetch new messages, then exit).' It distinguishes from siblings by specifying a one-time sync operation rather than continuous syncing or other message-related functions. The description explicitly mentions the three-step process: connect, fetch new messages, then exit.
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 through 'once' and 'then exit,' suggesting this is for a single synchronization operation rather than ongoing syncing. However, it doesn't explicitly state when to use this tool versus alternatives like continuous sync tools or when not to use it. No specific alternatives are named among the sibling 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. It states the tool shows messages, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, rate limits, error conditions, or what the output format looks like (e.g., list of messages with metadata). 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bullet-like 'Args:' section that efficiently explains parameters. Every sentence earns its place with no wasted words, making it easy to scan and understand.
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 4 parameters with 0% schema coverage and no output schema, the description does well on parameters but lacks behavioral context (e.g., output format, error handling). It's complete enough for basic usage but inadequate for full agent understanding, especially without annotations to cover safety or performance traits.
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 0%, so the description must compensate. It adds clear meaning beyond the schema by explaining all 4 parameters: 'message_id' as the center point, 'chat' as the location, and 'before'/'after' as counts with defaults. This fully documents the parameters, though it doesn't specify units or constraints (e.g., max values).
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 with a specific verb ('Show') and resource ('surrounding messages around a specific message ID'), distinguishing it from siblings like 'show_message' (which shows a single message) and 'list_messages' (which lists messages without centering on one). The phrase 'for context' adds useful nuance about the tool's intent.
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 usage context by specifying it centers on a message ID to get surrounding messages, which distinguishes it from tools like 'show_message' (single message) or 'list_messages' (general listing). However, it doesn't explicitly state when NOT to use it or name alternatives, missing full explicit 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 full burden for behavioral disclosure. While it describes the basic action, it doesn't mention important behavioral aspects: whether this requires specific permissions, what happens on success/failure, if there are rate limits, or what the user experience will be. For a mutation tool with zero annotation coverage, this leaves significant 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 front-loaded with the core purpose in the first sentence, followed by parameter details in a clear 'Args:' section. Every sentence earns its place with no wasted words, making it 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 single-parameter mutation tool with no annotations and no output schema, the description covers the basic purpose and parameter semantics adequately. However, it lacks information about return values, error conditions, or behavioral constraints that would be important for complete understanding. It meets minimum viable standards but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description fully compensates by providing essential semantic context. It explains what the 'code' parameter represents ('Invite code from a group link'), specifies the exact format ('the part after https://chat.whatsapp.com/'), and clarifies the source. This adds substantial value beyond the bare 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 clearly states the specific action ('Join a WhatsApp group') and resource ('by invite code'), distinguishing it from sibling tools like group_leave, group_info, or group_rename. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 usage context by specifying the invite code format ('the part after https://chat.whatsapp.com/'), but doesn't explicitly state when to use this tool versus alternatives like group_participants_add or when not to use it (e.g., if already in the group). It provides clear context but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![mcp-wacli MCP server](https://glama.ai/mcp/servers/grrek/mcp-wacli/badges/card.svg)](https://glama.ai/mcp/servers/grrek/mcp-wacli)

Score Badge

Copy to your README.md:

[![mcp-wacli MCP server](https://glama.ai/mcp/servers/grrek/mcp-wacli/badges/score.svg)](https://glama.ai/mcp/servers/grrek/mcp-wacli)

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/grrek/mcp-wacli'

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