Install and auth checks
Expose setup commands and OAuth steps inside the CLI instead of assuming every user knows how to wire a server.
MCP · tools · OAuth
Govern MCP tools before agents call them.
Muster treats MCP as a capability surface: installable servers, setup guidance, OAuth hints, include/exclude policy, result caps, circuit breakers, and token-ledger evidence.
MCP controls
Useful tools still need boundaries.
Include/exclude rules
Keep tool access deliberate with configured allowlists, result-size limits, and circuit breakers.
Memory and token receipts
MCP results flow through the same scoped memory and token ledger as normal agent turns.
Everyday MCPs
GitHub, Notion, Google Drive, Postgres, browser, web search, and custom stdio/http servers fit this model.
In practice
What goes wrong with MCP, and what the policy layer is for.
MCP solved the plumbing problem. Any server can now expose tools to any client without a bespoke integration, which is why MCP servers appeared faster than anyone's ability to review them. The problems that replaced the plumbing problem are operational, and they show up in a predictable order.
Setup is where most MCP deployments actually fail
The first failure is not dramatic. A server needs an API key, an OAuth grant, or a config path, the person wiring it up does not have one of those, and the tool silently returns errors that the model interprets as "this data does not exist." Muster's answer is to make setup a first-class part of the capability description: a server declares what it needs, the CLI surfaces the setup commands and OAuth steps, and a readiness check tells you which of your configured servers are actually usable before a run depends on one.
Result size is a cost problem disguised as a correctness problem
The second failure is expensive. An MCP tool returns a 400KB JSON document, it goes into the context window, and it stays there for every subsequent turn of the conversation. Nobody notices until the invoice arrives, because the waste is spread across hundreds of turns rather than concentrated in one bad call. Result caps bound the single response; the token ledger makes the accumulated cost visible, including a replay-waste flag when a run resends far more history than the task needed. Muster's benchmark measures the general version of this effect: 875.8k tokens naive versus 355.2k across five scenarios and 170 turns, a 59.4% reduction, deterministic and with no model calls involved.
Allowlists beat instructions
The third failure is a governance one. Telling a model in its prompt not to use a destructive tool is a request, not a control. Include and exclude rules decide which tools exist from the agent's point of view at all, which is a different kind of guarantee. Circuit breakers cover the remaining case: a server that has started failing or returning garbage should stop being called rather than being retried into a rate limit.
The results are evidence, not just output
MCP results flow through the same scoped memory lanes and the same token ledger as any other turn, which means a tool call is attributable after the fact: which scope it ran in, what it cost, and what it returned. If the run also touched a repository, the file changes are derived from git and the filesystem rather than from the agent's report — a distinction that matters more than it sounds, since a live measurement against Codex found the self-reported patch channel firing zero times across five runs while the edits landed on disk.
Practically, this covers the servers most teams reach for first: GitHub, Notion, Google Drive, Postgres, browser control, web search, and whatever custom stdio or HTTP server your own systems expose.
Guide: MCP with token visibility -> How file changes are observed -> Capability pack docs ->