Key takeaways

2026-07-28 is an infrastructure release, not cosmetics. initialize / initialized and session IDs are gone. Each request is self-describing: protocol version, client identity, and capabilities travel in _meta. Any request can land on any replica behind plain round-robin.

State did not vanish — it became visible to the model. If you need continuity across calls, mint a handle (job id, draft id, snapshot) and require the agent to pass it as an argument. Hidden transport session bags are worse: the model cannot deliberately thread them between tools.

Security is the real scaling ceiling. Shadow MCP — servers installed in IDEs without IT visibility — is often several times larger than security expects. A write tool with prod access is more dangerous than “just chat”. Sandboxes and server allowlists belong next to MCP, not after the first incident.

Tool design beats raw API coverage. Eight task-shaped tools with clear modes usually beat eighty near-duplicate wrappers. That pattern already shows up in practical MCP-over-API write-ups.

Auth and observability are product features. RFC 9207 (iss validation), the shift from DCR toward Client ID Metadata Documents, and Mcp-Method / Mcp-Name headers for gateways are what separate a demo from a platform service.

What MCP is and why engineering teams care

MCP is an open protocol for how an LLM agent discovers and calls tools, reads resources, uses prompts, and — in newer flows — asks a human for mid-call input. Clients include Cursor, Claude Desktop, VS Code, and cloud agent runtimes. Servers are your wrappers over Git, tickets, databases, internal APIs, and CI.

Before MCP, every “model ↔ service” link was a one-off connector. Changing model vendors threw away the integration library. The protocol externalizes the contract: one server can serve many clients; one client can attach many servers.

Why this topic peaked now

By July 2026 the ecosystem is industrial: hundreds of millions of SDK downloads per month, thousands of public servers, and support across major platforms. On 28 July the 2026-07-28 spec shipped with a stateless protocol core — the biggest shift since remote MCP landed.

At the same time, teams discovered shadow installs: a developer adds an MCP server on Friday; security learns about it during an incident. That overlaps sandbox security for agentic code and the reminder that local models are not automatically private.

How MCP fits together: roles and surfaces

Client

The agent host: keeps the model conversation, connects servers, renders elicitations, and enforces which servers are allowed. The client decides which tools enter the model context.

Server

A process or HTTP endpoint that advertises capabilities and executes calls. In 2026, remote MCP over Streamable HTTP is normal for production; local stdio remains convenient for development and personal tools.

Tools, resources, prompts

Tools perform actions or computations (create a ticket, run a query, request a recrawl).
Resources are readable entities (a file, a schema, a report).
Prompts are templates the server offers to the client.

For agents, the catalog is critical: names, descriptions, argument schemas. Weak descriptions → wrong tool. Too many near-synonyms → confusion. A good server groups API calls around user tasks, not OpenAPI paths.

Spec 2026-07-28: what actually changes

The official announcement frames the core as request/response without pinning a session to one server instance.

No handshake and no Mcp-Session-Id

Previously clients and servers exchanged initialize / initialized, then lived inside a session. Now each request carries what it needs. Optional server/discover can learn capabilities up front — but it is not required before the first tools/call.

Deployment impact: run MCP behind a load balancer without sticky sessions and without a protocol-level shared session store.

Application state via handles

If a tool starts a long job or creates a draft, return an id. The next call accepts that id in arguments. The model sees the handle in history and can pass it on — unlike an invisible session bag on the server.

Multi Round-Trip Requests (MRTR)

Older server-initiated elicitation/sampling needed a held-open bidirectional stream. MRTR lets the server return input_required; the client gathers human (or subsystem) answers and retries the original call with inputResponses. Typical cases: confirm a delete, or choose a project before an expensive action.

Header-based routing

Streamable HTTP requests must include Mcp-Method and Mcp-Name. Gateways, WAFs, and rate limiters can meter by tool name without parsing JSON bodies. Ops-wise, that is the difference between an opaque POST /mcp and a normal HTTP service.

