MCP in 20 Minutes

The Model Context Protocol — MCP — is the single most important piece of infrastructure in AI tooling as of April 2026. It’s also deeply under-explained. Most posts you’ll find either lean too hard on the “universal plug for LLMs” marketing or drop straight into protocol internals without ever saying why you should care.

This primer is the middle path. Twenty minutes from zero to “I understand MCP, I have a server connected, I know what to do with it.”

What MCP actually is

MCP is an open protocol that standardizes how AI applications talk to external tools and data sources. That’s it. That’s the whole thing.

The reason it matters is that before MCP existed, every AI app wired up every tool integration from scratch — a custom adapter for GitHub in Cursor, a custom adapter for GitHub in Claude Code, a custom adapter for GitHub in ChatGPT, a custom adapter for GitHub in whatever agent framework you were using this week. Every integration, rebuilt N times.

MCP replaces those N adapters with one. A GitHub MCP server exposes GitHub operations through a shared protocol, and every MCP-compatible client — Claude Code, Cursor, ChatGPT, Zed, Windsurf, VS Code with the right extension, your custom agent — can use that one server.

That’s the promise. The reason the promise matters now, specifically in 2026, is that it’s actually starting to be kept. We’ll get to that.

Why this is a big deal right now

Three things shifted in late 2025 and early 2026 that turned MCP from “Anthropic’s hopeful protocol” into industry infrastructure:

1. Anthropic donated MCP to the Agentic AI Foundation in early 2026. It is no longer an Anthropic-governed standard. Google, OpenAI, Microsoft, and a half-dozen other vendors all contribute to the spec. The Foundation publishes the reference implementations.

2. All major AI clients now support MCP natively. Claude Code, Cursor, ChatGPT, Zed, Windsurf, Copilot, VS Code, JetBrains AI Assistant, and Amazon Q all support MCP in their current stable versions. That wasn’t true twelve months ago.

3. The server ecosystem crossed critical mass. There are over 10,000 public MCP servers as of April 2026. The TypeScript SDK alone did 97M downloads in March. A year ago, “let me check if there’s an MCP server for that” was a throwaway line. Today it’s a real first question to ask.

Put those three together and MCP is no longer a bet. It’s the plumbing.

The mental model

Three roles:

• MCP client — the AI app you’re using. Claude Code, Cursor, ChatGPT, etc.
• MCP server — a separate process that exposes tools/data through the protocol. Can be written in any language, but TypeScript and Python are by far the most common.
• MCP host — the runtime that sits between them and routes messages. In practice “host” and “client” are usually the same process.

The client starts a server (either as a subprocess over stdio, or by connecting to a running HTTP endpoint), discovers what tools the server exposes, and then the LLM inside the client can call those tools as naturally as if they were built-in.

That’s the whole architecture.

Three things MCP servers can expose

When a server announces itself to a client, it can offer three kinds of capabilities:

Tools

Functions the model can call. search_github_issues, read_file, run_sql, send_slack_message. This is the most common and most useful capability.

Resources

Static or parameterized documents the model can read. Think: “the contents of this directory,” “the current database schema,” “the latest on-call runbook.” Resources are fetched on demand and inserted into the model’s context.

Prompts

Pre-baked prompt templates the user (not the model) can invoke. Useful for things like “run the 3-step code review” where you want a reusable entry point with known parameters.

For your first six months of using MCP, 95% of what you’ll touch is tools. Resources are nice; prompts are niche. Start with tools.

Connecting your first MCP server (5 minutes)

Let’s install one real server and use it. The target: the official GitHub MCP server, which exposes issue-reading, PR-reading, and repo-searching tools.

In Claude Code

Edit ~/.claude/settings.json (or your project’s .claude/settings.json) and add:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

Restart Claude Code. Ask it: “What are the 5 most recent open issues in anthropic-cookbook?” It will use the GitHub server’s tools automatically. No code written.

In Cursor

Cursor uses the same mcpServers schema. Edit Cursor’s MCP config through Settings → MCP or directly at ~/.cursor/mcp.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    }
  }
}

Same structure, same server, same behavior.

In ChatGPT

ChatGPT’s MCP support (shipped late 2025) lives under Settings → Connectors → Model Context Protocol. You paste a URL or command for the server, ChatGPT runs it in its cloud sandbox, and the tools appear in your conversations.

The same server package works in all three clients. That’s the point — you configure it once per client, not once per (client × server) pair.

Ten servers worth installing today

I’ll keep this list opinionated and narrow. Every server below is one I’d install for a fresh setup.

Install the ones relevant to your work. Skip the rest — more servers connected ≠ more useful; each one consumes a slot of tool schema in the context window.

Writing your first MCP server (10 minutes)

This is where MCP gets interesting. Writing a server is trivial enough that you’ll find yourself doing it for things you wouldn’t have bothered to integrate otherwise.

Here’s a complete server in TypeScript that exposes one tool — a random-number generator — to show the full shape:

// server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "rng-server",
  version: "0.1.0",
});

