Add Context Gateway

One MCP endpoint and one agent key in place of every MCP server the agent configures today. The Gateway holds each Upstream's secret, namespaces tool names so they never collide, can expose a large catalog as search_tools and run_tool instead of every schema, caches read-only tools you opt in, and can hand a large result back as a handle. The agent keeps its tools; only where it reaches them changes. Ask first, provision, then repoint.

1. Discover

Read the project:

• Find every MCP server the agent configures: .mcp.json, .cursor/mcp.json, McpToolset, MCPServerStreamableHttp, MultiServerMCPClient, stdio_client, or a hand-written MCP client. Note each endpoint and where its secret comes from.
• Find where tools are handed to the model and where the turn runs.
• Identify the framework from imports, and whether it has its own MCP client.
• Note stdio-only servers: an Upstream is an HTTP MCP endpoint (streamable-http). A stdio server has to be served over HTTP first, or stays outside the Gateway.

First ask where the Gateway runs:

• Redis Cloud (console). The developer creates the Gateway and its Upstreams in the console, and the CLI only talks to the Gateway's MCP endpoint (step 3, "In Redis Cloud"). Cloud keeps the Gateway's cache and compression off, so skip questions 3 and 4.
• Self-managed (on-prem, or the local Compose stack). The CLI provisions everything (step 3).

Then ask the developer these five questions, nothing more. A shrug takes the default.