How to Build an MCP Server in 2026: What Changed in the New Spec

Build an MCP server for the 2026-07-28 specification (changelog). That means stateless requests, a mandatory server/discover call, deterministic tool lists with cache metadata, multi round-trip input and the Tasks extension for slow work. The old session handshake and HTTP+SSE transport are being retired.

TL;DR

• Sessions and the initialize handshake are gone; every request carries the protocol version and client capabilities in _meta.
• Implement server/discover first: it advertises versions, capabilities and identity.
• Return tools/list in a deterministic order and set ttlMs and cacheScope on list results.

Disclosure: ZeroRaised publishes this guide and is a launch site for bootstrapped products. Facts come from the linked sources as checked on 27 Oct 2026; ZeroRaised has no commercial relationship with the companies named.

Model Context Protocol (MCP) is an open protocol that lets an AI client discover and call tools, read resources and fetch prompts from an external server, so a model can reach data and actions beyond its context.

What changed in the 2026-07-28 specification?#

Protocol-level sessions and the Mcp-Session-Id header are removed, and the initialize handshake is gone (changelog). MCP is now stateless: every request carries the protocol version and client capabilities in _meta.

Servers must implement server/discover to advertise supported versions, capabilities and identity. subscriptions/listen replaces the HTTP GET endpoint and resources/subscribe. Multi Round-Trip Requests replace server-initiated calls such as elicitation/create: the server returns an input_required result and the client retries with inputResponses, and every result carries a resultType field. Tasks moved out of core into the official io.modelcontextprotocol/tasks extension.

Tool lists changed too: servers should return tools in a deterministic order to help client caching and LLM prompt cache hit rates, and list results require ttlMs and cacheScope.

Why does stateless MCP matter for hosting?#

Any request can land on any process, so you do not need sticky routing or a shared session store to answer a tool call. That removes a class of operational bugs for a small team.

The trade-off is that state becomes your design problem. If a tool needs to remember something, the server mints a handle and the client passes it back as a tool argument (changelog). Treat it like a database row id: unguessable, scoped and checked on every use.

How do you implement server/discover?#

A client that cannot discover your server will not call your tools. server/discover must advertise the protocol versions you support, your capabilities and your identity (changelog).

1. Decide which capabilities you offer: tools, resources, prompts or a subset.
2. Return supported versions honestly. Claiming a version you have not implemented is worse than supporting fewer.
3. Put a stable identity in the response so operators can tell your server apart.

How should tools/list behave?#

Return the same tools in the same order every time. A shuffled list changes the prompt prefix and destroys cache hits. List results also require ttlMs and cacheScope (changelog). Do not cache a list across users when it reflects per-user permissions.

Write inputSchema and outputSchema carefully. Any JSON Schema 2020-12 keyword is allowed, so you can describe enums, required fields and formats properly instead of hoping the model guesses.

How do you handle slow work with Tasks?#

An export, crawl or render takes longer than a request should stay open. A slow tool returns a task id, the client polls with tasks/get, can send input with tasks/update and can cancel with tasks/cancel (Tasks spec).

Statuses are working, input_required, completed, cancelled and failed. Servers suggest a pollIntervalMs and a ttlMs. IDs must be unguessable, and servers must check authorisation on every task request. There is no tasks/list, so one caller cannot see another's tasks.

Wrap your existing job system. Client support is uneven. In Claude Code, Tasks are in public beta from CLI v2.1.304 in the interactive terminal, the Agent SDK and GitHub Actions, but not yet in subagents, one-shot claude -p, the VS Code extension or the desktop app (Upstash, Claude Code docs). Calls over two minutes run in the background. See MCP Tasks in Claude Code.

How do you ask the user for input?#

Return an input_required result and let the client retry with inputResponses (changelog). The server describes what it needs; the client decides how to present it. A form-capable client can ask for a name or a choice (Upstash).

Ask for one thing at a time. If the answer is missing, fail clearly rather than guessing a default.

What security rules should you follow?#

Check authorisation on every task request, not only when it is created, and make task IDs unguessable (Tasks spec). Do not add a list endpoint that lets one caller enumerate another's work.

Streamable HTTP POSTs now require Mcp-Method and Mcp-Name headers (changelog). OAuth Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. Logging is deprecated too: log to stderr or use OpenTelemetry.

Keep credentials out of tool arguments, and treat every argument as untrusted. Our guide to rotating API keys covers credentials.

What is deprecated, and when must you migrate?#

Roots, Sampling and Logging are deprecated. HTTP+SSE is replaced by Streamable HTTP, and OAuth Dynamic Client Registration by Client ID Metadata Documents. There is a minimum twelve-month window (changelog).

That window is a schedule, not a reprieve. List every deprecated feature you use and move the transport first, because it affects every request. If you are starting now, build on Streamable HTTP.

A build sequence for a bootstrapped founder#

1. Pick one job with a clear output, such as a report export or a data lookup.
2. Write the tool descriptions and schemas before the handlers.
3. Implement server/discover with honest versions, capabilities and identity.
4. Make every request stateless; mint handles for anything that persists.
5. Return a deterministic tools/list with ttlMs and cacheScope.
6. Move jobs over a few seconds into Tasks.
7. Use input_required and inputResponses for missing information.
8. Check auth on every request and log to stderr or OpenTelemetry.
9. Test against Claude Code and one other client, then publish and decide pricing.

What this means for bootstrapped founders#

The protocol work is ordinary backend work: a discovery endpoint, a tool list, a job system and an authorisation check. The hard part is product design: which job is worth exposing, and who pays.

Do not treat a free server as the business. If it calls a paid model or licensed data, every call costs money. Our guide to monetizing an MCP server covers keys, usage pricing and directory fees. If the server sells an API, how to market an API covers distribution.

If your server drives a screen rather than an API, read what computer use AI is first. A proper tool beats automating a screen.

Where ZeroRaised fits#

ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. If you have shipped an MCP server people can try, submit your product. The newsletter carries new analysis like this, and the pricing page explains the listing options. Say which clients you support and how billing works.

Sources#

• MCP 2026-07-28 changelog
• MCP Tasks extension specification
• Upstash: Claude Code MCP Tasks
• Claude Code MCP documentation