MCP server

ReplyPlex speaks the Model Context Protocol — the open standard AI apps use to work with external systems. Connect your workspace once, and your assistant can search tickets, pull customer history, look things up in your knowledge base, and (with permission) triage conversations.

https://api.replyplex.com/mcp

Connect by signing in (recommended)

Pick your app. Chat apps (Claude, ChatGPT) connect by pasting the URL above; agentic ones (Claude Code, Cursor) can set themselves up from a pasted prompt — a conversation is deliberately not allowed to grant itself new tool servers, which is why the two differ.

These menus move around. If the steps below don’t match your build, what you’re looking for is anywhere the app lets you add a remote (Streamable HTTP) MCP server — point it at the URL above and it will work.

Using ReplyPlex, show me what needs my attention: list my inboxes, then find the
conversations assigned to me that are still active, oldest first. For each, tell me what the
customer is waiting on and what you'd suggest doing next.

Using ReplyPlex, summarise the last 24 hours in my support workspace: what came in,
what's still open, and anything that looks urgent or has a bad CSAT rating.

Set up the ReplyPlex MCP server for me, then verify it works.

ReplyPlex is my team's email support platform (tickets, customers, knowledge base).
No API key: authentication is a browser sign-in that I'll complete myself.

1. Register it in your own MCP config:
 claude mcp add --scope user --transport http replyplex https://api.replyplex.com/mcp
2. Trigger authentication for the new server. A browser will open a ReplyPlex sign-in —
 pause and let me approve it.
3. Once I've approved, verify by calling the list_inboxes tool and showing me my inboxes.

Never ask me for a password or token in chat; the browser sign-in is the only credential step.

Set up the ReplyPlex MCP server for me, then verify it works.

ReplyPlex is my team's email support platform (tickets, customers, knowledge base).
No API key: authentication is a browser sign-in that I'll complete myself.

1. Add this to ~/.cursor/mcp.json under "mcpServers":
 "replyplex": { "url": "https://api.replyplex.com/mcp" }
2. Trigger authentication for the new server. A browser will open a ReplyPlex sign-in —
 pause and let me approve it.
3. Once I've approved, verify by calling the list_inboxes tool and showing me my inboxes.

Never ask me for a password or token in chat; the browser sign-in is the only credential step.

Set up the ReplyPlex MCP server for me, then verify it works.

ReplyPlex is my team's email support platform (tickets, customers, knowledge base).
MCP endpoint: https://api.replyplex.com/mcp — Streamable HTTP, standard MCP OAuth.
No API key: authentication is a browser sign-in that I'll complete myself.

1. Register the server in YOUR OWN MCP configuration, using this environment's native
 mechanism (a remote/HTTP MCP server entry named "replyplex").
2. Trigger authentication for the new server. A browser will open a ReplyPlex sign-in —
 pause and let me approve it.
3. Once I've approved, verify by calling the list_inboxes tool and showing me my inboxes.

Never ask me for a password or token in chat; the browser sign-in is the only credential step.

If you can't modify your own MCP configuration here (e.g. a chat app like claude.ai or
ChatGPT), don't work around it — tell me the exact steps for THIS app instead.

On first use the app opens a ReplyPlex sign-in: log in with your normal account, pick a workspace if you belong to several, and approve. The connection acts as you — your inboxes, your permissions — and assignee:me style questions work.

Workspace admins see every connection under Settings → Developer → Connected AI apps (who connected what, acting as whom, last used) and can revoke any of them; revocation is immediate.

Connect with an API key

For scripts, CI, or clients that send fixed headers, an API key works instead: send Authorization: Bearer rp_live_… on every request. A key acts org-wide rather than as a person, so prefer signing in for interactive use.

Scopes

The scope is fixed when the connection is approved and shown on the consent screen. Read-only connections don’t even see the write tools.

Tools

Read (all connections):

Triage (write scope only):

Every triage action lands in the conversation’s activity timeline attributed to the person whose connection performed it — e.g. Rupok · via Claude — so nothing an AI app does is anonymous or irreversible.

Sending replies is off by default

By default no tool sends a reply to a customer — the AI drafts, a person sends. That is deliberate: a customer email can’t be recalled, models are sometimes confidently wrong, and a message body is untrusted input that may be trying to make an assistant mail something.

A workspace that wants automation can turn it on per inbox, in that mailbox’s settings. When it is on, send_draft sends a reply — with three properties that stay true regardless:

• Draft-then-send, never compose-and-send. send_draft takes a conversation id and no body. The text must already have been staged with create_draft, so the exact wording is in your client’s transcript and in the console’s Drafts view before a send is possible.
• The undo window applies. The reply lands as a held message and can be cancelled from the console for the sender’s grace period.
• It’s attributed. The timeline shows the person and the client that sent it.

Sending broadcasts

stage_broadcast prepares a message and reports the resolved recipient count without sending anything. Show that count to the person requesting the broadcast and get their explicit agreement before calling send_broadcast with the returned id.

Broadcast sending requires a signed-in user’s write connection, the workspace’s separate Settings → Developer sending switch, an admin role and permission to send broadcasts in the target inbox. The prepared broadcast must originate from MCP, have at most 500 recipients, and avoid the all-customers audience. Every To and cc recipient must already be a customer in that workspace; bcc is unavailable. Otherwise, review and send from the console.

