Educational guide · covers the 2026-07-28 release candidate

MCP Explained: The Easy Guide to Model Context Protocol

Understand how AI assistants connect to tools, data, and APIs — and what changes in the new 2026-07-28 MCP standard.

In one sentence

MCP is a standard way for AI applications to talk to external tools, APIs, files, databases, and services. Think of it like USB-C: instead of every device needing its own special cable, one standard plug works everywhere. MCP is that plug — any AI app that speaks MCP can connect to any tool that speaks MCP.

01 · The problem

Why MCP exists

Before MCP, every AI application needed a custom integration for every tool it wanted to use. Ten apps × ten tools meant up to a hundred one-off integrations. MCP replaces that with one standard interface: a tool exposes itself once, and any MCP-capable client can use it.

Without MCP N × M integrations
AI App Acustom →Tool 1
AI App Bcustom →Tool 1
AI App Ccustom →Tool 2

Every connection is bespoke code: separate auth, separate formats, separate maintenance.

With MCP One standard
AI Apps MCP Client MCP Server Tools · APIs · Data

A tool exposes one MCP interface. Every MCP-capable app can use it — no custom glue code per pairing.

02 · The vocabulary

Core MCP building blocks

Three architecture roles (indigo) carry the conversation, and three capability types (teal) are what servers offer.

HMCP Host

The AI application the user actually interacts with — an AI chat app, an IDE, or an agent product.

Analogy  The laptop you plug things into.
Example  A desktop AI assistant or a code editor with an AI panel.
CMCP Client

The component inside the host that speaks the MCP protocol. A host runs one client per server it connects to.

Analogy  The USB-C port and its driver.
Example  The piece of the chat app that sends tools/call messages.
SMCP Server

The service that exposes tools, resources, and prompts. It can wrap a database, an API, a filesystem — anything.

Analogy  The device on the other end of the cable.
Example  A small service exposing “search the docs” to any AI app.
TTools

Actions the AI can call: “search files”, “create ticket”, “query database”. Each tool has a name, description, and input schema.

Analogy  Buttons the AI is allowed to press.
Example  create_ticket(title, priority)
RResources

Readable context and data: files, documents, records, or API-backed content the AI can read but not change.

Analogy  A bookshelf the AI can read from.
Example  file:///reports/q2.md
PPrompts

Reusable prompt templates the server exposes, so common workflows are one click away in the host UI.

Analogy  Saved recipes anyone can reuse.
Example  A “summarize this ticket” template with a ticket-ID argument.
03 · The wire format

What methods does MCP use?

MCP messages are JSON-RPC style: a method name, params, and a matching result. Methods come in groups — discovery, tools, resources, prompts — plus notifications for events like “the tool list changed”.

tools/list

Purpose: ask the server which tools exist. Called by: the client. Returns: tool names, descriptions, and input schemas.

tools/call

Purpose: execute one tool with arguments. Called by: the client (when the model decides to act). Returns: content blocks plus an isError flag.

Request — tools/call
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_files",
    "arguments": { "query": "quarterly report" }
  }
}
Response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "Found 3 matching files: …" }
    ],
    "isError": false
  }
}
resources/list

Purpose: discover readable data. Called by: the client. Returns: a list of resources with URIs, names, and MIME types.

resources/read

Purpose: read one resource by URI. Called by: the client. Returns: the content (text or binary) with its MIME type.

Request — resources/read
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "resources/read",
  "params": {
    "uri": "file:///reports/q2-summary.md"
  }
}
Response
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "contents": [
      {
        "uri": "file:///reports/q2-summary.md",
        "mimeType": "text/markdown",
        "text": "# Q2 Summary\n…"
      }
    ]
  }
}
prompts/list

Purpose: discover available prompt templates. Called by: the client. Returns: template names, descriptions, and accepted arguments.

prompts/get

Purpose: fetch one template, filled in with arguments. Called by: the client. Returns: ready-to-use chat messages.

Request — prompts/get
{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "prompts/get",
  "params": {
    "name": "summarize_ticket",
    "arguments": { "ticketId": "T-1042" }
  }
}
Response
{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Summarize ticket T-1042 for a customer update."
        }
      }
    ]
  }
}
server/discover New in 2026-07-28

Purpose: learn the server’s identity, capabilities, and instructions — replacing the old initialize handshake. Called by: the client, any time. Returns: server info and capabilities, with cache metadata so clients and gateways don’t have to re-ask constantly.

Notifications

Servers can emit events such as notifications/tools/list_changed so clients know to refresh their cached lists.

Request — server/discover
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      }
    }
  }
}
Response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "serverInfo": { "name": "docs-server", "version": "2.1.0" },
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "listChanged": false },
      "prompts": { "listChanged": false }
    },
    "_meta": {
      "io.modelcontextprotocol/cache": {
        "ttlMs": 300000,
        "cacheScope": "server"
      }
    }
  }
}
04 · Moving messages

