Wawp MCP Server

Server Quality Checklist

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

Latest release: v3.5.0
Disambiguation5/5
Each tool has a distinct action: sending files, listing endpoints, generating code, executing raw requests, setting config, getting SDK info, and checking health. The potential overlap between send_local_file and execute_request is minor since one is specific and the other generic.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern, e.g., send_local_file, list_endpoints, get_session_health. The verbs vary but are clear and stylistically consistent.
Tool Count5/5
With 7 tools, the set is well-scoped for an integration helper server. Each tool serves a clear purpose, and the count is within the optimal range.
Completeness3/5
The server covers configuration, session health, file sending, and API introspection, but lacks dedicated tools for common WhatsApp operations like sending text messages. However, execute_request and SDK code generation can partially compensate, so there are minor gaps.
Average 3.2/5 across 7 of 7 tools scored. Lowest: 2.4/5.
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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 discloses no behavioral traits such as side effects, authentication requirements, rate limits, or error handling. It only states 'execute' without explaining what happens on success/failure or whether the request is actually sent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and efficient in length, but it under-specifies crucial details. It is front-loaded with the core purpose but lacks structural elements like parameter guidance or usage notes, making it minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 4 parameters, nested objects, no output schema, and no annotations. The description provides almost no information for an agent to correctly select and invoke it. It fails to cover the required context for successful utilization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (path, method, body, params). It doesn't explain how to format the raw request, what each parameter controls, or how they relate. The method enum is the only hint, which is already in the schema.
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 executes a raw request to the Wawp API, which is a specific verb+resource pairing. It implicitly differentiates from siblings like send_local_file or list_endpoints by focusing on raw API requests, though it doesn't explicitly name the 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?
It says 'useful for quick tests' but provides no guidance on when to use it versus the sibling tools, nor any exclusions or prerequisites. This is minimal usage context without alternatives.
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 is the sole source of behavioral information. It does disclose that the update applies 'for the current session', which is useful, but it omits potential side effects, persistence, validation behavior, or what happens if credentials are invalid. The poor coverage leaves significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and object. There is no wasted wording, and every word contributes meaning. It is appropriately concise for the information it conveys.
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?
With 3 parameters, no annotations, and no output schema, the description is severely under-specified. It tells the agent that credentials are updated but leaves the meaning of each parameter, the expected effects, and any return behavior unexplained. The description does not sufficiently support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters (instance_id, test_number, access_token). The unusual parameter 'test_number' is especially ambiguous. The description adds no meaning beyond the raw schema listing.
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 uses a specific verb 'Update' and identifies the resource as 'Wawp API credentials for the current session', which clearly distinguishes it from sibling tools focused on file sending, endpoint listing, and request execution. It is not a tautology, but it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention situations requiring credential updates, prerequisites, or any exclusions. It is a standalone statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the basic action and API type, but does not mention authentication requirements, side effects, error handling, rate limits, or any other operational details. Users would be left blind to important behavioral aspects.
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 very short (two clauses) and gets to the point. However, the second clause ('Better to suggest SDK version to the user') is a bit of an odd aside and could be considered non-essential. Still, it is concise and free of unnecessary fluff, so it earns a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is extremely thin. It does not explain what happens after sending (e.g., response format, success/failure indicators), any prerequisites like an active session (given sibling get_session_health), or file constraints. The description leaves many important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 for explaining parameters. It mentions no parameters at all, leaving the schema's required fields (file_path, chatId, type) and optional caption unexplained. For example, the 'type' enum values are not elaborated. The description adds zero value beyond the parameter names.
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 ('Upload and send a local file to WhatsApp') and specifies the mechanism ('using raw API'). This distinguishes it from SDK-based alternatives, though it doesn't explicitly name sibling tools. The purpose is understandable but slightly vague due to the odd final clause about suggesting the SDK version.
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 phrase 'Better to suggest SDK version to the user' implies that the SDK approach is preferred and this raw API tool is for cases when SDK is not used. However, there is no explicit 'when to use' or 'when not to use' statement, nor are alternatives named. The guidance is minimal and implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It lacks any mention of side effects, read-only nature, authentication needs, rate limits, or how the output is structured. 'List' implies a read operation but doesn't explicitly guarantee it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise and avoids any unnecessary content, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description is adequate but not complete. It lacks explanation of the 'category' parameter, the return format, and any behavioral details. Given no output schema or annotations, the description could have clarified how the endpoint list is structured and how the optional parameter affects results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes an optional 'category' parameter with no description, and the tool description does not explain it. Schema description coverage is 0%, so the description must compensate, but it doesn't. The statement 'List all available' even potentially conflicts with a filtering parameter, leaving the parameter's purpose entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('all available Wawp API endpoints'), making it obvious what the tool does. It distinguishes itself from sibling tools like send_local_file or execute_request by focusing on endpoint discovery.
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 offers no guidance on when to use this tool versus alternatives, no exclusions, and no mention of typical scenarios. The only implicit hint is that it lists endpoints, but no explicit 'use this when...' is provided.
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 present, so the description carries the full burden of behavioral disclosure. It only says 'Generate' code, but does not explain whether this is a read-only operation, whether it returns code directly, or if it requires any specific permissions or network access. It lacks details on side effects or output behavior, leaving the agent to assume the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the action, and contains no filler. It is appropriately concise for the tool's simplicity.
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 output schema, no annotations, and only 50% parameter coverage, the description is too sparse. It fails to mention what the tool returns, how the parameters influence the output, or any prerequisites. It is not complete enough for an agent to know precisely what to expect or how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the parameters 'task' or 'language' at all. The schema provides a description for 'task' but only enum values for 'language' with no explanation of their meaning. With schema coverage at 50%, the description should compensate but does not, leaving the language parameter semantics vague.
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 action ('Generate professional production-ready code') and resource ('using official Wawp SDKs'), and explicitly frames it as the preferred integration method. It is unambiguous and easily distinguishes from sibling tools like send_local_file or list_endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: 'This is the preferred way to integrate Wawp.' It implies using this tool for Wawp integration, but does not explicitly mention alternatives or when-not conditions. Still, it provides sufficient directional 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?
No annotations are provided, so the description carries the full burden. It states the tool checks connectivity but does not describe return values, error behavior, or confirm it's read-only with no side effects. For a health check, this minimal disclosure leaves behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise, with the key action and resource front-loaded. There is zero wasted wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is largely complete. However, it could be more explicit about the result format (e.g., 'returns true if connected'), which would enhance completeness given the absence of annotations and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers everything with 100% coverage. Per guidelines, a 0-parameter tool receives a baseline of 4, and the description adds nothing about parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resource 'WhatsApp session' with its health status. It distinguishes from sibling tools like send_local_file and list_endpoints, which are about file sending and endpoint listing, none of which concern session connectivity.
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 verifying session connectivity but does not explicitly state when to use this tool versus alternatives. It offers no exclusions or references to other tools, leaving the timing to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only, informational operation ('Get detailed information'), but it does not explicitly state that it is non-mutating, nor does it describe the output format or any limitations. The context is helpful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences that front-load the action and follow with a direct usage directive ('USE THIS'). Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is largely complete: it specifies the tool's function and use case. However, it does not mention the 'cli' platform option or what the response looks like, which is a minor gap given the tool's simplicity. Overall, it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the 'platform' parameter. It does list the SDK names (Node.js, PHP, Python, Laravel), which map to enum values and clarify the parameter's purpose. However, it omits the 'cli' option and does not explain that the parameter is optional, which leaves a gap for the agent.
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: 'Get detailed information and installation guides for official Wawp SDKs'. It names specific SDKs (Node.js, PHP, Python, Laravel), which distinguishes it from sibling tools like execute_request or generate_starter_code. The verb 'Get' plus the resource 'information and installation guides' makes the action explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'USE THIS to help the user integrate WhatsApp into their projects.' This tells the agent when to invoke the tool. However, it does not explicitly mention when not to use it or compare to alternative tools, so it lacks the explicit exclusion criteria that would earn a 5.
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:

[![wawp-mcp-server MCP server](https://glama.ai/mcp/servers/Whatsapp-Automation-web-platform/wawp-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Whatsapp-Automation-web-platform/wawp-mcp-server)

Score Badge

Copy to your README.md:

[![wawp-mcp-server MCP server](https://glama.ai/mcp/servers/Whatsapp-Automation-web-platform/wawp-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Whatsapp-Automation-web-platform/wawp-mcp-server)

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/Whatsapp-Automation-web-platform/wawp-mcp-server'

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