server.tool(
  "random_number",
  "Return a random integer between min and max (inclusive).",
  {
    min: z.number().int(),
    max: z.number().int(),
  },
  async ({ min, max }) => {
    const value = Math.floor(Math.random() * (max - min + 1)) + min;
    return {
      content: [{ type: "text", text: `${value}` }],
    };
  },
);

await server.connect(new StdioServerTransport());

That’s an entire working MCP server. Compile it with tsc, then add it to your Claude Code config:

{
  "mcpServers": {
    "rng": {
      "command": "node",
      "args": ["/absolute/path/to/server.js"]
    }
  }
}

Restart. Ask Claude for a random number. It will use your tool.

Take that skeleton and replace random_number with whatever operation your work actually benefits from — a shortcut for querying your team’s wiki, a read-only view into your production database, a wrapper around an internal script that you keep re-explaining to Claude. The 10-minute bar is real.

Stdio vs HTTP transport

The example above uses stdio — the server runs as a subprocess and messages flow over stdin/stdout. That’s the simplest transport and the right default for local tools.

For shared or cloud-hosted servers, use streamable HTTP instead. The shape is the same — swap StdioServerTransport for StreamableHTTPServerTransport, bind it to a port, and deploy. Cloudflare Workers and Vercel both have one-click MCP hosting paths as of early 2026; both accept the standard SDK output unchanged.

What to expose, what not to expose

A few rules of thumb that emerged in practice:

• Tools should do one thing. Don’t write a do_everything tool with a mode parameter. Write get_issue, list_issues, create_issue as separate tools. The model picks the right one based on the name and description.
• Descriptions matter more than names. The model reads the description to decide whether to use a tool. A 2-sentence description of when to use the tool dramatically outperforms a 1-word name.
• Return structured text. MCP tool responses are flexible, but plain text (Markdown, formatted prose, or JSON-as-string) is what the model handles best. Avoid binary blobs unless necessary.
• Fail loudly with context. When a tool fails, return a text response explaining what failed and what to try instead — the model will use that to self-correct instead of giving up.

When NOT to use MCP

MCP is not always the right answer. Three cases where it’s the wrong tool:

1. One-off operations. If you need the model to run one specific command once, just give it a bash tool (or use Claude Code’s built-in Bash). Writing or installing an MCP server for something you’ll do once is overkill.

2. Tight-loop tools in a custom agent. If you’re building your own agent with the Claude Agent SDK or OpenAI Agents SDK and your tools are already defined in-process, there’s no reason to add MCP’s RPC overhead. Use MCP for the external things; use native tool definitions for the internal things.

3. Anything where latency matters per call. MCP is fast, but not zero-cost — there’s a per-call round-trip through stdio or HTTP. For a tool called 1,000 times in a loop, that adds up. Inline native tools when latency matters.

Most real-world agent stacks end up being mostly native tools + a handful of MCP servers for external systems. That’s the right shape. Don’t try to put everything through MCP.

Common pitfalls

Config scope confusion. Client configs can live at multiple levels (global, project-level). Which one wins depends on the client. Claude Code merges them; others override. Read your specific client’s docs before putting production credentials in a global config.

Secret handling. MCP server configs commonly include API keys in the env block. That file is plaintext on disk. Use environment variable indirection ("GITHUB_TOKEN": "${env:GITHUB_TOKEN}") and a proper secrets manager, not hard-coded tokens.

Too many servers. Each connected server contributes tool schemas to the model’s context window. Ten servers × ten tools each = 100 tools in the schema. Models perform measurably worse when they have too many tools to choose from. Keep it tight; disconnect what you don’t use.

Server version drift. Pinning to @latest via npx -y means a server can update underneath you and break your workflow. For production, pin specific versions.

Thinking MCP replaces prompts. MCP gives the model tools. It does not give the model judgment. A bad prompt with ten MCP servers attached is still a bad prompt — it just fails in more elaborate ways.

What’s next for MCP

Three things to watch through mid-2026:

• Server discovery. There’s no “npm search” for MCP servers yet — you find them through curated lists. A proper registry is expected from the Agentic AI Foundation later this year.
• Authenticated, multi-tenant HTTP servers. The spec is evolving to handle OAuth-backed servers cleanly. This is what makes “SaaS MCP servers” a real category instead of just local tools.
• Resource subscriptions. The ability for a server to push updates to a subscribed client, rather than the client pulling. Useful for long-running agents that need to react to external state changes.

None of these block using MCP productively today. They’re just the next layer.

Getting started — the five-minute version

If you read nothing else above:

1. Pick one MCP server from the table above that connects to a tool you use every day (GitHub, Linear, Postgres — something concrete).
2. Add it to your Claude Code config.
3. Restart Claude Code.
4. Ask a question that requires using that tool (“What were the last 10 PRs merged on repo X?”).
5. Notice it worked without you doing any integration work.

That’s the moment MCP clicks. After that, writing your own server for something weird and internal is a small step.

Where to go next

• Official MCP docs — the spec, SDKs, and reference servers.
• The Opus 4.7 primer — MCP servers pair naturally with the memory tool for stateful agent workflows.
• Pick a specific server from the table above and read its README. Every server has its own quirks; learning by doing beats reading the spec.