What is the Model Context Protocol (MCP)? A complete guide

The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools, data, and services in a consistent way. Instead of every AI app inventing its own integration format, MCP gives them one shared language — so a tool you build once works across Claude, Cursor, and any other MCP-compatible client.

What problem does MCP solve?

Large language models are good at reasoning but isolated by default. They can't read your database, call your API, or take an action in your product unless you wire that capability in. Before MCP, every team built those connections by hand, and every AI app expected a slightly different format. The result was an M×N problem: M AI applications each needing custom glue for N data sources.

MCP collapses that into an M+N problem. Each AI client implements MCP once, each data source exposes an MCP server once, and everything interoperates. It's the same idea that made the Language Server Protocol succeed for code editors — standardize the interface, and the ecosystem compounds.

How MCP works: clients and servers

MCP is built on a client–server architecture using JSON-RPC messaging. There are three roles worth knowing:

• Host — the AI application a person uses, such as Claude Desktop, Cursor, or Windsurf.
• Client — the connector inside the host that speaks MCP and maintains a session with one server.
• Server — the program that exposes capabilities (your tools and data) to the client.

When you connect a server, the client and server perform a capability handshake, then the client can discover what the server offers and call into it on the model's behalf.

The three MCP primitives

Tools

Tools are actions the model can invoke — "create an invoice," "search users," "get the latest deploy status." Each tool has a name, a description, and a JSON schema for its inputs so the model knows how to call it correctly. Tools are the primitive most people mean when they say "giving the AI tools."

Resources

Resources are read-only data the model can pull into context — files, records, documents, or any addressable content. They let the model read without necessarily taking action.

Prompts

Prompts are reusable, parameterized templates a server can offer — for example a "summarize this ticket" workflow the user can trigger directly.

How does the model actually talk to a server?

MCP defines transports for moving JSON-RPC messages between client and server. The two most common are:

• stdio — the server runs as a local subprocess and communicates over standard input/output. Great for local, single-user tools.
• HTTP + Server-Sent Events (SSE) — the server is reachable over the network at a URL. This is what hosted, multi-user MCP servers use.

A hosted server exposes an endpoint that clients connect to. For example, a Claude Desktop configuration that points at a remote MCP URL looks like this:

{
  "mcpServers": {
    "my-api": {
      "command": "npx",
      "args": ["-y", "mcp-remote@latest", "https://mcp.getcast.io/my-api-abc123"]
    }
  }
}

Where does your API fit in?

Most companies already have the hard part built: a documented HTTP API. MCP is the wrapper that makes that API usable by AI clients. You can write an MCP server by hand with one of the official SDKs, or — if you have an OpenAPI (Swagger) spec — generate one automatically. Cast takes the second path: upload your spec, pick which operations to expose as tools, configure how Cast authenticates to your API, and you get a live MCP URL. No servers to run.

Frequently asked questions