MCP Gateway

The Model Context Protocol (MCP) Gateway governs tool discovery and invocation in Consul Agentic Runtime Fabric. It applies policy to tool access while backend services retain responsibility for tool business logic.

The gateway runs as an Envoy external processor on the agent's tool-call path. It reads each JSON-RPC request, applies per-tool policy, and marks calls that need human approval before Envoy routes them to the tool server. To learn how model, tool, and identity paths fit together, refer to the Consul Agentic Runtime Fabric architecture.

Introduction

An agent can discover a tool without having permission to invoke every operation that the tool exposes. Consul Agentic Runtime Fabric separates catalog visibility, network connectivity, delegated user authority, tool-level policy, and human approval. A successful decision at one layer does not bypass the others.

Consul configures the mesh data plane. Envoy forwards approved requests through the configured mesh path.

Discovery and invocation

The gateway architecture exposes an authorized tool catalog and evaluates invocation independently. Discovery responses describe available tools. They are not credentials or durable authorization decisions. Policy can change between discovery and invocation.

For a tool call, the enforcement path considers:

• The authenticated workload making the request.
• Delegated user authority when the operation carries user context.
• The requested MCP method, tool, and applicable tool policy.
• Verified approval evidence when policy requires a human decision.

Routing and decision metadata must derive from validated request content and trusted configuration. Caller-supplied headers must not be accepted as proof of authorization or human approval.

Human approval

For a protected operation, an application approval workflow supplies a decision to an enforcement processor. The processor must verify evidence bound to the original action before allowing the request to proceed. Relevant bindings include the operation, destination, arguments, and request challenge.

A missing, expired, rejected, or mismatched approval does not authorize execution. An approval for one action must not authorize a different tool, changed arguments, or a different destination. Destination policy still applies after approval.

The application owns the human interaction. The gateway owns enforcement on the tool-call path. It does not determine whether a human's business decision is correct.

Backend connectivity

External credential injection is distinct from delegated user authorization. A provider credential proves the gateway's authority to authenticate to the external service. It does not replace the caller's permission to invoke the tool.

Operational evidence

Correlate discovery, invocation, policy decisions, approval outcomes, and backend results using request and trace context where available. Record bounded decision metadata without logging tool arguments, tool results, credentials, or approval tokens.

A successful HTTP or MCP response establishes a protocol outcome, not completion of the user's workflow. Applications supply the task outcome needed for business-level analysis.

Dependencies and boundaries

• Consul and Envoy own configured connectivity and mesh enforcement.
• Participating identity processors validate delegated authority separately from workload identity.
• Applications explicitly integrate human-approval callbacks when required.
• Backend services implement tools and their business-side effects.

The MCP component owns supported topologies, sessions, protocol handling, processor ordering, and catalog aggregation behavior. Do not assume that every topology supports the same session or aggregation behavior, or that a disconnected client cancels an action already executed by a backend.

Related documentation

• Identity plane
• External credential injection
• AI observability and KPIs