What Is the Model Context Protocol (MCP)?
The connection problem MCP solves
AI assistants are most useful when they can act, not just talk. An assistant that can read your files, query your database, or build a document for you is worth far more than one that only suggests what you might do yourself. But for a long time, every integration was custom. Each assistant spoke to each tool through its own glue code, and connecting a new app meant writing that glue all over again.
The Model Context Protocol (MCP) fixes this. Introduced by Anthropic in late 2024 as an open standard, MCP gives AI assistants a single, shared way to talk to external systems. Write your tool to the protocol once, and any MCP-compatible assistant can use it — no per-integration plumbing.
The analogy that stuck is “USB-C for AI.” Instead of a different cable for every device, you have one standard connector and everything speaks the same language.
How MCP works
MCP is a client–server protocol built on JSON-RPC:
- The MCP server is the thing that knows how to do the work. It exposes a set of capabilities — tools to call, data to read, prompt templates to fill in. A server might wrap your email builder, your file system, a database, a design tool, or anything else with an API.
- The MCP client is the AI assistant (or the app hosting it). It discovers what the server offers and decides when to call on it during a conversation.
- They communicate over a transport. The two in common use are stdio (the server runs as a local process the assistant spawns) and Streamable HTTP (the server is hosted at a URL the assistant connects to over the network).
The assistant never needs to learn your tool’s private API. The server translates its capabilities into the standard MCP vocabulary, and the assistant picks the right capability based on what you asked for in plain language.
The three kinds of capability
An MCP server can expose three primitives:
| Primitive | What it is | Example |
|---|---|---|
| Tools | Actions the assistant can take | ”Create an email”, “Publish the layout” |
| Resources | Data the assistant can read | ”My workspace branding”, “The list of fonts” |
| Prompts | Reusable, parameterized templates | ”A newsletter scaffold I fill in with a topic” |
Most servers lean on tools, because tools are what let an assistant actually do things. But resources and prompts matter too — they’re how an assistant loads the context it needs to act intelligently rather than guessing.
Why a standard matters
Before MCP, the integration graph was combinatorial: every assistant times every tool meant a tangle of bespoke connectors. MCP collapses that into a star. Connect your tool once as a server, and every compatible client — Claude, ChatGPT, and a growing list of others — can reach it the same way.
For users, the payoff is practical: you pick the assistant you like, connect the tools you use, and they just work together. You’re not locked into one vendor’s integration catalog.
MCP in practice: building email
A concrete example makes it tangible. Temway hosts an MCP server that lets an assistant like Claude or ChatGPT build and edit emails on your behalf. You describe the email in plain language — “create a June newsletter from my branding, add a hero button, preview it” — and the assistant calls the right tools: read your branding, create a draft, add a block, render a preview.
Because that surface speaks standard MCP, the same server works whether you connect from a desktop app or a web client, and it’s available on every plan — including Free. The MCP documentation walks through the few-minute setup if you want to try it.
Where to go next
- See exactly how to connect an assistant in the MCP setup guide.
- Learn the prompting patterns that get great results in Create Stunning Emails with AI.
- Understand why an email builder exposes MCP and what it unlocks.
- Compare approaches in AI Email Builder vs. Manual Drag-and-Drop.