If you have been following the AI tooling space closely, you have probably heard “MCP” mentioned more and more over the past year. It started as an Anthropic project in late 2024. By mid-2025 it had become an industry standard that OpenAI, Google DeepMind, Microsoft, and Salesforce all adopted. By early 2026 it was donated to the Linux Foundation and tens of thousands of MCP servers existed in the wild.
And yet most developers still do not have a clean mental model of what MCP actually is. The explanations tend to be either too abstract (“it is a protocol for connecting AI to tools”) or too technical to be immediately actionable. This post tries to fix that.
The Problem Before MCP
To understand why MCP matters, you need to feel the pain it solves.
Before MCP, every AI tool integration was a bespoke implementation. If you wanted Claude to read your GitHub issues and create a Jira ticket, someone had to write code that:
- Authenticated with GitHub’s API
- Fetched the issues
- Formatted them into a prompt
- Sent that to Claude
- Parsed Claude’s response
- Authenticated with Jira’s API
- Created the ticket
- Handled errors in every step
This was not just one integration. Every combination of AI model and external tool required its own custom implementation. If you switched from Claude to GPT-5, you rewrote the integrations. If a new tool had a useful API, you wrote a new connector. The maintenance surface was enormous.
The deeper problem was context. AI models need information to be useful. A model answering questions about your codebase needs to read the code. A model helping with customer support needs access to customer records. A model helping you plan your week needs your calendar. But getting that information into the model’s context was always custom work.
This created what engineers call an N x M problem. N AI models times M external tools means N x M custom integrations. With dozens of models and hundreds of useful tools, that math becomes unmanageable.
MCP solves this by turning it into N + M. Build one MCP server for a tool, and every MCP-compatible AI model can use it.
What MCP Actually Is
Model Context Protocol is an open standard that defines a common language for AI models to communicate with external tools, data sources, and services.
The simplest way to think about it: MCP is to AI tools what USB is to hardware peripherals. Before USB, every device needed its own proprietary connector and driver. After USB, any device with a USB connector worked with any computer that had a USB port. MCP does the same thing for AI integrations.
Technically, MCP is a JSON-RPC based protocol. An MCP server exposes capabilities to an MCP client using a defined message format. The capabilities come in three forms:
Tools are things the AI can do. Read a file. Send a message. Create a calendar event. Execute a database query. Tools have a name, a description, and a defined input schema. The AI model can call them like functions.
Resources are things the AI can read. A file’s contents. A database row. A web page. An API response. Resources give the model access to information it would not otherwise have in its context window.
Prompts are templates the AI can use. Pre-written system prompts, workflow templates, or structured instructions that an MCP server can expose for specific use cases.
An MCP server is a lightweight program that exposes some combination of tools, resources, and prompts using this protocol. An MCP client is an AI tool (like Claude Code, Cursor, or any AI application) that connects to one or more MCP servers and uses what they expose.
How MCP Works in Practice
The architecture is straightforward once you see it.
Your AI tool acts as the MCP client. When you start a session, it connects to one or more MCP servers. Those servers register their tools, resources, and prompts with the client. The AI model then knows it has access to those capabilities and can invoke them when relevant.
Here is a concrete example. You have Claude Code open in your terminal. You have an MCP server running for your PostgreSQL database. Claude Code’s system prompt now includes a description of that database’s tools: query_database, list_tables, get_schema. When you ask Claude to “find all users who signed up last week and check if they completed onboarding,” it:
- Calls
list_tablesto understand what tables exist - Calls
get_schemaon the users and onboarding tables - Calls
query_databasewith the right SQL query - Gets the results back
- Answers your question
You never wrote any custom integration code. You just pointed Claude Code at an existing MCP server for PostgreSQL.
The communication happens over one of two transports:
stdio is for local MCP servers that run on your machine as child processes. The client and server communicate over standard input/output. Fast, simple, good for local tools.
HTTP with Server-Sent Events (SSE) is for remote MCP servers. The client connects over HTTP. This works for cloud services, shared team servers, or any case where the server needs to run independently.
The MCP Ecosystem in 2026
The growth of the MCP ecosystem has been remarkable. In November 2024 when Anthropic released MCP, there were a handful of reference servers. By early 2026, there are tens of thousands.
Some of the most widely used MCP servers in the ecosystem:
Developer tools:
- GitHub (read repos, issues, pull requests, create branches, comment on PRs)
- GitLab (similar GitHub capabilities for GitLab users)
- Linear (project management, issue creation, sprint tracking)
- Jira (read and create issues, update status, query boards)
- Sentry (read error reports, get stack traces, check release health)
Data and databases:
- PostgreSQL (query, schema inspection, data exploration)
- MySQL (same)
- SQLite (same, local)
- MongoDB (document queries, collection management)
- Supabase (includes auth, storage, and database in one MCP server)
Communication and productivity:
- Slack (read channels, send messages, search history)
- Notion (read and write pages, query databases)
- Google Drive (read documents, search files)
- Gmail (read and search email, draft replies)
- Google Calendar (read events, create meetings, check availability)
Infrastructure:
- Kubernetes (read pod status, logs, apply manifests)
- Docker (container management, log inspection)
- AWS (S3 operations, CloudWatch logs, resource queries)
- Cloudflare (Workers deployment, KV operations, analytics)
Browser and web:
- Puppeteer (browser automation, screenshot capture, web scraping)
- Playwright (same, with better cross-browser support)
- Fetch (simple HTTP requests, web content retrieval)
Local system:
- Filesystem (read and write files with configurable path restrictions)
- Terminal (execute shell commands with permission controls)
- Memory (persistent key-value storage across sessions)
This is a small slice of what exists. The ecosystem keeps growing because the protocol is simple to implement.
Real Examples of MCP in Action
Here are some actual workflows that become straightforward with MCP:
Debug with full context
Without MCP, you copy a Sentry error URL, paste the stack trace, and manually add context about what the affected code looks like.
With Sentry’s MCP server and your filesystem connected, you ask: “The error in Sentry issue SEN-4821 is showing up in production. What is causing it and what should I fix?” Claude reads the Sentry issue, pulls the stack trace, reads the relevant files in your codebase, and gives you a diagnosis with a suggested fix. One prompt instead of five minutes of context gathering.
PR reviews with real understanding
You ask: “Review my last pull request on the backend repo and flag anything that could cause performance issues in production.”
With GitHub MCP, Claude reads the actual diff, the files changed, and the context of what changed. It is reviewing real code, not code you copied into a chat window.
Data exploration without writing queries
You ask: “Which of our paid users logged in less than once in the last 30 days? I want to prioritize them for a re-engagement email.”
With a database MCP server, Claude writes and executes the query, gets the results, and formats them for you. No SQL, no dashboard lookup, no waiting for a data analyst.
Meeting prep
You ask: “I have a call with Acme Corp at 2pm today. Pull up the last three email threads with them and summarize what we have discussed and what is outstanding.”
With Gmail and Google Calendar MCP servers, this takes seconds. Claude checks the calendar, finds the contact, searches the email threads, and gives you a pre-meeting brief.
Building Your First MCP Server
The protocol is accessible enough that you can build a basic MCP server in an afternoon. Here is a minimal example using the official TypeScript SDK:
npm install @modelcontextprotocol/sdkA simple MCP server that exposes a tool to fetch weather data:
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import {
CallToolRequestSchema,
ListToolsRequestSchema,
} from '@modelcontextprotocol/sdk/types.js';
const server = new Server(
{
name: 'weather-server',
version: '1.0.0',
},
{
capabilities: {
tools: {},
},
}
);
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: 'get_weather',
description: 'Get current weather for a city',
inputSchema: {
type: 'object',
properties: {
city: {
type: 'string',
description: 'The city name',
},
},
required: ['city'],
},
},
],
};
});
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === 'get_weather') {
const city = request.params.arguments?.city as string;
// Your actual weather API call here
const weatherData = await fetchWeatherFromApi(city);
return {
content: [
{
type: 'text',
text: `Weather in ${city}: ${weatherData.description}, ${weatherData.temp}°C`,
},
],
};
}
throw new Error('Unknown tool');
});
async function fetchWeatherFromApi(city: string) {
// Replace with real API call
return { description: 'Partly cloudy', temp: 18 };
}
const transport = new StdioServerTransport();
await server.connect(transport);To use this in Claude Code or Cursor, you add it to your MCP config:
{
"mcpServers": {
"weather": {
"command": "node",
"args": ["/path/to/weather-server/dist/index.js"]
}
}
}That is the whole thing. The server registers its tools, handles requests, and returns results. The AI client discovers the tools automatically and can use them in any conversation.
The real power comes when your MCP server connects to internal systems: your company’s database, your own APIs, internal documentation. You control what the AI can access and what it cannot. The filesystem MCP server, for example, only exposes paths you explicitly allow.
Why MCP Becoming a Standard Actually Matters
Proprietary protocols are a trap. When your integrations only work with one AI model, you are locked in. When a better model comes out, switching costs are high because everything has to be rewritten.
MCP breaks that lock-in at the integration layer. Your GitHub MCP server works with Claude Code, Cursor, and any other MCP-compatible client. When you switch or add AI tools, your integrations come with you. The work you put into building or deploying MCP servers is not wasted when the AI model landscape shifts.
This is why the industry adoption happened so quickly. OpenAI, Google, and Microsoft adopted MCP not because Anthropic asked nicely but because the alternative (maintaining proprietary integration ecosystems) is expensive and creates fragmentation that hurts everyone. Developers want integrations that work everywhere. The standard that wins is the one the whole ecosystem backs.
Anthropic donating MCP to the Agentic AI Foundation under the Linux Foundation in December 2025 was the signal that cemented this. It removed any concern that MCP was a vendor-controlled standard. The Linux Foundation governance model means no single company can steer it for competitive advantage.
The Security Model You Should Understand
MCP servers have real access to your systems. That filesystem server can read any path you allow. That database server can run any query. That shell server can execute commands.
This means you need to think about what you expose through MCP the same way you think about API permissions. Practical rules:
Restrict filesystem paths. Only expose the directories relevant to your current project. Do not give blanket access to your home directory.
Use read-only tools where you can. For data exploration, a read-only database connection is safer than full access. Many MCP servers support configuration flags for this.
Be careful with community MCP servers. The ecosystem is large and not everything is well-reviewed. For anything touching production systems or sensitive data, audit the server code before using it.
Remote MCP servers need proper auth. If you deploy a remote MCP server for your team, treat it like any API: authentication, rate limiting, audit logging.
The protocol has security in mind at the design level, with a permission scoping model built in, but the server implementations vary in how seriously they take it.
Where MCP Goes from Here
The protocol is at version 1.0 now and relatively stable. The 2026 roadmap includes better streaming support, richer resource types, and improved sampling capabilities (letting MCP servers trigger model calls themselves for multi-agent workflows).
The enterprise adoption curve is accelerating. Salesforce, ServiceNow, and Workday all adopted MCP in 2025. This means MCP servers for enterprise systems are being built by the enterprise software vendors themselves, not just by individual developers. The coverage of the ecosystem will get much broader.
The most interesting direction is multi-agent orchestration. MCP servers can already call other MCP servers. AI agents can act as both clients (consuming tools from servers) and servers (exposing their own capabilities to other agents). This makes it possible to build layered agent systems where specialized agents handle specific tasks and a coordinator agent orchestrates them. The infrastructure for this is MCP.
Should You Start Using MCP Now?
Yes, and the entry point is lower than you think.
If you use Claude Code, MCP support is built in. You just need a config file and an MCP server. Start with the filesystem server (official, well-maintained) to give Claude access to your project files beyond what it reads automatically. Then add a database server if you do data work. Then add whatever integrations are relevant to your workflow.
If you use Cursor, MCP support was added in late 2025. The setup is similar.
If you are building AI-powered applications, design your tool integrations as MCP servers from the start. You get multi-model compatibility for free, the community gets servers they can reuse, and you future-proof your architecture against the inevitable model switches ahead.
The window where MCP was a “cool but experimental thing” has closed. It is infrastructure now, the same way REST APIs were experimental in 2005 and are just how the web works today. Getting fluent with MCP in 2026 is the same kind of career move as getting fluent with REST in 2006.
The standard is set. The ecosystem is growing. Time to build on it.