# MCP for customer support: what changes for the agent on your website Half the vendors now say MCP somewhere on their site, and most mean the same small thing. Here is what MCP for customer support actually is, who has it, and which way each one points. ## What is MCP (Model Context Protocol), for a support lead MCP, the Model Context Protocol, is a standard way for an AI assistant to use somebody else's software. A product exposes an MCP server: a list of things the assistant is allowed to do, each with a name, a description and the fields it needs, such as 'search conversations', 'update the greeting', 'book a meeting'. An assistant that speaks MCP, and Claude, ChatGPT, Claude Code, Codex and Cursor all do, connects to the server, reads the list, and can then call those things in the course of a conversation with you. Before MCP, every assistant needed its own integration with every product. After it, one server serves all of them. For a support or operations lead, the practical meaning is this: anything with an MCP server can be operated by typing to the assistant you already have open. 'Show me yesterday's conversations that ended in a handover' is a sentence, and the assistant turns it into the right call. The protocol does not make the assistant smarter about your business; it only gives it hands. Which product's hands, and pointed in which direction, is the part that varies between vendors, and it is the whole of this post. ## Which customer support vendors have MCP, and which way it points MCP shows up in the customer-support market in two directions, and vendors rarely say which one they mean. The first direction is inward: the vendor's agent acts as an MCP client and reaches your systems. [Tidio's Lyro does this](https://www.tidio.com/ai-agent/lyro-actions/), connecting once to your CRM or billing platform and using the tools that system exposes. Zendesk's MCP client, in early access, lets admins connect Zendesk to external MCP servers and use their tools as steps in action flows. The second direction is outward: the vendor exposes an MCP server, so your assistant can reach into their product. [Zendesk's own support article](https://support.zendesk.com/hc/en-us/articles/10889847373466-Announcing-the-MCP-client-early-access-program) dates its MCP server to summer 2026, also as early access. Delight.ai, Sendbird's support brand, [announced Delight Agent MCP](https://www.prnewswire.com/news-releases/delightai-launches-delight-agent-mcp-for-ai-assistant-access-to-live-customer-service-data-302843631.html) on 5 August 2026, letting Claude, Codex and Cursor query a Delight workspace and, by the announcement's own list, write to actionbooks, tools, knowledge sources and agent configuration through more than 35 tools. [Ada lists MCP in a developer toolkit](https://www.ada.cx/platform) beside APIs and SDKs. Sierra and Docket use MCP a third way, to publish their agents into ChatGPT. Outside the support vendors, [Shopify's Storefront MCP](https://shopify.dev/docs/apps/build/storefront-mcp) is worth knowing about because it is what a storefront agent on a Shopify site can be built on: MCP servers for product search, carts and checkout, store policies and order status. [Chatbase, the closest product to ours in shape](/resources/vs-chatbase), mentions no MCP anywhere on its site as of 3 September 2026. ## Exposing an MCP server is not the same as being operated through one Every vendor above still has a builder of its own: Zendesk's Agent Builder, Delight's Builder, Tidio's Flows, Ada's Performance Center. MCP is a door into that builder, or a door out of it into your tools. The builder remains the product, and what your assistant can do through the door is whatever the vendor chose to list. Delight's announcement is the most complete in the category so far, and it is still a door into Builder. Algomo made the other bet. There is no builder chat of our own. The platform is an MCP server, and the coding agent you already run, Claude Code, Codex, Cursor, ChatGPT or Claude, signed in over OAuth with no API key, is how the support agent is built, changed, tested and reviewed. Everything the agent can see and change is on that server, which is why 'move the greeting, stage it, test it on the live site and keep it' is a sentence you type rather than a ticket you file. The reasoning is in [our post on why we built it this way](/resources/why-algomo): the frontier labs will spend more on Claude Code and Codex this year than this category spends on builders in a decade, and their harness already holds the context of everything else your team does in it. One line has to stay sharp, and we draw it every time. The coding agent does not talk to your visitors. It configures, tests and reviews. The conversation a visitor has runs in web chat on your site, inside Algomo's own runtime on frontier models, in the visitor's own browser session. Two agents, two jobs: one is your operator, the other is your front desk. ## What the website support agent actually does The front desk answers in web chat, and its reach is your site's reach. Algomo discovers the endpoints your own pages already call, through our browser extension while someone browses the site, and calls them in the visitor's own session. Whatever a signed-in customer can already see, their order, their plan, their invoices, the agent reads in that session; anything only your staff can reach, we connect with you. It co-navigates: it opens the setting the visitor asked about, filters the table, starts the return, in the tab they are already in. It books Google and Outlook calendars. When a question needs a person, your team takes the conversation live with the transcript in front of them, and the team is told by email and Slack. There is no copy of your site to keep in sync: it reads the live page. ## MCP customer support setup: what the first week looks like ### 1. Day one: browse your site with the extension Someone on your team installs the browser extension and walks the site the way a customer would: the help centre, an order page, the account settings, a checkout. The extension records the data connections those pages make. By the end of the walk the agent has a map of the endpoints your site already uses. ### 2. Day one, later: the coding agent writes the instructions In Claude Code or Codex, connected to Algomo over MCP, you describe the job in plain language: what to answer, what to hand over, what is out of bounds, most teams put refunds and anything that charges a card there. The coding agent turns that into the agent's instructions and keeps the questions your queue actually gets, so you can try them after every change. Every change is staged with a diff you read before it is live. ### 3. Days two to three: test on the live site, before visitors see it The agent runs against your real pages and your real endpoints, visible only to you. You ask it the questions your queue gets, and the awkward ones, and read what it does. When it gets something wrong, you tell the coding agent, which fixes the instruction and tries the same questions again on the draft. Snippet on the site, live to visitors, when you say so. ### 4. Days four to seven: read the transcripts The first real conversations are the review. You read them in the dashboard, and you change what needs changing by telling the coding agent. A rule added on Thursday is followed on Thursday. The history holds what changed and why. ## Where it stops Algomo answers in web chat on your site, and only there: no email, SMS, WhatsApp or voice, and no message to a visitor who has left. It does not create tickets or cases in a helpdesk, and it does not read or write a CRM; the handover is a person on your team taking the conversation with the transcript, plus the email and Slack notification. It is not a helpdesk itself: if most of your support arrives by phone or email today, buy one of the vendors above and read their MCP page carefully for the direction it points. Anything behind a login, the agent reads in the visitor's own session if the visitor can already see it; anything only your staff can reach, we connect with you. Everything inside those lines runs from a free plan, and the details of what you pay are on [this site's pricing page](/pricing). ## MCP customer support questions, answered ### What is MCP in customer service? The Model Context Protocol, a standard that lets an AI assistant call another product's software through a published list of tools. In customer service it appears in two directions: a vendor's agent acting as an MCP client to reach your CRM or billing system (Tidio's Lyro, Zendesk's MCP client), or a vendor exposing an MCP server so your assistant can reach into their product (Delight Agent MCP, Zendesk's planned server, Algomo). The protocol only gives the assistant hands; which product's hands, and pointed which way, is the whole question. ### Does Zendesk have an MCP server? Not a generally available one, as of 3 September 2026. Zendesk's MCP client is in early access and lets Zendesk reach external MCP servers as steps in its action flows. Its own MCP server, which would let your assistant reach into Zendesk, is listed for summer 2026 in Zendesk's support article, also as early access. Both keep Agent Builder as the place the agent is built. ### Does Claude Code talk to our customers? No. Claude Code, Codex, Cursor, ChatGPT or Claude is how your team builds, tests and reviews the Algomo agent over MCP. Visitors talk to the Algomo agent in web chat on your site, which runs in Algomo's own runtime on frontier models. The coding agent is the operator; the website agent is the front desk. ### Do we need an engineer to run it? You need someone comfortable typing to Claude Code or Codex, which in most support teams is now several people. Nobody writes integration code: the extension discovers the endpoints your site already calls, and the coding agent writes the instructions from what you say and tries them on a draft before anything is live. The dashboard does the same jobs on screen for anyone who prefers it. ### We are on Zendesk. What does MCP change for us? Zendesk's MCP client, in early access, lets Zendesk reach external tools as steps in its action flows, and its MCP server, dated summer 2026 in Zendesk's own article, will let your assistant reach into Zendesk. Both keep Agent Builder as the place the agent is built. Algomo is not a helpdesk and does not create Zendesk tickets; it answers visitors on your site and hands the conversation to your team with the transcript. ### Is an MCP server secure enough for support data? The protocol carries whatever permissions the server grants, so the question is about the server. Algomo's MCP server is reached over OAuth with your own login, no API key; the website agent reads only what the visitor in front of it can already see; changes are staged with a diff and kept in a history. What we do not have is an audit log in the compliance sense, and we say so rather than imply one. ### What does it cost? You pick a monthly amount, Free, then $50 to $500 on Business and Enterprise above, and it buys credits: a conversation that actually helped someone costs five, one that went nowhere costs nothing, and the amount is the most you can be charged. No overage, no top-ups; run out early and you renew early, or wait for the month to turn. Every number is on the pricing page. ## If you want to see the two agents Algomo is our product, so weigh this section accordingly. [The product page](/product) shows the build flow with the coding agent on the left and the platform assembling on the right, which is the clearest picture of the distinction this post draws. The test costs an afternoon: install the extension, browse your own site, and ask Claude Code what it found.