MCP Funnel

A funnel is a local MCP endpoint at http://127.0.0.1:5559/mcp/<slug> that pools several MCP servers and exposes a subset of what they offer. Point one funnel at each agent.

Off by default — enable it with Enable MCP funnel on the MCP Funnel tab. While off, every path under /mcp returns 404.

1. Add sources#

A source is one MCP server the funnel can draw from:

Kind	What it is
Route (credentialed)	An MCP server reached through one of your routes. The OAuth token is attached automatically.
API bridge	One of your own API to MCP bridges. Its tools join the funnel like any other source's, and the credential is attached one hop further along, by the route the bridge calls.
URL (no auth)	Any MCP server needing no credential.

An API bridge source needs both switches on: the funnel's, and Enable API bridges on the API to MCP tab.

Press Refresh on a source to connect and read what it offers. The status column reports the result, or the reason it could not be reached.

2. Create a funnel#

Give it a name and an endpoint slug. The full URL appears in the grid, selectable and ready to paste.

3. Choose what it exposes#

Select the funnel, tick the sources it pools, then per source and per kind (tools, resources, prompts):

Mode	Behaviour
All	Everything, including whatever the server gains later.
Include	Only what is ticked. A tool added upstream later stays hidden until you pick it.
Exclude	Everything except what is ticked. A tool added later is exposed immediately.

Use Include to grant a known set, Exclude to revoke a few from an otherwise trusted server.

Edits apply on the agent's next call — no reconnect, no restart.

Tool naming#

Every name is prefixed with its source's alias: create_issue from a source aliased gh reaches the agent as gh__create_issue. Resources are rewritten to funnel://gh/<original-uri> and mapped back on read.

Prefixing is unconditional by design. Prefixing only on collision would rename a tool the day you add an unrelated source, breaking every agent prompt that referenced it.

Pointing an agent at a funnel#

{
  "servers": {
    "my-agent": {
      "url": "http://127.0.0.1:5559/mcp/my-agent",
      "headers": { "X-Proxy-Key": "<this-funnel's-key>" }
    }
  }
}

Each funnel has its own proxy key — no route's key opens it, and no other funnel's does. Select the funnel to copy its key.

The key must go in the X-Proxy-Key header. An MCP client that cannot set request headers cannot reach a funnel — see Calling the proxy.

Behaviour#

Endpoints are independent. Two funnels drawing on the same upstream hold separate MCP sessions, so one agent cannot perturb another and one expired session cannot take both down.
Calls run in parallel, across endpoints and within one.
A dead source degrades only itself — the healthy sources still list, and the failure is shown on that source's row and in the log.
Filtering is enforced on the call path, not just the listing. A tool an agent learned before you unticked it is refused, and the call never reaches the upstream.
Arguments are never logged. Tool names and outcomes are; the values an agent passes are not.
/mcp is reserved, and a request that already passed through a funnel is refused rather than allowed to loop.

Limits#

Sources must be HTTP MCP servers. Local stdio servers (npx …) are not supported.
Sampling, elicitation, and resource subscriptions are not offered on a funnel endpoint — it runs stateless, which is what makes edits take effect on the next call.
Two agents on the same funnel share its upstream sessions. Give each agent its own funnel if they must be isolated.
A route-backed source that keys sessions on a cookie rather than the standard Mcp-Session-Id header cannot hold a session: Cookie is stripped on the way upstream, deliberately, so a caller cannot launder its own credentials through the proxy.

Edit this page on the wiki Request support · Report vulnerabilities privately