mcp: evaluate mcp 2.x support (co-install with mcp>=2 fails on the <2.0.0 cap)

[RichardHightower]

Summary

agent-brain-ag-mcp pins mcp<2.0.0,>=1.27.2. mcp 2.0.0 shipped on 2026-07-28 (2.2.0 on 2026-09-07). Any environment that already holds mcp>=2, for example one shared with a newer MCP tool, cannot install any Agent Brain MCP release.

Found while reproducing #236 on 2026-09-19 with pip 26.2.1 on Python 3.10.14:

$ pip install --dry-run "mcp>=2" agent-brain-ag-mcp==10.7.0
ERROR: Cannot install agent-brain-ag-mcp==10.7.0 and mcp>=2 because these package versions have conflicting dependencies.
The conflict is caused by:
    The user requested mcp>=2
    agent-brain-ag-mcp 10.7.0 depends on mcp<2.0.0 and >=1.27.2

Why this is not a pin bump

mcp 2.x changes its own dependency set, so the migration touches our code and our pins:

• httpx is replaced by httpx2>=2.5.0. agent-brain-ag-mcp, agent-brain-cli, and agent-brain-uds pin httpx<0.29.0,>=0.28.0.
• pydantic>=2.12.0 (we allow >=2.10.0).
• sse-starlette>=3.0.0.
• New mcp-types package and opentelemetry-api dependency.
• The auth surface used by Phase 67 (mcp.server.auth) needs a compatibility check against the 2.x API.

Proposed scope

1. Spike: install mcp==2.2.0 in a scratch venv and run the agent-brain-mcp test suite to list the breaking API changes.
2. Decide between a dual-range pin (>=1.27.2,<3) with compatibility shims, or a hard move to 2.x with a major version bump.
3. Update the install troubleshooting docs to name the current supported mcp range.

Refs #236.

[BrierAinz]

A useful first split might be to treat this as two separate compatibility questions:

1. packaging compatibility: can �gent-brain-ag-mcp co-install in an environment that already has mcp>=2;
2. protocol/runtime compatibility: do the MCP server entrypoints, auth hooks, transports, and tool schemas behave the same under 2.x.

For the spike, I would make the matrix explicit so the decision is less vibes-driven:

• Python versions currently supported by Agent Brain;
• mcp==1.27.2 as current floor;
• latest <2 release;
• latest 2.x release;
• install-only, unit suite, and at least one smoke run for ools/list plus a representative tool call.

If 2.x requires auth or transport shims, I would lean toward keeping the published pin <2 until there is a small compatibility adapter with tests, rather than widening to <3 just because resolution succeeds.