A
license-
qualityB
maintenanceHuman-in-the-loop approvals and notifications for AI agents via WhatsApp. Enables Cursor, Claude Code, and autonomous AI agents to reach users away from their computers.
Last updated
60
ISC
pingwa
Server Details
Zero-setup WhatsApp notifications + human-in-the-loop for AI agents — text 'join', send in 60s.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- grzgrzgrz3/pingwa-client
- GitHub Stars
- 0
- Server Listing
- pingwa
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.6/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation4/5
Tools are mostly distinct: ask (blocking question), check_replies (retrieve messages), notify (send notification), check_status (account info), upgrade (plan management). There is some overlap between ask and check_replies, but descriptions clarify their different purposes.
Naming Consistency5/5
All tool names are single lowercase verbs, following a consistent verb-only naming pattern. No mixing of conventions.
Tool Count5/5
Five tools is appropriate for the server's purpose of WhatsApp interaction, covering core actions without being excessive or too sparse.
Completeness4/5
The tool set covers key operations: asking questions, retrieving replies, sending notifications, checking status, and upgrading. Minor gaps exist (e.g., no separate send image tool), but the core workflow is supported.
Available Tools
5 toolsaskAInspect
Ask the human a question on WhatsApp and BLOCK until they reply (or timeout).
`text` is the question. `buttons` (optional, up to 3) render as tappable reply
buttons; omit them to invite a free-text answer the human types on their phone —
use this to let the human steer you mid-task. `timeout` is seconds to wait
(max 90). Returns the human's reply (free text and/or the chosen option). On
timeout, returns a note — the question was delivered and the answer is still
retrievable via `check_replies`.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| buttons | No | ||
| timeout | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: blocking until reply or timeout, buttons optional, timeout max 90, return on timeout is a note with retrievable answer. No destructive behavior is implied, but the blocking nature is clearly disclosed.
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?
Description is two paragraphs with clear structure: first sentence defines purpose, then bullet-like explanations of parameters and timeout handling. Backticks for parameter names aid readability. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description needn't detail return values. It covers the blocking behavior, optional buttons, timeout handling, and how to retrieve answers on timeout. This is complete for the tool's complexity.
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?
Schema coverage is 0%, so description must explain parameters. It defines text as 'the question,' buttons as 'optional up to 3 tappable reply buttons; omit for free-text,' and timeout as 'seconds to wait (max 90).' This adds complete meaning beyond the schema's minimal type info.
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?
Description clearly states 'Ask the human a question on WhatsApp and BLOCK until they reply (or timeout).' It specifies the verb (ask), resource (human on WhatsApp), and blocking behavior. It distinguishes from sibling check_replies by mentioning that timeout replies are retrievable via that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (when you need a question answered), optional buttons vs free-text, timeout limits (max 90 seconds), and directs to check_replies for retrieving answers on timeout. This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_repliesAInspect
Pull inbound WhatsApp messages the human sent to pingwa (out-of-band
instructions, or late answers to an ask). since is a cursor from a previous
call (pass it back to get only newer messages); wait long-polls up to that many
seconds for something to arrive. Returns the messages and a new cursor.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| since | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: long-polling (`wait` parameter), cursor-based pagination (`since`), and return value (messages + cursor). It does not mention side effects or auth requirements, but as a read-only poll, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states the purpose clearly; the second explains parameters and return value. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters and behavior. Since an output schema exists, return values are likely well-defined in the schema. The description is complete enough for correct usage.
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?
Schema coverage is 0%, but the description fully explains both parameters: `since` as a cursor for pagination and `wait` as a timeout for long-polling. This adds meaning beyond the schema's property names and defaults.
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: 'Pull inbound WhatsApp messages the human sent to pingwa'. It specifies the use case (out-of-band instructions or late answers to an `ask`) and distinguishes from siblings like `ask` (sending questions) and `notify` (outbound messages).
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 explains when to use this tool (for inbound messages, especially late answers to `ask`) and how the parameters work. It does not explicitly state when not to use it, but the context provided is sufficient for an agent to recognize appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_statusAInspect
Show the pingwa account's plan, remaining monthly quota, and whether the free 24h WhatsApp reply window is currently open.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implicitly indicates a read-only operation ('Show'), but does not explicitly state that it is non-destructive or list any authentication or rate limit considerations. For a simple query tool this is adequate but not exemplary.
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?
Single sentence front-loads the action and specifies outputs. No wasted words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an existing output schema. The description adequately explains what the tool returns. No additional context is necessary.
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?
There are zero parameters and schema coverage is 100% trivially. Per guidelines, baseline for 0 parameters is 4. The description adds no parameter details but none are needed.
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 shows the pingwa account's plan, remaining monthly quota, and free WhatsApp reply window status. It uses a specific verb ('show') and resource, and distinguishes from siblings like 'check_replies' which likely operates on individual messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given, but the purpose is straightforward. Usage is implied from the description, but the description does not explicitly compare to siblings or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notifyAInspect
Send a WhatsApp notification to the account owner's own phone.
`text` is the message (1-1024 chars). `image_url` (optional) is a public https
image link — a screenshot, chart or diff — delivered as an image with `text` as
the caption when the user's 24h window is open (otherwise text only). Returns a
confirmation with the queued message id; raises an actionable error on quota/auth.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| image_url | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: how image_url works conditionally (24h window), the return value (confirmation with queued message id), and error handling (actionable error on quota/auth). This is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and efficiently covers parameters, behavior, and return values in a single paragraph with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count and presence of an output schema, the description is complete. It covers all necessary aspects for an agent to use the tool correctly, including error scenarios.
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?
Despite 0% schema coverage from context signals, the description provides rich semantics for both parameters: text limits (1-1024 chars) and image_url usage (public https, conditional image delivery). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a WhatsApp notification to the account owner's own phone, specifying the verb 'send' and the resource 'WhatsApp notification'. It distinguishes from siblings like 'ask' and 'check_replies' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for self-notification and explains image behavior, but does not explicitly state when to use versus alternatives or when not to use. The context is clear, leaving no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upgradeAInspect
Get a link to upgrade the account to Pro (raises the monthly quota).
Returns a Stripe Checkout URL for the human to open and pay — no pingwa password needed, the card is handled by Stripe. If the account is already Pro, returns a billing-portal URL to manage or cancel instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a URL, does not require a password, uses Stripe for payment, and behaves differently for already-Pro accounts. No contradictory or missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and efficiently explains the two return URL cases. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a clear self-contained description, the description fully explains the tool's behavior and return types. The existence of an output schema is noted but the description already covers the return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100%. The description adds no further parameter details, but baseline score of 4 is appropriate for zero-parameter tools.
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 returns a link to upgrade the account to Pro, and specifies two distinct outcomes (Stripe Checkout URL for non-Pro, billing portal URL for existing Pro). The verb 'Get a link' and resource 'upgrade the account' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to upgrade to Pro or manage/cancel existing Pro. However, it does not explicitly state when not to use it or mention alternatives among sibling tools (ask, check_replies, etc.), but the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceHuman-in-the-loop approval inbox for AI agents: an agent proposes an action (send email, post comment, run a command), a human approves, rejects, or edits it from a web, mobile, or Slack/Discord/Telegram inbox, and the agent only runs on approval. Full audit trail, self-hostable (MIT).Last updated81MIT
- AlicenseBqualityBmaintenanceEnables AI agents to control WhatsApp, including sending messages and media, reading chats, managing groups and communities, with QR/pairing auth and session persistence.Last updated14112MIT
- AlicenseAqualityDmaintenanceSlack for AI agents — rooms, messaging and context sharing for multi-agent collaboration.Last updated6MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.