TramAI - governed AI workflows for Java and Kotlin

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 pointMCP meaning
BEFORE_TOOL_EXPOSUREIs the MCP tool definition shown to the model at all?
BEFORE_TOOL_EXECUTIONMay this specific MCP call run?
BEFORE_TOOL_RESULT_REINJECTIONIs 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:

CapabilityStatus
MCP workflow serverImplemented / evolving
Tool governance applied to runtime tools (including MCP-bound)Available today — policy engine, ALLOW / DENY / REQUIRE_APPROVAL, tool permission evidence
Governed remote MCP tool connectorNot implemented — roadmap direction

The distinction matters. The policy engine and enforcement points that govern tools are shipped and usable today. A governed remote MCP tool connector — where remote MCP tool calls are governed end-to-end through the same runtime boundary — is future work, and this page does not present it as available.

What to Ask Before Connecting an MCP Server

  1. Inventory — what tools does the server expose, and what permissions do they exercise?
  2. Policy — which tools are allowed, denied, or approval-gated in your configuration?
  3. Evidence — can you reconstruct, per MCP call, the decision that allowed or blocked it?
  4. 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 — ALLOW under 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