Transport mechanisms

MCP defines the message format — but messages still need a way to travel between client and server. That carrier is the transport.

stdioLocal

The server runs locally as a child process and talks over standard input/output. Great for developer tools, desktop apps, and IDEs. Simple and private by default — but not suitable for public internet APIs.

Streamable HTTPRemote

The server is remote or web-hosted. Requests go over HTTP POST, and responses can stream. The right choice for hosted services, gateways, cloud deployments, and enterprise systems. Earlier versions layered sessions on top; the 2026-07-28 direction makes it stateless.

SSE (older)Legacy

Earlier MCP setups used HTTP + Server-Sent Events with a separate endpoint per direction. Streamable HTTP became the primary HTTP transport direction; SSE-style setups remain mostly for backwards compatibility.

TransportBest forRuns whereStrengthsLimitations
stdioLocal dev tools, IDEs, desktop appsSame machine, child processSimple, fast, no network exposureNot usable over the internet
Streamable HTTPHosted services, gateways, enterpriseRemote server or cloudScales, streams, plays well with infraNeeds auth and hardening
SSE / older HTTPBackwards compatibilityRemote serverWorked before Streamable HTTPSuperseded; more moving parts
05 · The big change

Old MCP vs new MCP 2026-07-28

The 2026-07-28 release candidate introduces a stateless-first protocol core and several production-oriented changes. This is the most important shift since MCP launched — it changes how clients connect, how requests are routed, and where session state lives.

Details below reflect the release candidate and may change before final release. Support will vary by SDK, client, and server.

Old Earlier MCP style
initialize + notifications/initialized handshake before any work
Server-issued Mcp-Session-Id carried on every request
Session-oriented HTTP behavior — requests effectively pinned to the instance holding the session
Gateways often had to parse the JSON body just to route or rate-limit a request
Long-running work was mixed into the normal request/response flow
Roots, Sampling, and Logging lived in the protocol core
New MCP 2026-07-28 (RC)
Stateless protocol core — no protocol-level session ID, no handshake Breaking change
Every request carries protocol version, client info, and client capabilities in _meta
New required server/discover method New
Mcp-Method and Mcp-Name headers for routing and rate limiting Gateway friendly
List/read responses can carry cache metadata: ttlMs, cacheScope Gateway friendly
Tasks become an official extension: io.modelcontextprotocol/tasks New
MCP Apps: servers can provide UI templates rendered by compatible hosts New
Hardened authorization / OAuth behavior Production ready
Roots, Sampling, and Logging deprecated, with suggested replacements Breaking change
See the difference on the wire
Old style — handshake + session ID
// 1. Client must open a session first
POST /mcp
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "clientInfo": { "name": "example-client", "version": "1.0.0" },
    "capabilities": { }
  }
}

// 2. Server responds and assigns a session
HTTP/1.1 200 OK
Mcp-Session-Id: 8f3c-a1d2-77b9

// 3. Client confirms, then must echo the session ID forever after
POST /mcp
Mcp-Session-Id: 8f3c-a1d2-77b9
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_files",
    "arguments": { "query": "roadmap" }
  }
}
New style — one self-contained request
// No handshake. No session. Headers tell gateways everything.
POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_files

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_files",
    "arguments": { "query": "roadmap" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": { }
      }
    }
  }
}
RootsDeprecated

Filesystem-boundary hints move out of the core; clients pass relevant context with requests instead.

SamplingDeprecated

Server-initiated model calls leave the core; the spec points to replacement patterns outside the stateless flow.

LoggingDeprecated

Protocol-level logging is deprecated in favor of standard observability on the server and gateway side.

06 · Operations

Why stateless MCP matters

When every request is self-contained, the server doesn’t need to remember who you are between requests. That one property simplifies almost everything about running MCP in production.

Any instance can answer

No session pinning — any request can go to any server instance.

Simpler load balancing

Load balancers stop tracking sticky sessions and just distribute traffic.

Easier routing

Gateways route on headers like Mcp-Method without opening the body.

Easier scaling

Add or remove instances freely — there is no session state to migrate.

Fewer operational failures

No expired or lost sessions; a restarted server doesn’t break clients.

Per-request policies

Auth, rate limits, and allow/deny rules can be applied to each request on its own.

Client Load Balancer
MCP Server · instance 1 MCP Server · instance 2 MCP Server · instance 3

Any request → any instance. Nothing to remember in between.

07 · Architecture

The MCP gateway view

In larger deployments, a gateway sits between AI clients and many MCP servers. The stateless core and routing headers in 2026-07-28 are designed to make this layer practical.

Central authentication

One place to verify identity before anything reaches a server.

Rate limiting

