Labsco
MCP SERVER

MCP Broker

by NavinAgrawal

A local broker in front of your other MCP servers: one connection per client, upstreams started and reaped on demand, and per-client profiles deciding which tools are visible at all.

MCP Plumbing: Proxies, Registries & Inspectors
Summary
The mutating-tool gate is the part worth adopting on its own.

Context reduction is the headline, and the published numbers back it. The quieter win is that write tools stay invisible unless a profile allowlist names them, which makes "this client may read but not act" a configuration rather than a hope. What you take on in exchange is real: a daemon to run and watch, and a YAML contract that is now the source of truth for every client's tool surface.

What it is

A process broker for MCP, in the mould of a connection pooler. A small daemon owns the upstream servers — starting them on demand, sharing them across sessions or isolating them when state must not be shared, and cleaning them up afterwards — while each client sees one stable local entry and a compact set of broker tools instead of the full inventory.

What you get
  • Four tools in place of every upstream tool definition: search the inventory, read one tool's schema, call it, and inspect broker state — `broker_search_tools`, `broker_describe_tool`, `broker_call_tool`, `broker_status`
  • Profile-scoped exposure, so each client gets a configured view of the upstreams rather than everything by default, with per-profile tool budgets enforced
  • Mutating-tool gates: an upstream's write tools stay hidden until a profile allowlist explicitly grants them
  • Lifecycle ownership — shared and per-session upstreams are started, watched, stopped and reaped by the broker, which is what stops orphaned MCP processes surviving a client exit
  • One place for the state that otherwise spreads across tools: OAuth, browser state, sockets, logs and cleanup, kept under a runtime directory outside the repository
  • Client config rendering with a dry run, a backup at apply time and a rollback, for Codex, Claude and AGY profiles
  • Service installation flows per platform — a macOS LaunchAgent, a Linux systemd user service, and a Windows scheduled task — each with render, install and removal steps
  • Upstreams configured as stdio, HTTP, streamable HTTP or SSE connectors, with a YAML contract validated both structurally and against a published JSON Schema
  • A published measurement of what this buys: on one Codex setup the direct MCP server entries went from 11 to 1, always-loaded tool definitions from 609 to 43, and serialized tool tokens from 276,989 to 45,281
Requirements

No account and no key — everything is local. Python 3.10 or newer available as `python3`, `make`, and Node.js with `npx` for npm-based upstream servers. macOS needs `launchctl` for the LaunchAgent path. Install the package with pipx, uv or Homebrew, which give you the same console scripts; a Docker image exists for container-friendly configs. Configuration is a private YAML file created from the bundled example — installing the package deliberately does not write your MCP client config, that stays an explicit action. The package publishes as `mcp-broker` on PyPI (2.0.0) with a client shim, a daemon and a CLI entry point.

Setup effort

One command — pipx install mcp-broker