Cacheable lists

tools/list, prompts/list, resources/list, and some resources/read responses carry ttlMs and cacheScope. Clients refetch catalogs less often; stable ordering helps prompt caches stay warm across reconnects.

Authorization

Stronger iss checks (RFC 9207), credentials bound to the issuing authorization server, and a formal move away from Dynamic Client Registration toward Client ID Metadata Documents (CIMD). DCR still works for compatibility, but new builds should plan for CIMD.

Tasks and extensions

Long-running work moves into the Tasks extension (tasks/get, tasks/update) instead of immortal sessions. Roots, Sampling, and Logging are deprecated with at least a twelve-month window — do not found new products on them.

Writing an MCP server that survives production

Start from user questions, not OpenAPI

List 5–15 questions the agent must answer (“which URLs have indexing errors”, “draft a PR description”, “show slow queries”). Each question is a tool candidate or a mode of one tool. IDs that cannot be guessed from a URL deserve an explicit discover step.

Keep results compact and explainable

Models handle a curated 2 KB answer better than a raw 50 KB dump. Sort, drop stale rows, add summary counters, and spell out the next step on errors. Distinguish 401 (re-auth) from 403 (no rights on this object) or the agent will spin OAuth forever.

Make side effects obvious

Write tools should read like actions (submit_, delete_, create_), not neutral get_. Destructive operations should plan for MRTR/elicitation.

Versioning and compatibility

Evolve argument schemas carefully. Optional fields are safer than renames. Document supported MCP-Protocol-Version values; test clients on 2026-07-28 and the previous line until the IDE fleet upgrades.

Stack

The TypeScript SDK remains the default for web teams; Python, Go, and C# Tier 1 SDKs also speak the new spec. For serverless (Workers and peers), the stateless core removes the main operational blocker.

Migrating off the session model

A boring plan beats a heroic one:

1. Inventory every place that reads a session id or stores cross-call state in process memory.
2. For each piece of state, introduce an explicit handle (DB, Redis, object storage) plus a tool argument.
3. Upgrade the SDK to 2026-07-28; run tools/list and critical tools/call behind a balancer with two instances.
4. Re-test elicitations via MRTR if you used server-push flows.
5. Update the gateway for Mcp-Method / Mcp-Name rules.
6. Freeze deprecations: no Roots/Sampling/Logging in new features.

Mixed client/server versions in August–September 2026 are a likely incident source. Use canaries and, if policy allows, pin protocol versions in the corporate client image.

Security and governance: shadow MCP

Shadow MCP means servers developers attach locally (or in personal clouds) outside the company catalog. Industry readouts repeatedly show a large gap between what security thinks is installed and what IDEs actually load.

Team minimum:

• Allowlist servers in managed IDE / agent-gateway config.
• Ban arbitrary remote URLs without review.
• Secrets via vault / short-lived tokens — never permanent arguments.
• Call logs with redaction of sensitive fields.
• Sandboxes for tools that run code or shell — see Docker Sandboxes.
• Split read-only vs write tools; put writes behind confirmation.

Prompt injection via resource/tool result content remains real: treat external text as untrusted data, not instructions.

Observability and operations

Without metrics, production MCP is a black box. Minimum set:

• RPS and errors by Mcp-Name.
• Latency p50/p95 per tool.
• Share of input_required and human declines on elicitation.
• Response size in bytes — guard against accidental dumps.
• Client protocol versions.
• Audit: which OAuth subject called which tool with which handle.

OpenTelemetry spans fit naturally on gateway → server → downstream API. Tool name is an excellent span attribute.

Comparison: MCP, function calling, and “just OpenAPI”

MCP does not replace OpenAPI. Often an MCP server is a curated façade over your API. OpenAPI stays the service contract; MCP is the agent contract.

Common mistakes

