What is MCP? A Practical Introduction

MCP — the Model Context Protocol — is the standard way to connect AI assistants to external tools, data, and systems. This guide explains what it is, why it exists, and how a single MCP server lets one integration work across every compatible AI client.

MCP stands for the Model Context Protocol. It’s an open protocol — originally introduced by Anthropic in late 2024 — for connecting AI assistants to the systems where data and tools actually live: databases, business tools, source control, file systems, anything you’d otherwise have to write a one-off integration for.

If you’ve used a “connector” or a “tool” inside an AI app and wondered how it gets wired up, MCP is the answer for an increasing share of the ecosystem.

The problem MCP solves

Before MCP, every AI app rolled its own way of plugging into external tools. ChatGPT had plugins. Claude had its own connectors. Cursor had its own hooks. Each integration had to be re-written N times — once per AI host. The work scaled with the product of {tools you want to expose} × {AI clients you want them in}.

MCP collapses that to {tools} + {clients}. Build one MCP server for your tool, and every MCP-compatible client can use it.

The three roles

Every MCP setup involves three pieces:

  • Host — the AI app the user is interacting with (Claude Desktop, Cursor, Cowork, etc.)
  • Client — the in-host runtime that speaks MCP to servers (usually invisible to the user)
  • Server — the small program that exposes the actual tools / resources / prompts

An MCP server can be local (running on your machine, talking over stdio) or remote (running somewhere else, talking over HTTP+SSE). The protocol is the same.

What an MCP server can expose

The protocol defines four things a server can offer to the host:

Tools

Functions the model can call. Each has a name, a JSON-Schema for its inputs, and a description. Tools are the most common surface — “send a Slack message”, “create a calendar event”, “search this database”.

Resources

Read-only data the host can pull into the model’s context. Files, database rows, API responses — exposed as URIs the host can fetch.

Prompts

Reusable prompt templates the server provides. Useful for “best-practice” prompts that ship alongside a tool.

Sampling

The server can ask the host to make an LLM call on its behalf. Less common, used when servers themselves want to reason.

A tool call, end to end

Here’s what happens when you ask an AI host to do something that needs a tool:

  1. Discovery. When the host starts, it asks each connected MCP server: “what tools do you offer?” The server returns a list of {name, description, inputSchema}.
  2. Planning. You send a user message. The host puts your message + the tool list in front of the model and asks it to decide whether a tool is needed.
  3. Tool call. If the model picks a tool, the host translates that into an MCP tools/call request and sends it to the right server.
  4. Execution. The server runs the tool (hits an API, queries a DB, whatever) and returns a structured result.
  5. Synthesis. The host puts the result back in front of the model, which writes the final reply to you.

What a minimal server looks like

A working MCP server is just a small program that responds to a handful of JSON-RPC methods. Here’s the shape of a tool definition in TypeScript:

typescript
server.tool(
  "search_users",
  "Search the directory by partial name. Returns up to 10 matches.",
  {
    query: z.string().describe("Partial name to search for"),
  },
  async ({ query }) => {
    const rows = await db.search(query);
    return { content: [{ type: "text", text: JSON.stringify(rows) }] };
  }
);

That’s it. Once registered with a host, this tool shows up in the model’s tool list every time the host talks to your server.

When MCP is the right answer

  • You have a tool / API / dataset and want it usable from multiple AI clients
  • You want users to be able to install your integration the way they’d install a plugin
  • You want the integration to work in chat and in IDE-like agents (Cursor, Cowork, etc.) without two builds

When it’s not

  • You’re building a single-app integration and won’t need portability
  • The tool is so deeply tied to the host’s UI that an external server can’t do the job (rare)

To go from theory to a working server, see Build your first MCP server in 30 minutes. For when to choose between MCP and a plain function-calling integration, see MCP vs function calling.

#integrations #mcp #model-context-protocol #tools