What Is an MCP Server? A Complete Guide to Setup and Benefits

If you use more than one AI coding tool or AI assistant, you have probably run into the same wall over and over: your AI can write brilliant code, but the moment you need it to actually check something in a real system — your database, your GitHub repo, your security dashboard, your calendar — you are back to copy-pasting between browser tabs. The AI can reason. It just cannot reach anything outside the chat window.

MCP servers exist to close that gap. Model Context Protocol (MCP) is the open standard that lets an AI assistant connect directly to real tools and data sources — run a scan, query a database, read a file, trigger a build — and get structured results back, all without leaving the conversation. It sounds like a small plumbing detail. In practice it changes what "asking your AI to do something" actually means.

This guide covers what an MCP server actually is, how the protocol works under the hood, how to set one up in a real AI client, and why it is worth the ten minutes of setup. We will use a real, working example along the way — Sayver's own MCP server — not as a pitch, but because seeing an actual config block is far more useful than a hypothetical one.

What is an MCP server?

An MCP server is a small program that exposes a specific set of capabilities — called "tools" — to an AI application, using a shared, standardized protocol. Instead of every AI app writing custom, one-off integration code for every tool or data source it wants to support, both sides just speak MCP. The AI app gets a universal way to discover and call tools; the tool builder writes one server instead of five different plugin formats for five different AI clients.

This is sometimes called the "N×M problem" in integration design: without a shared protocol, connecting N AI applications to M external tools requires roughly N×M custom integrations. MCP turns that into N+M — each AI app implements MCP once, each tool builder implements MCP once, and every combination just works.

MCP was originally published by Anthropic in November 2024 as an open standard. It did not stay an Anthropic-only technology for long: in December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with OpenAI and Block as co-founding members and AWS, Google, Microsoft, Cloudflare, GitHub, and Bloomberg as supporting members. That makes MCP a vendor-neutral, community-governed standard today — not a Claude-specific feature. Adoption reflects that: the official SDKs see roughly 97 million combined monthly downloads.

The three pieces of every MCP connection

Every MCP setup has the same three architectural roles, and understanding them makes the rest of this guide click into place:

• Host — the AI application itself: Claude Desktop, Cursor, Continue, Windsurf, or a CLI agent. The host creates and manages one or more MCP client connections.
• Client— one instance per connected server, living inside the host. It handles the dedicated connection to a single server, discovers what that server offers, and invokes its tools on the host's behalf.
• Server — the program that actually exposes tools, resources, or prompts. This is what a tool builder writes: a thin layer that wraps an existing API (a database, a scanner, a calendar, a search engine) and speaks MCP on the outside.

When a host connects to a server, the server declares what it offers, and the client discovers this automatically — the AI does not need any hardcoded knowledge of a server's tools ahead of time. It learns them dynamically the moment the connection opens, the same way plugging in a USB device lets your computer discover what kind of device it is without you installing anything by hand.

How the wire format works

Under the hood, MCP uses JSON-RPC 2.0 as its message format, with every message UTF-8 encoded. Every interaction is either a request/response pair or a one-way notification. A tool call from the host to a server looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "run_scan",
    "arguments": { "url": "staging.myapp.com" }
  }
}

That is the entire mechanism. The AI decides which tool to call and with what arguments, sends this JSON-RPC message, and the server responds with structured content — usually text, sometimes richer structured data — that the AI reads back into the conversation.

The two transports

MCP defines two ways a client and server actually talk to each other, and picking between them matters for both performance and deployment:

• stdio — the client launches the server as a local subprocess and communicates over standard input/output. There is no network hop, so this is the fastest option, and it is what almost every desktop-client integration uses (Claude Desktop, Cursor, and similar tools all spawn MCP servers this way). The server itself runs entirely on your machine, though it commonly makes its own outbound network calls to a real backend API using a key you provide.
• Streamable HTTP— used for servers deployed remotely, supporting multiple simultaneous client connections over standard HTTP, optionally using Server-Sent Events (SSE) to stream multiple messages back over one connection. This is the mechanism behind "streaming progress" claims you will see from some MCP server providers — instead of one client blocking on a single giant response for a long-running job, the server can push incremental updates as the job progresses. The newer Tasks extension in the MCP specification formalizes this pattern further: a server can respond to a tool call with a task handle immediately, and the client polls or receives updates while the real work continues in the background — the shape needed to avoid a blocking, silent wait on something like a long scan or a slow build.

For local, single-user tools, stdio is almost always the right choice — it is simpler, faster, and does not require you to run or trust a remote server. Streamable HTTP earns its complexity when a server needs to serve many users or clients at once.

How to set up an MCP server

The good news is that using an MCP server, as opposed to building one, is close to identical no matter which server or which AI client you are using. Nearly every MCP integration follows the same four steps:

1. Get a credential from the provider.Most MCP servers that talk to a real backend (a database, a SaaS product, a scanner) need an API key so the server can authenticate outward on your behalf. You generate this from the provider's own dashboard, scoped to your account.
2. Add one JSON block to your AI client's MCP config. Every MCP-speaking client reads a small config file listing the servers it should launch.
3. Ask your agent, in plain language. You do not call tools by name — you just describe what you want, and the AI figures out which tool to call.
4. Get structured results back in the conversation. No switching tabs, no copy-pasting output back into the chat by hand.

