Skip to main content
Glama

mcp-broker

mcp-broker routing backbone brand header

mcp-broker is a local Model Context Protocol process broker for MCP clients.

Think PgBouncer for MCP: one stable local endpoint in front of many upstream MCP servers. The broker owns upstream startup, reuse, cleanup, profile exposure, status, and safe tool routing.

The core idea is simple: do not make every agent session load every upstream tool definition before the user asks a task.

Why this exists

AI coding sessions with many MCP servers tend to accumulate the same problems:

  • every client config repeats the same MCP server list

  • every new session can start duplicate upstream processes

  • OAuth, browser state, local files, and database handles spread across tools

  • raw tool lists consume context before the task begins

  • hosted connector caches can duplicate local MCP tools

  • orphaned MCP processes survive after client sessions exit

mcp-broker puts a small broker facade in front of those upstreams. It is not a hosted workflow builder; it is local infrastructure for keeping MCP clients small, predictable, and under one config contract.

Client profile
        |
        | one local MCP entry
        v
  mcp-broker-client
        |
        | Unix socket
        v
  mcp-broker-daemon
        |
        | profile gates, namespace routing, status, cleanup
        v
  upstream MCP servers

The client sees a small set of broker tools:

broker_search_tools
broker_describe_tool
broker_call_tool
broker_status
broker_close_session

The upstream MCPs still exist. They are discovered and called through the broker when a task needs them.

Related MCP server: MCP Manager

Measured context reduction

On 2026-05-24, the measured Codex setup went from many raw MCP and hosted app tool definitions to one broker facade plus a pruned codex_apps cache.

Surface

Before

After

Reduction

Direct Codex MCP server entries

11

1

90.91%

MCP tool definitions

414

4

99.03%

Hosted codex_apps tool definitions

195

39

80.00%

Combined always-loaded tool definitions

609

43

92.94%

Combined serialized tool payload bytes

1,026,171

185,877

81.89%

Combined o200k_base tool tokens

276,989

45,281

83.65%

The 92.94% number is a tool-definition count reduction. The 83.65% number is a token reduction for canonical serialized tool payloads measured with tiktoken o200k_base.

See docs/context-reduction-measurement.md for evidence and caveats.

What it does

  • Runs one local broker daemon over a Unix socket.

  • Exposes one lightweight stdio client shim to MCP clients.

  • Starts upstream MCP servers on demand.

  • Reuses shared upstreams across sessions when configured.

  • Isolates per-session upstreams when state must not be shared.

  • Maps upstream tools into stable namespaces.

  • Exposes compact search, describe, call, status, and caller-bound session-close tools.

  • Enforces profile-level tool budgets and exposure gates.

  • Blocks mutating upstream exposure unless a profile allowlist grants it.

  • Stores runtime state under $HOME/mcp/mcp-broker, outside the repo.

  • Renders MCP client config entries with dry-run, backup, and rollback.

  • Provides LaunchAgent install and uninstall flows for macOS.

  • Provides Linux systemd user-service render, install, unload, and removal flows.

  • Provides Windows PowerShell Scheduled Task render, install, and removal flows.

  • Includes unit, journey, live, and e2e tests through Makefile targets.

Core differentiators:

  • Profile-scoped exposure: each MCP client gets a configured view of upstreams instead of every tool by default.

  • Mutating-tool gates: mutating upstreams stay hidden until a profile allowlist grants access.

  • Lifecycle ownership: shared and per-session upstreams are started, watched, stopped, and reaped by the broker.

  • Client parity checks: rendered profiles can be validated through the same compact broker facade before config is applied.

Who this is for

Use mcp-broker if you:

  • use Codex, Claude Code, AGY CLI, or other MCP clients

  • have more MCP tools than you want in every session

  • need shared local MCP servers without duplicate process startup

  • want one place for OAuth state, browser state, sockets, logs, and cleanup

  • need per-client profiles instead of the same tool list everywhere

  • want a small broker facade instead of raw upstream tool dumps

