5 MCP Dev Summit Takeaways That Change How You Build Python Agents

#ai #programming #python #mcp

The first MCP Dev Summit just ended. April 2-3, New York City, 95 sessions, speakers from Anthropic, AWS, Microsoft, OpenAI, Datadog, and Hugging Face. The Agentic AI Foundation now has 170 member organizations governing the protocol.

Most coverage focuses on announcements. This post focuses on what you need to change in your Python code.

1. The Python SDK V2 Is Coming — Plan Your Migration Now

Max Isbey from Anthropic presented "Path to V2 for MCP SDKs" at the summit. The Python SDK has moved slower than TypeScript — v1.26.0 landed in January 2026, with v1.27 following later. Meanwhile, the TypeScript SDK shipped multiple releases with conformance testing improvements. The pace difference is intentional — Anthropic is holding back major Python changes until the V2 design solidifies.

What V2 likely breaks:

mcp.server.auth module — The authentication surface is being redesigned. If you use the current auth middleware, document every import and configuration pattern you depend on.
Transport initialization — Streamable HTTP is evolving (more on this below). Server setup code will change.
Session management — Sessions are moving from transport-level to data-model-level, which means your session handling code needs a different abstraction.

What to do this week: Audit your MCP servers. Run pip show mcp and note your current version. Document every mcp.server.auth import. List every transport configuration. When V2 drops, you will have a migration checklist instead of a debugging session.

# Document your current setup before V2 lands
# Example: typical MCP server with auth (v1.x pattern)
from mcp.server import Server
from mcp.server.stdio import stdio_server

server = Server("my-tool-server")

@server.tool()
async def search_docs(query: str) -> str:
    """Search internal documentation."""
    # Your tool implementation
    results = await doc_index.search(query)
    return format_results(results)

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write)

Pin your current version in requirements.txt until V2 migration guides ship. Do not upgrade blindly.

2. OAuth 2.1 Becomes the Standard Auth Pattern

Six dedicated sessions at the summit focused on MCP authentication. Aaron Parecki — the author of the OAuth 2.1 draft specification — attended and participated. That signals the auth solution is grounded in real spec work, not vendor positioning.

The key shift: Client-Initiated Metadata Discovery (CIMD) replaces Dynamic Client Registration (DCR) as the preferred registration method. DCR required enterprise authorization servers to enable a feature most disable by default. CIMD lets each client publish a metadata document at a .well-known URL, and authorization servers make trust decisions based on the domain.

What this means for your MCP servers:

STDIO servers stay simple — they inherit the host process's permissions and do not need auth.
HTTP servers should prepare for OAuth 2.1 with PKCE as the standard flow.
Multi-tenant servers will benefit from CIMD — one metadata document per domain instead of managing client registrations.

Two spec enhancement proposals are under review: SEP-1932 (DPoP) for token binding and SEP-1933 (Workload Identity Federation) for cloud service-to-service authentication. If you are building MCP servers that run in AWS, GCP, or Azure, watch SEP-1933 — it will let your server authenticate using cloud-native identity instead of managing OAuth clients.

# Future pattern: MCP server with OAuth 2.1 (conceptual)
# Exact API will ship with SDK V2 — do NOT implement this yet

# What to prepare NOW:
# 1. Separate your tool logic from your auth logic
# 2. Keep auth configuration in environment variables
# 3. Design tools to be auth-agnostic

@server.tool()
async def query_database(sql: str) -> str:
    """Run a read-only SQL query."""
    # Tool logic should not know about auth
    # Auth happens at the transport layer
    result = await db.execute(sql)
    return result.to_json()

3. Streamable HTTP Goes Stateless With .well-known Discovery

The 2026 MCP roadmap makes the direction clear: agentic applications should be stateful, but the protocol itself should not be. The current Streamable HTTP transport has three scaling problems:

Stateful sessions fight load balancers. If your MCP server holds session state, sticky sessions are required, which defeats horizontal scaling.
No discovery without a live connection. A registry or crawler cannot learn what your server does without connecting to it and negotiating a session.
No standard metadata format. Every MCP server describes its capabilities differently.

