Skip to main content
mcpSource-backed

tbxark MCP Proxy Server

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.

by tbxark · submitted by oktofeesh1·added 2026-06-06·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://github.com/tbxark/mcp-proxy/blob/master/README.md, https://github.com/tbxark/mcp-proxy
Brand
MCP Proxy Server
Brand domain
github.com
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.
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.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

CLI install

Copy-ready — paste the snippet to get started.

20 minutes

Adoption plan

Balanced adoption plan

Current risk score 24/100. Use staged verification before broader rollout.

Risk 24

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    No review metadata found; increase manual validation.

    Pending
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Missing required evidence: Metadata review. Risk score 31.

Risk 31

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Missing

Review metadata is missing.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required gaps: Metadata review

Decision timeline

Decision timeline · balanced

Blocking gaps: Check metadata review status. Risk 28.

Risk 28

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is missing.

Pending

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

Blockers: Check metadata review status

Prerequisite readiness

Prerequisite readiness

4 prerequisites to line up before setup. Have accounts and credentials ready first.

0/4 ready
Account & credentials1Install & runtime1Network & hosting220 minutes

Safety & privacy surface

Safety & privacy surface

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.

Source Review

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.

Source citations

Add this badge to your README

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.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/mcp/tbxark-mcp-proxy-server.svg)](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.

Field

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 dossier

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.

Open dossier

Docker-deployed MCP gateway that aggregates downstream MCP servers into namespaces, endpoints, SSE, Streamable HTTP, OpenAPI, auth, and rate limits.

Open dossier

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.

Open dossier
Next steps
Trust
Review statusNot reviewedNot reviewedNot reviewedNot reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
Submitteroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandBifrost logoBifrostMetaMCP logoMetaMCPagentgateway logoagentgateway
Categorymcpmcpmcpmcp
SourceSource-backedSource-backedSource-backedSource-backed
Authortbxarkmaximhqmetatool-aiagentgateway
Added2026-06-062026-06-062026-06-052026-06-06
Platforms
Harness
Source repo
Safety notestbxark 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 notesThe 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.
Install
go install github.com/tbxark/mcp-proxy@latest
npx -y @maximhq/bifrost
git clone https://github.com/metatool-ai/metamcp.git && cd metamcp && cp example.env .env && ${EDITOR:-vi} .env
docker pull ghcr.io/agentgateway/agentgateway
Config
{
  "mcpProxy": {
    "baseURL": "MCP_PROXY_BASE_URL",
    "addr": ":9090",
    "name": "MCP Proxy",
    "version": "1.0.0",
    "type": "streamable-http",
    "options": {
      "authTokens": [
        "REPLACE_WITH_PROXY_TOKEN"
      ]
    }
  },
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": [
        "mcp-server-fetch"
      ],
      "options": {
        "toolFilter": {
          "mode": "allow",
          "list": [
            "fetch"
          ]
        }
      }
    }
  }
}
{
  "mcpServers": {
    "bifrost": {
      "url": "BIFROST_MCP_URL",
      "headers": {
        "Authorization": "Bearer ${BIFROST_VIRTUAL_KEY}"
      },
      "type": "http"
    }
  }
}
{
  "mcpServers": {
    "metamcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy",
        "--transport",
        "streamablehttp",
        "METAMCP_ENDPOINT_MCP_URL"
      ],
      "env": {
        "API_ACCESS_TOKEN": "${METAMCP_API_KEY}"
      }
    }
  }
}
{
  "mcpServers": {
    "agentgateway": {
      "url": "LOCAL_AGENTGATEWAY_MCP_URL",
      "headers": {
        "Authorization": "Bearer AGENTGATEWAY_MCP_TOKEN"
      }
    }
  }
}
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.