What Is an MCP Server? A Plain-English Developer Guide

What is an MCP server? It's a small program that exposes tools and data to AI applications through the Model Context Protocol (MCP) — an open standard that works like a universal port between an AI model and your systems. Instead of writing custom glue code so every AI tool can reach your database, browser, or issue tracker, you run one MCP server, and any MCP-compatible client — Claude Code, Cursor, Windsurf, and most other agents in 2026 — can connect to it and use it.

You've probably heard MCP described as "USB-C for AI." That's the right mental model: one standardized connector, many devices. This guide explains what an MCP server actually does under the hood, how it differs from a regular API, which servers developers actually run, and how to connect your first one — plus the cases where you don't need MCP at all.

What is an MCP server? MCP in plain English

The Model Context Protocol is an open standard, released by Anthropic in late 2024 and since adopted across the industry, that defines how AI applications talk to external systems. It solves an N×M integration problem: before MCP, every AI tool needed its own bespoke integration with every service. Ten agents times ten services meant a hundred adapters. With MCP, each service ships one server, each AI app ships one client, and everything interoperates.

If you've worked with editors, the closest analogy is the Language Server Protocol. LSP meant a language team could write one language server and have it work in VS Code, Neovim, and every other editor. MCP — which was explicitly inspired by LSP — does the same for AI capabilities: write one server for your system, and every agent can use it.

Three roles matter:

• Host: the AI application the user interacts with — Claude Code, Cursor, Windsurf, a desktop chat app.
• Client: the connector inside the host that maintains a session with one server.
• Server: your program. It advertises what it can do, and answers requests.

The server is usually thin. It doesn't contain a model and it doesn't decide anything — it wraps an existing system (GitHub, Postgres, a browser, an internal service) and presents it in a form models can discover and call.

How an MCP server works: tools, resources, and prompts

Under the hood, MCP is JSON-RPC 2.0 messages over a transport. When a client connects, the two sides run an initialize handshake and exchange capabilities. Then the client asks the server what it offers. Servers expose three primitives.

Tools: functions the model can call

Tools are the workhorse. Each tool has a name, a human-readable description, and a JSON Schema describing its inputs:

{
  "name": "create_issue",
  "description": "Create a new issue in a GitHub repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string", "description": "owner/name" },
      "title": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["repo", "title"]
  }
}

The client fetches this list at runtime (tools/list) and hands it to the model as part of its context. When the model decides a tool is relevant, the client sends a tools/call request, the server executes it, and the result flows back into the conversation. The description is not documentation for humans — it's the text the model reads to decide when and how to call the tool. Bad descriptions are the number-one cause of tools that never get used.

Resources: data the application can read

Resources are read-only data identified by a URI — a file, a database schema, a log stream. Unlike tools, resources are application-controlled: the host decides which ones to pull into context, rather than the model calling them on its own. Think of tools as "things the model does" and resources as "things the model reads."

Prompts: reusable templates the user invokes

Prompts are pre-built templates a server offers to users — they often surface as slash commands in the host. A database server might ship a /explain-query prompt that wraps your query with the right context before sending it to the model.

Transports: stdio and HTTP

Local servers usually run as a subprocess and speak over stdio — your agent launches the server and pipes JSON-RPC through stdin/stdout. Remote servers speak streamable HTTP, which supports OAuth for authentication and lets one hosted server serve many users. That's the split to remember: stdio for tools on your machine, HTTP for services on someone else's.

MCP vs API: what actually changes

The honest answer to the MCP vs API question: an MCP server usually wraps an API. It's not a replacement for REST or gRPC — it's a presentation layer that makes an existing system usable by a model instead of a developer. What changes is who the consumer is and when integration happens.

The practical difference shows up in how you spend your time. Integrating an API means writing and maintaining client code. Integrating an MCP server means adding one config entry — after that, the model reads the tool descriptions and figures out the rest. That's also why tool design matters more than endpoint design: you're writing for a reader that takes descriptions literally.

What is an MCP server used for? Popular picks developers run

The MCP server ecosystem now covers most systems developers touch daily. The categories that come up constantly:

• Source control: GitHub's MCP server for issues, PRs, and CI status without leaving the agent.
• Browsers: Playwright's MCP server so agents can drive a real browser — click, fill forms, read pages, take screenshots.
• Databases: Postgres and other database servers so agents can inspect schemas and run queries instead of guessing at your data model.
• Errors and observability: servers like Sentry's, so the agent can pull the actual stack trace it's supposed to fix.
• Documentation: docs servers that fetch current library documentation, cutting down on hallucinated APIs.
• Design: Figma's MCP server for reading designs during implementation work.

We keep a hands-on roundup in the best MCP servers for coding if you want concrete recommendations with setup commands.

One more worth knowing: localskills.sh runs its own MCP server, so an agent can search the skill registry and install skills mid-session over MCP, with OAuth and scoped access rather than a raw API key.

Connecting your first MCP server in five minutes

Claude Code makes this a one-liner. Here's the whole flow:

1. Add a local server (stdio). The agent launches it as a subprocess:

claude mcp add playwright -- npx @playwright/mcp@latest

2. Or add a remote server (HTTP). OAuth happens in your browser:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

3. Verify the connection. Inside a Claude Code session, run /mcp to see connected servers, their tools, and auth status.

4. Share it with your team. Check a .mcp.json into your repo root and everyone who opens the project gets the same servers:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

5. Use it. Ask the agent to do something the server enables — "open the staging site and screenshot the checkout flow" — and watch it call the tools.

Cursor, Windsurf, and other clients follow the same pattern with their own config files. For scopes, permissions, and debugging failed connections in Claude Code specifically, the Claude Code MCP guide goes deeper on all of it.

When you don't need MCP at all

MCP is for giving agents live capabilities — things that require calling a system at runtime. A lot of what teams reach for MCP to solve is actually a knowledge problem, and knowledge doesn't need a server.

• Conventions and patterns belong in skills, not servers. "Always use our API error format" or "here's how we structure Next.js routes" is static instruction. A SKILL.md file loads it into context with zero processes to run and zero auth to manage. The Claude skills vs MCP breakdown covers how to split responsibilities between the two.
• If the agent can run a CLI, a script often beats a server. Agents already execute shell commands. Wrapping gh pr list in an MCP server adds a layer without adding capability.
• Every server you add costs context. Tool definitions are injected into the model's context window on every session, and a dozen servers with fifty tools each will bloat prompts and degrade tool selection. We wrote up the failure mode in too many MCP tools cause token bloat.

A reasonable rule: reach for MCP when the agent needs to act on or read from a live system, especially one requiring authentication. Reach for skills when the agent needs to know something — and keep both lists short.

FAQ: MCP servers

Is an MCP server the same as an API?

No. An API is an interface designed for developers to program against; an MCP server is a standardized wrapper that makes a system usable by AI models at runtime. Most MCP servers call regular APIs internally — the value is the model-readable tool schemas and the universal client compatibility.

Do I have to build my own MCP server?

Usually not. For mainstream systems — GitHub, browsers, databases, error trackers — official or well-maintained servers already exist, and connecting one is a single config entry. You build your own when you want agents to reach an internal system that has no public server.

Is MCP only for Claude?

No. Anthropic created the protocol, but it's an open standard. Claude Code, Cursor, Windsurf, and a wide range of other agents and IDEs ship MCP clients, which is exactly the point: one server, every tool.

How is an MCP server different from an agent skill?

An MCP server provides live capabilities — functions the model calls against real systems at runtime. A skill provides knowledge and procedure — instructions loaded into context. They complement each other: a skill can teach the agent when and how to use an MCP server's tools well.

Are MCP servers safe to add?

Treat them like dependencies. A server runs with real credentials and its tool results enter your model's context, so only add servers from sources you trust, prefer OAuth-scoped remote servers over pasting long-lived API keys, and review what a tool can do before granting it write access to anything important.

---

Once your agents have live capabilities over MCP, give them your team's knowledge too — localskills.sh lets you publish versioned skills once and install them into Claude Code, Cursor, Windsurf, and more.

npm install -g @localskills/cli
localskills install your-org/your-first-skill --target cursor claude windsurf