What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools, data and services. An MCP server exposes capabilities such as tools, resources and prompts in a standard way, and any MCP-compatible application, such as Claude, ChatGPT, Cursor or VS Code, can connect to it without custom integration code.
MCP turns an M-by-N integration problem into M plus N. Without a standard, every AI application needs its own connector for every tool. With MCP, each tool is wrapped once as a server and each application implements the protocol once.
Why was MCP created?
Anthropic introduced MCP as an open specification in November 2024 to solve a practical problem: every AI assistant was wiring up integrations with files, databases, GitHub, Slack and internal systems in its own way. The same integration had to be rebuilt for each assistant, and each assistant's tools could not be reused elsewhere. MCP is often compared to USB-C for AI applications: one standard connector instead of a drawer of adapters.
Adoption was fast. OpenAI, Google, Microsoft and many developer tools added MCP support during 2025. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI, to keep the protocol vendor-neutral. The project reported at that time more than 10,000 active servers and over 97 million monthly SDK downloads.
How does MCP work?
MCP has three roles and uses JSON-RPC 2.0 messages between them.
| Role | What it is | Example |
|---|---|---|
| Host | The AI application the user interacts with | Claude Desktop, ChatGPT, an IDE such as VS Code or Cursor |
| Client | A connector inside the host that keeps one connection to one server | The host runs one client per connected server |
| Server | A program that exposes capabilities through MCP | A GitHub server, a Postgres server, your company's internal API |
When a host starts, its clients connect to the configured servers and ask what each one offers. The host passes those capabilities to its model. When the model decides to use one, for example by making a tool call, the client sends the request to the right server and returns the result.
Servers run either locally, as a subprocess talking over standard input and output (stdio), or remotely over HTTP using the Streamable HTTP transport, with OAuth-based authorisation defined for remote servers.
What can an MCP server provide?
- Tools
- Functions the model can call to take actions or fetch data, such as create_issue or run_query; the model decides when to use them
- Resources
- Data the application can read and give the model as context, such as a file, a database schema or a document, identified by URI
- Prompts
- Reusable prompt templates a user can pick, such as "review this pull request"
Clients can offer features to servers too. Sampling lets a server ask the host's model to generate text, roots tell a server which folders or locations it may work in, and elicitation lets a server ask the user for more information during a task.
How is MCP different from a normal API?
A normal API is built for programmers who read its documentation and write code against it. MCP is built so an AI application can discover a service's capabilities at runtime, with descriptions written for a model, and use them without anyone writing integration code for that pair. An MCP server often wraps an existing API. The free MCP guide's chapter "MCP, RAG, and Plain APIs" compares these in depth.
| Question | Plain API | MCP |
|---|---|---|
| Who integrates it? | A developer, for each application | Any MCP host, automatically |
| How are capabilities found? | Documentation | Discovered at connection time |
| Who decides when to call it? | The application's code | The model, from tool descriptions |
| Reusable across AI apps? | Only with new code for each | Yes |
What are the risks of using MCP?
Connecting a model to real systems gives it real power, so the risks are real. The main ones are prompt injection through data a tool returns, servers from untrusted sources that request broad permissions or change behaviour after installation, and tools that perform destructive actions without confirmation.
- Do: Install servers only from sources you trust, and review what tools they expose
- Do: Give each server the narrowest credentials and permissions it needs
- Do: Require user approval for write and destructive actions
- Avoid: Connect a server with access to private data and a server that can send data outward without thinking about how they combine
- Avoid: Assume the protocol makes a server safe; MCP standardises the connection, not the server's behaviour
Frequently asked questions
Who created MCP?
Anthropic created the Model Context Protocol and released it as an open standard in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation.
Is MCP only for Claude?
No. MCP is an open protocol supported by many AI applications and model providers, including ChatGPT, Gemini, Microsoft Copilot, Cursor and VS Code, alongside Claude.
What is the difference between MCP and function calling?
Function calling is a model's ability to request a tool run. MCP is a standard way to package tools, resources and prompts in servers so any compatible application can discover and use them. MCP tools reach the model through function calling.
Is MCP the same as RAG?
No. RAG retrieves documents to add to the model's context. MCP is a general connection protocol; an MCP server can provide retrieval as a tool or resource, but it can also take actions, run queries and more.
Do I need MCP to build an AI agent?
No. You can define tools directly in your application's code. MCP becomes valuable when you want tools to be reusable across applications or want to use the large ecosystem of existing servers.
Last checked for accuracy on . Written by the solidcoder team.