Parley
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_channelsA | List the messaging channels Parley supports and each channel's capabilities (how you link it, media/groups/threads). |
| list_connectionsA | List the messaging accounts linked to Parley (there can be several per channel, e.g. a personal and a work WhatsApp), with each one's number ( |
| connectA | Start linking a messaging account (e.g. WhatsApp) to Parley. You can link several on one channel (another WhatsApp number is just another connect); linking a number that is already linked replaces the old link. Returns a link URL to open in a browser (scan the QR / authorize), and a connection id to poll with connection_status. |
| connection_statusB | Check a connection. While linking, returns the link material (e.g. the WhatsApp QR string). Returns "connected" once live. |
| read_inboxA | Read recent messages across all your connected accounts, newest first (each says which |
| list_chatsA | List the chats (people and groups) agents can see (everything except what the account holder ignored), across all connected accounts, most recent first (the same person can appear once per account). |
| searchA | Search like WhatsApp's search bar, across all your connected accounts (or one, or one chat): |
| get_notificationsA | What came in from the other side since chats were last read: totals ( |
| send_messageA | Queue a message on a connected channel: text, or a photo, video, GIF, voice note or document (pass |
| load_historyA | Fetch a chat's older messages from the account holder's phone, as WhatsApp's own "get older messages from your phone" does: the |
| react_to_messageA | React to a message with an emoji, as the account holder would from their phone. Paced like a reply. Pass an empty emoji to take your reaction back; a new one replaces the old. |
| delete_messageA | Delete a message the account sent, for everyone in the chat, as the account holder would from their phone (the chat shows "This message was deleted"). Works on messages sent through Parley or from the phone, for about two days after sending. Paced like a reply; follow it with message_status. Still scheduled? Use cancel_message instead. |
| get_mediaA | Open the photo, video, voice note, audio recording, document or sticker a message carries (a message from read_inbox with |
| send_availabilityA | Whether a connection can send right now, and if not, when each kind of message could next go out and why. Includes today's sends against the account's daily limit, which every kind of message counts toward. |
| set_send_gapA | Set how long a connection waits between two sends: at least |
| list_outboxA | Messages you queued: scheduled ones in send order, then sent, failed and canceled ones. A failed message carries an error code; outcome_unknown means the send was interrupted and may or may not have arrived. To follow one message, use message_status. |
| message_statusA | Check on one message, reaction or deletion you queued (the id send_message, react_to_message or delete_message returned): scheduled (with when it goes out), sending, sent (with when), failed (with why), or canceled. Poll this after a send to know it went out. |
| cancel_messageA | Cancel a message that is still scheduled. Messages already sent or sending can't be canceled; to take back one that went out, use delete_message. |
| list_webhooksA | Webhooks (URLs Parley calls the moment a message, reaction or deletion happens on a linked number). Each belongs to one number ( |
| create_webhookA | Have Parley POST to a URL the moment something happens on one linked number, instead of polling read_inbox. Each webhook belongs to one number; add one per number to hear from several. Events: message.received (a message came in from someone else); message.sent (the account sent a message (from its phone, or through Parley)); reaction.added (someone (or the account) reacted to a message, or changed their reaction); reaction.removed (someone (or the account) took their reaction back); message.deleted (a message was deleted for everyone). Only real, live changes are sent: never history, backfills, or a message seen twice; chats the account holder ignored never send. Each request is a signed JSON POST: { id, type, created_at, sent_at, connection: { id, channel, account }, data }; for messages the text is at data.message.text (the answer's |
| update_webhookA | Change a webhook's URL, events, description or headers, turn it off or back on, or replace its signing secret (rotate_secret: the old one stops working at once and the new one is in the answer). Turning it off drops what it still had waiting. |
| delete_webhookB | Remove a webhook. Nothing more is sent to it, including deliveries still waiting. |
| test_webhookA | Send a webhook.test event to a webhook (signed like every other, and shaped like a message.received: the text is at data.message.text) and wait up to about 10 seconds to say whether it was delivered: the status the URL answered, or why it failed. A failed first attempt is retried like any delivery. The answer includes the exact payload sent. |
| resend_webhook_deliveryA | Send a past delivery's event again (delivery ids are in list_webhooks), e.g. after fixing a receiver. It goes as a new delivery to the same webhook with the same body and event id (a receiver that dedupes on Parley-Event-Id sees a repeat; sent_at shows when this one went) and a fresh media download link. Waits up to about 10 seconds for the outcome. The webhook must be on (test events go either way). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Most tools target clearly distinct resources and actions: outbound messages, inbound reading, media, connections, and webhooks are cleanly separated. There is some overlap between get_notifications and list_chats with only_new/new counts, and between read_inbox and load_history, but the descriptions provide clear selection guidance.
All tool names use snake_case and are highly readable, with a strong verb_noun pattern such as list_outbox, send_message, and create_webhook. A few names like message_status, connection_status, and search depart from that pattern, so it is not perfectly uniform.
24 tools is heavy for a single MCP server, even though the domain spans messaging, media, connections, and webhooks. The surface is well organized and avoids obvious redundancy, but it sits in the 16-25 'borderline heavy' range.
The set covers the main messaging lifecycle: connecting accounts, sending/canceling/deleting messages, reading/searching/history/notifications, media, pacing, and webhook creation/testing/resending. Minor gaps remain, such as disconnecting or unlinking a connection and some explicit chat-level management, but core workflows are covered.