Where the config file actually lives

Step two is the part people get stuck on, mostly because the file location differs by client:

• Claude Desktop — Settings → Developer → Edit Config, or edit the file directly: %APPDATA%\Claude\claude_desktop_config.json on Windows, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS.
• Cursor — Settings → MCP → Add, or edit ~/.cursor/mcp.json directly.
• Continue, Windsurf, Codex CLI — each has its own MCP settings section in its client settings, using the same JSON shape.

If the file already has other MCP servers configured, add your new server as another entry inside the existing mcpServers object — do not overwrite the others.

A real, working example

Rather than show a made-up config block, here is Sayver's own MCP server — a small program that lets an AI client run a Sayver security scan, read findings, and triage them, all from inside the chat. The config looks like this once you have generated an API key from your Sayver dashboard:

{
  "mcpServers": {
    "sayver": {
      "command": "npx",
      "args": ["-y", "@sayver/mcp"],
      "env": { "SAYVER_API_KEY": "sayver_sk_..." }
    }
  }
}

A few things worth noticing in that block, because they generalize to almost any MCP server you will add: command and args tell the client how to launch the server (here, npx -y downloads and runs the package fresh, so there is nothing to install manually), and env passes the credential the server needs to authenticate outward. This is the stdiotransport in practice — the client spawns this process locally, and the process itself makes real network calls back to the provider's API using your key.

After saving the config, fully restart the AI client. On launch, it spawns the server and discovers its tools automatically. From there, you just talk to it: "Scan staging.myapp.com with Sayver," and the AI selects the right tool, runs it, and reports back what it found — findings, severities, and in Sayver's case a ready-to-paste fix prompt for each issue.

A note on authentication

The MCP specification supports a subset of OAuth 2.1 for remote, multi-tenant servers over Streamable HTTP — the client acts as an OAuth client, the server acts as a resource server, and access requires explicit user consent. In practice, most locally-run, stdio-launched servers (including Sayver's) skip that complexity and use a simple API key passed as an environment variable instead. This is a legitimate, common pattern for this deployment model — full OAuth 2.1 mainly earns its keep when a server needs to serve many different users or organizations at once, not when it is a single developer running a tool locally against their own account.

If you are building your own server

Most developers will only ever be a consumer of MCP servers, not a builder of one. But if you are curious: the standard, documented shape (using the official TypeScript SDK) is a small server object with one or more schema-validated tool functions, each returning structured content. A tool definition is typically just a name, a description, an input schema, and a handler function that calls whatever real API already exists behind the scenes — the MCP layer itself does no business logic. That is a well-established, low-risk architecture: nearly every MCP server exposing real tools is a thin adapter over an API that already existed before the MCP server was built.

Benefits of using MCP servers

Once the setup is done, the day-to-day payoff is bigger than the ten minutes of config suggests:

• No more tab-switching. The most immediate benefit is also the simplest: you stop copy-pasting between your AI chat and five different dashboards. Ask, and the answer (or the action) happens inside the conversation.
• Write the integration once, use it everywhere. Because MCP is a shared standard, one server works across every MCP-speaking client — Claude Desktop, Cursor, Continue, Windsurf, Codex CLI, and anything else that adopts the protocol. You configure it once per client, not once per tool per client.
• Structured results, not scraped screenshots.Because tool responses are structured data rather than free text pasted in by hand, the AI can reliably act on what it gets back — reference a specific finding, re-run a specific scan, or chain one tool's output into the next tool's input.
• Long jobs do not block the conversation. Servers built on the Streamable HTTP transport can stream progress on long-running work, so a scan or a build that takes a minute or two does not leave you staring at a frozen chat window.
• Dynamic discovery means no brittle hardcoding.Because a host discovers a server's tools at connect time rather than needing them baked in ahead of time, servers can add or change tools without breaking every client that already integrated with them.

The other side: MCP is also a new attack surface

It is worth being honest about the flip side. Giving an AI agent the ability to call real tools and read real data means a compromised or malicious tool response can influence what the agent does next — this is the same underlying risk described in prompt injection, just arriving through a tool's output instead of a webpage or a document. If you are integrating MCP servers into an agent that also has access to sensitive actions, it is worth reading up on the broader category of risks in the OWASP LLM Top 10 — excessive agency and insecure output handling are directly relevant to any tool-calling setup, MCP included. None of this is a reason to avoid MCP; it is a reason to only connect servers you trust, the same way you would only install a browser extension from a source you trust.

The bottom line

An MCP server is a small, standardized bridge between an AI application and a real tool or data source — built once, usable from any MCP-speaking client. Setup is the same four steps everywhere: get a key, add one config block, ask in plain language, get structured results back. The protocol itself is simple (JSON-RPC over stdio or Streamable HTTP), the governance is now vendor-neutral, and the payoff — no more copy-pasting between your AI and every tool you use — is bigger than the setup effort suggests.