feat(serve): host MCP and A2A on a single Starlette binary (parity with JS)

[bokelley]

Summary

Today adcp.server.serve(transport=...) takes either streamable-http (MCP) or a2a — adopters wanting both have to run two processes. JS hosts both on one Express/Hono app. Achieve parity for Python.

Design

• Build MCP app via mcp_server.streamable_http_app()
• Build A2A app via a2a_app.build()
• Mount both on a parent Starlette via Mount("/mcp", mcp_app) + Mount("/", a2a_app)
• Careful auth/middleware composition across both prefixes — middleware must apply to both transports identically (signing verification, audit, registry lookup, tenant routing)
• New transport="both" option (or similar; bikeshed during impl)

Cross-references

• RFC: docs/proposals/v3-identity-bundle-design.md
• JS parity tracker: adcp-client#1249

🤖 Generated with Claude Code

[bokelley]

Triage

Classification: Feature request
Bucket(s): client, middleware (no matching labels exist in this repo — flagged in run summary)
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Approved in principle; cross-transport idempotency (MCP idempotency store ≠ A2A TaskStore namespace) must be documented — same key silently double-executes across transports; _wrap_with_size_limit must wrap the combined parent, not each sub-app independently.
• code-reviewer: Two implementation blockers — no starlette>=0.36 lower bound (required for reliable Mount lifespan propagation), and _serve_a2a hard-codes 0.0.0.0 ignoring host/ADCP_HOST; both fixable.
• security-reviewer: Three security blockers — BearerTokenAuthMiddleware is MCP-wire-specific and will reject all A2A traffic when applied at parent level; no SDK-exported A2A_DISCOVERY_PATHS constant for operators writing parent-level auth guards; A2A's catch-all / mount must be registered after /mcp or MCP requests misroute to the A2A executor, enabling log injection via attacker-controlled skill name.

My take: All blockers are implementable in a careful PR, but the auth-middleware composition design decision — specifically whether the SDK should enforce per-sub-app auth placement (runtime assertion / API-level guard) or document-only — is security-sensitive enough to need sign-off before code. @bokelley, would you like to weigh in on that design question and whether the PR should also export A2A_DISCOVERY_PATHS alongside DISCOVERY_METHODS?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_016ohdyJ7nTVHgKU72BQwkz4

---

Generated by Claude Code