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
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a unique purpose: ask sends a question and waits for reply, check_replies retrieves messages, check_status shows account info, notify sends notifications, upgrade handles account upgrades. No overlapping functionality.
Tools use a mix of single verbs (ask, notify, upgrade) and verb_noun (check_replies, check_status). The pattern is mostly consistent but not perfectly uniform.
Five tools cover the core functionalities of a WhatsApp assistant (sending messages, checking replies, account management) without being excessive or insufficient.
The set covers key operations: asking, replying, notifying, and account handling. Missing features like conversation history are minor for the stated purpose.
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`.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| buttons | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly discloses blocking behavior, timeout (max 90 seconds), return values (reply text and/or chosen option, or a note on timeout), and that the question is delivered even on timeout. The button behavior is also explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and well-structured. It opens with the main purpose and behavior, then explains parameters in a clear, scannable format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, but an output schema, the description covers return values and timeout behavior adequately. It mentions what is returned on success and timeout. Minor omission: it does not clarify the format of the reply when buttons are used versus free-text, but overall it is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: 'text' is the question, 'buttons' are optional up to 3 tappable reply buttons (omit for free-text), and 'timeout' is seconds to wait (max 90). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asks a human a question on WhatsApp and blocks until they reply (or timeout). It specifies the verb (ask), resource (human on WhatsApp), and blocking behavior, distinguishing it from siblings like check_replies and notify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get human input mid-task) and describes the optional buttons vs free-text input. It also mentions that on timeout, the answer is retrievable via check_replies, providing a fallback. However, it does not explicitly state when not to use it or name alternatives beyond check_replies.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| since | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains long-polling behavior and return values (messages + cursor) but omits side effects, permissions, or state changes. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with output schema, the description covers core functionality and parameter usage. Minor omission: no mention of zero-result handling or errors, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so by explaining 'since' as a cursor for pagination and 'wait' for long-poll timeout, adding meaning beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the verb 'pull' and resource 'inbound WhatsApp messages from the human to pingwa', with explicit use cases (out-of-band instructions or late answers). This distinguishes it from siblings like ask, notify, or check_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use (out-of-band or late answers) and how parameters work (since as cursor, wait for long-poll). It lacks explicit exclusions but the context is clear enough for an agent to decide.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the output (plan, quota, reply window status) but does not explicitly state it is a read-only operation, nor does it mention permissions, rate limits, or other behavioral traits. The verb 'Show' implies non-destructive behavior, which is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the purpose and 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the description lists the three key pieces of information returned (plan, quota, reply window status), it is complete for the tool's purpose. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the output without addressing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the account's plan, monthly quota, and WhatsApp reply window status. The verb 'Show' combined with specific resources makes the purpose unambiguous and distinguishes it from sibling tools like 'ask' or 'notify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives (e.g., ask, check_replies). The context implies it is for account status, but the description lacks explicit use-case directives or exclusions.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| image_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: character limit for text, conditional image delivery based on 24h window, return of queued message id, and actionable errors on quota/auth. This provides useful transparency beyond raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at 3 sentences, front-loads the main purpose, then efficiently adds parameter and behavioral details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return value, and error handling. Lacks mention of prerequisites or permissions (though implied), and could note that it's specifically WhatsApp channel. Still sufficient given low complexity and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so description supplies all parameter meaning. It specifies text character limit (1-1024), image_url must be public https, and describes conditional behavior. This fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sends a WhatsApp notification to the account owner's own phone, with specific verb and resource. It distinguishes itself from sibling tools (ask, check_replies, check_status, upgrade) which do not involve sending notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While sibling names imply distinct purposes, the description does not clarify when notify is appropriate or when to choose other tools like ask or check_status.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool returns a Stripe Checkout URL, does not require a password, and that Stripe handles payment. For already Pro accounts, it returns a billing-portal URL. It does not mention potential side effects like starting a subscription, but the tool is non-destructive and returns a URL for human action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and each sentence adds value. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description adequately explains the return behavior (Stripe URL vs billing portal) and handles the edge case of already Pro accounts. No additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds all necessary context about what the tool does without needing parameters, fully covering the intended use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a link'), the resource ('upgrade the account to Pro'), and the effect ('raises the monthly quota'). It is distinct from sibling tools which handle Q&A, replies, status, and notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to upgrade to Pro, or if already Pro to manage/cancel via billing portal) and provides context about the Stripe checkout process. It does not explicitly state when not to use it or list alternatives, but the purpose is clear given sibling tools.
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!