| FMRS | 62 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 8 / 20 | 12 / 20 |
|---|
| Security and permissions | 12 / 20 | 18 / 20 |
|---|
| Maintenance | 13 / 20 | 16 / 20 |
|---|
| Documentation | 16 / 20 | 18 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 |
|---|
| Best for | - Developers and teams that need a unified, secure entry point in front of many MCP servers
- Security-conscious users worried about Tool Poisoning Attacks who want new servers quarantined by default
- AI agent users limited by context windows or client tool caps who want large token savings
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Users who want a fully cloud-hosted setup and will not run a local proxy
- Lightweight setups connecting only one or two simple MCP servers where discovery, quarantine and auditing add no value
- Environments where running a Go binary or local service is not possible
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Read and write the local config directory ~/.mcpproxy/ (mcp_config.json, certificates, activity logs)
- Listen on a local HTTP port (127.0.0.1:8080 by default)
- Spawn local stdio upstream MCP servers using the commands in your configuration
- Connect to remote HTTP upstream servers as configured, potentially including OAuth login
- If HTTPS is enabled, add a self-signed CA certificate to the system keychain via mcpproxy trust-cert
- If third-party scanners are enabled, a working Docker environment is required
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - The proxy becomes the single channel for all upstream tools, so a misconfiguration could expose tools the agent should not reach
- The proxy inspects tool arguments and responses for sensitive data, and sensitive content may end up in the local activity log
- Quarantine blocks new servers, but an already-approved server that later changes still requires re-approval (the README notes tool changes trigger blocking)
- Spawning stdio upstreams means the proxy can execute the commands in your config, so the config source must be trusted
- HTTPS uses self-signed certificates that must be manually trusted, otherwise clients fail to connect
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Cursor, Claude Desktop, VS Code, Goose | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 5 | 0 |
|---|