Throttle per client, per method, or per tool using the new headers.

Tool allow/deny lists

Block dangerous tools centrally via Mcp-Name — no body parsing.

Routing

Fan requests out to many MCP servers behind one endpoint.

Observability

Metrics, traces, and logs for every tool call passing through.

Caching

Cache tool and resource lists using ttlMs / cacheScope.

Auditing

Record who called which sensitive tool, when, and with what result.

AI Client MCP Gateway
MCP Server A MCP Server B MCP Server C
08 · Safety

Security and authorization

MCP can expose powerful actions — deleting files, writing to databases, sending messages. Remote servers should use strong authentication; OAuth/OIDC enables delegated access with explicit scopes; and the 2026-07-28 spec hardens authorization behavior. Sensitive tools may require stricter scopes or step-up approval.

Never expose dangerous tools without authentication, input validation, logging, and user consent.

!MCP servers can be powerful

Tools can read data and take real actions. Treat every exposed tool as production attack surface with clear permissions.

!Don’t expose dev servers to the internet

Local and stdio-based servers assume a trusted machine. Putting one behind a public URL without auth is an open door.

!Validate inputs and outputs

Treat tool arguments as untrusted input — and treat tool results as untrusted before they flow back into the model’s context.

!Use least privilege

Narrow OAuth scopes, read-only credentials where possible, and step-up approval for destructive operations.

09 · In practice

Practical examples

Pick a use case to see what an MCP server for it might expose — and what to watch out for.

File search MCP
Tools
search_files · read_file · list_directory
Resources
File contents and directory trees inside allowed folders.
Security concerns
Path traversal, symlink escapes, scoping to an allowlist of folders. Never expose the whole disk.
Example tools/list response
{
  "result": {
    "tools": [
      {
        "name": "search_files",
        "description": "Search names and contents in allowed folders",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string" }
          },
          "required": ["query"]
        }
      },
      {
        "name": "read_file",
        "description": "Read one file by path",
        "inputSchema": {
          "type": "object",
          "properties": {
            "path": { "type": "string" }
          },
          "required": ["path"]
        }
      }
    ]
  }
}
Database query MCP
Tools
run_query · list_tables · describe_table
Resources
Table schemas and saved, pre-approved views.
Security concerns
SQL injection, runaway queries, PII exposure. Use read-only credentials, row limits, and query timeouts.
Example tools/list response
{
  "result": {
    "tools": [
      {
        "name": "run_query",
        "description": "Run a read-only SQL query (SELECT only)",
        "inputSchema": {
          "type": "object",
          "properties": {
            "sql": { "type": "string" },
            "limit": { "type": "number" }
          },
          "required": ["sql"]
        }
      }
    ]
  }
}
Code & project tracker MCP
Tools
create_issue · search_issues · get_pull_request
Resources
Issue threads, PR diffs, repository file contents.
Security concerns
Token scope creep, accidental writes to protected branches. Audit all writes; require confirmation for destructive ops.
Example tools/list response
{
  "result": {
    "tools": [
      {
        "name": "create_issue",
        "description": "Create an issue in a project",
        "inputSchema": {
          "type": "object",
          "properties": {
            "title": { "type": "string" },
            "body": { "type": "string" },
            "labels": {
              "type": "array",
              "items": { "type": "string" }
            }
          },
          "required": ["title"]
        }
      }
    ]
  }
}
Customer support MCP
Tools
search_tickets · create_ticket · add_note
Resources
Ticket threads and help-center articles.
Security concerns
Customer PII in ticket bodies. Redact sensitive fields, respect per-agent permissions, log every access.
Example tools/list response
{
  "result": {
    "tools": [
      {
        "name": "search_tickets",
        "description": "Search support tickets by text and status",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string" },
            "status": {
              "type": "string",
              "enum": ["open", "pending", "solved"]
            }
          },
          "required": ["query"]
        }
      }
    ]
  }
}
Hosting / cloud MCP
Tools
list_services · get_logs · restart_service
Resources
Service status, configuration summaries, recent log excerpts.
Security concerns
Mutating infrastructure is high-stakes: require step-up approval for restarts/deploys, least-privilege API keys, full audit logs.
Example tools/list response
{
  "result": {
    "tools": [
      {
        "name": "restart_service",
        "description": "Restart a service (requires approval)",
        "inputSchema": {
          "type": "object",
          "properties": {
            "serviceId": { "type": "string" },
            "reason": { "type": "string" }
          },
          "required": ["serviceId", "reason"]
        }
      }
    ]
  }
}
10 · Reference

Quick glossary

20 terms shown
No terms match that search.
11 · Getting ready

Migration checklist: older MCP → 2026-07-28

If you maintain an MCP client, server, or gateway, this is the rough order of operations. Tick items off as you plan.

0 of 10 done