What Is MCP? How the Model Context Protocol Turns Local Apps Into Agent Tools

If you've used a modern coding agent — Claude Code, Codex, Cursor — you've probably been told to "add an MCP server" at some point and just pasted the command. This post explains what's actually happening: what the Model Context Protocol is, why it exists, and how the pieces fit together. We'll use VoxBee's own MCP server as a concrete, working example.

The Problem MCP Solves

A large language model on its own is a closed box. It can reason about text, but it can't read your files, query your database, hit an API, or — in VoxBee's case — transcribe an audio file or speak text aloud. To do anything useful in the real world, the model needs tools.

The trouble is that before MCP, every tool integration was bespoke. If you wanted Claude to talk to your app, you wrote Claude-specific glue. If you also wanted Cursor to talk to it, you wrote Cursor-specific glue. Every (app × agent) pair was its own custom wiring. That's an M×N problem: M apps times N agents equals a lot of one-off integrations that all do roughly the same thing.

The Model Context Protocol, introduced by Anthropic in late 2024 and since adopted broadly, turns that M×N problem into M+N. You build one MCP server for your app, and every MCP-aware agent can use it. You write one MCP client into your agent, and it can talk to every MCP server. Think of it as "USB-C for AI tools" — one standard plug instead of a drawer full of adapters.

The Three Roles

MCP has a small, clean vocabulary. Three roles matter:

Host / Client — the AI app, like Claude Code or Cursor. It runs the model and manages connections to servers.
Server — a program that exposes capabilities. VoxBee is an MCP server. So is a GitHub connector, a Postgres connector, or a filesystem connector.
The model — decides when to use a server's capabilities, based on what the user asked for.

The client and server speak JSON-RPC to each other. When they first connect, they perform a handshake: the client says "hello, here's what I support," the server replies "hello, here's what I support," and they agree on a protocol version. After that, the client can ask the server what it offers and start making calls.

What a Server Actually Exposes

An MCP server can expose three kinds of things. Tools are actions the model can take (and the most common). Resources are data the model can read (like file contents). Prompts are reusable templates a user can invoke. Most servers, including VoxBee, focus on tools.

A tool has a name, a human-readable description, and a JSON Schema describing its arguments. That schema is the contract: it's how the model knows what a tool does and how to call it correctly. When you connect VoxBee, your agent calls tools/list and gets back something like:

transcribe — "Transcribe an audio file." Takes a path argument (a path to an audio file on disk).
speak — "Read text aloud." Takes the text and an optional voice.
stop — "Stop playback." No arguments.
list_models / list_voices — discovery tools, so the model can pick a valid model or voice before acting.

The descriptions matter more than they look. The model reads them to decide whether a tool is relevant to the user's request. A vague description means the model guesses; a precise one means it picks the right tool at the right time.

A Request, End to End

Here's what happens when you tell Claude Code "summarize this PDF and read me the summary," with VoxBee connected:

The model reads the PDF (using a filesystem tool or built-in capability) and writes a summary.
The model sees VoxBee's speak tool in its tool list and decides it's the right one for "read me the summary."
The client sends a tools/call request over JSON-RPC: tool name speak, arguments { "text": "...the summary..." }.
VoxBee's server receives it, validates the arguments against the schema, and dispatches into the same speech engine the app uses.
Audio plays through VoxBee's floating dock, and the server returns a result to the model so it knows the call succeeded.

The model never touched an audio codec or a speech API. It just picked a tool and filled in the arguments — the server did the work.

Transports: How Client and Server Talk

MCP doesn't care where a server runs, only how messages move. There are two common transports:

stdio — the client launches the server as a subprocess and pipes JSON-RPC over standard input/output. Great for local command-line tools.
Streamable HTTP — the server is a long-running HTTP service the client connects to. Better when the server is a real app that's already running, like VoxBee.

VoxBee uses Streamable HTTP, exposing a single POST /mcp endpoint. That's why connecting it looks like a URL plus an auth header rather than a path to an executable:

claude mcp add --scope user --transport http voxbee http://127.0.0.1:5111/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"

Why "Local" Is the Interesting Part

A lot of MCP servers are remote SaaS connectors. VoxBee's is the opposite: it runs on your Mac, binds to loopback (127.0.0.1), and authenticates every request with a bearer token. The agent talks to a server that is physically on your machine, and the actual work — transcription, speech synthesis — happens on-device. Your audio never leaves your computer unless you've deliberately wired in a cloud provider with your own key.

That's a useful mental model for MCP in general: the protocol is just a standard way to expose capability. Whether that capability is a cloud API or a local, private, on-device engine is entirely up to the server author.

Try It Yourself

The fastest way to understand MCP is to watch an agent use one. VoxBee's MCP integration gives Claude Code, Codex, and Cursor a voice in one command, and the underlying local API server lets you poke at the same capabilities over plain REST if you'd rather see the wire format.

Download VoxBee and try it free for 14 days — connect your agent, ask it to read something aloud, and watch the protocol do its thing.