MCPProxy: One Local Endpoint in Front of Every MCP Server

The problem MCPProxy actually addresses

Model Context Protocol clients have hard ceilings on how many tools they will load. The README names two: Cursor's 40-tool limit and OpenAI's 128-function cap. Past that, tools silently disappear from the model's view, and every schema you do load is paid for in context tokens on every request. MCPProxy sits between the client and the servers and presents a single endpoint, so the client sees one `retrieve_tools` function and asks for tools by description rather than enumerating all of them.

The second problem is trust. An MCP server is executable code that hands tool descriptions to a model, and a malicious or compromised server can describe a tool in a way that makes the model call it. MCPProxy's answer is quarantine: a newly added server is blocked until a human approves it. The README describes this as protection against Tool Poisoning Attacks. That framing is honest about the threat model, which is that the server, not the user, controls the text the model reads.

The audience is anyone running several MCP servers in an agent workflow and finding the tool list unmanageable, or anyone who wants an audit record of what the agent called. The repository lists audit-logging and tool-routing among its topics, and the demo screenshot shows an activity log with sensitive-data detection.

Federation, BM25 routing and the quarantine gate

The core is a Go binary. It speaks MCP to the client on one side and to each configured server on the other, which is why the repository carries `github.com/mark3labs/mcp-go` as a dependency. Tool discovery is indexed rather than enumerated: `github.com/blevesearch/bleve/v2` is a full-text search library, and the project's topics include bm25, so `retrieve_tools` is a ranked search over indexed tool descriptions, not a linear scan. That is the mechanism behind the token claim. The README cites a figure of roughly 99 percent token reduction with a 43 percent accuracy improvement and attributes it to research, without naming the study, so treat the number as a claim to reproduce on your own tool set rather than a specification.

State lives locally. `go.etcd.io/bbolt` is an embedded key-value store, and the project describes itself as local-first, so configuration, quarantine state and the audit trail sit in a local file rather than a hosted service. `github.com/zalando/go-keyring` suggests secrets go to the OS keychain instead of a plain config file. If you need a central proxy that many developers share, that local-first choice is the first thing to examine.

Security scanning is pluggable. The README says you can run Snyk, Semgrep, Trivy, Cisco and other Docker-based scanners against a quarantined server before approving it, and that findings are normalized to SARIF with a composite risk score. The dependency list includes `github.com/santhosh-tekuri/jsonschema/v6`, which is consistent with validating scanner output against a schema. Because the scanners are Docker-based, the scanning path requires a working Docker daemon on the host, which is a real deployment constraint the README does not discuss in the install section.

The HTTP surface uses `github.com/go-chi/chi/v5` and `github.com/golang-jwt/jwt/v5`, and the Dockerfile exposes port 8080. The web UI is embedded in the binary, so there is no separate frontend service to run. The macOS menu-bar app is optional and built on `fyne.io/systray`.

Installing MCPProxy and adding a first server

On macOS the README recommends the DMG installer or the Homebrew cask, which installs the menu-bar app and bundles the CLI. The formula is the headless CLI only. Both update through `brew upgrade`.

brew install --cask smart-mcp-proxy/mcpproxy/mcpproxy

On Debian and Ubuntu the project publishes an apt repository. The README gives the keyring and source list setup, then a single install command, and says the package ships a hardened systemd unit and starts the service automatically. Auto-updates come through `apt upgrade`.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://apt.mcpproxy.app/mcpproxy.gpg \
  | sudo tee /etc/apt/keyrings/mcpproxy.gpg > /dev/null
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/mcpproxy.gpg] https://apt.mcpproxy.app stable main" \
  | sudo tee /etc/apt/sources.list.d/mcpproxy.list > /dev/null
sudo apt update && sudo apt install mcpproxy

Fedora and the RHEL family use a dnf repository instead. The README notes that Fedora 41 and later use dnf5 and gives a different command for adding the repo file.

sudo dnf config-manager --add-repo https://rpm.mcpproxy.app/mcpproxy.repo
sudo dnf install -y mcpproxy

For containers, the repository Dockerfile builds a server-edition binary with the `server` build tag and runs it from a distroless static image. The entrypoint is fixed, and the container listens on 8080.

mcpproxy serve --listen 0.0.0.0:8080

