Python MCP SDK v1 now gets security fixes only: use v2 for new clients

Start new Python MCP clients and servers on SDK v2. The Python SDK release page says v1.x is security-fix only, while v2.0.0 added multi round-trip requests and support for the 2026-07-28 specification.

If you are pointing a Python agent at Sume's hosted MCP endpoint, that decides which line you build on and what you verify after connecting.

What the release page says

The page text read here printed unreliable years, so this table leaves dates out. Check the page itself for the release you install.

Connecting to Sume

Sume's hosted MCP lives at one production URL, https://mcp.sume.com/mcp. Two credentials work: OAuth with the MCP-host consent page, or a Sume API key sent as Authorization: Bearer or x-api-key.

OAuth gives a read-only session by default (mcp:read). Write and paid tools appear only when mcp:write is granted on the consent page, and an API key sees the full hosted set. There is no mcp:paid scope; spend is governed by wallet and admission.

Verify the connection the same way on either SDK line

The quickstart lists useful first read-only calls after a client connects. They show the endpoint, the auth source and the tool surface without spending anything.

• mcp_health: confirms the endpoint, the auth source and the safety posture.
• tools_list: lists every tool visible to this session.
• tools_schema with a name: returns one tool contract, for example generate_image.
• account_me: confirms the workspace account context. balance_get, also in the hosted tool list, reads the spendable balance.

Spend gates do not depend on the SDK

Whatever client library you use, paid calls need the same fields. idempotency_key is required on write and paid tools. dry_run=true previews cost without submitting a job, and max_spend_usd is enforced only when you provide it.

A client upgrade from v1 to v2 should therefore be tested with a dry run, not a real render. Compare the preview against your expectation, then submit with a fresh key.

A short migration plan

• Pin the Python MCP SDK major version in your lock file so a v1 resolver does not silently stay behind.
• Re-run the four-call verification above after the upgrade.
• Repeat one dry_run generation on a write-enabled session.
• Keep job ids in your own store; they work across SDK versions because they are Sume identifiers.