An accepted MCP send also saves an in-app notification for each active workspace admin. If those notifications cannot be saved, or there is no active admin to notify, the broadcast stays staged. The notification records acceptance for sending; it does not confirm that every recipient received the email or that an admin read the notification.

If the connection drops or the result is uncertain, check the broadcast’s status in the console before trying again. A broadcast already sending cannot be sent again. Staging the same content again creates a separate broadcast and can result in duplicate mail.

Prompts and resources

In clients that surface them, the server also publishes three ready-made prompts — Triage my queue, Daily digest, and Brief me on a customer — and a resource template (replyplex://conversations/{id}) for attaching a ticket as context directly.

Rate limits

300 requests per 60 seconds per connection, in a separate bucket from the REST API.

Send outcomes

In the next grouped release, create_conversation_once and send_reviewed_draft return a submission object alongside the conversation. It identifies the exact submitted message and describes its current outcome:

The object also includes conversationId, messageId, deliveryState and scheduledFor. IDs are null when the exact source is unavailable. A conversation response by itself does not prove delivery. Repeating create_conversation_once with the same request ID and content reads its original outcome. Repeating send_reviewed_draft with the same revision reads its original message outcome and never creates or resends a replacement. The person’s Undo window and inbox sending permission remain in effect for a new draft send.

The versioned send tools require server version 0.17.1 or newer. Refresh your connection’s tool list and confirm the tool is available before using it.

Reviewed draft sending

MCP version 0.16 adds revision, inboxId, customerEmail and saved attachments to the get_draft and create_draft results. Review the text, files and destination, then call send_reviewed_draft with conversation_id and that exact revision. It accepts no reply body or attachment list from the caller. Changes after review require another review.

Keep the same revision when recovering from a lost response. Its receipt survives draft cleanup and returns the existing message outcome. A deleted source does not permit a replacement send. A retry also preserves any newer draft on the conversation. Do not obtain a new revision just to retry an uncertain send.

The connection must still have write access to this workspace when the message is saved, including if its permission changes during the request. Reading a repeated send’s outcome also requires current OAuth access. After reconnecting, use the same reviewed revision to inspect the original message; reconnecting does not send it again.

The existing send_draft tool remains available with its conversation response. Without a revision it selects the current saved draft at request time; this does not prove that the client reviewed that version. It is not safe to retry automatically after a lost response or a changed draft. Prefer send_reviewed_draft for explicit review and same-version replay. Check for an existing message before upgrading an earlier request. Older servers do not support the new tool name; refresh the connection’s tool list after the grouped release. Check the connection’s tool list for server-version support.

create_draft checks replacement atomically. An identical body preserves the current version; a different existing body requires replace_existing: true. Saved attachments are preserved, including attachment-only drafts. Files are downloaded during send preparation; a missing file fails before message commitment rather than being silently omitted.

Creating a conversation once

MCP version 0.17 adds create_conversation_once. Generate one UUID request_id for a new conversation the user has asked you to send. Keep that ID and the same content when retrying a failed or lost response. A different ID represents a different send; never generate a new ID just because the previous outcome is uncertain.

{
  "request_id": "f43b65d1-528e-4435-91f2-bf3c887bd759",
  "inbox_id": "the-inbox-id",
  "to": "customer@example.com",
  "cc": ["colleague@example.com"],
  "subject": "Your support request",
  "body": "Here is the update you requested."
}

The recipient and every cc must already be customers in the workspace, including recognized secondary addresses. Workspace sending opt-in and a current admin role are required. There is no bcc input. Use stage_conversations for human review when someone is not yet a customer. The first message and its request receipt are saved together. Reusing an ID with different content is refused; deleting a conversation does not make its ID available for another send. Current workspace access and OAuth authority are required to read a repeated request’s outcome.

If a customer is merged while creation is being processed, the conversation keeps the requested To and cc addresses and links to the surviving profile. Repeated directory changes can require you to review the recipients and retry; keep the same request_id and content. A committed message is never replaced by a directory retry.

The existing create_conversation tool remains available with its conversation response. A call without request_id keeps its original non-idempotent behavior: do not automatically repeat it after a lost response. A server-created receipt cannot identify a later client retry. Prefer create_conversation_once and preserve its request ID for future sends. Check ReplyPlex for a conversation created by an earlier legacy call before starting a new request. Both legacy tools advertise that they can send mail and are not generally idempotent. They still require current OAuth, workspace, inbox and recipient authorization. Check the connection’s tool list for server-version support.

Broadcast authorization

stage_broadcast, stage_conversations and send_broadcast require the connection’s current write grant when their changes are saved. Account, workspace, inbox-role and sending-domain changes during a request are checked again at that point.

Ordinary broadcast staging can remain available with connected-client sending switched off. Tailored conversation staging requires that workspace setting. Support agents can prepare messages for review; approving a send from MCP requires a current workspace admin. Human approval in the console keeps its existing rules. These checks apply when the message or approval is committed.

MCP send approval checks every pending To and cc address against the current workspace customer directory, including secondary addresses. An address removed after staging requires review; a customer ID saved during staging does not authorize it. An address that has become a customer since staging can qualify at approval. Bcc is unavailable, with at most 500 recipients and ten copied customers per recipient. Once approved, the existing send continues its normal lifecycle; later directory edits do not rewrite its approved addresses.