MCP Hub 向所有 Agent 公開全部工具，作者主張按 Agent 篩選

We stood up an internal MCP hub last quarter. It aggregated four services behind one endpoint, listed every tool in a single catalog, and let any connected agent pick what it needed. Within a week, a support bot scoped to read tickets had called create_user twice and reset_password once. It had no business doing either. The tool list just made them available.

The tempting fix is a longer system prompt: "You are a support agent. Do not call user-management tools." That works until a new agent joins, until the model updates, or until someone rephrases the prompt during a late-night incident. Prompt-level scoping is a wish, not a boundary. The boundary has to live where the list is served.

The cheap, structural fix is per-agent tool lists. When an agent connects to the hub with its API key, it gets back a filtered tool catalog — not the global one. The support bot sees ticket-read and customer-lookup operations and nothing else. The billing agent sees invoice and payment-status operations. Nobody has to remember a rule; the tools aren't in the namespace to begin with.

We started by hiding every mutating tool by default. Read-only operations are visible to all agents. Writes, deletes, and state-changing calls require an explicit opt-in per agent, reviewed when the key is issued. That single change cut the stray write calls to zero, even before we started auditing what each agent was actually doing.

The second structural change was rate-limiting on the write paths. A read tool called 500 times in a row is suspicious but rarely catastrophic. A write tool called even ten times in a row usually is. Per-key rate limits on mutating operations mean an agent that goes off the rails hits the ceiling before it has created 400 users.

The third change is where the spec comes in. We stopped hand-maintaining a tools.json in the repo. The hub now serves the operation list derived from each service's OpenAPI document, filtered per agent. That means when a service adds a new endpoint, it shows up in the catalog the next time the spec is regenerated — and we control whether it's read-only or mutating in the same file that defines it. There's no separate YAML to drift.

This is the workflow we kept refining inside Powerduck: a local-first OpenAPI studio where the spec is the source of truth for what's exposed, what's read-only, and what needs per-agent opt-in. No second tool list to keep in sync.

The mental model: your MCP hub is an API gateway, not a bulletin board. Bulletin boards publish everything to everyone. Gateways filter per caller. The moment you treat the tool catalog as a per-agent response rather than a global manifest, most of the prompt-engineering arm wrestles you've been having about what agents "shouldn't" do go away.

How do you scope tools per agent today? Long prompts, or per-key catalog filtering?