MCP Tool Governance
The Model Context Protocol (MCP) standardizes how AI applications discover and invoke tools from external servers. It is a powerful integration surface — and a governance surface. Every tool an MCP server exposes is a capability your AI system can invoke, which means every MCP tool needs the same decision boundary as any other tool: what is it allowed to do, and who decides?
Why MCP Makes Governance Harder
MCP lowers the cost of connecting an AI system to tools. That is exactly why it concentrates risk:
- One MCP server can expose dozens of tools — read, write, and destructive.
- The model discovers tools dynamically; you do not review each one at registration time the way you might with a hand-wired tool.
- MCP servers are often third-party — the tool surface is not code you wrote.
- A single model call can chain multiple MCP tools, multiplying the side-effect surface.
The governance question is not "can we call this MCP server" — it is "which of its tools may run, under what policy, and with what evidence?"
The Same Boundary Applies
TramAI's tool permission model covers MCP-bound tools through the same mechanisms as any tool:
ALLOW— the tool may execute.DENY— the tool call is blocked before execution.REQUIRE_APPROVAL— the tool call suspends until a human authorizes it.
And the same enforcement points apply:
| Enforcement point | MCP meaning |
|---|---|
BEFORE_TOOL_EXPOSURE | Is the MCP tool definition shown to the model at all? |
BEFORE_TOOL_EXECUTION | May this specific MCP call run? |
BEFORE_TOOL_RESULT_REINJECTION | Is the MCP result fed back into the model context? |
Exposure permission remains distinct from execution permission: the model can know a destructive MCP tool exists without being able to call it.
Security Metadata Per Tool
Each tool — including MCP-exposed tools — carries security metadata that policy evaluation consumes: the permission it exercises, its risk level, and whether human approval is required. Deny-by-default means no tool is callable unless explicitly allowed by configuration.
Shipped vs Roadmap: Be Precise
MCP support in TramAI has a specific status, and this page states it exactly:
| Capability | Status in 0.6.0 |
|---|---|
MCP workflow server (tramai-mcp) | Repository module that exposes registered workflows as MCP tools (list_workflows, run_workflow, resume_workflow, get_workflow_status). Internal in 0.6.0 — not published to Maven Central. |
| Tool governance applied to runtime tools | Shipped — policy engine, the three tool enforcement points, ALLOW / DENY / REQUIRE_APPROVAL, and the tool.permission evidence family |
| Governed remote MCP tool connector | Not shipped in 0.6.0 and not published as a roadmap date — a connector that routes remote MCP tool calls through the same runtime boundary is future direction |
The distinction matters. The policy engine and its enforcement points are shipped and usable today, and they govern any tool registered in the runtime under the same three enforcement points. The MCP workflow server exists in the repository but ships internal in 0.6.0, and a governed remote MCP tool connector — where each remote MCP call is checked end-to-end inside the runtime — is not available. This page does not present it as available.
What to Ask Before Connecting an MCP Server
- Inventory — what tools does the server expose, and what permissions do they exercise?
- Policy — which tools are allowed, denied, or approval-gated in your configuration?
- Evidence — can you reconstruct, per MCP call, the decision that allowed or blocked it?
- Fallback — if the MCP server is a provider-adjacent service, does data classification constrain routing?
If a team cannot answer these, an MCP server is a hole in the governance boundary, not just an integration.
When Not to Use This
- Read-only MCP tools over public data may not need approval gates —
ALLOWunder a constrained policy is fine. - If the MCP server exposes only non-sensitive, non-destructive tools, the full policy machinery is overkill — but the deny-by-default posture still costs nothing.
- If a governed remote MCP connector is required and not yet implemented, plan for it as roadmap work rather than assuming it exists.
Related Documentation
- Tool governance — ALLOW / DENY / REQUIRE_APPROVAL in depth
- Runtime governance — the enforcement chain
- Human approval — REQUIRE_APPROVAL lifecycle
- AI agent governance — the category pillar
- MCP guide — MCP integration in TramAI
- Tool calling guide — tool mechanics
- TramAI on GitHub