The solution shipping in the next spec release (targeted for June 2026):

.well-known metadata documents — Your server publishes a JSON document at a well-known URL describing its tools, resources, and capabilities. Registries can index this without connecting.
Cookie-like session mechanism — Sessions decouple from the transport layer, mirroring standard HTTP patterns. Your server can scale horizontally behind a load balancer without sticky sessions.
Stateless protocol, stateful applications — The protocol handles routing and discovery. Your application handles state.

# Future: .well-known/mcp-server.json (conceptual)
# Enables discovery without a live MCP connection

{
  "name": "my-tool-server",
  "version": "1.0.0",
  "tools": [
    {"name": "search_docs", "description": "Search documentation"},
    {"name": "query_database", "description": "Run SQL queries"}
  ],
  "transport": "streamable-http",
  "auth": "oauth2.1"
}

What to do now: If you are running MCP servers over Streamable HTTP, start designing for statelessness. Move session state to Redis or a database. When the June spec drops, migration will be straightforward if your transport layer does not hold state.

4. Cross-App Access Brings SSO to AI Agents

Paul Carleton from Anthropic presented Cross-App Access (XAA), part of the ID-JAG project. This is single sign-on for AI agents.

Today, every MCP client manages its own auth tokens per server. If an agent connects to five MCP servers, it negotiates five separate authentication flows. XAA changes this: one authentication event grants scoped access across multiple servers that trust the same identity provider.

Why this matters for Python developers:

Fewer auth flows to implement. Your MCP server trusts an identity provider. The client authenticates once. Done.
Cross-platform interop. Nick Cooper from OpenAI keynoted the summit. OpenAI is moving toward MCP Resources support. Agents built with either Anthropic or OpenAI SDKs will be able to query resources from the same MCP servers.
Enterprise adoption unlocks. SSO is table stakes for enterprise. Without it, MCP stays in developer tooling. With it, MCP enters production enterprise workflows.

What to do now: If you are building MCP servers for internal tools, do not roll custom auth. Wait for the SDK V2 auth module. Design your tools to be auth-agnostic (business logic separated from transport), so plugging in XAA later requires zero tool code changes.

5. The Enterprise Working Group Changes the Governance Game

The Agentic AI Foundation announced the formation of an Enterprise Working Group. This is new — it did not exist before the summit.

What this group will tackle:

Audit trails — Logging which agent called which tool with which parameters. Required for compliance in regulated industries.
SSO-integrated auth — Enterprise identity providers (Okta, Azure AD, Google Workspace) as first-class MCP auth sources.
Gateway behavior — Standard patterns for MCP gateways that proxy, filter, and log tool calls. Think API gateways, but for MCP.
Configuration portability — Standard formats for describing MCP server configurations that work across Claude Code, Cursor, Windsurf, and other clients.

Most of this work will ship as extensions rather than core spec changes. That means your existing MCP servers will not break. But if you need enterprise features, you will opt into extension modules.

The governance model is also decentralizing. Working Groups can now accept Spec Enhancement Proposals (SEPs) in their domain without full Core Maintainer review. This means the spec can evolve faster in areas like enterprise auth without blocking the core protocol.

What to Do This Week

Run pip show mcp and pin your current version. Do not upgrade until V2 migration guides are published.
Separate tool logic from auth logic. Every @server.tool() function should be a pure function that takes inputs and returns outputs. Auth lives in the transport layer.
Move session state out of your transport. If you use Streamable HTTP, store state in Redis or a database, not in the MCP session object.
Document your current auth setup. List every mcp.server.auth import, every environment variable, every OAuth client configuration.
Watch three SEPs: SEP-1686 (Tasks), SEP-1932 (DPoP), SEP-1933 (Workload Identity Federation). These determine what ships in the June spec release.

The MCP spec is moving fast. The Dev Summit proved that the protocol has institutional backing from every major AI lab. The Python SDK V2 will be the biggest migration event since the SSE-to-Streamable-HTTP transition. Prepare now, migrate cleanly later.

Follow @klement_gunndu for more MCP and AI agent content. We are building in public.