Copying every REST method into a tool. The model drowns in synonyms.
Hiding critical state in process memory. After going stateless with two replicas, drafts vanish.
Shipping write tools without confirmation. One wrong call becomes an incident.
Logging arguments verbatim. Tokens and PII leak.
Ignoring protocol version. Client upgrades; server silently degrades.
Assuming localhost is safe by default. A local server with a dangerous tool on a shared laptop is still an attack surface.

Launch checklist

1. One server, 5–10 tools around real team tasks.
2. Read-only first; writes behind MRTR.
3. OAuth / CIMD plan and iss validation.
4. Deploy ≥2 instances without sticky sessions.
5. Metrics by Mcp-Name; alerts on 5xx and oversized responses.
6. Allowlists in developer clients.
7. Migration runbook for 2026-07-28.
8. Sandbox coupling if a tool executes code.

Scenarios from practice

An agent supports a release

Tools expose pipeline status, diffs for critical files, a release-notes draft, and rollback only via elicitation. Without MCP the same flow is CI scripts plus a human chat. With MCP a lead asks “why is deploy red” and gets a structured tool answer instead of a log paste.

Support and internal data

Read-only tools against CRM or knowledge bases reduce risk when an agent helps L2. Write tools (ticket status, customer comment) belong behind confirmation and subject audit. Compact results matter again: the agent needs “open tickets for customer X with SLA under 4h”, not the full entity JSON.

Platform owns the catalog

In a mature model, MCP servers are platform products, not personal experiments. The platform publishes the catalog, SLAs, protocol versions, and a breaking-change channel. Developers attach servers like dependencies, not like “another URL from a tweet”.

Gateways and the enterprise contour

Between IDE and origin servers you almost always want a gateway: shared OAuth, allowlist, rate limits, log redaction, routing on Mcp-Name. The same edge is a natural canary point. Without it every server reinvents auth and security review becomes a zoo of exceptions.

Separate edge policy (who may call MCP at all) from tool policy (which tool names a role may use). Interns get read catalogs; on-call gets writes with elicitation. That is easier to express at the gateway than hoping each IDE filters correctly locally.

Testing a server without a full IDE

Opening Cursor and chatting with a model is expensive for regressions. Keep contract tests:

• tools/list stable on names and required schema fields;
• golden tests for arguments → downstream HTTP (mocked);
• two instances behind nginx/caddy without sticky: the same handle reads on both;
• MRTR path: first input_required, then success after inputResponses;
• negatives: expired token, 403 on another tenant’s resource, oversized responses truncated.

Separately review tool descriptions with humans: an unfamiliar engineer should know when to call the tool from the description alone. If not, neither will the model.

FAQ

Further reading

• Giving an AI agent API access via MCP — curated tools over an external API
• Sandbox security for agentic AI
• Your local LLM is not as private as you think
• Corporate AI platform
• Enterprise RAG architecture
• SEO / AEO / GEO for AI search

Primary sources: the 2026-07-28 specification announcement, MCP docs, and Tier 1 SDK migration notes.

What to do this week

If MCP is new for you, do not start by “writing a Cursor plugin”. Pick one internal API agents already ask about manually and wrap it in 5–7 read-only tools. Run two instances without sticky sessions, add metrics by Mcp-Name, and put the server on the team allowlist. In parallel, list write tools that must never ship without MRTR. In a week you will have a working contour and a backlog of holes — not a slide deck.

If you already run servers, spend the week inventoring session state and piloting 2026-07-28 on one non-critical service. Document handles and breaking changes the same way you would for a public HTTP API: changelog, protocol version, owning team.

Conclusion

In 2026 MCP is past the “wire the filesystem into chat” experiment. A stateless core, MRTR, gateway headers, and stricter auth turn the protocol into ordinary — and therefore demanding — platform infrastructure. Teams that win design a small intelligible tool catalog, move state into handles, govern against shadow MCP, and treat spec migration like an API migration. Everyone else will still meet client upgrades — better with a runbook than with a Friday incident.