Welcome to AIEdTalks' Newsletter!
In today's edition:
What MCP is, and why AI agents need it
The M×N integration problem it solves
Why the old MCP was a sticky-session trap
What the July 28, 2026 stateless spec changed
Let's dive in.
In partnership with
AI made PMs faster. Multiplayer mode is still broken.
A PM can summarize research, draft a PRD, and mock up a prototype before lunch. The hard part starts when the team has to decide what actually gets built.
Jira Product Discovery gives product teams one place to capture insights, prioritize ideas with consistent frameworks, and build living roadmaps stakeholders can rally around.
And because it’s connected to Jira, the context behind every decision stays with the work—so developers and their agents know not just what to build, but why.
AI helps PMs move faster. Jira Product Discovery helps the whole team build with confidence.
Today’s Edition
AI SYSTEMS
MCP Just Went Stateless
Here's a bug you'll recognize even if you've never touched AI. You build a small service. It works perfectly on your laptop. You ship it, put two copies behind a load balancer for scale, and suddenly one in two requests fails. The reason is old and familiar: the first request set up some state on copy A, the second request landed on copy B, and copy B had no idea what you were talking about.
That exact bug just played out across the AI world — in the layer that lets agents use tools. It's called MCP, and on July 28, 2026 it got a fix any backend engineer will find deeply satisfying. This primer explains what MCP is from zero, why agents need it, and what that fix changed. It assumes you know HTTP, load balancers, and "stateful vs stateless," and nothing about AI.
1. What MCP is
An AI model on its own can only produce text. It can't query your database, search the web, or file a ticket. To do things, an agent needs tools — real functions it can call. The problem is wiring those tools up.
MCP (the Model Context Protocol) is an open standard for connecting AI apps to external tools and data. Anthropic open-sourced it in November 2024, and it's now run by a neutral group under the Linux Foundation. The tagline that stuck: it's "the USB-C for AI" — one standard plug instead of a drawer full of proprietary cables.
It's a plain client–server setup, and if you've built web services it'll feel familiar. The MCP host/client is the AI app or agent (a chat app, an IDE, your custom agent). The MCP server is a small wrapper around one tool or data source — GitHub, Google Drive, Slack, Postgres, your filesystem. A server offers three kinds of things: tools (functions the model can call), resources (data it can read), and prompts (reusable templates). Fix one thing in your head early: MCP is not a model, and not an agent framework. It's the plug between an agent and the outside world.
2. Why MCP is needed
Before MCP, every AI app wrote its own custom glue code for every tool. If you had 10 AI apps and 100 tools, you were potentially on the hook for 10 × 100 = 1,000 one-off integrations. Engineers call this the M×N problem: M apps times N tools.
MCP turns that multiplication into addition — M + N. Build one MCP server per tool, and any MCP-compatible app can use it. You've seen this pattern win before: HTTP did it for the web, ODBC did it for databases, LSP did it for code editors. Standardize the interface once, and you stop rewriting N connectors by hand.
3. How an agent uses it
An agent runs a simple loop — think → act → observe — over and over:
The model thinks and decides it needs a tool.
The client asks the server, "what tools do you have?" — this is tool discovery.
The server lists them; the model picks one; the client calls it.
The server runs the tool and returns a result.
The result goes into the model's context; the model observes and loops until done.
So if you ask an agent "what changed in our repo today?", the model calls a list_commits tool, the GitHub MCP server runs it, the commits come back, and the model writes your summary. Two ways client and server talk (the transport): stdio (the server runs as a local program on your machine) and streamable HTTP (the server is remote, reached over a URL). That second one is where our story happens.
4. The state problem (the heart of it)
The older MCP protocol was stateful. Before doing anything, a client ran a handshake: send an initialize request, and the server replied with a session ID (a header called Mcp-Session-Id). Every later request had to carry that ID, and the server kept the matching session in its own memory.
You already know why that's trouble at scale. A server that remembers each client in its own memory can't sit behind a plain round-robin load balancer — the kind that just spreads requests evenly with no memory of who went where. Picture two copies, Pod A and Pod B: the handshake lands on Pod A, which stores the session in its memory; the next request gets round-robined to Pod B; Pod B has never seen that session ID and returns an error. This is the classic sticky session problem. To work around it you had to pin each client to one copy ("sticky sessions"), or put sessions in a shared Redis store, or build a gateway smart enough to peek inside each message. All extra latency, cost, and things to break.
5. What the July 28, 2026 spec changed
The new spec did the obvious, correct thing: it removed the session and made servers behave like ordinary stateless HTTP services.
The handshake is gone. No more
initializestep. Every request is now self-describing — it carries what it needs (protocol version, client info, capabilities) inside itself, in a field called_meta.The session ID is gone. No more
Mcp-Session-Id, no server-held sessions. In the spec's words, any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage.Discovery is now optional. A client that wants the tool catalog up front can ask once with a
server/discovercall — but it's no longer required.Routing got easier. Requests carry simple headers (like
Mcp-Method) so a load balancer can route without opening the message body.Streaming changed. If a long response stream breaks, there's no session to "resume" — the client just re-issues it as a new request.
How big is MCP by now? From the release post: the main SDKs see close to half a billion downloads a month, with the TypeScript and Python SDKs each crossing a billion total downloads. GitHub, Google Cloud, and Cloudflare all shipped support on day one. (Those download figures are the project's own numbers.) One honest caveat: this is a breaking change — old and new clients don't silently mix, though servers can run both paths during a long migration window.
6. Why it matters: state didn't vanish, it moved
Going stateless doesn't mean your tool forgets everything — the database still has state. It means the state moved out of the invisible transport session and into a place you can see and control. An analogy: HTTP itself is stateless, yet the web is full of stateful apps. The trick was never "have no state" — it was "stop hiding the state in the connection." A website gives your browser a cookie or an order ID; the browser hands it back on the next request; any server can pick it up.
So instead of a hidden session that dies when the load balancer does its job, a tool now hands back something like a basket_id, and the model passes that ID back on the next call — as an ordinary argument it can see:
# First call - create something, get an explicit handle back
call create_cart() -> { "basket_id": "abc123" } # saved to a shared DB
# Later call - the model passes the handle back itself
call add_item(basket_id="abc123", sku="otter-plush")
-> any copy of the server can look up abc123 in the shared DBThe payoff is the whole point: a remote MCP server now scales like any stateless web service — round-robin load balancing, autoscaling, no sticky sessions, no shared session store. The failure-before-fix in one line: a multi-step tool call that broke the moment you added a second replica now just works.
7. Common beginner confusions
MCP isn't a model or a framework. It's the standard plug between an agent and its tools.
Stateless protocol ≠ stateless app. The database still remembers things; the state just left the transport.
stdio vs HTTP. Local program vs remote URL. This change is about the remote HTTP case.
Too many tools is still a real cost — piling dozens of tools into one agent burns context and confuses tool choice (a separate problem).
Statelessness is a scaling fix, not a security fix. Tool results can still carry hidden malicious instructions; treat tool output as untrusted.
MCP vs function calling vs A2A. Function calling is one vendor's way for a model to request a tool. MCP is the portable, discoverable tool layer across apps. A2A is a different protocol for agents talking to other agents. Rule of thumb: MCP is agent → tools; A2A is agent ↔ agent.
Key terms
MCP — an open standard for connecting AI apps to external tools and data.
MCP host/client — the AI app or agent. MCP server — a wrapper exposing one tool or data source.
Tool / resource / prompt — a callable function / readable data / reusable template.
Tool discovery — the client asking a server what it offers.
Transport — how they talk: stdio (local) or streamable HTTP (remote).
Stateful vs stateless — whether the server must remember your earlier requests.
Session / session ID — a server-side memory of a client, keyed by an ID. Removed in the new spec.
Sticky session — pinning a client to the one server copy that holds its session.
Round-robin load balancer — spreads requests evenly, with no memory of who went where.
Self-describing request — a request that carries everything a server needs, so any copy can handle it.
The one idea to remember
State didn't disappear when MCP went stateless — it just stopped hiding in the connection, where a load balancer could break it, and moved somewhere every copy of your server can reach. That's the same move HTTP made 30 years ago. Your AI agent's tool layer is a distributed system, so build it like one: keep the servers stateless, and pass the state around out in the open.
Notes on the facts: MCP was open-sourced by Anthropic in November 2024 and is now governed under the Linux Foundation. The stateless changes — dropping the initialize handshake and the Mcp-Session-Id session, self-describing requests, header-based routing, optional discovery — are from the official 2026-07-28 spec and its changelog. The "half a billion downloads a month / a billion total" figures are the project's own release-post numbers, not independently audited. "USB-C for AI" is a community framing. Statelessness is a scalability fix only — tool overload and prompt injection remain separate, unsolved problems.
Rate today's Newsletter
Wall Street’s New Shopping List
Big money is rotating into a select group of stocks for the second half of 2026.
MarketBeat’s analysts tracked the move and identified 10 companies attracting fresh capital right now.
The updated 10 Best Stocks to Own in 2026 report lays out the tickers, trends, and catalysts.
👋 That’s All Folks!
Before you go, just a few public service announcements:
See you soon,
AIEdTalks’ Newsletter Team
