Managing a Chatbot Platform From Claude via MCP (2026)

An MCP server exposes a product's functions as tools an AI assistant can call directly, so you can manage the product by describing what you want instead of clicking through a dashboard. The Model Context Protocol is an open standard that Anthropic open-sourced on 25 November 2024 for connecting AI applications to external systems¹, and it has since been adopted broadly enough that Claude, ChatGPT, VS Code, Cursor and most other AI coding and assistant tools now speak it as a common client protocol².

For a chatbot platform that means an assistant can list your bots, read a conversation flow, add a node, publish a knowledge base article, or pull last week's analytics - as tool calls against your workspace, not as guesses about what your dashboard's buttons might do.

Conferbot ships an MCP server exposing 49 tools across 10 modules, plus 7 read-only resources and 6 pre-written prompt templates. It runs statelessly per request behind a single endpoint and is scoped to one workspace by API key.

To be concrete about who this is for: if you already run a chatbot business on a platform and your team spends real hours a week in the dashboard doing repetitive things - reviewing conversations, editing flow copy, checking whether a webhook fired - an MCP connection turns a chunk of that time into a written request instead of a click-through session. It is not a replacement for the dashboard, and it is not a way to build a chatbot from nothing without ever looking at a flow editor. It is a second interface to the same underlying product, optimised for description rather than navigation.

¹ Anthropic, "Introducing the Model Context Protocol", 25 November 2024.
² modelcontextprotocol.io, MCP ecosystem overview.

A REST API is for code you write. An MCP server is for an assistant you talk to. The difference shows up in three places:

• No integration project. Point an MCP client at the server, paste an API key, and the assistant can already operate the product. There is nothing to build.
• Composition is free. "Find the flow node with the highest drop-off and draft a knowledge base article answering it" spans analytics, flow and knowledge tools. With a REST API that is a script; with MCP it is a sentence.
• It stays current. The assistant reads the tool schemas at connect time, so it does not rely on a model's stale memory of your endpoints - a real advantage over asking a model to write API calls from documentation it may have memorised incorrectly or that has since changed.

Most chatbot platforms publish a REST API and a Zapier integration. Very few ship an MCP server, which means the work of wiring an assistant to them still falls on you - writing the glue code, keeping it updated as the API changes, and re-authenticating it every time a key rotates.

There is a subtler benefit too. Once tools exist behind a stable, machine-readable interface, they compose in ways nobody explicitly programmed. The knowledge base tools were not built with "summarise drop-off and draft an article" in mind - they were built to create, read, update and search articles. The composition is entirely on the assistant's side, at the moment you ask for it, which is the whole point of exposing small, well-defined primitives instead of a handful of pre-built workflows someone had to anticipate in advance. A REST API can technically be composed the same way, but only by someone who sits down and writes the orchestration code first; MCP lets the composition happen conversationally, once, for a task that may never recur in exactly that shape again.

MCP defines three things a server can offer a client, and the distinction matters when you are deciding what an assistant should be allowed to do:

• Tools. Functions the model can execute - create_chatbot, publish_flow, get_webhook_delivery_logs. These have side effects, so a well-built client asks for explicit user consent before calling one, which is a requirement written into the spec itself, not a nicety left to implementers.
• Resources. Read-only context the model or the user can pull in, addressed by a URI - Conferbot exposes these under a conferbot:// scheme, so conferbot://chatbots returns your bot list as structured data without the model having to decide which tool to call first.
• Prompts. Reusable, server-defined workflows a user can invoke directly, rather than having to describe the multi-step task from scratch every time.

Underneath all three, MCP messages are JSON-RPC 2.0 - a much simpler wire format than a REST API's varied verbs and status codes, which is part of why building an MCP server for an existing product is usually smaller than it sounds once the underlying service functions already exist.

Each tool also carries a machine-readable schema describing its arguments, similar in spirit to function calling in a model API, except the schema is discovered live from the server rather than hard-coded into a prompt. That is what lets a general-purpose assistant operate a product it has never seen documentation for: it reads the tool's name, description and parameter types at connection time and reasons about which one to call the same way it would reason about any other instruction. A software development kit gives a developer the same convenience for writing code; MCP gives an assistant the equivalent for taking action directly.

The breadth is deliberate. A tool set that only reads data is a reporting integration; one that only writes is dangerous without review. Splitting close to evenly - knowledge base and flow tools skew toward content creation, analytics and response tools toward read-only reporting - means an assistant can genuinely do a knowledge base rewrite or a flow audit end to end rather than doing half the job and leaving the rest for a dashboard session anyway. See the full module list in our API integration and integrations docs.

