MCPProxy: MCP Server Access, Discovery, Isolation, Quarantine

Overview

MCPProxy is a gateway for interacting with MCP (Model Context Protocol) server networks and the ecosystem of MCP-compatible tools. It provides a central access point that discovers available MCP servers, exposes their tools through a consistent API, and enforces runtime isolation and quarantine policies to reduce risk from untrusted or unknown tools.

For developers and platform operators, MCPProxy simplifies managing large, distributed tool fleets: it can automatically discover MCP servers, route requests to appropriate tool runtimes, run tools inside isolated sandboxes (containers or constrained processes), and quarantine tools that violate safety or policy checks. This makes it straightforward to integrate MCP tool networks into CI pipelines, research environments, and production systems with stronger safety and governance controls.

Features

• Automatic discovery of MCP servers and their registered tools
• Unified API and proxying layer for interacting with distributed MCP toolsets
• Isolated runtimes for executing tools in containers or restricted processes
• Automatic quarantine of tools flagged as malicious, unverified, or policy-violating
• Pluggable authentication and per-server credentials
• Runtime and execution policy configuration (timeouts, resource limits)
• Audit logging and telemetry for tool execution and quarantine events
• Config-driven deployment with support for Docker or native Go binaries

Installation / Configuration

Install the binary with Go (recommended for development) or run via Docker for production:

Install with Go:

# requires Go 1.18+
go install github.com/smart-mcp-proxy/mcpproxy-go/cmd/mcpproxy@latest

# run default
mcpproxy --config ./config.yaml

Run using Docker:

docker run -p 8080:8080 \
  -v $(pwd)/config.yaml:/etc/mcpproxy/config.yaml:ro \
  ghcr.io/smart-mcp-proxy/mcpproxy-go:latest \
  --config /etc/mcpproxy/config.yaml

Example config.yaml (minimal)

# config.yaml
server:
  listen_addr: ":8080"
  api_key: "replace-with-secret"

discovery:
  refresh_interval: 30s
  known_servers:
    - name: my-mcp
      url: https://mcp.example.com
      token: "server-token"

runtime:
  engine: "docker"          # or "native"
  default_image: "mcp-runtime:latest"
  max_exec_time: 60s
  memory_limit: "256mb"

quarantine:
  enabled: true
  auto_quarantine: true
  quarantine_path: "/var/lib/mcpproxy/quarantine"
  allowlist: ["trusted-tool-id-1"]

Sample CLI to list discovered tools (after the proxy is running):

curl -H "Authorization: Bearer replace-with-secret" \
  http://localhost:8080/v1/tools

Available Tools

MCPProxy is agnostic to tool types; it discovers and proxies whatever tools the connected MCP servers expose. Typical categories you will see:

Example JSON response from the /v1/tools API:

[
  { "id": "tool-123", "name": "python-runner", "server": "my-mcp", "status": "allowed" },
  { "id": "tool-456", "name": "web-scraper", "server": "public-mcp", "status": "quarantined" }
]

You can extend the tool registry by adding MCP servers to the discovery list; MCPProxy will merge discovered tool manifests into its API.

Use Cases

• Secure third-party tool execution

  • Scenario: a CI job needs to run a community-provided test tool. Configure MCPProxy to route that tool into a container runtime, enforce a 60s CPU/memory limit, and quarantine it automatically if it tries to access the host filesystem.
  • Steps:
    1. Add the MCP server URL to config.yaml discovery.
    2. Enable runtime.engine=docker and set resource limits.
    3. Execute the tool via the proxy API; the proxy starts the tool in an isolated container.

• Federated tool discovery for research clusters

  • Scenario: multiple research groups host their own MCP servers. MCPProxy aggregates their tool catalogs so a single API can discover and call tools across the federation with centralized access control and auditing.

• Safety-first deployments

  • Scenario: enterprise wants to permit model-augmented tools but must block data exfiltration. Enable quarantine.auto_quarantine and set allowlists. Suspicious tools are automatically moved to quarantine and flagged for review.

• Developer local environment

  • Scenario: developers want to test an experimental MCP tool locally without risking their machine. Run MCPProxy locally with runtime.engine=native or lightweight containers; developers can call the tool through the proxy and inspect logs and quarantine actions.

Best practices

• Use separate credentials for each MCP server and rotate tokens regularly.
• Start with conservative resource limits and quarantine enabled, then relax policies as tools are validated.
• Integrate proxy audit logs with your observability stack (ELK, Prometheus) to track execution and quarantine decisions.
• Maintain an allowlist of vetted tool IDs and use labels/metadata to automate safe classification.

For source code, advanced configuration options, and contribution guidelines, see the project repository: https://github.com/smart-mcp-proxy/mcpproxy-go.