You have probably seen the letters MCP popping up everywhere AI agents are discussed: in Cursor’s settings, in Claude’s integrations, in startup pitch decks. Most explanations either drown you in JSON-RPC jargon or wave it away as “USB-C for AI” and move on. This is the middle ground: what MCP actually is, why it exists, how it works, where it fits, and what it means for you as a developer or a business in India.
What MCP actually is
MCP (Model Context Protocol) is an open standard that defines how AI applications connect to external data sources and tools. That is the whole idea. A chatbot on its own can only do two things: read your message and generate text. To do anything useful, it needs to reach outside itself: read your files, query a database, call an API, search the web.
Before MCP, every one of those connections was a custom-built integration. After MCP, any AI application that speaks the protocol can connect to any tool that speaks the protocol. One shared language instead of a tangle of one-off plugins.
The protocol was created by Anthropic and open-sourced on November 25, 2024. In December 2025, Anthropic donated it to the newly formed Agentic AI Foundation under the Linux Foundation, alongside contributions from OpenAI and Block, making it a vendor-neutral standard rather than one company’s project. That handoff matters: it is why ChatGPT, Gemini, and Copilot can all support the same protocol.
The problem it solves: the M×N integration mess
Imagine you are building three AI apps, and each one needs to reach ten tools: a database, a CRM, a calendar, a file system, and so on. Without a standard, you write a custom connector for every pairing. That is 3 × 10 = 30 integrations, each with its own authentication, data format, and error handling. Add a fourth app and you write ten more.
This is the M×N integration problem, and it is the reason MCP exists. With a shared protocol:
- Each AI app implements one MCP client.
- Each tool implements one MCP server.
- 3 apps + 10 tools = 13 components instead of 30 integrations.
| Without MCP | With MCP |
|---|---|
| Every AI app needs a custom connector for every tool | Every AI app speaks one protocol; every tool speaks one protocol |
| M apps × N tools = M×N integrations | M apps + N tools components |
| Updating one tool can break many integrations | Standard interface; updates do not cascade |
| Each integration has its own auth approach | Shared auth model (the protocol supports OAuth for remote servers) |
This is exactly the USB-C analogy. Before USB-C, every device needed its own cable. After it, manufacturers build one port and cable-makers build one connector, and everything interoperates.
How MCP works: hosts, clients, and servers
MCP has three roles. Getting them straight clears up most confusion:
- MCP host — the AI application you interact with. Claude Desktop, Cursor, VS Code, ChatGPT: these are hosts.
- MCP client — lives inside the host. It keeps a one-to-one connection with a server and negotiates what the server can do. A host can run many clients, one per server.
- MCP server — the thing that exposes capabilities. It wraps a data source or tool (your Postgres database, your GitHub account, a weather API) and offers them to clients in the standard format.
The conversation between client and server runs on JSON-RPC 2.0, a simple, widely used message format. How the messages travel depends on where the server lives:
- stdio (standard input/output): for servers running locally on your machine, like a filesystem server reading your project folder.
- HTTP-based transports: for remote servers, such as a company’s hosted MCP server you connect to over the internet.
A typical flow: you ask Claude Desktop a question about your code. Its MCP client asks the filesystem server what it offers. The server says “I can read files and list directories.” The model decides which tool fits, calls it, gets the result back, and answers you with real context instead of guessing.
The three building blocks: tools, resources, and prompts
An MCP server can expose three kinds of capabilities:
- Tools — actions the AI can perform. Query a database, send an email, create a calendar event, run a search. Tools are what turn a chatbot into something that does things.
- Resources — data the AI can read. Files, documents, database records, API responses. Think of these as read-only context the model can pull in.
- Prompts — reusable templates for common tasks. A server can offer a “summarize this week’s tickets” prompt so users get a consistent workflow instead of writing it from scratch each time.
The distinction that matters: tools act, resources inform, prompts structure. When people say “MCP gives AI agents hands,” they mean tools.
MCP vs API vs function calling
This is the comparison most people get wrong, because all three involve “calling things.” Here is the clean version:
| API | Function calling | MCP | |
|---|---|---|---|
| Designed for | Software talking to software | One app giving one model specific functions | Any AI app discovering and using any tool |
| Who decides what to call | The developer, in code, ahead of time | The developer defines functions; the model picks among them | The model discovers the server’s capabilities at runtime |
| Scope | One backend system | One application | Whole ecosystem of apps and tools |
| Analogy | A phone number you dial directly | A speed-dial list programmed into one phone | A universal plug that works in any socket |
And the honest caveat, because MCP’s own documentation is clear about this: MCP does not replace function calling. When an MCP tool runs, it still executes in your application code. MCP standardizes the discovery and description of tools; your code still does the work. If you are one developer connecting one model to one application, raw function calling has fewer moving parts and you should stay there. MCP earns its place at ecosystem scale.
Where MCP fits: agents, A2A, and the bigger picture
MCP is one layer in the emerging agent stack, and it helps to see the neighbors:
- AI agents (like the ones you can build with n8n, which we covered in our beginner’s AI agent tutorial) are the workers: they plan, act, and observe in loops. MCP is how they reach tools without custom code for each one.
- A2A (Agent-to-Agent), a Google-originated protocol also hosted under the Linux Foundation, standardizes how agents talk to each other. The mental model, as IBM puts it: MCP is how an agent talks to tools; A2A is how agents talk to each other.
- Function calling remains the mechanism inside a single app.
A short history, so the timeline is clear:
- November 25, 2024 — Anthropic open-sources MCP, with SDKs and local server support in Claude Desktop apps.
- 2025 — Rapid iteration: OAuth-based auth for remote servers, streamable HTTP transport, and a community registry. Adoption spreads to OpenAI, Google DeepMind, and Microsoft products.
- December 2025 — Donated to the Agentic AI Foundation under the Linux Foundation. Vendor-neutral from here on.
- 2026 — Spec revisions continue (the July 2026 revision made the protocol core stateless, which helps it scale like ordinary web services). One academic study of the ecosystem reported Anthropic’s claim of 97M+ monthly SDK downloads within the first year, which gives a sense of scale even if you treat aggregator figures as directional.
What this means for Indian developers and startups
Strip away the hype and MCP changes two practical calculations:
For developers: if you build internal tools, the question is no longer “which AI app do we integrate with?” Build one MCP server for your database or API, and it works with Claude, ChatGPT, Gemini, Copilot, Cursor, and VS Code. That is genuinely new. The flip side: check what is already in the community server directory before building. Thousands of servers exist for common tools (GitHub, Postgres, Google Drive, Slack), and a weekend build may already exist as a maintained project.
For startups and businesses: MCP lowers the cost of making your product “AI-ready.” Instead of building bespoke integrations for each AI platform your customers use, one MCP server covers all of them. It also reduces lock-in: because the protocol is vendor-neutral, switching the model behind your agent does not mean rebuilding every integration. For Indian SaaS startups selling to global customers, that portability is a real selling point.
For everyone else: you do not need to understand MCP to benefit from it. But when a tool advertises “MCP support,” it means it can plug into whichever AI assistant you already use, rather than locking you into its own chatbot.
The security side: trust your servers
MCP is a protocol, not a safety guarantee, and this part deserves plain language.
The subtle risk: the AI reads a server’s tool descriptions as part of its context. So a malicious or compromised MCP server could hide instructions inside those descriptions, instructions the model might follow. Security researchers call this tool poisoning, and it is the MCP-specific flavor of prompt injection.
Practical checklist, whether you are a developer or just connecting servers in Cursor or Claude Desktop:
- Only connect servers from sources you trust. Treat an MCP server like installing software, because that is what it is.
- Check what access each server gets. A filesystem server that can read your whole home directory is different from one scoped to a single project folder. Narrow is better.
- Be extra careful with remote servers. They talk over the network and use OAuth; verify the provider before authorizing.
- Review tool descriptions when you can. If a “weather” tool’s description contains paragraphs of instructions unrelated to weather, that is a red flag.
- For businesses: MCP servers that touch customer data belong behind the same access controls and audits as any other production integration. The protocol standardizes the connection; your governance still has to cover what flows through it.
How to try MCP in about 15 minutes
You do not need to write code to see MCP working:
- Claude Desktop (free) supports MCP servers natively: add a community server such as the filesystem or web-search server through its settings, then ask Claude something that requires the tool, like “summarize the README files in my project folder.”
- Cursor or VS Code both have MCP settings panels where you can paste a server configuration and watch the agent call tools as it works.
- When you are ready to build, the official documentation at modelcontextprotocol.io has SDKs for TypeScript, Python, Java, Go, C#, Rust, and more, plus a quickstart for your first server.
The Wikipedia overview is a solid neutral reference for the history and adoption facts in this article.
The bottom line
MCP is plumbing, and plumbing is boring until you notice what it enables. Before it, every AI-to-tool connection was bespoke, which meant agents stayed demos or stayed locked inside one vendor’s garden. A shared, vendor-neutral protocol means an agent built for one assistant can reach the same tools from another, and a tool built once works everywhere.
It will not make a bad agent good, it does not replace the judgment of which tools an agent should have, and it has real security sharp edges. But as the layer that lets AI applications touch the real world in a standard way, it is the least-hyped important thing in the agent stack right now. That is worth understanding before everyone assumes you already do.
Sources
- Model Context Protocol — Wikipedia (launch date, donation to the Linux Foundation, adoption)
- Anthropic’s new standard raises AI privacy, other concerns — TechTarget, Nov 27 2024 (original announcement details)
- Linux Foundation announces the formation of the Agentic AI Foundation (December 2025 handoff)
- Official MCP documentation — modelcontextprotocol.io (protocol mechanics: JSON-RPC 2.0, hosts/clients/servers, tools/resources/prompts, transports)
- Model Context Protocol — eWeek explainer (architecture, OAuth, spec history)
- A Two-Dimensional Study of the Model Context Protocol — arXiv (ecosystem scale figures, cited with attribution)
AI-assistance disclosure: this article was drafted with AI assistance. All facts, dates, and technical claims were verified against the primary and authoritative sources listed above before publication.
