The MCP handshake diagram in your bookmarks is already stale

If you've read that an MCP client and server "shake hands and open a session", that's the old model. A lot of it was published this year.

The 2026-07-28 MCP spec dropped initialize, initialized, and the Mcp-Session-Id header. Every request now carries its own protocol version, client info, and client capabilities in _meta. For a server author that means no session store and no reconnect logic. Draftbase ships an MCP server built on that stateless shape, with 26 tools.

The role split, since two-box diagrams get this wrong too. The host is the app that runs the model. The client is a connection object, one per server, always. The server is the thing you write, and it never talks to a model at all. That's why a server built for Claude Code also works in VS Code.

What else changed, specifically:

• Servers can't call back mid-stream. A server needing input returns resultType: "input_required". The client gathers answers and retries with inputResponses. The spec calls it Multi Round-Trip Requests.
• Sampling, logging, and roots are deprecated as of 2026-07-28, with a twelve-month minimum window before removal. Existing code keeps working. New servers should skip them.
• Notifications are opt-in. A client opens subscriptions/listen and names the types it wants. Delivery is best effort, per the spec, so keep polling.

The underused bit: caching moved into the protocol. server/discover returns ttlMs and cacheScope. HTTP requests carry Mcp-Method and Mcp-Name headers, so a gateway can route and meter without parsing the body. Sessions are gone, so any request can land on any instance.

Build the server like a web service. Stateless handlers, cache headers you mean, per-request auth. The chat framing was never doing you any favors.

Also: don't ship 60 tools because your REST API has 60 endpoints. The tool list is context, and context is a budget.

Full lifecycle, plus the who-does-what table, on the canonical: How MCP Clients and Servers Work Together.

The interesting part of an agent writing to your CMS isn't the tool call. It's scoped keys, revision history, and an agent that writes drafts a human publishes. Hobby is free, Startup is $49/mo. Agent experiments welcome at r/draftbase_cms.

Comments

[Marcus Kim]

Putting protocol version, client info, and capabilities into each request changes the operational model more than the missing handshake suggests: stateless handlers and per-request auth now become the sensible default. The input_required retry flow and opt-in, best-effort notifications also mean server authors need explicit idempotency and polling semantics, not hidden conversational state. I'd treat the tool catalog as a product surface rather than an API mirror-26 well-scoped tools may already be a lot-because every extra tool spends context and increases selection ambiguity.

[Samer Alsayegh Draftbase]

I’ve seen some MCP tools with 90+ tools, even though most usage is likely concentrated around the main 10. The other 80 tools I never use were quietly eating up ~100K tokens of context in every fresh chat—before I’d even sent the first message.

Now repeat that across dozens of chats and multiple turns, and you’re easily burning hundreds, if not thousands, of dollars in token usage just loading context for tools you never intended to use or even care about.

Definitely something to balance with context on available tools and context on getting work done.