An MCP server is a program that exposes tools, data, and prompts to AI agents over the Model Context Protocol (MCP), an open standard created by Anthropic. Instead of pasting documentation into chat, agents like Claude Code and Cursor call the server directly to read schemas, query APIs, and act on live project state.
If you build with AI coding agents — Claude Code, Cursor, Codex, or any of the others — you've probably hit the same wall we did. The model is smart enough. It can write code, refactor functions, even architect systems. But it keeps asking questions it shouldn't need to ask. "What's the database schema?" "Which API endpoints exist?" "What tickets are in progress?" The model isn't stupid. It's blind. It can't see your project's context, and that is exactly the problem an MCP server solves.
MCP in one sentence
MCP is an open standard that lets AI agents connect to external tools and data sources through a single, universal interface. Think of it as USB-C for AI context: one plug, every device. Before MCP, every AI tool needed its own custom integration with every data source. After MCP, you build one server and every MCP-compatible client can use it. That answers the literal question — what is an MCP server? It's the thing on the other end of that plug: the process that holds the tools and serves the context.
The LSP analogy: why developers get MCP instantly
If you've worked with modern editors, you already understand the pattern. Before the Language Server Protocol (LSP), every editor had to build its own support for every language. VS Code needed a Python plugin, Vim needed a Python plugin, Sublime needed a Python plugin — all doing the same work independently. LSP changed that: language authors build one server, and every editor that speaks LSP gets autocomplete, go-to-definition, and diagnostics for free.
MCP does the same thing, but for AI agents instead of editors. A service builds one MCP server, and every agent that speaks MCP — Claude Code, Cursor, Windsurf, Codex, your own custom agent — gets access to that service's tools and data. The MCP server meaning is right there in the name: it serves context to models over a shared protocol. No more N×M integration matrices. No more fragile, one-off context pipes.
Why context matters more than code generation
Here's something we learned building AppHandoff's MCP server: the bottleneck in AI-assisted development isn't code generation. Models are already good at writing code. The bottleneck is context — giving the model accurate, up-to-date information about your specific project so it writes the right code.
Without proper context, an AI agent is like a brilliant contractor who showed up to the job site without blueprints. They know how to frame a wall, but they don't know where it goes. So they ask you. Constantly. Every question breaks your flow. Every answer you give manually is context you're carrying instead of the system carrying it for you.
We tested this directly. We gave the same task — 'add a project settings page' — to an agent with MCP context and one without. The agent without context generated a plausible settings page that called three endpoints that didn't exist, used a data shape that didn't match the database, and skipped auth entirely. The MCP-connected agent generated a page that called real endpoints with correct shapes. It wasn't smarter — it just knew more.
How an MCP server works: the architecture
MCP follows a client-server architecture with three core components. For a deeper technical breakdown — sessions, transports, capability negotiation — see our deep dive on MCP server architecture.
MCP hosts are the applications you interact with — Claude Desktop, Cursor, VS Code with Copilot, or any AI-powered tool. The host is what you see on screen.
MCP clients live inside the host. Each client maintains a 1:1 connection with a specific MCP server. The client handles protocol negotiation, capability discovery, and message routing. You usually don't interact with clients directly — they're the plumbing.
MCP servers are where the action is. Each server exposes a specific set of capabilities — tools to call, resources to read, prompts to use. A server might wrap a database, an API, a ticketing system, or an entire development workflow. The server is a lightweight process, not a heavy-weight service. It does one thing well.
These components communicate over one of two transports. stdio — the server runs as a local subprocess. The host spawns it and communicates over stdin/stdout. This is the most common setup for local development tools. Streamable HTTP — the server runs remotely and communicates over HTTP with optional server-sent events (SSE) for streaming. This is the transport for cloud-hosted MCP servers that need authentication, multi-user access, or persistent state.
// MCP tool call example — agent asks for the API spec
{
"method": "tools/call",
"params": {
"name": "get_api_spec",
"arguments": {
"project_id": "2eb00287-ebfd-412d-827f-a10c45faa7be"
}
}
}
// Server responds with the actual OpenAPI spec:
{
"content": [{
"type": "text",
"text": "{ \"openapi\": \"3.1.0\", \"paths\": { \"/api/projects/{id}\": { \"get\": { ... } } } }"
}]
}Tools, resources, and prompts: the three primitives
Every MCP server exposes capabilities through three primitives. Understanding these is key to understanding what MCP servers actually do in practice.
Tools are functions the agent can call — the "do something" primitive. A tool has a name, a description, and a JSON Schema defining its inputs. When an agent calls a tool, the MCP server executes it and returns a result. Examples: create_ticket, get_db_schema, trigger_rescan, deploy_check. Tools are the most commonly used primitive.
Resources are data the agent can read — the "know something" primitive. A resource has a URI and returns structured content. Resources are read-only and can be anything: a file, a database schema, a project configuration, an API specification. The agent requests what it needs, and the server delivers it.
Prompts are reusable templates the server offers — the "think about it this way" primitive. A prompt provides a structured starting point like a code review template that already knows your team's conventions. Prompts let server authors encode domain expertise into the protocol.
MCP server examples
Let's make this concrete with the servers developers actually run. If you want a fuller MCP server list with setup instructions for each, see our roundup of MCP server examples; if you work mainly in one editor, the best MCP servers for Claude Code ranks the ones worth adding first.
GitHub MCP server — official, maintained by GitHub. Exposes repositories, issues, pull requests, and code search. An agent can look up open issues, read PR comments, search across your codebase, and create branches — all through the protocol. See our guide on setting up the GitHub MCP server in Cursor.
PostgreSQL MCP server — exposes your database schema as a resource and provides tools like query and describe_table. Your agent can inspect table structures, understand your data model, and write queries that match actual column names — without you copying schema definitions into a prompt. Full breakdown in our PostgreSQL MCP server guide.
Linear / Jira MCP servers — issue tracking, sprint management, and workflow automation. Agents can read and update tickets directly without you narrating the backlog.
AppHandoff MCP server — full-project development context for AI-built apps. It gives every connected agent the shared work state as MCP tools — handoff tickets with roles, milestones, published API contracts, deploy checks, and health dashboards. When an agent connects, it can see what work needs doing, what is claimed, and what the current interface agreements are — all structured and current.
MCP server vs API: what's actually different
A fair question, because an MCP server usually wraps an API. The difference is the contract. A REST API documents its endpoints for humans; every client team writes its own integration code, picks an SDK, handles auth its own way. An MCP server is self-describing: every tool ships a name, a description, and a JSON Schema for its inputs, and the client discovers all of it at runtime through capability negotiation. No SDK, no wrapper code, no per-client integration.
The second difference is the consumer. APIs are designed for programs written by developers; MCP servers are designed for models. Responses come back as structured content an agent can drop straight into its context window. Authentication is standardized — remote servers use OAuth 2.1 rather than a bespoke key scheme per vendor. Sessions, streaming, and progress notifications are part of the protocol instead of something every team reinvents. If your system already has an API, an MCP server is typically a thin layer on top of it — one that makes the API legible to every agent at once.
How to connect Claude Code or Cursor to an MCP server
Here's what a connection looks like in practice. For a full walkthrough including OAuth authentication, see our step-by-step connection guide for Claude Code, Cursor, and Codex.
Claude Code — add a remote Claude MCP server with one command:
claude mcp add apphandoff https://api.apphandoff.com/api/mcp-botCursor — add the server to your .cursor/mcp.json file:
{
"mcpServers": {
"apphandoff": {
"url": "https://api.apphandoff.com/api/mcp-bot"
}
}
}For a local stdio-based server like the GitHub MCP server, the config looks different:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token"
}
}
}
}That's it. No SDK to install in your project. No wrapper code. The agent discovers the server's capabilities automatically — it asks the server what tools, resources, and prompts are available, and the server responds with a structured manifest. Remote servers like AppHandoff run over Streamable HTTP with OAuth 2.1: the first connection opens a browser window, you approve access, and the session persists from there. Codex connects the same way, and Lovable connects through its MCP integration.
Is MCP only for Claude?
No. Anthropic created the protocol and Claude had it first, which is why so many searches read "Claude MCP server" — but MCP is an open standard with an open specification, and the client list has long outgrown its origin. Claude Code, Claude Desktop, Cursor, Windsurf, Codex, and VS Code with Copilot all ship MCP clients today, and any tool that implements the client spec can connect to any compliant server. That's the entire point of a protocol: you build or connect a server once, and you never redo the work when your team switches editors or adds a second agent.
MCP servers and multi-agent orchestration
Giving one agent context is step one. The next problem shows up the moment you run two: agents duplicating work, overwriting each other, or both "fixing" the same bug from different directions. An MCP server is also the natural coordination layer for that. AppHandoff exposes handoff tickets (HO-1, HO-2, ...) on a shared Kanban where humans and bots work the same board: each ticket carries explicit roles — backend, frontend, QA — plus milestones and a human verification gate, so any connected agent can query what is assigned, what is ready, and what is blocked instead of colliding. We cover the full pattern in our guide to agent orchestration.
There's also a gateway tool, ask_apphandoff, that takes a natural-language ask — "what should I work on next?", "is the deploy healthy?" — and routes it to the right underlying tool. An agent doesn't need to memorize the tool catalogue; it asks, the server routes, and the answer comes back grounded in actual project state. Multiple agents coordinating through shared tickets and one gateway beats every ad-hoc alternative we tried first.
What this means for your development workflow
If you're using AI agents for development today, MCP changes three things immediately.
1. Agents stop hallucinating your infrastructure. When an agent has direct access to your database schema, it doesn't guess column names. When it can read your API spec, it doesn't invent endpoints. Real context eliminates an entire class of AI mistakes.
2. You stop being the context bottleneck. Every time you paste a schema, describe an endpoint, or explain a ticket — you're acting as a manual context bridge between your systems and your agent. MCP automates that bridge. Your role shifts from "context provider" to "decision maker."
3. Your tooling becomes composable. With MCP, Claude Code and Cursor connect to the same servers, see the same context, and use the same tools. Switching agents doesn't mean losing context. Adding a new agent to your workflow doesn't mean building new integrations.
We've been running our own development on MCP for over a year now. Agents that used to generate plausible-but-wrong code now generate correct code on the first try — not because they're smarter, but because they're informed. That's the whole point of MCP: context, not magic. It's also what makes verification possible — agents that can see real state can verify their own work against it.
Get started with MCP
Connect your first server. The GitHub MCP server is the easiest starting point — five minutes to set up, immediate value. Add a PostgreSQL MCP server for your database, and your agent already knows more about your project than it did yesterday.
Try a full-context server. Connect to AppHandoff's MCP server to see what it looks like when an agent has access to your entire project's development context — API contracts, schemas, tickets, deploy status — through a single connection.
Go deeper. Read our technical deep dive on MCP server architecture to understand the protocol internals, or browse our survey of MCP server examples to build out your own MCP server list.