P1-9: MCP gateway (registration, transports, auth, access control, cost tracking)

Problem

LiteLLM ships a full MCP (Model Context Protocol) gateway: register MCP servers, multiple transports (HTTP-streamable / SSE / stdio), auth methods (OAuth2 client-creds / AWS SigV4 for Bedrock AgentCore / API key / Bearer / Basic / static-headers), per-request `x-mcp-{server}-{header}` injection, access control by Key/Team/Org, server aliases, access groups, end-user attribution, semantic tool filtering, MCP cost tracking, MCP-specific guardrails, and auto-tool-execution inside `/v1/chat/completions` and `/v1/responses`.

ai-gateway has none of this. 2026 trend: agent infrastructure without MCP support is becoming a deal-blocker.

Scope (large; can be split)

DP (api7/aisix)

• New crate `crates/aisix-mcp/`.
• MCP server registration + transport adapters (HTTP-streamable + SSE first; stdio later).
• Per-server auth: OAuth2 / AWS SigV4 / API key / Bearer / static headers.
• Per-request header injection `x-mcp-{server}-{header}` from request → forwarded to upstream MCP.
• Access control: filter the tool list returned to the LLM by api_key / team / org membership.
• Auto-tool-execution: inside `/v1/chat/completions` if the model returns a `tool_calls` referencing an MCP tool, the gateway invokes the MCP server, feeds result back, loops until model stops calling tools.
• MCP-specific guardrails (extend Guardrail trait with MCP hook points).
• Cost tracking: associate MCP tool-call usage with the api_key's spend.

CP (api7/AISIX-Cloud)

• New resources: `mcp_server` (org-scoped — connection details), `mcp_access_group` (env-scoped).
• CRUD + push to etcd.

Dashboard UI (api7/AISIX-Cloud)

• MCP Servers page (org-scoped).
• Per-environment MCP access-control page.

e2e

• Mock MCP server (HTTP-streamable + SSE).
• Test: chat completion that calls a tool → gateway round-trips to mock MCP → response includes tool result.
• Test: end-user with no MCP access → tool list filtered.

Estimate

DP 10-15d (large scope), CP 3d, UI 3d, e2e 2d. Probably should be a parent issue with sub-issues per phase.

Update 2026-07-01 — 拓扑订正 + 进展. DP = api7/aisix，CP = api7/AISIX-Cloud（原文 api7ee-3-control-plane 已过时，已订正）。DP 侧 MVP 运行时已 SHIPPED：MCP server 注册 + 上游 auth(none/bearer) + per-tool ACL(#668) + guardrails/rate-limit/budget over MCP(#671/#672/#670) + Admin OpenAPI(#675) + timeout 校验(#676)。作用域已定：mcp_server = org 级注册表(照抄 provider_keys)+ allowed_environments 暴露到环境；弃独立 mcp_access_group(per-key 工具 ACL 复用 api_keys)。CP + Dashboard 落地设计（含 UI/UX 效果图）见 AISIX-Cloud#894 Revision B。

Treat this as a parent issue rather than a first contribution: review the shipped DP MVP details and the CP/Dashboard design in AISIX-Cloud#894 Revision B. Start with the proposed crates/aisix-mcp/ entry point, the /v1/chat/completions flow, and the listed e2e mock-server tests. Done requires splitting and completing the DP, CP, Dashboard, and e2e phases described in the scope.