MCP in customer support: what Plain, Pylon and Tidio shipped

mcp, ai-support, vendor-evaluation, tool-calling

"MCP" showed up in three vendor changelogs this year, and it means three different things depending which one you're reading. Plain's MCP server hands an outside AI client 30 tools over your own workspace. Plain's other MCP feature, Sidekick Tools, does roughly the opposite: it lets Plain's own agent pull context from tools you already run. Pylon and Tidio ship both directions at once, under names that don't tell you which is which either.

The distinction is not academic. If you're picking a support platform because it "has MCP," you're picking between an integration your team configures and points at whatever AI client it wants, and a capability the vendor's agent gets to use against your other systems. Those are different products with different security models, and the marketing page rarely says which one you're looking at.

Pattern 1: an MCP server over your own workspace

This is the simpler shape. The vendor stands up an MCP server; you point Claude, Cursor, ChatGPT or any other MCP-compatible client at it; the client can now read and write your support data through tool calls instead of a bespoke integration.

Plain MCP is the clearest example: 30 tools across threads, customers, tenants and help-center articles — read a thread, reply, assign, snooze, add a label, search a customer's history, spot patterns across a company's threads, publish an article. Authentication rides on your own Plain login, so the MCP server has exactly your account's permissions, nothing more.

Gorgias MCP took the same shape into open beta: connect Claude or ChatGPT, ask about return patterns or CSAT outliers, get an ad-hoc report in plain English. Gorgias is explicit that this is read-heavy by design during the beta — full reads, but macro edits and AI Agent config are gated and rolling out later — and that it only pulls data when you ask, scoped to what your existing user role already grants. Document360 went further on the write side: as of its June 2026 release, its MCP server can move an article through an entire review-to-publish workflow from inside a chat with an AI assistant, not just search and read.

What all three share: the tenant is the one deciding what the client can do, because the tenant is the one who authenticated. The vendor never has to trust anything the model says about who's asking.

Pattern 2: the vendor's agent consumes your MCP servers

Flip the direction and you get a different product. Instead of your client calling the vendor's MCP server, the vendor's own AI agent calls MCP servers you stood up — your CRM, your issue tracker, your internal database — as a source of tools it can invoke while working a ticket.

Plain Sidekick Tools launched with seven ready integrations — Linear, Sentry, Incident.io, Notion, Granola, Datadog, Slack — plus a GitHub App that gives Sidekick read access to selected repos, so it can look up code while triaging a bug report. Tool integrations are read-only for now, and the feature itself is in beta.

Pylon runs both patterns from one page: its own MCP server exposes issues, accounts, contacts and (as of a June 2026 count) 29 tools total for an outside client to call, while its AI Agents v2 — runbooks that engage a customer, call APIs, and execute predefined actions — pull in third-party MCP servers like Linear, Notion and PostHog so Pylon's own AI features can use whatever those systems expose. Tidio does the same double duty: Lyro is itself an MCP server any AI builder can connect to, and Lyro can also connect out to a CRM or billing platform over MCP and use every tool that system exposes — Tidio's own copy calls each such call "scoped, authenticated, and auditable."

This is the pattern that competes directly with a support platform's own tool-calling layer: instead of the vendor building a curated whitelist of what an AI agent may do to your product, you point their agent at an MCP server you already run and it inherits whatever that server allows.

What the July spec change does to pattern 1 specifically

The 2026-07-28 MCP specification release candidate made the protocol's transport layer stateless: it drops the Mcp-Session-Id header and the sessions it implied, so the same request can be answered by any server instance sitting behind an ordinary load balancer. No sticky routing, no shared session store to keep consistent across instances. The initialize handshake goes with it — protocol version and client capabilities now travel as request metadata instead, with a server/discover call a client can make up front to learn what a server supports before committing to anything.

This mostly matters for pattern 1. A vendor MCP server that used to need session affinity — the same instance handling every call from a given client — can now run behind round-robin, which is the ordinary way to run a stateless HTTP service and a meaningfully smaller operational surface than keeping session state pinned. Pattern 2 barely notices: the vendor's agent is still the one initiating calls out to your systems, and a stateless core changes how those servers scale, not what the agent is doing with them.

Where we stand on this ourselves

