Here is the part that reframes the decision for everyone else.

The 2026-07-28 revision is not a point release. Per the announcement on blog.modelcontextprotocol.io, it turns MCP "from a bidirectional stateful protocol into a request/response stateless protocol." Concretely, in that revision:

• The handshake is gone. The initialize/initialized exchange and the Mcp-Session-Id header have been retired. Each request now travels on its own, carrying its protocol version, client identity and client capabilities in _meta. An optional server/discover RPC lets clients learn capabilities upfront, but it is not required.
• Routing moved into headers. Streamable HTTP requests must now include Mcp-Method and Mcp-Name, so gateways and rate limiters can route and meter without parsing the JSON body.
• List results are cacheable. Responses to tools/list, prompts/list, resources/list and resources/read can now carry ttlMs and cacheScope, so clients can stop re-fetching things that have not changed.
• Server-initiated calls were rebuilt. Multi Round-Trip Requests replace the old open-stream pattern: the server returns a result of type input_required with the inputs it needs, and the client re-issues the call with the answers.
• Roots, Sampling and Logging are deprecated. They still work, and the announcement gives them a twelve-month minimum window. The legacy HTTP+SSE transport got the same year-long offramp.
• Auth got stricter. RFC 9207 issuer validation, credentials bound to the issuer that minted them, and Dynamic Client Registration formally deprecated in favour of Client ID Metadata Documents — with DCR compatibility maintained for at least twelve months.

This is a healthy protocol doing a hard thing well. Statelessness is why an MCP server can now sit behind a plain round-robin load balancer with no sticky sessions. The migration windows are generous and clearly signposted.

But notice what it means if you are not a developer: a hand-rolled MCP server is not a thing you build. It is a thing you maintain, through breaking revisions, on a clock somebody else sets. There is now a dated list of things you have to stop using before a deadline. Something will land on that list again.

A note on dates: every claim above is tied to the 2026-07-28 revision as announced. The spec moves. Before you act on any specific field name or deadline here, check the current specification — this article will not update itself.

Be honest about this. If you are an ops lead, a consultant, or an agency owner, the twelve-month deprecation clock on Roots and Sampling is not a thing you are going to track. Nor should you. Your product is the workflow, not the transport it rides on.

For you the useful question is not "how do I build an MCP server" but "who absorbs the churn."

That is the case for a hosted builder. You define the workflow once; the platform owns the protocol layer, and when the next revision lands the migration is supposed to be somebody's full-time job rather than a Tuesday you did not plan for. That is the promise, and it is worth a paragraph on how to check whether a given vendor is keeping it — below.

MindStudio is the one I would point at here, for a specific reason: exposing an agent as an MCP server is one of its standard deployment surfaces, not an add-on. Per the deployment section of MindStudio University, its own documentation site, the same agent can be shipped as a web app, a scheduled autonomous run, a browser extension, an email-triggered agent, an API or webhook endpoint, or an MCP server that external applications and LLMs can invoke as a tool. You build the workflow once and pick the surface.

The practical shape of it: build the agent, publish it, point Claude or your IDE at the generated server, done. No transport code, no auth plumbing, no header work.

Verify this before you commit to it

Hosted does not automatically mean current, and I am not going to assert otherwise about any vendor — I have not audited what revision anybody's endpoint speaks today. A platform can sit as far behind a spec revision as you would have. That matters more than usual right now for a structural reason: one of the things the 2026-07-28 announcement put on a twelve-month clock is the legacy HTTP+SSE transport, and any remote MCP endpoint that predates this revision was by definition built on the older transports. Every hosted server in existence on 27 July had migration work ahead of it. The only question is whether a given vendor has done it.

So make it a five-minute check rather than an assumption. Connect a client to the generated endpoint and see what it expects: does it still want the retired initialize handshake and an Mcp-Session-Id, or does it accept a standalone stateless request with Mcp-Method and Mcp-Name headers? Then ask the vendor, in writing, what their migration timeline for the 2026-07-28 revision is. If nobody can answer that, you have not outsourced the churn — you have moved it somewhere you cannot see it, which is worse than owning it.

Where MindStudio is the wrong answer

Being specific, because a vague caveat is not a caveat:

• You would rather write the server yourself. If the SDK route in the first section sounded appealing rather than tedious, take it. A short, tested, version-controlled file beats a hosted config you cannot grep. This is genuinely the better engineering answer and I am not going to pretend otherwise.
• Complex branching state or real debugging needs. Visual builders are excellent up to a complexity ceiling and painful above it. If your workflow has meaningful conditional logic, or you expect to spend time asking "why did it do that", you want a stack trace, not a canvas.
• Data residency or compliance constraints. The server runs on someone else's infrastructure. If your data cannot leave a jurisdiction or your contracts specify where processing happens, a hosted platform relocates that problem rather than solving it.
• You need control over the new spec behaviours. Caching policy, cacheScope decisions, auth posture under the tightened issuer rules — a hosted platform decides those for you. Usually that is the point. Occasionally it is disqualifying.
• The vendor cannot tell you where they are on the spec. If the check in the previous section comes back vague, walk. The entire argument for hosting is that somebody else tracks the protocol; a vendor who cannot name their migration timeline is not doing the one job you are paying them for.

If two or more of those describe you, do not use a hosted builder for this. Write the server.

Three questions, in order:

1. Will you be maintaining this in eighteen months? If yes, and you can code, own it. Ongoing maintenance is exactly the cost a hosted platform is priced against, and if you are going to do the maintenance anyway you are paying for nothing.
2. Does the workflow branch? Linear pipelines — fetch, transform, summarise, return — are what visual builders are good at. Anything with real conditional depth is not.
3. Who gets paged when it breaks? If the answer is "nobody, and it needs to just keep working," hosting is buying you an on-call rotation you do not have.

Everything else is noise. Volume, pricing tiers, the specific model behind the workflow — all of it is downstream of those three.

MCP stopped being a young protocol and started being a maintained one. The 2026-07-28 revision removed the handshake and sessions, moved routing into headers, made list results cacheable, and started twelve-month clocks on Roots, Sampling, Logging, HTTP+SSE and Dynamic Client Registration. That is good protocol stewardship and it is also a standing maintenance bill.

If you can write the server, write the server — it is the better answer and it is not much code. If you were never going to track a spec changelog, do not pretend you were; pick a platform that treats MCP as a deployment target and let the churn be its problem.

The failure mode to avoid is the middle: hand-rolling a server you will not maintain, and discovering that eleven months from now.

---

Protocol details in this article come from the 2026-07-28 specification announcement on the official MCP blog, blog.modelcontextprotocol.io/posts/2026-07-28/ (28 July 2026). MindStudio's deployment surfaces come from its published documentation at MindStudio University; no claim is made here about which spec revision its MCP endpoint currently implements, because that is not something I verified. Specifications and product feature sets both change — check anything load-bearing against the current source before you build on it.

Disclosure: Some links are affiliate links. We earn a small commission at no extra cost to you. This helps us create more comprehensive guides like this. Thank you for supporting independent tech content!