Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Correct several claims in the SDK betas blog post #2997

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
localden merged 2 commits into from
Jul 1, 2026
+22 −14
Merged

Correct several claims in the SDK betas blog post #2997

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4fb8f71
Correct several claims in the SDK betas post
maxisbey Jul 1, 2026
aeecd51
Keep the original post date
maxisbey Jul 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 22 additions & 14 deletions blog/content/posts/2026-06-29-sdk-betas-for-2026-07-28.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ session, and completing the plan we laid out in
[The Future of MCP Transports](/posts/2025-12-19-mcp-transport-future/). If you're building MCP
servers, you can now scale them using a simple round-robin load balancer, removing the need to
manage sticky sessions and to store shared sessions. For client developers, new patterns, like
[Multi Round-Trip Requests (MRTR)](http://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr)
[Multi Round-Trip Requests (MRTR)](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr)
enable a whole new range of possibilities for server-to-client interactions. You can check out
the [full changelog](https://modelcontextprotocol.io/specification/draft/changelog) to see
what's coming.
Expand Down Expand Up @@ -51,16 +51,22 @@ before the new specification is locked. For any critical workloads, the stable S
remain the recommended versions.

You might've seen that some of the SDKs, like Python and TypeScript, have also switched to v2.
Those are new major versions, so moving your own code onto them is a breaking change, and one
you can take on your own schedule; it is separate from anything that happens on July 28.
Once v2 ships, the TypeScript SDK will continue shipping v1.x bug fixes and security updates
for at least six months, and the Python v1.x branch continues to receive critical bug fixes and
security patches.

Trying a beta is safe because it is opt-in at every step. Installing any of
the four aforementioned SDKs without explicitly requesting a pre-release still resolves to
a stable version. The opt-in extends to the wire: in the TypeScript and Go
SDKs, upgrading does not by itself change what your server speaks over
Trying a beta is safe because it is opt-in at every step. Installing the
Python, Go, or C# SDK without explicitly requesting a pre-release still resolves to
a stable version; the TypeScript v2 packages are new package names with no
stable release yet, so installing them is itself the opt-in. In the TypeScript and Go
SDKs, the opt-in extends to the wire: upgrading does not by itself change what your server speaks over
HTTP. Serving `2026-07-28` is an explicit choice you make when you wire up
the transport. And clients that speak `2026-07-28` fall back to the
the transport. A Python or C# server picks up the new revision on upgrade
instead: a Python v2 server answers both protocol revisions from one
endpoint, and the C# preview's HTTP transport defaults to the new stateless
mode. And clients that speak `2026-07-28` fall back to the
`initialize` handshake when they reach a server on `2025-11-25` or earlier,
so old servers and new clients keep interoperating.

Expand All @@ -74,8 +80,8 @@ If you want to make sure your own users are not caught out:

## What beta SDKs implement

All four beta releases implement the protocol changes from the release candidate,
with each release's notes listing exactly which SEPs are covered. The
All four beta releases implement the core protocol changes from the release candidate,
with each release's notes detailing which changes are covered. The
[RC announcement](/posts/2026-07-28-release-candidate/) covers the changes
in depth, but if you're curious about the short version:

Expand All @@ -91,8 +97,9 @@ in depth, but if you're curious about the short version:
required!
- **Routable transport headers**
([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)).
`Mcp-Method` and `Mcp-Name` ride on every request so gateways and rate
limiters can route without parsing bodies.
`Mcp-Method` rides on every request, and `Mcp-Name` on requests that name
a tool, resource, or prompt, so gateways and rate limiters can route
without parsing bodies.
- **Authorization hardening**, including `iss` validation per
[RFC 9207](https://www.rfc-editor.org/rfc/rfc9207)
([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)),
Expand Down Expand Up @@ -124,8 +131,9 @@ lists every change against `2025-11-25`.

## Python: `mcp` v2

The v2 line is a rework of the package you already know, and the API got
smaller in the process. A complete server can now be implemented like this:
The v2 line is a rework of the package you already know: `FastMCP` becomes
`MCPServer`, and the decorator API carries over. A complete server still
looks like this:

```python
from mcp.server import MCPServer
Expand All @@ -145,8 +153,8 @@ def greeting(name: str) -> str:
return f"Hello, {name}!"
```

No JSON Schema to write, as idiomatic Python constructs take over. Install the beta
with an exact pin, since unpinned installs stay on v1.x:
As in v1, there is no JSON Schema to write, as idiomatic Python constructs take over.
Install the beta with an exact pin, since unpinned installs stay on v1.x:

```bash
uv add "mcp[cli]==2.0.0b1"
Expand Down
Loading