We didn't have an answer to this three weeks ago. Now we do: Replium ships a tenant MCP server at /api/mcp, on your own subdomain, mounted separately from the platform's own MCP endpoint that only serves our blog. That separation is deliberate — a stateless server publishes a fixed tool list, so one endpoint serving both audiences would hand every connecting tenant the platform's tool names too.

It's pattern 1, and it's real, not a stub: 14 tools across three areas of the product. articles_search and article_get read the knowledge base, drafts included; article_create, article_update and article_update_content write it, plus an image-upload tool and a shareable preview link for a draft. conversations_search and conversation_get read the operator inbox — status, assignee, the full thread including internal notes; conversation_note, conversation_reply, conversation_update and conversation_transfer act on it, including answering the visitor directly from your AI client. teammates_list turns a name into the id a transfer needs. You mint a bearer token from Settings → Integrations, and we hand you the exact claude mcp add command or the JSON block for Claude Desktop, Cursor or a project's .mcp.json — copy, paste, connect.

Two things worth being precise about rather than glossing over. First, authentication is a single workspace-scoped bearer token, not per-user OAuth the way Plain's MCP server rides on your own login — but every token remembers which teammate issued it, so a reply or a note it produces is attributed to that person, not to an anonymous workspace credential, and revoking it disconnects only that person's client. Second, and this is the honest gap: we have zero of pattern 2. There's no Replium agent that consumes an MCP server you point it at, because there's no Replium agent, full stop — no LLM provider is wired into the product at all right now. The tenant MCP server gives your own AI client hands on your workspace; it doesn't give our product a brain of its own that reaches out to yours.

That's not a hedge before a roadmap slide. It's where the two patterns actually put a small vendor: pattern 1 is buildable in the open, on your own schedule, without betting the product on which model provider you trust this quarter. Pattern 2 means shipping an agent, which means picking a provider, which is a commitment we haven't made and won't fake in a changelog entry. If what you actually need is a vendor's own agent working your ticket queue against systems it discovers through MCP, we're not that product today, and you shouldn't take our word for "soon."

What we do have going for us building it this way: nothing here is queued behind thirty thousand other accounts. The knowledge-base tools went out on August 21; the inbox tools — search, reply, note, transfer — followed on September 3, less than two weeks later. That's the pitch for picking a vendor this size over an incumbent: not more features today, but a shorter distance to the next one you actually need.

Who ships which pattern

• Plain — both. 30 tools serving your client, plus Sidekick Tools (beta, read-only) consuming yours.
• Pylon — both. 29 tools serving your client, plus AI Agents v2 pulling in Linear, Notion and PostHog.
• Tidio — both. Lyro is itself an MCP server, and it also connects out to your CRM or billing system.
• Replium — pattern 1 only. 14 tools serving your client, shipped over the last two weeks; no agent of ours consumes anything.

Telling the two apart in five minutes

Next time a vendor's page says "we have MCP," here's what to check before you take that as an answer:

• Read the connection instructions, not the marketing copy. If you're told to run claude mcp add <their-url> or drop a block into your own mcp.json, that's pattern 1 — their server, your client. If the instructions are about connecting their agent to your systems (an API key for your CRM, an OAuth grant to your issue tracker), that's pattern 2.
• Check who authenticates whom. Pattern 1: you authenticate to their server (your login, or a token you minted). Pattern 2: their agent authenticates to your systems, using credentials you handed it.
• Look for a fixed tool list vs. an open connection slot. Pattern 1 vendors document a tool list — Plain's 30, our 14 — because the server's capabilities are fixed at deploy time. Pattern 2 features describe categories of systems you can connect (issue trackers, CRMs, "any MCP-compatible tool"), because the tool list depends on what you point it at.
• Ask what happens if you revoke access. Pattern 1: your AI client stops working, nothing in the vendor's product changes. Pattern 2: the vendor's agent loses a source of tools it was using inside your account — a bigger blast radius, worth knowing before you grant it.
• A vendor can genuinely have both, like Pylon and Tidio do. That's not a trick answer — it just means the "we have MCP" checkbox on a comparison page was never going to tell you which capability you were actually buying.

If what you need is your own AI client reading and answering from your support workspace, that's a narrower ask than "an AI-first helpdesk," and it's one self-serve signup away — no sales call, and today's answer includes what it doesn't do yet.