After the service is up, the README points to the embedded web UI for the server dashboard, tool discovery, activity log and quarantine screen. The first real task is adding a server and watching it land in quarantine rather than becoming immediately callable. The README does not document the exact configuration key for adding a server in the excerpt available, so open the web UI and use its server-add flow rather than hand-editing a file you have not seen the schema for.

Where MCPProxy gets in the way

Quarantine is a manual gate, and that is the point, but it also means every new server is a blocking step in someone's workflow. If you add servers often, or if you run MCPProxy in CI where no human is present to approve, the gate becomes an obstacle rather than a control. The README does not document a programmatic approval path or a policy file for pre-approving known servers, and it does not document rollback of an approval. That silence matters if you plan to automate.

The plugin scanners require Docker. On a host where Docker is unavailable, or where the proxy runs in a distroless container without a mounted socket, the scanning half of the security story is unavailable even though the binary installs fine. The README presents scanning as a feature of the product without stating this prerequisite in the install section.

The token-reduction figure comes from research the README does not cite. Routing quality depends entirely on how well your tool descriptions match the queries the model generates, and BM25 is a lexical ranker: a tool whose description uses different vocabulary than the model's request can rank poorly. Projects with many similarly named tools are the case to test first.

Finally, this is the wrong tool if you only need to convert a stdio MCP server into HTTP. Several of the related searches point at exactly that narrower job, and a full federation layer with quarantine, an audit store and a web UI is more machinery than a transport bridge needs. The README also does not document how the embedded web UI is authenticated or whether it binds to loopback only, which is something to confirm before exposing the host.

How it differs from the smaller mcp-proxy projects

The related searches surface several projects with similar names, and the difference is scope. A typical `mcp-proxy` in the wild is a transport adapter: it takes a stdio-based MCP server and republishes it over HTTP or SSE, sometimes with an API key in front. That is a single-server, single-concern tool, and it is the right size for the job of reaching a local server from a remote client.

MCPProxy starts from the opposite end. It assumes you have many servers and that the client cannot hold them all. Federation, the BM25 tool index, the quarantine state machine and the audit log are all consequences of that assumption. The transport bridging still happens, but it is incidental.

The practical difference shows up in what you configure. A transport adapter needs a command line and a port. MCPProxy needs a server inventory, an approval decision per server, and a place for its local state to live. If you cannot describe a reason to keep that inventory, the smaller tool is the better fit.

The other axis is language and packaging. This project is Go, ships a single static binary, and publishes apt, dnf, Homebrew and Docker distribution channels plus a Windows installer that adds itself to PATH. That packaging breadth is unusual among the smaller proxies and is a genuine reason to pick it if you have to deploy to a mixed fleet.

Maintenance, licensing and what upgrades cost

The repository is not archived, and the last push was on 2026-09-17, the same day as the v0.67.0 release. Release cadence is fast: v0.66.0 on 2026-09-12, v0.66.1 on 2026-09-13, v0.67.0 on 2026-09-17. That pace is good for fixes and bad for anyone who wants a quiet dependency. The version numbers are still in the 0.6x range, so expect configuration or state format changes between minor releases; check CHANGELOG.md before upgrading rather than assuming compatibility.

Upgrade mechanics differ by channel. Homebrew handles both the cask and the formula through `brew upgrade`. The apt and dnf repositories update with the system package manager, which also means the systemd unit is replaced on upgrade. The Windows installer supports silent installation with `/VERYSILENT`, which is what you would script. The repository contains an AUTOUPDATE.md file, so the binary appears to have a self-update path as well; the README excerpt does not describe it, and you should read that file before enabling it on a managed host.

Licensing is MIT. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It also means the project offers no warranty and no patent grant, unlike Apache-2.0. If your legal team cares about an explicit patent grant or about a contributor licence agreement, MIT without a CLA is the gap to raise. None of this is legal advice; read the LICENSE file in the repository.

Editorial conclusion

Adopt MCPProxy if you run more than a handful of MCP servers and want one audited endpoint, quarantine on new servers, and a single retrieve_tools function instead of a wall of schemas. Skip it if you run one or two servers you wrote yourself, or if you need a stdio-to-HTTP bridge only, since several smaller proxies do that and nothing else. Before rolling it out, verify two things yourself: how the quarantine approval flow behaves in your client, and whether the embedded web UI binds to a port you are willing to expose. The apt and dnf packages start a systemd unit automatically, so check what that unit listens on before you install it on a shared host.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. smart-mcp-proxy/mcpproxy-go on GitHub