Two modules are easy to underrate on a first read. Widget tools cover the settings customers actually see - colours, greeting message, channel connections - which means an assistant can carry out a rebrand or a copy pass across every bot in a workspace in one session instead of opening each widget's customiser individually. Template tools matter for the opposite reason: they turn "start me a bot for X" into a search-then-apply operation grounded in an existing, tested flow, rather than an assistant improvising a conversation design from a text description with no reference point.

Tools get most of the attention because "the AI can take actions" is the headline feature, but the other two primitives change how a session actually feels to use:

• Resources save round trips. Instead of the model guessing it should call list_chatbots before doing anything else, a client can attach conferbot://chatbots directly to the conversation the way you might attach a file - the assistant starts with context already loaded rather than having to ask for it.
• Prompts encode expertise. Conferbot ships prompt templates such as analyze-chatbot-performance, which walks the assistant through pulling a chatbot's details, thirty days of analytics and its most recent responses before writing up trends and recommendations, and debug-webhook-deliveries, which drives the same investigative sequence a support engineer would run manually. A user invokes the prompt by name instead of writing that multi-step brief from scratch every time.

The practical effect is that a well-built MCP server is not just an API with a different auth header - it is closer to a colleague who already knows which order to check things in.

Access to a resource is still gated the same way a tool call is - it goes through the same API key and the same workspace scoping, so attaching conferbot://chatbots to a conversation does not bypass anything a tool call would have enforced. The distinction is purely about mechanics: a resource is context you pull in once and reason over, a tool is an action with a result you get back and can chain into the next step.

MCP has moved through a few transport designs since 2024; the current recommended one for remote servers is Streamable HTTP, defined in the protocol's 2025-03-26 specification revision, which replaced the older HTTP+SSE transport with a single endpoint that accepts JSON-RPC 2.0 over POST and can optionally stream a response back³. The specification's most recent 2026-07-28 revision goes further, moving the protocol core toward a fully stateless design where protocol version and capabilities travel on every request rather than being pinned to a long-lived session⁴.

Conferbot's server follows that pattern already: there is one route, POST /mcp, and each request creates a fresh server instance with no session ID and no server-side state carried between calls. That has a concrete security benefit - a request cannot be replayed against accumulated session state because there is none - and an operational one: any request can be handled by any server instance, so there is no sticky-session routing to get wrong as the platform scales.

³ Model Context Protocol, Transports specification, 2025-03-26.
⁴ Model Context Protocol, Specification, 2026-07-28.

The security model is deliberately narrow:

• API-key auth. The key identifies a single workspace. Tools cannot read across workspaces.
• Stateless per request. No server-side session accumulates between calls, so a leaked session cannot be replayed.
• Plan-bound quotas. API call limits and the number of active API keys both follow your plan, so an over-eager assistant loop is capped rather than unbounded.

Treat the API key like a password: it can create and modify bots. Issue a separate key for assistant use so it can be revoked without breaking your other integrations - see our chatbot security guide for the same discipline applied more broadly, and API rate limiting for what happens once you exceed your quota.

Note what this model deliberately does not include: there is no OAuth-style delegated-user flow where an assistant acts as a specific team member with that person's individual permissions - it acts as the workspace, full stop, with whatever the key can do. That is simpler to reason about but means every key you issue should be scoped in your head to "anyone with this key can do anything a workspace admin can do through the API," not to an individual's role. If your team needs per-person audit trails for assistant-driven changes, track that at the process level - who was told to use which key for what - rather than expecting the platform to distinguish between two people sharing one key.

Free workspaces can create API keys but cannot make calls with them, which is why MCP - like the REST API it shares infrastructure with - requires a paid plan. Two API keys on the free tier exist mainly so you can see the settings page before upgrading, not to use them. Every additional MCP tool call from an assistant session counts against the same monthly quota as your other API usage, so a long automation session and a script hitting the REST API draw from one shared number - see pricing for full plan details.

This shared-quota design has a practical consequence worth planning around: an assistant working through a multi-step task can burn through a surprising number of calls quickly, because a single request like "audit every flow in this workspace" expands into one tool call per bot, then one per flow within each bot. On Starter's 10,000-call monthly allowance that is rarely a problem for occasional use, but a team running MCP-driven automation daily alongside a REST API integration should watch usage through the account tools before committing to a workflow that depends on headroom staying available.

These are not competing options so much as different layers. A support workflow might use a webhook to notify Slack the moment a conversation escalates, the REST API to sync response data into a warehouse on a schedule, and MCP for the ad hoc "draft me a knowledge base article about the checkout bug we keep seeing" requests that do not justify writing a script for a one-off task.

The useful patterns are the ones that span more than one module:

1. Turn drop-off into content. Pull the node with the worst drop-off, then draft and publish a knowledge base article that answers the question people were abandoning on.
2. Clone and localise. Duplicate a working bot, then walk the flow and rewrite copy for a second market.
3. Weekly review. Ask for conversation summaries and analytics for the last seven days and get a written digest without opening a dashboard.
4. Debug an integration. Read webhook delivery logs and identify which payloads failed and why - the built-in debug-webhook-deliveries prompt runs this sequence automatically.
5. Audit before launch. Export a flow and check every branch terminates and every question has a fallback.
6. Template triage. Browse the template library, apply the closest match to a new use case, then hand the assistant the brief for what to change rather than starting the flow from a blank canvas.

The honest limitation: an assistant is good at reading, drafting and repetitive edits. It is not a substitute for reviewing a conversation flow yourself before publishing it to customers, and tool descriptions - even from a trusted server - should still be treated as untrusted input by the client rather than blindly executed, which is exactly what the MCP specification's own trust and safety guidance recommends.

A less obvious pattern worth trying once the basics work: pairing MCP with your own webhook events. Have a webhook fire into a small script the moment a conversation is escalated, and have that script post a summary into whatever channel your team actually watches, with a note asking someone to open an assistant session and investigate using the conversation and flow tools. This keeps the always-on part of the system - noticing something happened - on the reliable, deterministic REST/webhook layer, and reserves the assistant's reasoning for the part that genuinely benefits from it: figuring out why.

MCP earns its keep for a specific kind of work: irregular, judgement-heavy tasks that touch several parts of a product at once, done by someone who would otherwise be clicking through a dashboard by hand. A support lead reviewing last week's escalations and drafting three knowledge base fixes is a good fit. A marketing team publishing the same weekly report from the same query is not - that is a scheduled job, and a scheduled job belongs on the REST API or a webhook, run by a script that does not depend on an assistant being available and does not consume a model's reasoning budget for a task that never varies.

It also is not a training interface. Connecting an assistant to the knowledge base tools lets it create and edit articles, but it does not change how your chatbot is trained on that content - publishing an article through MCP is the same event as publishing it through the dashboard, and the bot picks it up the same way either route. MCP changes how you operate the product, not what the product's underlying AI does with the data once it is there.

The clearest sign MCP is the wrong tool for a given task: if you can describe exactly what should happen, in what order, every single time, you do not need an assistant reasoning about it - you need a script or a saved flow that runs the same way whether or not anyone is watching.

The setup is short:

1. Create an API key in your workspace settings. Note that the free plan includes zero API calls, so this needs a paid plan.
2. Add the Conferbot MCP endpoint to your MCP client - Claude Desktop, Claude Code, Cursor, VS Code, or any client that speaks the protocol.
3. Provide the API key as the credential.
4. Ask the assistant to list your chatbots. If the tool call returns your bots, the connection is live.

Because the transport is standard Streamable HTTP MCP, anything that implements the protocol works - you are not tied to one vendor's client, unlike a plugin built specifically for a single AI product.

A sensible first session, rather than diving straight into a write action: ask the assistant to summarise your busiest chatbot's last thirty days using the built-in analyze-chatbot-performance prompt. It is read-only, it exercises three tool modules in one request, and it gives you a feel for how the assistant sequences calls before you hand it anything that changes live data. Once that feels right, move to something with a visible, easily-reversible effect - drafting a knowledge base article as a draft rather than publishing it immediately - before trusting it with flow edits on a bot customers are actively talking to.

If you already run bots on Conferbot, the MCP server is the fastest way to stop doing repetitive dashboard work. If you are evaluating platforms and your team works inside AI assistants, it is worth asking every vendor whether they expose one - most will point you at a REST API and leave the integration to you.

Full endpoint details, including every tool's argument schema, live in the documentation and the developer API reference, and the same underlying capabilities are available over the public REST API with a published OpenAPI spec for conventional, code-driven integrations. For background on the protocol itself rather than Conferbot's implementation of it, our explainer on MCP covers the concept independent of any one vendor.

If you evaluate other platforms alongside Conferbot, ask each vendor three questions rather than taking "we have an API" at face value: does the MCP server expose write actions or only read-only reporting, is it scoped per workspace the way an API key normally is, and does tool coverage roughly match what their dashboard can do, or is it a thin slice bolted on for a launch announcement. A server with five tools covering only analytics is a very different product decision than one with fifty spanning the whole platform, even though both can be truthfully described as "an MCP server."

The gap between those two answers tends to predict, better than any sales page will, how much of your actual dashboard workload the connection will genuinely absorb once you start using it day to day rather than on the first demo call.