This repo is not an enterprise MCP control plane. It is local desktop infrastructure for developer-agent workflows.

Current status

Implemented:

  • YAML config loading from config/broker.private.yaml, created from config/broker.example.yaml.

  • Strict YAML contract validation for runtime, clients, profiles, upstreams, and policy blocks.

  • Public JSON Schema validation through config/broker.schema.json.

  • Runtime path derivation from runtime.root.

  • Tool namespace mapping from configured upstream prefixes.

  • Local upstream subprocess lifecycle management and process-group cleanup.

  • Broker daemon over Unix socket.

  • MCP client shim and renderers for configured MCP client profiles, including Codex, Claude, and AGY.

  • AGY profile rendering to .gemini/config/mcp_config.json, including its MCP allowed-server policy.

  • Dry-run client config rendering, apply-time backups, and rollback.

  • LaunchAgent render and install scripts with dry-run defaults.

  • Compact broker facade for search, describe, call, status, and caller-bound session close.

  • Profile validation from YAML smoke probes.

  • Discovery parity checks between compact client profiles.

  • Public and maintainer quality gates through Makefile targets.

  • Shared-runtime guardrail contracts through P3.8 E2E proof while hosted execution remains disabled by default.

Wiring status:

  • Codex is wired through the broker.

  • Claude is wired through the broker after profile validation and manual /mcp acceptance.

  • AGY is wired through the broker by rendering .gemini/config/mcp_config.json.

Public release status:

  • The repo is designed to stay public-safe.

  • Private upstream inventory, account paths, OAuth state, secrets, sockets, logs, and generated client configs stay outside git.

  • Stable release metadata is validated by make release-version-check; publication proof is tracked in docs/distribution.md.

  • Docker image support is available for container-friendly configs. Docker MCP Catalog submission still requires Docker review.

  • MCPB metadata is present at mcpb/manifest.json for local directory review.

See ROADMAP.md for public-facing release work.

Architecture

mcp-broker has three runtime layers:

Layer

Responsibility

Client shim

Presents one stdio MCP server entry to each MCP client and forwards JSON-RPC over the broker socket.

Broker daemon

Owns profile gates, namespace routing, upstream lifecycle, status, logging, and cleanup.

Upstream MCP servers

Run as configured stdio, HTTP, streamable HTTP, or SSE connectors with shared or per-session process policy.

The config file is the contract. Profiles decide exposure, upstreams define transport and lifecycle behavior, and smoke probes define safe read calls for validation.

Comparison

Approach

Best fit

Tradeoff

Raw MCP client config

Small setups with a few tools.

Every session loads the full tool list and each client repeats config.

Simple MCP proxy

Forwarding one server to one client.

Does not own upstream lifecycle, profile budgets, or cross-client cleanup.

Hosted app connectors

SaaS tools managed by the client provider.

Local MCP state and cross-client parity remain outside user control.

mcp-broker

Local developers with many upstream MCPs across MCP clients.

Adds a local daemon and config contract that must be installed and monitored.

Screenshots Or GIF

The quickstart flow should look like this:

mcp-broker quickstart terminal

make config-init
make config-validate
make broker-status
make codex-facade-smoke

In an MCP client, /mcp should show one mcp-broker entry. Use broker_status to inspect profile-visible upstream state.

Quickstart

Prerequisites:

  • macOS with launchctl for LaunchAgent use.

  • Python 3.10 or newer available as python3.

  • make.

  • Node.js and npx for npm-based upstream MCP servers.

  • A clone of this repo.

Package installs:

pipx install mcp-broker
uv tool install mcp-broker
brew tap ${HOMEBREW_TAP_REF}
brew install mcp-broker

Homebrew installs the same console scripts as the Python package. Package installs do not write MCP client config; client wiring stays an explicit Makefile action.

Docker is for container-friendly configs:

docker build -t mcp-broker:local .
docker run --rm -i mcp-broker:local

Local stdio clients and MCPB-style installs use the package-owned lifecycle:

mcp-broker stdio --init-if-missing

Create the local venv, install dependencies, and verify runtime layout:

make setup

Create private config from the public template:

make config-init

config-init creates the destination directory when needed and copies the public template as the starting point. It does not import local MCP inventory, user paths, or secrets.

Edit config/broker.private.yaml for local upstreams. Keep secret values out of config. Use environment variable names or files under:

$HOME/mcp/mcp-broker/secrets/

Run the quality gate:

make quality-gate

Validate the configured YAML contract:

make config-validate

Start the broker:

make broker-start

Check status:

make broker-status

For the full install flow, see docs/install.md. For a clone-to-running adoption flow, see docs/adoption-guide.md#clone-to-running-path. For shared-runtime boundaries, see docs/shared-runtime-guardrails.md. P3.8 E2E proof covers tenant isolation, authz denial, quota denial, session affinity, audit events, rollback, degraded mode, local-only routing, and shared-eligible routing. Hosted execution remains unsupported in the public local broker.

Runtime layout

Default runtime root:

$HOME/mcp/mcp-broker/
|- backups/
|- logs/
|- renders/
|- run/
|- secrets/
|- sockets/
`- state/
   `- upstreams/

Runtime files are not repo files. Upstream OAuth state, browser state, secret files, sockets, logs, rendered client configs, backups, and daemon state belong under the runtime root.

See docs/runtime-layout.md.

Client wiring

Back up a client config:

make config-backup CLIENT=codex

Dry-run render:

make config-render CLIENT=codex CONFIG_RENDER_APPLY=0

Apply after reviewing the rendered file under $HOME/mcp/mcp-broker/renders/:

make config-render CLIENT=codex CONFIG_RENDER_APPLY=1

Rollback:

make config-rollback CLIENT=codex

Use CLIENT=claude or CLIENT=agy after that profile smoke passes and that client is intended to use the broker. For new JSON-based MCP clients, generate a starter block:

make profile-snippet NEW_PROFILE=local-client NEW_CLIENT_FORMAT=mcp-settings-json

See docs/add-profile.md for the full new-profile flow.

Compact broker facade

The compact facade keeps chat-facing profiles small:

Tool

Purpose

broker_search_tools

Search configured upstream tools by query. Results carry name, description, upstream, purpose, tags, and mutating flag; the heavy inputSchema is omitted and fetched on demand from broker_describe_tool.

broker_describe_tool

Return schema and metadata for one upstream tool.

broker_call_tool

Call one upstream tool through broker routing. Accepts an optional projection ({"paths": [...], "max_array_items": N}) that trims the response server-side before it reaches the client.

broker_status

Show profile-visible upstream state, passive auth probes, and last errors without starting tools.

broker_close_session

Release caller-owned per-session upstream processes without stopping shared upstreams or another client session.

Codex /mcp shows the single mcp-broker entry by design. Per-upstream visibility, status, and socket path come from broker_status.

Profiles and safety

Profiles decide which upstreams a client can see and call.

Supported concepts:

  • max_tools protects clients from huge tool lists.

  • compact_tools_enabled exposes broker facade tools instead of raw upstream tools.

  • broker_tool_name_style adapts broker facade names for clients that cannot surface dotted tool names.

  • mcp_allowed_servers renders client settings for MCP clients that require an explicit server allowlist.

  • allow_mutating_upstreams is required before a mutating upstream can be exposed.

  • shared mode reuses one upstream process where shared account state is acceptable.

  • per_session mode isolates upstream state per client session.

  • disabled mode keeps compatibility records without exposing the upstream.

Protected surfaces such as OAuth, browser state, filesystem roots, and databases require explicit config and validation. Public examples stay disabled or placeholder-based.

