Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 (account) and whether it can send right now. Other tools take connection_id: this id, or simply the account'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 account it is on) — from every chat except ones the account holder ignored. Filter by channel, connection, or one chat (chat_id from list_chats). Page back with before. A message with media carries a photo, video, voice note, document or sticker (its text is the caption, or a placeholder like "[photo]"): call get_media to see it. reactions lists who reacted with what. new_since_last_read says how much came in from the other side since these chats were last read (messages and reactions, per chat); new messages and reactions carry new: true, and new_reactions lists every new reaction with the message it's on (even one on an old message not shown). Reading marks what it shows as read, for every agent on the account; pass mark_read: false to just look. Paging back with before never marks anything. Reading that marks read also sends read receipts on WhatsApp by default (blue ticks, if that number's WhatsApp has them on; the account holder can turn this off per number in Parley): pass read_receipts: false to read without telling the sender. Looking (mark_read: false) or paging back sends none unless read_receipts is true.

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). awaiting says who owes the next message: "you" when the last word was theirs. new counts the messages and reactions from the other side since the chat was last read (read_inbox or load_history mark it read; listing doesn't). Set awaiting_reply to get just the conversations waiting on you, only_new for just the ones with something new.

searchA

Search like WhatsApp's search bar, across all your connected accounts (or one, or one chat): chats whose name (or number) matches, and messages whose text matches, newest first. Every word in query must appear, in any order, case-insensitively and anywhere in a word ("inv" finds "invoice"); put a "quoted phrase" in quotes to keep it whole. A photo, video or document's caption counts as its text, and a document without one matches on its file name. Narrow it by date (after, before), by who sent it (from_me), to attachments (media), to messages with links (links), or to ones not yet read (only_new); filters work without a query too (e.g. every document in a chat last week). It searches what Parley has stored: everything in the chats the account holder didn't ignore since the account was linked, plus the history WhatsApp sent at linking and anything load_history fetched. Older messages that are only on the phone aren't found; load_history fetches a chat's older ones. Searching never marks anything read or sends read receipts. To read the conversation around a match, read_inbox with its chat_id and before (page back to it), or load_history.

get_notificationsA

What came in from the other side since chats were last read: totals (all_chats), and each chat with something new and how many messages and reactions. Pass chat_id to split it into that chat (this_chat) and the rest (other_chats). Never marks anything read; read_inbox with a chat_id reads one. Every other tool's answer carries the same totals as new_since_last_read when something is new.

send_messageA

Queue a message on a connected channel: text, or a photo, video, GIF, voice note or document (pass media; text is then its caption). Parley sends at a human pace to keep the account safe: with gaps between sends, breaks after bursts, and a daily limit; if the person turned on active hours for the number, only inside its local active hours. The reply says when it will go out (scheduled_for) and why it isn't sooner (waits). Replies in existing conversations go ahead of conversation openers that hit their limit.

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 count messages before the oldest one Parley has (e.g. from before the account was linked, or while the chat was ignored), with their attachments and reactions. Call it again to go further back, count at a time. Waits up to about 20 seconds for the phone, which must be online; answered says whether it replied. Answered, it returns the older messages it fetched; not, the chat's latest messages as Parley has them. Afterwards they're in read_inbox too. Like read_inbox, it says what's new since the chat was last read (new_since_last_read, new: true, new_reactions; older history fetched now isn't new) and marks what it returns as read unless mark_read is false — and then, by default, sends read receipts on WhatsApp too (see read_receipts).

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 media). Photos and stickers come back as images you can see, and text files (txt, csv, json, …) as text. Voice notes, audio, videos, PDFs and other files up to 10 MB come back as the file itself, which your client saves to disk; videos also come with their preview frame. Every answer has a download_url (any size, valid for an hour) and a ready save_with curl command for saving the file yourself. Needs the connection online; an old file may take a moment while the sender's phone uploads it again.

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 gap_seconds, up to twice that at random so it doesn't look scripted. 0 sends back to back; null goes back to the channel's default (WhatsApp 1–3s). Messages already queued are rescheduled on the new gap. A short gap makes the account look less human and raises the chance the platform restricts it, so change it only when the person asks. Openers to new contacts, breaks after bursts and the daily limit still apply.

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 (account, connection_id). Lists each one's URL (keys in it masked), events, the headers it sends (names only), whether it's on, its last success and failure, and its latest deliveries (with include_payloads, the exact JSON body each sent: use it to debug a receiver). Also answers payload_format, what every request body looks like.

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 payload_format has every event's shape and an example: build the receiver from it). If the receiver checks who's calling with a key of its own (an Authorization header or API key its setup gave you), pass it in headers. The answer carries the signing secret: keep it, it isn't shown again (update_webhook with rotate_secret makes a new one). The account holder sees and can change every webhook on that number's page on the Parley dashboard. At most 10 per number.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 24 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues