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.
What Is an MCP Server?
An MCP server is a program that exposes tools, data, and prompt templates to an AI application through the Model Context Protocol (MCP), an open standard. The AI application connects to the server as a client, discovers what it offers, and calls it over JSON-RPC. One server then works with any MCP-compatible client, so you write the integration once.
Host (the AI app: Claude Code, Cursor)
|
+-- MCP client (one per server, lives inside the host)
|
+-- MCP server (GitHub, Postgres, filesystem)
|
+-- your tools and dataAnd 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. If you want to install servers right away, jump to the Claude Code MCP setup guide. If you want to write one, see how to build an MCP server in TypeScript.
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, and this is exactly where context engineering comes in as the actual skill worth mastering. 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 Is Model Context Protocol (MCP)?
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 the piece of an AI tool (like Claude Code, Cursor, or any AI application) that connects to an MCP server and uses what it exposes.
MCP Host, Client, and Server: How the Pieces Fit
MCP has three roles, and people mix them up constantly. The host is the AI application you use. The client is a connector the host creates, one per server. The server is the program that provides the capabilities.
+-----------------------------------------+
| Host (Claude Code, Cursor, your AI app) |
| |
| MCP client A MCP client B |
+--------+----------------+---------------+
| |
stdio (local) Streamable HTTP (remote)
| |
+--------v------+ +------v----------------+
| MCP server | | MCP server |
| (filesystem) | | (GitHub, Sentry, ...) |
+---------------+ +-----------------------+| Role | What it is | Examples | Who builds it |
|---|---|---|---|
| Host | The AI application that talks to the model and the user | Claude Code, Claude Desktop, Cursor, VS Code | The AI tool vendor, or you for a custom app |
| Client | A connector inside the host that keeps a one-to-one connection with one server | Created automatically by the host | The host, using an MCP SDK |
| Server | A program that exposes tools, resources, and prompts | Filesystem, GitHub, Postgres, your own internal API wrapper | A vendor, the community, or you |
If a host connects to three servers, it runs three clients. The model never talks to a server directly. The host passes the server's tool descriptions to the model, the model asks for a tool call, and the host's client sends that call to the right server.
MCP Server vs API
An MCP server is not a replacement for an API. Most MCP servers wrap an API. The difference is who the interface is built for.
| REST or GraphQL API | MCP server | |
|---|---|---|
| Built for | Developers writing code | AI models choosing actions at runtime |
| Discovery | You read the docs, then write the client | The client asks the server what it offers and gets names, descriptions, and schemas |
| Contract | Endpoints and payloads you hard-code | Self-describing tools the model can pick without custom code |
| Who decides what to call | Your code | The model, based on the conversation |
| Integration work | One client per API per app | One server works with every MCP client |
| Typical transport | HTTP | stdio (local) or Streamable HTTP (remote) |
A concrete case: GitHub has a REST API. To let an AI agent triage issues with it, you would write glue code for auth, pagination, and prompt formatting in every app. A GitHub MCP server does that once and describes its tools (list issues, comment, open a pull request) in a form any MCP client can read.
Two practical consequences. First, a good MCP server is not a one-to-one copy of an API. Models do better with a few tools that match user intent than with fifty endpoints, which I cover in designing tools the model will actually use. Second, your existing API does not go away. The MCP server sits in front of it.
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. This ties nicely into the broader move toward spec-driven development in 2026, where the spec itself becomes the interface.
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.
Streamable HTTP 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. It replaced the older HTTP+SSE transport, which the current spec lists as deprecated.
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
A basic MCP server is small enough to write in an afternoon. The official TypeScript SDK handles the protocol, so you register tools and return results. I put the complete working example, tool design rules, testing, auth, and deployment in a separate guide: how to build an MCP server in TypeScript.
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
MCP versions its spec by date rather than by number. The latest revision at the time of writing is 2026-07-28. Its biggest change is that MCP is now stateless: the initialize handshake and protocol-level sessions are gone, and every request carries its own protocol version and client capabilities. That makes remote servers much easier to scale horizontally. The same revision deprecates the old HTTP+SSE transport, and also deprecates the Roots, Sampling, and Logging features.
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. AI agents can act as both clients (consuming tools from servers) and servers (exposing their own capabilities to other agents). MCP handles the agent-to-tool edge well. For independent agents that need to coordinate with each other, a sibling protocol exists: see A2A vs MCP for when to use which.
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, the setup is similar. The Claude Code MCP setup guide walks through the exact commands and config files for both.
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.
Frequently Asked
What is an MCP server? A program that exposes tools, data, and prompt templates to an AI application through the Model Context Protocol. The AI app connects as a client, discovers what the server offers, and calls it over JSON-RPC.
What does MCP stand for? Model Context Protocol. It is an open standard that Anthropic released in November 2024 and later donated to the Agentic AI Foundation under the Linux Foundation.
Is an MCP server the same as an API? No. Most MCP servers wrap an API. An API is built for developers who write code against fixed endpoints. An MCP server describes its tools in a form an AI model can read and choose from at runtime.
What is the difference between an MCP host, client, and server? The host is the AI application (Claude Code, Cursor). The client is a connector inside the host that keeps one connection to one server. The server is the program that provides tools, resources, and prompts.
Do I need to run an MCP server locally? Not always. Local servers run as a child process over stdio. Remote servers run as a web service and clients connect over Streamable HTTP, which is how most hosted vendor servers work.
Is MCP safe to use? It depends on the server. An MCP server has whatever access you give it, so restrict paths, prefer read-only credentials, and audit community servers before installing them.
How do I build my own MCP server? Use an official SDK. The TypeScript walkthrough is in how to build an MCP server in TypeScript.