See docs/security-review.md and docs/upstream-compatibility-matrix.md. For a deeper safety checklist, see docs/safety.md.

Config contract

The public template is config/broker.example.yaml. The matching JSON Schema is config/broker.schema.json.

Supported top-level sections:

schema_version: 1
runtime: {}
broker: {}
profiles: {}
clients: {}
upstreams: {}

The loader rejects unknown keys. Runtime placeholders such as {runtime.root}, {runtime.state_dir}, and {runtime.secrets_dir} can be used in upstream command, args, working directory, and env file paths.

make config-validate checks the selected CONFIG_PATH against the public JSON Schema first, then runs the runtime loader so semantic rules are enforced from the same code path the broker uses.

Each enabled upstream exposed to a profile should define a safe smoke probe:

smoke:
  query: read example graph
  tool: example-store.read_graph
  arguments: {}
  call: true

make profile-validation PROFILE=<profile> validates every enabled upstream visible to that profile through broker_status, broker_search_tools, broker_describe_tool, and the configured safe broker_call_tool.

Codex operator acceptance

Repo-owned tests validate broker behavior through the local client shim. The last Codex-specific check has to run inside an active Codex session because that is where the deferred MCP wrapper tools exist.

Generate the current acceptance steps from YAML:

make codex-deferred-acceptance

The target reads the configured smoke probes and prints the exact mcp__mcp_broker__ wrapper calls for search, describe, and safe call. It does not invoke Codex, does not call an external LLM session, and is not part of make quality-gate.

See docs/codex-deferred-tool-acceptance.md.

LaunchAgent

Render without writing:

make launchagent-install

Apply and load:

make launchagent-install LAUNCHAGENT_APPLY=1
make launchagent-load
make broker-status

Unload or remove:

make launchagent-unload
make launchagent-uninstall LAUNCHAGENT_APPLY=1

systemd

Linux user-service install uses the same runtime root and config path contract:

make systemd-install
make systemd-install SYSTEMD_APPLY=1
make systemd-load

For package installs, set MCP_BROKER_DAEMON_COMMAND to the installed daemon path before applying the service.

Windows

Windows startup uses PowerShell Scheduled Task commands with the same runtime root and config path contract:

make windows-install
make windows-install WINDOWS_APPLY=1
make windows-load

Remove it with:

make windows-unload
make windows-uninstall WINDOWS_APPLY=1

Test and release gates

Run all test tiers:

make test

Run the public quality gate:

make quality-gate

The coverage gate uses line and branch coverage for Python source.

Run the release gate when preparing a tag:

make release-gate

release-gate runs package, smoke, and mutation checks. Mutation receives a release-scoped child count derived from LOCAL_CPU_BUDGET and RELEASE_GATE_JOBS, so it does not take the full CPU budget while other release children run. Mutation runs public unit and journey tests last and writes var/quality/mutation_stats.json with total counts, score, and ranked blocked_by_file entries. On macOS, the release gate runs mutation inside a Linux container to avoid local mutmut fork failures. E2E tests remain in make quality-gate.

Run smoke and runtime cleanup checks:

make config-validate
make broker-smoke
make broker-stop
make broker-reap
make doctor
make release-smoke

Release or client config apply should wait for:

  • make quality-gate

  • make config-validate

  • make broker-smoke

  • dry-run config render for each intended client

  • rollback test

  • make release-smoke

  • make release-gate before tagging

  • make doctor with no stale broker-owned resources

See docs/release-checklist.md.

Public commands

These targets use this repo plus declared Python and Node prerequisites:

make setup
make config-init
make test
make test-unit
make test-journey
make test-live
make test-e2e
make test-cov
make precommit
make quality-gate
make release-gate
make config-validate
make broker-smoke
make broker-start
make broker-status
make broker-stop
make broker-reap
make doctor
make config-backup
make codex-app-policy
make config-render
make config-rollback
make tools-count
make facade-smoke
make codex-facade-smoke
make claude-facade-smoke
make agy-facade-smoke
make profile-validation
make codex-profile-validation
make claude-profile-validation
make agy-profile-validation
make discovery-parity
make codex-claude-discovery-parity
make codex-deferred-acceptance
make launchagent-install
make launchagent-load
make launchagent-unload
make launchagent-uninstall
make systemd-install
make systemd-load
make systemd-unload
make systemd-uninstall
make windows-install
make windows-load
make windows-unload
make windows-uninstall
make linux-container-smoke
make windows-powershell-smoke
make release-smoke
make mutation
make mutation-linux

make quality-gate is repo-local. It does not call personal scripts outside this repo.

make codex-deferred-acceptance is maintainer-only. It does not invoke Codex or an external LLM session. It reads the same YAML smoke probes and prints the exact mcp__mcp_broker__ deferred wrapper calls to run inside an active Codex session. See docs/codex-deferred-tool-acceptance.md.

Project tree

