Tools MCP and External Integration

Tools MCP and External Integration

MCP Gateway — Stack

Mcp gateway › Stack

21 of 65 in this book · 3 min read

Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.

Selection criteria

You are introducing a component that every tool call passes through, so the evaluation is dominated by what it costs you when it is wrong.

  • Added latency. Milliseconds at the high percentiles for a pass-through call, measured with policy evaluation and logging switched on rather than in a bare proxy configuration.
  • Blast radius and failure behaviour. Whether it can run active-active, whether a restart drops in-flight sessions, and what consumers experience when the policy store it depends on is unavailable.
  • Catalogue curation. Whether offerings can be assigned to consumers selectively, renamed, and withheld, or whether aggregation is all-or-nothing.
  • Policy expressiveness. Whether a decision can consider the caller, the specific offering, and the argument values, or only the first two. Argument-blind policy cannot distinguish reading one record from exporting the table.
  • Credential brokering. Whether it can hold per-upstream credentials, exchange a consumer identity for an upstream-scoped one, and avoid forwarding an inbound token to a system it was not issued for.
  • Error fidelity. Whether upstream error structure survives the crossing intact, which determines whether a model can still recover from a correctable failure.
  • Protocol adaptation. Whether backends that do not speak the protocol can be exposed through the same policy surface, since most organisations have more of those than of native servers.
  • Audit completeness. Whether the record covers who called what, with which arguments, under which policy decision, and what came back — and where that record is retained.

Options

Option Best for Watch out for
Purpose-built MCP gateway and proxy projects (open-source aggregators and routers) Teams that want catalogue curation and central auth without building it A young and fast-moving category; evaluate operational maturity, session handling, and upgrade story rather than feature lists
Existing API gateways extended with protocol plugins (Kong, Envoy-based products, and similar) Organisations that already run an API gateway and want one policy and audit plane Session-oriented and streaming traffic fits the request-response model of these products awkwardly
Commercial AI gateways with tool mediation Buying governance, quotas, and reporting as a product rather than assembling them Policy and catalogue live in a vendor control plane; exporting them later is rarely straightforward
A thin in-house aggregator built on an SDK Small upstream counts and unusual policy that no product expresses You own session resumption, reconnection, and upstream health handling — all of which are more work than the routing
Service mesh with an egress policy and per-workload identity Fleets already running a mesh, where the aim is network-level control and workload identity Operates below the protocol: it can allow or deny a connection but cannot reason about which tool or which arguments
Per-application direct connections with no gateway Single-team deployments with a handful of trusted upstreams There is no inventory and no central revocation; the day a credential must be rotated everywhere is the day this choice gets revisited