Wiring an MCP Server
into a Live Chatbot

MCP — the Model Context Protocol — is a plain JSON-RPC contract that lets a chatbot ask any server two questions: what can you do? and do this for me. Point a chatbot at an MCP server's URL and it can list that server's tools and start calling them — no bespoke integration code, no hand-written schema, no redeploying the chatbot every time a tool changes.

That's the pitch. Below is the reasoning behind it, the mechanics of how it actually runs on the wire, and then the loop in practice — a sandbox server you can poke at directly, a real chatbot that already speaks MCP, and the code that sits in between.

Before MCP, every AI application that wanted to use an external tool wrote its own glue code for that specific model and that specific API. Give an agent access to Slack, Postgres, and GitHub, and you'd hand-write three integrations. Do that across five internal AI tools and you're maintaining fifteen brittle, one-off adapters — each with its own auth handling, its own schema translation, its own failure modes. That's the M × N problem: M applications, N tools, and a combinatorial mess of custom wiring connecting them.

MCP collapses that to M + N. A tool author builds one MCP server, once. Any MCP-compatible host — Claude, an internal chatbot, an IDE agent — can talk to it immediately, because the contract between "client" and "server" is standardized, not negotiated per integration. It's the same trade every USB-C port or every REST convention makes: a bit of upfront standardization in exchange for integrations that stop being bespoke projects.

MCP splits into three roles, not two. The host is the application the person is using — Claude Desktop, an internal chatbot, an IDE. The host runs an MCP client, and critically, it runs one client session per server: a host talking to three MCP servers is holding three separate, isolated 1:1 connections, not one shared bus. Each session negotiates capabilities independently, which is what makes it safe to connect a sketchy internal tool and a trusted production one in the same conversation without either seeing the other's context.

On the other end, the MCP server exposes its capabilities as one or more of three primitives, and the distinction between them matters more than most write-ups let on:

Everything moves over JSON-RPC 2.0, over one of two transports. stdio is for a server running as a local subprocess on the same machine as the host — no network hop, lowest possible latency, the default for developer tools like IDE agents. Streamable HTTP is for a server running remotely — the host POSTs JSON-RPC messages and the server can optionally stream results back over Server-Sent Events, which is what makes it possible to add a hosted MCP server as a "connector" from a web chatbot the way you saw above. Remote servers authenticate the same way any HTTP API does: bearer tokens, API keys, or full OAuth 2.1 for anything touching real user data.

One detail worth knowing before you deploy anything at scale: MCP sessions are stateful by default — a client and server hold a persistent handshake, which is fine for a single user's IDE but becomes a real load-balancing and horizontal-scaling problem once you're serving a hosted server behind a pool of instances. It's the main thing the protocol's maintainers are actively working through as MCP moves toward more stateless-friendly transport patterns.

This isn't just a spec — it's running. The chatbot below is a normal chat interface with one extra panel: Connectors. Add any MCP server's URL there and the assistant can immediately use whatever tools that server exposes, in the same conversation, with no restart needed.

The sandbox above isn't the only thing you can connect. The exact same connector panel accepts any MCP server's URL — yours included. Paste in your own server and the chatbot discovers whatever it exposes, the same way it discovered the demo's tools: no separate integration path for "your" server versus "the" server.

To make that concrete, the sandbox server is wired to a small product catalog with full read and write access exposed as tools — not just a lookup. From inside the chat, in plain language, you can:

That last one is the part worth pausing on when you're demoing this to a client rather than just yourself. The dashboard isn't a separate admin panel bolted on for show — it reads from the same store the MCP tools write to. So when the chatbot says "added," you can flip to the dashboard's product list and see the row sitting there, no refresh-and-hope. For a client evaluating whether to trust an LLM with write access to real data, that side-by-side — chat on one screen, source-of-truth table on the other — does more convincing than any explanation of the protocol.

Four requests carry the whole loop, plus two ways to hand the discovered tools to an LLM client. Step through them below.

The convenience angle is real but it's not the interesting part. The interesting part is what standardization does once an org has more than one AI application. Without MCP, "add our internal ticketing system to the chatbot" is a project — someone reads the Jira API, writes a schema, hard-codes it into that one chatbot's codebase. With an MCP server sitting in front of Jira, that same capability is a connector any host in the org can pick up: the internal chatbot, an IDE agent, a Slack bot, all reusing the same server instead of three teams writing three adapters that drift out of sync with each other and with the underlying API.

It also changes where the security conversation happens. Because tool access runs through a server boundary instead of being baked into application code, permissioning becomes a property of that server — least-privilege scopes, audit logging, and rate limits live in one place instead of being re-implemented per integration. The protocol's newer additions lean into this directly: elicitation lets a server pause mid-task and ask the human for explicit confirmation before a high-risk action executes, which is what turns "agent with tool access" into "agent with tool access and a human still in the loop for the actions that matter." For anything touching production data, money, or irreversible actions, that pause is the difference between a demo and something you can actually ship.

None of this is finished, and treating it as a settled, boring standard would be a mistake. Statefulness at scale is still an open problem for teams running MCP servers behind load balancers. Auth patterns are still consolidating around OAuth 2.1 rather than being fully settled. And the protocol itself is still moving — Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025 specifically so its evolution wouldn't depend on one vendor, and the spec has kept shipping since. Build on it, but read the changelog before you pin a version in production.

In about two minutes you can see the entire workflow end to end. Open the sandbox to watch the connection handshake, then open the chatbot and add the same server URL as a connector — the identical set of tools appears in both places, because both speak the same standardized protocol. Looking for more servers to connect? There's a running list at MCP Playground — Awesome MCP Servers.