mcp-broker/
|- .gitignore
|- Makefile
|- README.md
|- pyproject.toml
|- requirements.txt
|- config/
|  |- broker.example.yaml
|  |- broker.private.yaml        # local, ignored by git
|  `- broker.schema.json
|- docs/
|- registry/
|- scripts/
|  `- check_mutation_stats.py
|- src/
|  `- mcp_broker/
|- tests/
|  |- unit/
|  |- journey/
|  |- live/
|  |- e2e/
|  `- support/
`- var/                         # tracked skeleton; generated contents ignored

Generated reports stay under var/, especially var/coverage/, var/test-logs/, and var/quality/.

Docs

Design rules

  • Keep upstream definitions in central config.

  • Keep runtime state under $HOME/mcp/mcp-broker.

  • Keep private upstream inventory in config/broker.private.yaml, which is ignored by git.

  • Keep secret values out of config and source.

  • Do not hardcode personal paths in source, tests, docs, or public config.

  • Run build, test, runtime, and config operations through the Makefile.

Available Tools

4 tools
broker_call_toolA

Call one profile-visible upstream MCP tool through the broker using its broker-qualified name and exact argument object. The broker's mutating-tool policy remains gated by the active profile's allowlist, so call broker_describe_tool first and pass only arguments accepted by the described upstream schema.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesFull broker-qualified tool name to invoke. Use a name returned by broker_search_tools or broker_describe_tool, not an unqualified upstream name.
argumentsYesExact JSON object accepted by the described upstream tool schema. Use an empty object only when broker_describe_tool shows that the upstream tool accepts no parameters.
projectionNoOptional server-side projection applied to the upstream response before it reaches the client, so a verbose result is trimmed to only the fields you need and large arrays are capped. This cuts context tokens and latency. Omit it to receive the full, unmodified upstream response.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the broker's mutating-tool policy is gated by the profile's allowlist, and hints at server-side projection to cut tokens and latency. Missing details on error handling or response format, but acceptable given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence states purpose, the second provides a critical usage guideline. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers invocation, policy, and prerequisite steps. Lacks explicit statement about return format (dynamic), but the projection parameter description partially compensates. Enough for a proxy tool with variable output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context that names must come from broker_search_tools or broker_describe_tool, but does not significantly enhance understanding beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool invokes an upstream MCP tool via the broker using a qualified name and arguments. It distinguishes from sibling tools (broker_describe_tool, broker_search_tools, broker_status) by focusing on execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises calling broker_describe_tool first and passing only accepted arguments, providing clear when-to-use guidance and key steps for correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

broker_describe_toolA

Describe one profile-visible upstream MCP tool by broker-qualified name. Use this after broker_search_tools and before broker_call_tool so the client can inspect the exact description, input schema, upstream owner, transport, and mutating metadata instead of guessing arguments.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesFull broker-qualified tool name to inspect, such as an upstream prefix joined to the upstream tool name by the configured namespace separator.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It mentions the tool returns 'exact description, input schema, upstream owner, transport, and mutating metadata,' which is transparent about the output. However, it does not discuss error handling, permissions, or rate limits, leaving some gaps for a bare description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the action, the second provides workflow context. Every word is purposeful with no redundancy, making it highly efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema) and the presence of sibling tools, the description is fairly complete. It explains the workflow position and return contents, though it could mention error cases or that the name must come from search results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter schema coverage is 100% with a thorough description and examples. The tool description adds 'by broker-qualified name' but largely restates schema info, so it provides minimal additional value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Describe one profile-visible upstream MCP tool by broker-qualified name.' It also distinguishes from siblings by specifying its place in the workflow, making the purpose highly specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use this tool: 'Use this after broker_search_tools and before broker_call_tool.' It also explains the benefit—avoiding guesswork—which helps the agent decide correctly among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

broker_search_toolsA

Search the profile-visible upstream MCP tool catalog without advertising every upstream tool to the client. Use this first when the task mentions a capability, service, keyword, or upstream prefix and you need candidate broker-qualified tool names before describing or calling one of them.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of matching tools to return. Keep this small for exploration, then refine the query or call broker_describe_tool for exact schema details.
queryYesCapability, upstream name, tool name fragment, or task keyword to match against broker-qualified tool names, upstream names, descriptions, and schemas.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it does not advertise every tool to the client, and the input schema's description adds details about profile visibility, mutating-upstream policy, and return behavior including skipped upstreams on failure, fully compensating for missing annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The main description is two focused sentences, and the schema description is also concise. Every sentence adds value, no fluff, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully covers the tool's behavior: searching, policy application, return of metadata, and links to sibling tools for next steps. It is complete for a search tool with simple parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with good parameter descriptions (limit's usage hint to keep small, query's examples). The main description adds no extra parameter context but the schema descriptions are thorough and provide guidance beyond basic definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches the profile-visible upstream MCP tool catalog, distinguishing it from siblings by specifying it is used first to get candidate tool names. The verb 'Search' and resource are specific and exact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this first when the task mentions a capability, service, keyword, or upstream prefix' and mentions alternatives like broker_describe_tool for exact schema details, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

broker_statusA

Report broker and upstream status for the active profile without starting hidden or denied upstreams. Use this for health checks, support tickets, and client validation because it returns the profile name, broker socket path, aggregate status, upstream runtime state, auth state, transport, process id, restarts, and mutating exposure.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses return fields and the key behavioral detail of not starting hidden/denied upstreams. Since no annotations, the description covers the needed transparency for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words. Efficient and complete.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates by listing return fields and behavior. Could add a note about interpretation, but overall complete for a simple status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters to document. Schema already covers with description 'No user arguments accepted'. Description adds no param semantics, but that's appropriate given zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource. Explicitly states what it does and what it does not do (no starting hidden/denied upstreams). Distinguishes from sibling tools by specifying health-check usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use cases provided (health checks, support tickets, client validation). Does not list when not to use, but context makes it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev2.0.0
    • Changedbroker_call_tool1 field changed
      • addedInput schema / properties / projection
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Optional server-side projection applied to the upstream response before it reaches the client, so a verbose result is trimmed to only the fields you need and large arrays are capped. This cuts context tokens and latency. Omit it to receive the full, unmodified upstream response.",
        +  "properties": {
        +    "max_array_items": {
        +      "description": "Truncate every array in the projected response to at most this many items, so a long list returns only its first entries.",
        +      "minimum": 0,
        +      "type": "integer"
        +    },
        +    "paths": {
        +      "description": "Dotted field paths to keep, such as data.items.id. A path that reaches a list is applied to every element. Omit to keep all fields and only cap arrays with max_array_items.",
        +      "items": {
        +        "type": "string"
        +      },
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
  2. 4 tool updatesv1.1.2
    • Changedbroker_call_tool8 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / description
        Added value: +"Invocation request for a broker-managed upstream tool. The broker resolves the namespaced name, enforces profile exposure and mutating-tool policy, serializes calls when configured, and returns the upstream tool result."
      • addedInput schema / properties / arguments / additionalProperties
        Added value: +true
      • addedInput schema / properties / arguments / default
        Added value: +{}
      • addedInput schema / properties / arguments / description
        Added value: +"Exact JSON object accepted by the described upstream tool schema. Use an empty object only when broker_describe_tool shows that the upstream tool accepts no parameters."
      • addedInput schema / properties / name / description
        Added value: +"Full broker-qualified tool name to invoke. Use a name returned by broker_search_tools or broker_describe_tool, not an unqualified upstream name."
      • addedInput schema / properties / name / examples
        Added value: +[
        +  "github.get_file_contents",
        +  "filesystem.read_file"
        +]
      • addedInput schema / properties / name / minLength
        Added value: +1
    • Changedbroker_describe_tool5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / description
        Added value: +"Describe request for one catalog entry. The name must be the full broker-qualified tool name returned by broker_search_tools or another catalog response, including the upstream prefix and namespace separator."
      • addedInput schema / properties / name / description
        Added value: +"Full broker-qualified tool name to inspect, such as an upstream prefix joined to the upstream tool name by the configured namespace separator."
      • addedInput schema / properties / name / examples
        Added value: +[
        +  "github.get_me",
        +  "filesystem.read_file"
        +]
      • addedInput schema / properties / name / minLength
        Added value: +1
    • Changedbroker_search_tools7 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / description
        Added value: +"Search request for the broker catalog. The broker inspects only upstreams exposed to the active profile, applies mutating-upstream policy, and returns matching tool metadata plus skipped upstreams when discovery fails."
      • addedInput schema / properties / limit / default
        Added value: +20
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of matching tools to return. Keep this small for exploration, then refine the query or call broker_describe_tool for exact schema details."
      • addedInput schema / properties / query / description
        Added value: +"Capability, upstream name, tool name fragment, or task keyword to match against broker-qualified tool names, upstream names, descriptions, and schemas."
      • addedInput schema / properties / query / examples
        Added value: +[
        +  "github issue",
        +  "file read",
        +  "browser screenshot"
        +]
      • addedInput schema / properties / query / minLength
        Added value: +1
    • Changedbroker_status2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / description
        Added value: +"Status request for the active broker profile. No user arguments are accepted; clients may pass transport-control fields that the broker ignores, but status filters them before validating the request."
  3. 4 tool updatesv1.1.1
    • First observedbroker_call_tool
    • First observedbroker_describe_tool
    • First observedbroker_search_tools
    • First observedbroker_status

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: search, describe, call, and status. No ambiguity between them.

Naming Consistency5/5

All tools follow the consistent pattern 'broker_verb_noun' (e.g., broker_search_tools, broker_call_tool), making the set predictable.

Tool Count5/5

Four tools is exactly the right scope for a broker service, covering the essential workflow without redundancy or gaps.

Completeness5/5

The tools cover the full lifecycle: search to discover, describe to inspect, call to execute, and status for health checks. No missing operations.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Self-hosted MCP proxy and aggregation platform. Register multiple upstream MCP servers and expose them through a single unified endpoint with namespace routing, multi-transport support (HTTP/SSE, stdio, OpenAPI→MCP), per-tool overrides, and a web admin UI.
    17
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Centralized MCP control plane that proxies multiple upstream MCP servers with tool namespacing, filtering, policy enforcement, audit logging, and health checks.
    16
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A local MCP auth wrapper and credential broker for multi-account workflows, enabling profile switching, secret injection, and policy enforcement for upstream MCP servers.
    196
    4
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/doricstack/mcp-broker'

If you have feedback or need assistance with the MCP directory API, please join our Discord server