Auth and install checks
Users should see which MCP servers are configured, which need OAuth, and which environment variables are missing before a run begins.
guide · MCP
MCP agent harness with token visibility.
MCP makes tools portable. A harness makes those tools governable.
The risk
Tool access is useful only when it is bounded.
The Model Context Protocol gives agents a common way to reach tools, files, APIs, databases, browsers, and workspace systems. That portability is valuable. It also creates a new governance problem: once a tool server is available, which tools should the agent see, how large can results be, which credentials are active, what happens when auth fails, and how much context gets pushed back into the model?
A plain MCP connection can become a hidden expansion point. One tool call returns too much data. Another call fails and the agent retries without useful context. A third server requires OAuth but the setup path is buried in documentation. None of that is solved by asking the model to "be careful." The harness has to own setup, policy, and evidence.
Allowlists and caps
Include/exclude rules, result-size caps, and circuit breakers keep a useful MCP server from flooding context or widening access accidentally.
Scoped recall
Tool results should not automatically become global memory. They need tenant, workspace, user, role, and session scope.
Token receipts
The cost of tool-fed context should be visible. If an MCP result causes replay waste, the ledger should show it.
Muster's approach
MCP is a capability surface, not a shortcut around governance.
Muster treats MCP servers as governed capabilities. A server can be stdio or HTTP, local or remote, OAuth-backed or env-backed. The important part is that setup guidance, tool policy, result limits, auth state, and token visibility live in the harness. That lets a team add GitHub, Notion, Google Drive, Postgres, browser, web-search, or custom MCP servers without turning every model turn into an uncontrolled tool buffet.
This matters for production AI agents because MCP is often the bridge to real systems. If the agent can read issues, summarize documents, inspect data, or browse authenticated apps, the harness should record what happened. It should show which tools were configured, which calls ran, what results entered memory, and how much token budget the context consumed.
The goal is not to slow teams down. It is to make tool use repeatable. A good MCP agent harness gives developers enough friction to prevent accidental leaks and enough visibility to debug why an answer changed.
There is also a user-experience problem. Many MCP servers require several setup steps: install a package, create an OAuth app, copy a redirect URL, approve scopes, set an environment variable, and restart a client. Technical users can do that, but they still need clear feedback when something is missing. Non-technical operators need even more help. The harness should turn setup into an explicit workflow: what is installed, what is authenticated, what failed, and what link or command comes next.
Token visibility is the other half. MCP tools can return large payloads, and large payloads can quietly become expensive prompts. A ledger lets teams see when a tool result is useful, when it should be summarized, when it should be cached, and when it should be excluded from future turns. Without that visibility, teams often blame the model for latency or cost when the real issue is uncontrolled context.
For Muster, MCP support is not a separate feature island. It connects to the same memory scope, provider routing, gateway surfaces, capability packs, and eval fixtures as the rest of the harness. That is what makes MCP practical for long-running agents rather than just impressive in a one-off demo.
A mature MCP setup should also be boring to review. The list of servers should be inspectable, the active scopes should be clear, and failures should be explicit. If a Google Drive server is missing OAuth, say that. If a Postgres server can return too many rows, cap it. If a browser server depends on a local binary, check it before the run. This kind of surface makes MCP safer for teams that want strong integrations without making every user a toolchain expert.