What Is MCP (Model Context Protocol)? A Developer's Primer
An accessible primer on the Model Context Protocol — what it is, why Anthropic created it, and how it lets AI coding agents call real tools and read real data.
What is MCP?
The Model Context Protocol is an open specification for connecting AI agents to external tools and data sources. An MCP server runs as a separate process, exposes a typed set of tools, resources, and prompts over JSON-RPC, and an MCP-aware client (Claude Code, Cursor, Cody, Windsurf, Continue) connects to it on startup and lets the model call the tools as part of a conversation.
The shortest accurate definition: MCP is the USB-C of AI tools. Before MCP, every IDE had to write its own integration with every data source — Cursor needed its own Slack connector, Cody needed its own GitHub connector, and so on. After MCP, every data source ships one server that all MCP-capable IDEs can use.
Why MCP exists
Before MCP, the M×N integration problem dominated AI tooling. If you have M agent runtimes (Cursor, Claude Code, Cody, etc.) and N data sources (GitHub, Slack, your internal tracker), you need M×N integrations. With MCP, you need M+N — each runtime ships one MCP client, each data source ships one MCP server, and they speak the same protocol.
Anthropic announced MCP in November 2024. The bet was that an open protocol would generate ecosystem effects faster than any single vendor's proprietary plugin system. Eighteen months later that bet looks correct: the MCP server catalog hit 1,000+ entries in early 2026, and most major AI coding tools support it natively.
The other forcing function: agentic workflows. As LLMs got better at multi-step reasoning, the bottleneck moved from "can the model think?" to "can the model call the right tools at the right time?" MCP standardizes the tool-calling surface so the model isn't relearning a new API every time the IDE changes.
How an MCP server actually works
An MCP client (your IDE) spawns the MCP server as a subprocess, then communicates over stdio (stdin/stdout) using JSON-RPC. The client sends initialize, the server responds with its capabilities. The client asks tools/list, the server returns a typed list of available tools. When the LLM decides to call a tool, the client sends tools/call with the arguments, the server executes and returns a result.
Three transport options exist as of mid-2026: stdio (the default; client spawns server as a child process), HTTP (for hosted MCP servers), and Server-Sent Events (for streaming responses). Stdio is what 95% of installed servers use because it has zero auth overhead and the OS process model handles isolation.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
}
}
}
This config block lives in ~/.claude/mcp_servers.json for Claude Code, ~/.cursor/mcp.json for Cursor, and so on. Adding a new server is a config edit — no code changes, no IDE restart in most clients.
What MCP servers can expose
MCP defines three primitives a server can expose. Tools are functions the agent can call (e.g. list_bugs, create_pr). Resources are read-only data the agent can fetch into context (e.g. a docs page, a file, a database row). Prompts are reusable templates the agent can use as conversation starters (e.g. "review this PR for security issues").
In practice, tools dominate. Most servers ship a dozen tools and zero resources. Resources are powerful for cases where you want the agent to read documentation rather than guess at it — but most teams find tools-first easier to design.
// Simplified MCP TypeScript SDK usage
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const server = new McpServer({ name: 'bugmojo', version: '1.0.0' });
server.registerTool(
'list_bugs',
{
description: 'List bugs filed in the past N days',
inputSchema: { days: z.number().min(1).max(30) },
},
async ({ days }) => {
const bugs = await api.get(`/bugs?since=${days}d`);
return { content: [{ type: 'text', text: JSON.stringify(bugs) }] };
}
);
The ecosystem in mid-2026
The official Anthropic MCP repo ships reference servers for filesystem, GitHub, GitLab, Postgres, Brave Search, Slack, and Google Drive. The community Registry indexes 1,000+ third-party servers as of May 2026. Major SDK languages are TypeScript, Python, Rust, and Go — each maintained by the modelcontextprotocol org on GitHub.
Notable third-party servers as of mid-2026: Linear, Jira, Notion, Figma, Stripe, Sentry, Supabase, Cloudflare, Anthropic itself (Claude API as a tool), and Playwright for browser automation. Most are 100-300 lines of TypeScript wrapping the underlying service's REST API.
Search the MCP Registry by data source you want to expose. Roughly 80% of "I need an MCP server for X" turns out to be "X already has one, you just have to find it." Build only when the catalog comes up empty.
What you can build with MCP today
The three highest-impact uses of MCP in 2026: agents that read+write your bug tracker without leaving the IDE; agents that query your production database for context before suggesting fixes; agents that automate Slack updates after a deployment. Each replaces a context-switch that previously cost 5-15 minutes per task.
Concrete examples from teams shipping MCP-driven workflows:
- BugMojo + Claude Code: developer asks Claude to fetch this week's critical bugs, group by suspected root cause, and propose code fixes. All via the BugMojo MCP server.
- Postgres MCP + Cursor: schema introspection runs at the start of every Cursor session so completions know your actual column names without you pasting them.
- GitHub MCP + Cody: PR review agent reads the diff, the linked issue, and the team's recent merge patterns before commenting.
When to use MCP vs alternatives
Use MCP when an AI agent (in an IDE or standalone) needs to call your tool. Use OpenAPI function calling when an LLM running in your own application needs to call your tool. Use raw REST when no LLM is involved. The three coexist — MCP is not a replacement for APIs, it's a layer on top.
A useful heuristic: if your tool will be called by code your team controls, build a REST or RPC API. If your tool will be called by an LLM your team controls (e.g. inside a chatbot you built), use function calling. If your tool will be called by an LLM in someone else's IDE, ship an MCP server.
Where to learn more
- modelcontextprotocol.io — the official spec and primer.
- github.com/modelcontextprotocol/servers — Anthropic's reference servers, great as code examples.
- github.com/modelcontextprotocol/typescript-sdk — the TS SDK with a clean
McpServerbuilder API.
Ready to use MCP in production? BugMojo ships a public MCP server so Claude Code, Cursor, Windsurf, and Cody can read and triage your bug backlog without leaving the IDE.
Frequently asked questions
Sources
- Model Context Protocol specification — Anthropic (2024)
- Anthropic announcement of MCP — Anthropic (2024)
- MCP TypeScript SDK — modelcontextprotocol (2026)
Get bug-tracking insights, weekly.
Engineering deep-dives, QA playbooks, and honest tool comparisons. No spam — unsubscribe in one click.
Keep reading
How to Connect Claude Code to Your Bug Tracker via MCP
Step-by-step guide to wire Claude Code into BugMojo via the Model Context Protocol so your AI agent can read, triage, and update bugs in about 10 minutes.
How to file a bug report developers actually want to fix
A 2026 guide to bug reports that close fast — what to include, what to skip, and how session replay changes the rules.
How to Integrate BugMojo with Claude Code
Step-by-step guide to connecting BugMojo with Claude Code — what gets synced, how to set it up in 4 steps, and the workflows it enables.

