What Is MCP? The Model Context Protocol Explained Simply

An AI model on its own can only talk. It can't read your database, open a GitHub issue or check today's orders unless someone connects it to those systems.

For a long time, every AI app did that connecting in its own way. Each one had its own plugin system and its own integration code.

MCP (Model Context Protocol) fixes this. It's an open standard that gives AI apps one common way to connect to tools and data.

The simplest way to think about it:

MCP is the USB-C port for AI. Build a connector once, and any AI app that supports MCP can plug into it.

---

What Is MCP?

MCP is an open protocol that defines how an AI application talks to external systems: files, databases, APIs, SaaS products and internal services.

Anthropic released it as an open standard in November 2024. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a new foundation under the Linux Foundation co-founded with Block and OpenAI. That made MCP vendor-neutral. Today it is supported across tools from Anthropic, OpenAI, Google, Microsoft and many others.

In simple words:

MCP is a shared language that AI apps and tools both speak, so they can work together without custom glue code.

---

The Problem MCP Solves

Imagine you have 5 AI apps (a chat assistant, an IDE, a support bot and so on) and 10 tools (GitHub, Slack, Postgres, Google Drive and others).

Without a standard, each app needs its own integration for each tool:

• 5 apps × 10 tools = 50 separate integrations
• Every integration has its own auth, data format and bugs
• Every new tool means updating every app

With MCP, each tool is wrapped once as an MCP server, and each app supports MCP once as a host:

• 5 apps + 10 servers = 15 pieces of work
• Any MCP app can use any MCP server
• A new server works in every app straight away

This is the same idea that made the Language Server Protocol (LSP) successful in code editors. Language support is written once and works in VS Code, Neovim, JetBrains and more. MCP was inspired by LSP and applies the same pattern to AI.

---

How MCP Works: Hosts, Clients and Servers

MCP has three roles.

Role	What it is	Example
Host	The AI application the user interacts with	Claude Desktop, VS Code, Cursor, ChatGPT
Client	A connector inside the host, one per server	The host's link to the GitHub server
Server	A program that exposes tools and data to the AI	A GitHub, Postgres or Slack MCP server

A typical flow looks like this:

1. You ask the AI: "Which of my open GitHub issues are labelled bug?"
2. The host already knows, from its MCP servers, which tools are available.
3. The model decides it needs the list_issues tool from the GitHub server.
4. The host asks for your permission, then the client sends the request to the server.
5. The server calls the GitHub API and returns the result.
6. The model reads the result and gives you an answer.

The model never talks to GitHub directly. It only asks the host to use a tool, and the host stays in control.

---

The Building Blocks: Tools, Resources and Prompts

An MCP server can offer three kinds of things.

1. Tools

Tools are actions the AI can perform. Each tool has a name, a description and a JSON Schema for its inputs.

Examples:

• create_issue on GitHub
• run_query on a database
• send_message on Slack

Tools are model-controlled: the AI decides when to call them, usually with the user's approval.

2. Resources

Resources are data the AI can read. They are identified by URIs, like a file path or a database record.

Examples:

• A project's README.md
• A database table schema
• A customer record

Resources are app-controlled: the host decides which ones to load into the model's context, so the model gets information without having to run an action.

3. Prompts

Prompts are reusable templates that a server offers to users.

Examples:

• "Review this pull request"
• "Summarize this support ticket"

Prompts are user-controlled: the user picks them, often from a slash command or menu.

Clients can also offer a feature back to servers. The main one is elicitation, which lets a server ask the user for missing details (for example, "Which repository do you mean?") in the middle of a request.

---

What a Message Looks Like

Under the hood, MCP uses JSON-RPC 2.0, a simple request/response format in JSON.

Here is a simplified tool call from a client:

saveCopyzoom_out_map
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Ahmedabad" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

And the server's response:

saveCopyzoom_out_map
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [{ "type": "text", "text": "32°C, clear sky" }]
  }
}

Every request carries its own protocol version and capabilities in _meta. That's a big change in the latest spec, covered next.

---

Transports: Local and Remote

MCP messages can travel in two standard ways:

• stdio: the host starts the server as a local process and talks to it through standard input and output. This is a good fit for local tools like file systems, Git or a local database.
• Streamable HTTP: the server runs remotely and the client talks to it over HTTP. This is a good fit for SaaS integrations and shared company servers. Remote servers use OAuth-based authorization.

The older HTTP + SSE transport is deprecated, so new servers should use Streamable HTTP.

---

What Changed in the 2026 Spec

The 2026-07-28 specification is the biggest MCP update since launch. If you read an older MCP tutorial, these are the main differences:

• Stateless by design: the old initialize handshake and the Mcp-Session-Id header are gone. Each request is self-contained, so MCP servers can scale behind load balancers like any normal web API.
• Multi round-trip requests (MRTR): when a server needs more input from the user, it returns resultType: "input_required" and the client retries with the answers. No long-lived open stream is needed.
• Cacheable lists: tools/list, resources/list and similar responses can include cache hints, so clients don't re-fetch them every time.
• Header-based routing: HTTP requests include Mcp-Method and Mcp-Name headers, so gateways can route and rate-limit without parsing JSON.
• Formal extensions: optional features such as Tasks (long-running jobs) and MCP Apps (interactive UI like charts and forms inside the chat) are now opt-in extensions.
• Deprecations with a safety window: Sampling, Roots and Logging are deprecated, and every deprecation now has at least a 12-month notice period.
• Stronger auth: several OAuth hardening changes, plus Client ID Metadata Documents as the preferred way to register clients.

---

Build Your First MCP Server

Here is a minimal MCP server using the official TypeScript SDK (v2, which targets the 2026 spec). It exposes one tool that greets a user.

Install the packages:

saveCopyzoom_out_map
npm install @modelcontextprotocol/server zod

Create server.js:

saveCopyzoom_out_map
import { McpServer } from '@modelcontextprotocol/server';
import { StdioServerTransport } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

const server = new McpServer({ name: 'greeting-server', version: '1.0.0' });

server.registerTool(
    'greet',
    {
        description: 'Greet someone by name',
        inputSchema: z.object({ name: z.string() })
    },
    async ({ name }) => ({
        content: [{ type: 'text', text: `Hello, ${name}!` }]
    })
);

const transport = new StdioServerTransport();
await server.connect(transport);

Add this server to any MCP host (Claude Desktop, VS Code, Cursor and others each have an MCP config file), and the AI can now call greet.

Official SDKs are also available for Python, Go and C#, with Rust support in beta.

Tip: write clear tool descriptions. The model reads them to decide when to use a tool, so a vague description means the tool gets used at the wrong time, or not at all.

---

Real-World Use Cases

• Coding assistants: IDEs use MCP servers for GitHub, Jira, Sentry and databases, so the AI can read an issue, check the error logs and suggest a fix in one place.
• Company knowledge: an assistant can search Google Drive, Confluence or Notion through MCP servers, with each user's own permissions.
• eCommerce operations: a store team could expose order lookup, inventory and catalog data (for example from a Magento backend) as MCP tools, so support staff can ask "Where is order #10045?" in plain language.
• Data analysis: connect a database server and ask questions in plain English, with the AI writing and running the queries.
• Agent workflows: AI agents use MCP as their toolbox, chaining several tools to finish a multi-step task.

---

MCP vs APIs vs A2A

MCP vs a normal API

MCP doesn't replace APIs. Most MCP servers call existing APIs. The difference is that MCP adds a standard layer that AI can discover and understand: what tools exist, what inputs they take and what they return.

MCP vs A2A

These two solve different problems and work well together:

• MCP connects an agent to tools and data (agent ↔ tool).
• A2A (Agent2Agent) lets agents talk to other agents (agent ↔ agent).

MCP and context engineering

MCP is also a key part of context engineering. It's the standard way to get the right data and tools into a model's context at the right time.

---

Security: What You Must Know

MCP is powerful because it lets AI read data and take actions. That's also why security matters.

The main risks:

• Prompt injection: a web page, email or document the AI reads can contain hidden instructions that try to make it misuse a tool.
• Malicious or compromised servers: a server can lie in its tool descriptions or steal data. Only install servers from sources you trust.
• Too much access: a server with full admin rights can do full admin damage.

Best practices:

• Require user approval before tools run, especially tools that write, delete or send data.
• Give each server the least privilege it needs, such as read-only database users and scoped tokens.
• Use OAuth for remote servers, and never hardcode secrets in server code.
• Review and pin the versions of third-party servers, just like any other dependency.
• Log tool calls so you can audit what the AI actually did.

The MCP spec itself is clear on this: users must consent to data access and tool use, and tool descriptions should be treated as untrusted unless they come from a trusted server.

---

Final Thoughts

MCP turned "connecting AI to the real world" from a custom project into a standard.

Build an MCP server once, and every MCP-compatible AI app can use it. With open governance under the Linux Foundation and a stateless 2026 spec built for scale, MCP has become the default way AI agents reach tools and data.

If you build AI features, or want your product to be usable by AI agents, learning MCP is one of the most useful skills you can pick up right now. It's also one of the key skills for building AI agents.

Bookmark it for your future reference. Do comment below if you have any other questions.

P.S. Do share this note with your team.