MIT-licensed MCP proxy server that aggregates multiple downstream MCP servers behind one HTTP service, exposing each configured server through SSE or Streamable HTTP endpoints with auth tokens and tool filtering.
tbxark MCP Proxy Server can spawn stdio subprocess MCP servers and connect to remote SSE or Streamable HTTP MCP endpoints., Every exposed route inherits the permissions of its downstream server; use per-server `authTokens` and tool filters instead of exposing all tools broadly., The docs support remote config URLs and an `--insecure` TLS flag; avoid untrusted configs and do not disable TLS verification outside controlled testing., Token-in-route fallback can expose credentials through browser history, proxy logs, metrics, and referrers; prefer authorization headers when clients support them., Logging can be enabled globally or per server, so review logs before routing secrets, prompts, tool arguments, or tool outputs.
Privacy notes
The proxy may process downstream server commands, environment variables, headers, auth tokens, remote config URLs, tool names, tool arguments, tool outputs, prompts, resources, logs, and route keys., Stdio subprocesses inherit configured environment variables and can access whatever local paths, network services, or credentials those commands can reach., Remote config files can reveal internal MCP server names, endpoint URLs, auth headers, tool filters, and secret placeholders., Keep config files, tokens, `.env` values, logs, and Docker volume mounts out of public repositories and shared support output.
Author
tbxark
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-06
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
63
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Needs review
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
No reviewed flag detected in metadata.
Pending
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
5 safety and 4 privacy notes across 2 risk areas. Review closely: credentials & tokens, network access.
2 areas
SafetyNetwork accesstbxark MCP Proxy Server can spawn stdio subprocess MCP servers and connect to remote SSE or Streamable HTTP MCP endpoints.
SafetyCredentials & tokensEvery exposed route inherits the permissions of its downstream server; use per-server `authTokens` and tool filters instead of exposing all tools broadly.
SafetyNetwork accessThe docs support remote config URLs and an `--insecure` TLS flag; avoid untrusted configs and do not disable TLS verification outside controlled testing.
SafetyCredentials & tokensToken-in-route fallback can expose credentials through browser history, proxy logs, metrics, and referrers; prefer authorization headers when clients support them.
SafetyCredentials & tokensLogging can be enabled globally or per server, so review logs before routing secrets, prompts, tool arguments, or tool outputs.
PrivacyCredentials & tokensThe proxy may process downstream server commands, environment variables, headers, auth tokens, remote config URLs, tool names, tool arguments, tool outputs, prompts, resources, logs, and route keys.
PrivacyCredentials & tokensStdio subprocesses inherit configured environment variables and can access whatever local paths, network services, or credentials those commands can reach.
PrivacyCredentials & tokensRemote config files can reveal internal MCP server names, endpoint URLs, auth headers, tool filters, and secret placeholders.
PrivacyCredentials & tokensKeep config files, tokens, `.env` values, logs, and Docker volume mounts out of public repositories and shared support output.
Safety notes
tbxark MCP Proxy Server can spawn stdio subprocess MCP servers and connect to remote SSE or Streamable HTTP MCP endpoints.
Every exposed route inherits the permissions of its downstream server; use per-server `authTokens` and tool filters instead of exposing all tools broadly.
The docs support remote config URLs and an `--insecure` TLS flag; avoid untrusted configs and do not disable TLS verification outside controlled testing.
Token-in-route fallback can expose credentials through browser history, proxy logs, metrics, and referrers; prefer authorization headers when clients support them.
Logging can be enabled globally or per server, so review logs before routing secrets, prompts, tool arguments, or tool outputs.
Privacy notes
The proxy may process downstream server commands, environment variables, headers, auth tokens, remote config URLs, tool names, tool arguments, tool outputs, prompts, resources, logs, and route keys.
Stdio subprocesses inherit configured environment variables and can access whatever local paths, network services, or credentials those commands can reach.
Remote config files can reveal internal MCP server names, endpoint URLs, auth headers, tool filters, and secret placeholders.
Keep config files, tokens, `.env` values, logs, and Docker volume mounts out of public repositories and shared support output.
Prerequisites
Go toolchain for source install, or Docker for the GHCR image deployment path.
A v2 JSON configuration file defining `mcpProxy` and downstream `mcpServers`.
Downstream MCP server commands, URLs, headers, environment variables, and secrets prepared before proxy startup.
Public base URL, bind address, route type, auth token policy, logging policy, and tool filters reviewed before exposing the proxy beyond localhost.
Schema details
Install type
cli
Troubleshooting
No
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
20 minutes
Difficulty
intermediate
Full copyable content
mcp-proxy --config ./config.json
About this resource
Content
tbxark MCP Proxy Server is a Go-based MCP aggregation proxy. It reads a JSON
configuration, starts or connects to multiple downstream MCP servers, and
exposes each configured server through a single HTTP service using SSE or
Streamable HTTP routes.
The proxy supports stdio subprocess clients, SSE clients, and Streamable HTTP
clients. Configuration can set a public base URL, bind address, proxy identity,
transport type, default options, per-server auth tokens, logging, and allow or
block tool filters.
These sources were reviewed on 2026-06-06. Prefer the live repository,
README, configuration guide, usage guide, deployment guide, Go module metadata,
and license file for current install, route, config, auth, logging, and
deployment behavior.
Features
Aggregate multiple downstream MCP servers behind one HTTP service.
Expose downstream servers through SSE or Streamable HTTP routes.
Support stdio subprocess, SSE, and Streamable HTTP downstream client types.
Configure downstream commands, arguments, environment variables, URLs, and headers.
Set proxy defaults and per-server overrides for logging, auth tokens, and startup validation.
Allowlist or blocklist exposed tools per downstream server.
Fetch configuration from a local file or remote config URL.
Deploy from source with Go or run the GHCR container image with a mounted config.
Convert Claude-style MCP configs with the project's hosted converter.
Installation
Install from source with Go:
go install github.com/tbxark/mcp-proxy@latest
Then run the proxy with a local configuration file:
mcp-proxy --config ./config.json
The Docker image can also run with a mounted config file:
docker run -d -p 9090:9090 -v ./config.json:/config/config.json ghcr.io/tbxark/mcp-proxy:latest
For each downstream server key, clients use the generated route based on
mcpProxy.baseURL and the selected proxy type. For example, a fetch server
uses a /fetch/sse route for SSE mode or a /fetch/mcp route for Streamable
HTTP mode.
Use Cases
Expose a small team-approved set of MCP servers behind one HTTP entrypoint.
Move local stdio MCP servers into a managed proxy process.
Give clients one base URL while keeping per-server routes and tool filters.
Require a token for each downstream server route.
Disable risky tools from a broad MCP server before exposing it to agents.
Deploy an MCP proxy container that can launch npx and uvx servers.
Serve remote configs for repeatable deployments when the config source is trusted.
Safety and Privacy
tbxark MCP Proxy Server is only as safe as its config and downstream servers.
Review each command, URL, header, environment variable, and enabled tool before
exposing a route. Prefer explicit per-server tokens and allowlists for high-risk
servers that can write files, call cloud APIs, modify databases, or run shell
commands.
Avoid the --insecure flag outside controlled testing. Be careful with remote
config URLs because whoever controls the config can change the downstream
servers, exposed tools, headers, tokens, and logging behavior. If a client
cannot set headers and you embed a token in the route path, treat that URL as a
secret because it can leak through logs and history.
The proxy can see prompts, tool arguments, tool outputs, downstream resources,
auth tokens, headers, environment variables, config contents, and logs. Keep
config files, tokens, remote config credentials, Docker mounts, and logs out of
public repositories.
Duplicate Check
No tbxark/mcp-proxy source entry or tbxark MCP Proxy Server entry was found in
content/mcp. The existing sparfenyuk/mcp-proxy entry is a distinct
transport bridge for stdio, SSE, and Streamable HTTP conversion rather than this
multi-server aggregation proxy.
Show that tbxark MCP Proxy Server is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/mcp/tbxark-mcp-proxy-server)
How it compares
tbxark MCP Proxy Server side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
MIT-licensed MCP proxy server that aggregates multiple downstream MCP servers behind one HTTP service, exposing each configured server through SSE or Streamable HTTP endpoints with auth tokens and tool filtering.
Open-source AI gateway that can connect to downstream MCP servers and expose their aggregated tools through a single HTTP or SSE MCP endpoint for Claude Desktop, Cursor, and other MCP clients.
Apache-2.0 agentic proxy that can expose stdio, HTTP, SSE, and Streamable HTTP MCP servers through a managed gateway with federation, OAuth/JWT authentication, RBAC/CEL policy, CORS, TLS, observability, and Kubernetes Gateway API support.
✓tbxark MCP Proxy Server can spawn stdio subprocess MCP servers and connect to remote SSE or Streamable HTTP MCP endpoints.
Every exposed route inherits the permissions of its downstream server; use per-server `authTokens` and tool filters instead of exposing all tools broadly.
The docs support remote config URLs and an `--insecure` TLS flag; avoid untrusted configs and do not disable TLS verification outside controlled testing.
Token-in-route fallback can expose credentials through browser history, proxy logs, metrics, and referrers; prefer authorization headers when clients support them.
Logging can be enabled globally or per server, so review logs before routing secrets, prompts, tool arguments, or tool outputs.
✓Bifrost can expose all selected downstream MCP tools through one `/mcp` gateway endpoint, so treat the endpoint like an access layer for every connected tool.
The docs state that default LLM tool calls are suggestions until an explicit tool execution API call is made, but agent mode can enable configured automatic execution.
Gateway-mode auto-approval is controlled by the external MCP host, such as Claude Desktop, Cursor, Cline, or a custom client, not by Bifrost's `tools_to_auto_execute` setting.
Stdio connections spawn local commands inside the Bifrost runtime; Docker deployments need images that include the requested executables.
Use virtual keys, per-tool allowlists, auth headers, OAuth, per-user credentials, and network controls to limit which clients can reach high-impact tools.
✓MetaMCP can start, aggregate, and expose multiple downstream MCP servers through a single managed endpoint.
Public endpoints and public API keys can expose tool surfaces broadly if bootstrap settings or UI registration controls are left permissive.
The README notes that APP_URL and CORS settings must match the URL used to access the service.
Stdio-only clients generally need a proxy such as `mcp-proxy` to reach MetaMCP's remote endpoints.
Rate limits, endpoint ownership, namespace visibility, OIDC, and registration controls should be configured before production use.
✓Agentgateway can aggregate and expose many downstream MCP targets through one endpoint; every target's permissions become part of the gateway surface.
Stdio targets are spawned by the gateway process, so commands such as package runners or containers inherit the gateway host's trust boundary.
Demo configs use permissive CORS and local authorization servers; lock down origins, headers, issuers, audiences, JWKS, and resource metadata before production use.
CEL/RBAC policies can inspect MCP tool names, arguments, results, prompts, resources, request bodies, JWT claims, API keys, and backend metadata; test policies before relying on them.
Remote MCP proxying, OAuth provider adaptation, Kubernetes routing, TLS termination, and guardrails are infrastructure changes that should go through normal security review.
Privacy notes
✓The proxy may process downstream server commands, environment variables, headers, auth tokens, remote config URLs, tool names, tool arguments, tool outputs, prompts, resources, logs, and route keys.
Stdio subprocesses inherit configured environment variables and can access whatever local paths, network services, or credentials those commands can reach.
Remote config files can reveal internal MCP server names, endpoint URLs, auth headers, tool filters, and secret placeholders.
Keep config files, tokens, `.env` values, logs, and Docker volume mounts out of public repositories and shared support output.
✓Bifrost may process provider prompts, model responses, MCP tool names, tool arguments, tool results, headers, virtual keys, OAuth tokens, per-user credentials, logs, traces, metrics, and downstream server metadata.
Per-user auth stores credentials against a signed-in user, virtual key, or session identity; review credential lifecycle, revocation, and orphaned-session behavior.
Logs, config stores, provider settings, MCP sessions, and gateway analytics can contain sensitive operational or user data.
Keep real provider keys, virtual keys, OAuth secrets, MCP endpoint URLs, and upstream service credentials in environment variables or secret stores, not committed config.
✓MetaMCP can receive prompts, tool names, tool arguments, resource data, downstream MCP responses, endpoint metadata, API keys, OAuth tokens, user identifiers, and logs.
Downstream stdio server environment variables may include secrets that are resolved from the MetaMCP container environment.
Postgres persistence, file logs, bootstrap configuration, API keys, namespace definitions, and endpoint settings may retain sensitive operational data.
Do not commit real `.env` files, bootstrap passwords, API keys, OIDC secrets, downstream service credentials, or exported gateway configs.
✓MCP requests, tool arguments, tool results, prompt names, resource names, session IDs, JWT/API-key claims, raw request/response bodies, logs, traces, and telemetry may pass through the gateway.
CEL policy and observability features may buffer or inspect request and response bodies depending on configuration.
OAuth/JWT metadata, bearer tokens, API keys, DCR secrets, Keycloak/Auth0/Okta settings, and upstream MCP credentials must be protected as secrets.
Any data returned by downstream MCP tools can still be sent onward by the MCP client to the configured model provider.
Prerequisites
Go toolchain for source install, or Docker for the GHCR image deployment path.
A v2 JSON configuration file defining `mcpProxy` and downstream `mcpServers`.
Downstream MCP server commands, URLs, headers, environment variables, and secrets prepared before proxy startup.
Public base URL, bind address, route type, auth token policy, logging policy, and tool filters reviewed before exposing the proxy beyond localhost.
Node.js with `npx`, Docker, or another supported Bifrost Gateway deployment path.
Bifrost Gateway version `v1.4.0-prerelease1` or newer for MCP gateway mode.
Downstream MCP server commands or HTTP/SSE endpoint URLs prepared before registering clients.
Provider API keys, virtual keys, gateway auth settings, and governance policies reviewed before sharing the endpoint.
Docker and Docker Compose available for the recommended deployment.
Postgres storage, app URL, CORS, bootstrap users, API keys, and registration settings reviewed before first start.
Downstream MCP server commands, environment variables, and secrets prepared for the MetaMCP container runtime.
[object Object]
Agentgateway binary, container image, or source checkout from the upstream release/container/docs path.
At least one downstream MCP target, such as a stdio command, remote MCP server, SSE server, or Streamable HTTP server.
MCP client that can connect to the exposed Streamable HTTP or SSE route.
Auth, CORS, TLS, route, and policy configuration reviewed before shared or remote exposure.