You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Aether's codebase already contains a mcp gateway / tool aggregation layer that's used on the client side for aether's dynamic tool discovery.
It'd be nice to reuse the same machinery to offer an axum based mcp gateway as a separate binary that runs as an http server that aggregates N upstream http mcp servers tools, prompts etc.
In scope would be
Stateless http gateway
Aggregate N upstream http mcps (tools, prompts...etc)
Upstream mcps are authenticated using std authorization headers with API tokens (no human oauth flow for now)
Out of scope would be:
Progressive tool discovery (already supported in aether's harness, so no need to duplicate
Plan for issue #574 is written and committed (bfba51ad).
Summary
Task: Extract an axum-based, stateless HTTP MCP gateway binary that aggregates N upstream HTTP MCP servers (tools, prompts, resources) with static header/API-token auth.
Key findings from exploration:
Aggregation already exists: McpManager + ToolCatalog + McpSnapshot (crates/mcp-utils), orchestrated by McpBuilder/McpHandle (crates/aether-core/src/mcp), with a Unix-socket deferred-tool gateway (GatewayService) as the closest prior art.
The one real gap: nothing aggregates resources — tools and prompts do, resources don't.
rmcp 3.5.0 already ships a stateless server path (StreamableHttpService + NeverSessionManager, features currently unenabed); axum 0.8.9 is the workspace version with one production usage to copy from.
Plan (docs/aether/plans/issue-574-plan.md, force-added since plans/ is gitignored): new crates/mcp-gateway crate with binary aether-mcp-gateway, reusing McpBuilder/McpHandle for all upstream logic, a new HttpGatewayService (all tools model-visible, server__tool namespacing, prompts/resources routed), served statelessly via axum + rmcp's StreamableHttpService. Covers architecture, 8 sequenced steps with signatures/pseudo-code, testing plan, file table, and risks (notably allowed_hosts loopback default, tower-service version check, and the dist-shipping follow-up).
One question for follow-up (flagged in the plan rather than blocking): whether the new binary should eventually ship via cargo-dist or stay dist = false like the other auxiliary binaries.
Activity
contextbridge-pr-automation commentedon Oct 6, 2026
Plan for issue #574 is written and committed (
bfba51ad).Summary
Task: Extract an axum-based, stateless HTTP MCP gateway binary that aggregates N upstream HTTP MCP servers (tools, prompts, resources) with static header/API-token auth.
Key findings from exploration:
McpManager+ToolCatalog+McpSnapshot(crates/mcp-utils), orchestrated byMcpBuilder/McpHandle(crates/aether-core/src/mcp), with a Unix-socket deferred-tool gateway (GatewayService) as the closest prior art.rmcp3.5.0 already ships a stateless server path (StreamableHttpService+NeverSessionManager, features currently unenabed); axum 0.8.9 is the workspace version with one production usage to copy from.Plan (
docs/aether/plans/issue-574-plan.md, force-added sinceplans/is gitignored): newcrates/mcp-gatewaycrate with binaryaether-mcp-gateway, reusingMcpBuilder/McpHandlefor all upstream logic, a newHttpGatewayService(all tools model-visible,server__toolnamespacing, prompts/resources routed), served statelessly via axum + rmcp'sStreamableHttpService. Covers architecture, 8 sequenced steps with signatures/pseudo-code, testing plan, file table, and risks (notablyallowed_hostsloopback default, tower-service version check, and the dist-shipping follow-up).One question for follow-up (flagged in the plan rather than blocking): whether the new binary should eventually ship via cargo-dist or stay
dist = falselike the other auxiliary binaries.Pushed to
aether/issue-574. See the run.