Skip to content

Extract an axum http mcp gateway #574

Closed

Description

@jcarver989

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

  1. Stateless http gateway
  2. Aggregate N upstream http mcps (tools, prompts...etc)
  3. Upstream mcps are authenticated using std authorization headers with API tokens (no human oauth flow for now)

Out of scope would be:

  1. Progressive tool discovery (already supported in aether's harness, so no need to duplicate

Activity

  1. added
    size:LLarge change requiring an implementation plan
    assign-agentApply after an optional size:S/M/L label to assign the issue to Aether
    on Oct 6, 2026
  2. contextbridge-pr-automation commented on Oct 6, 2026

    @contextbridge-pr-automation
    Contributor

    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.

    Pushed to aether/issue-574. See the run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    assign-agentApply after an optional size:S/M/L label to assign the issue to Aethersize:LLarge change requiring an implementation plan

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions