Skip to content

PATTERN Cited by 9 sources

MCP as centralized integration proxy

Pattern

Deploy a single MCP server tier in front of the enterprise's internal systems (databases, queues, SaaS APIs, code repos, docs) and make it the mandatory choke-point through which every agent in the organisation accesses every internal tool. The MCP server speaks intent ("create a Redpanda cluster in us-east-1") and implements the mechanism ("the five API calls"), hiding binary-protocol complexity, connection-pool management, retries/backoffs, TLS, certificates, and authentication from every agent that would otherwise re-implement them.

Canonical statement on the wiki

Alex Gallego's 2025-04-03 founder-voice reframing of MCP from tool- description format to infrastructure-layer proxy (Source: Gallego 2025-04-03):

"MCP is about intent, 'create a Redpanda Cluster in us-east-1', while the MCP server worries about implementing the five API calls. While MCP is often nothing more than the wrapping of custom protocols for databases, queues, caches, docs, GitHub, Salesforce; the additional layer of abstraction pushes these complexities away from the application that is focused on the linear distribution of the data, sampling, chunking, etc., — not on validating credentials or the correct SASL handshake."

"Most critically, centralization offers composability, understandability, and debugging that would have to be replicated by every agent otherwise. Many products' APIs are brittle and evolution is riddled with conditional logic. An intent-based proxy pushes that complexity to a central location."

Why centralization wins

Gallego names four capabilities that only a proxy tier can provide, and that every agent would otherwise have to re-implement:

  1. Auditing — every tool call flows through one place, so audit log is deterministically complete.
  2. Tracing — end-to-end prompt → tool call → result traces are materialisable without cross-agent coordination.
  3. Cost accounting — per-tool / per-agent cost attribution converges to one aggregation point.
  4. Authentication + authorization + API-token management — credential handling lives in the proxy, not in every agent.

Plus two architectural capabilities:

  1. Composability — tools compose uniformly across agents.
  2. Brittle-API insulation — vendor API churn is absorbed by the MCP server layer; agents see a stable intent surface.

Mechanism at Redpanda

rpk connect mcp-server exposes Redpanda Connect pipelines, resources, and processors as MCP tools. Because Redpanda Connect ships ~300 pre-built connectors (databases, queues, caches, SaaS APIs) as open-source YAML-configurable pipelines, any of them becomes an MCP tool via a simple config — "allows you to expose any redpanda connect source and destination as a tool with a simple configuration."

The proxy layer handles connection pooling, retries, exponential backoffs, TLS, certificates, and authentication declaratively — "a simple HTTP endpoint with a YAML config that manages all of the connection pooling, retries, exponential backoffs, TLS, certificates, authentication, etc."

Orthogonal patterns

  • patterns/central-proxy-choke-point — the generic wiki-canon pattern; MCP-as-proxy is a content-aware instantiation targeting LLM agents specifically.
  • dynamic-content-filtering-in-mcp-pipeline — the per-call content-level policy enforcement the proxy enables.
  • patterns/wrap-cli-as-mcp-server — the Fly.io-canonicalised local-wrapper pattern; different altitude (individual CLI vs full integration surface).
  • hosted-mcp-ecosystem — the Pinterest-canonicalised centralisation pattern at a platform-org cardinality.

Contrast with "one MCP server per tool"

The non-centralized alternative — which is what most early MCP deployments look like — is "one MCP server per tool": each service team ships its own MCP server, each agent configures N servers (mcp-client-config-fragmentation), and the choke-point capabilities above have to be replicated. The centralised-integration-proxy pattern consolidates them into a single tier that owns the integration contract.

Caveats

  • Single-point-of-failure risk. A centralised proxy becomes a hot path dependency; availability needs to track the sum of its downstream tools, and a proxy outage blocks every agent. This is the classic choke-point trade-off (see patterns/central-proxy-choke-point caveats).
  • Ownership complexity. "One MCP tier" is a platform-org commitment; in practice, different MCP servers with different ownership end up being registered in one registry (see mcp-registry). The proxy-ness is policy-enforced, not topology-forced.
  • Content-filtering aspiration. Gallego's vision of per-call dynamic content filtering — see dynamic-content-filtering-in-mcp-pipeline — is a direction of travel, not a fully-specified MCP primitive in the source post.

Seen in

  • sources/2026-10-01-aws-accelerating-airline-retailing-innovation-datalex-modernization — MCP Gateway between agents and legacy REST APIs. Datalex's agentic booking assistant puts an MCP Gateway between its Bedrock AgentCore agents and the system's existing REST APIs, so the agents' natural-language tool calls reach legacy Datalex endpoints through one mediated, secured surface rather than bespoke per-API glue.

  • sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f — MCP server as one tool surface reused by both an in-house agent and external AI clients. Reclaim uses MCP bidirectionally: an MCP client inside its own agent loop consumes compatible tools from other services, and an MCP server exposes selected Reclaim tools to external AI clients (Claude, ChatGPT) that run their own models and agent loops but "can call the same tools used within Reclaim." The centralization payoff here is tool-surface reuse across callers: the Schedule Action tools are authored once and become the single integration point for both Reclaim's agent and third-party assistants — a smaller-scope instance of the choke-point idea (one tool tier, many agents) than the enterprise Redpanda deployments below.

  • sources/2025-04-03-redpanda-autonomy-is-the-future-of-infrastructure — Gallego's founder-voice reframing of MCP as infrastructure rather than tool protocol, with Redpanda Connect's ~300 connectors exposed via rpk connect mcp-server as the canonical instantiation.
  • sources/2025-10-28-redpanda-governed-autonomy-the-path-to-enterprise-agentic-ai — 2025-10-28 ADP companion post upgrades the pattern framing from "centralised integration proxy" to "agentic governance layer". Verbatim: adding MCP servers to Redpanda Connect "transforms it into an agentic governance layer between all the data systems and agents connecting through it." The proxy becomes the enforcement point for AAC's pre-and-post-I/O policy checks and the producer boundary for the durable event log audit envelope.

  • sources/2026-09-17-aws-how-dhi-group-accelerates-generative-ai-workloads-from-idea — AWS/DHI Group case study: a concrete customer instantiation. DHI's winning hackathon architecture exposes ClearanceJobs capabilities (search_candidates, get_candidate) as MCP tools on an AWS Lambda server, orchestrated by a Bedrock AgentCore agent behind a single natural-language recruiter interface — unifying ClearanceJobs and AgileATS without point-to-point integration. Cross-account transport is MCP over HTTPS with bearer auth; the AgentCore Gateway provides IAM-authed semantic tool discovery/routing. Shows the pattern applied to unifying disparate enterprise systems rather than exposing one vendor's connectors.

  • sources/2026-09-22-databricks-genie-one-mcp-give-any-ai-agent-the-right-business-context — Genie One MCP as a governed intent surface fronting analytics for every agent. Databricks' Genie One MCP is a content-aware instantiation of this pattern at the analytics altitude: one MCP server exposes governed conversational analytics (five tools; a natural-language question is the intent) to any MCP-compatible agent, hiding schema discovery, SQL generation, source-of-truth disambiguation, and permission enforcement behind a single surface. The centralization capabilities this pattern names are all present: auditing (Genie chat events in audit logs, SQL in Query History), cost accounting (consumption in billing system tables), auth/authorization (OBO token passthrough evaluated against Unity Catalog), and brittle-API insulation (agents see a stable intent surface, not the underlying tables/joins). The post also names the scoped alternative — the Genie Agent MCP server (/api/2.0/mcp/genie/{genie_space_id}) for a single curated domain — a smaller choke-point when the broad proxy surface isn't warranted.

  • sources/2026-09-25-databricks-from-data-to-dialogue-how-sp-global-energy-made-its-structured-data-estate-conversational — FastMCP composition of scoped Genie MCP servers into per-commodity composite endpoints. S&P Global Energy's realization of this pattern at the analytics altitude, one altitude below Genie One: instead of a single broad proxy, it composes many narrow, single-domain managed Genie Agent MCP servers (/api/2.0/mcp/genie/{genie_space_id}) behind a FastMCP proxy (FastMCP.as_proxy(...) + mount(prefix=…)) into one composite endpoint per commodity with name-spaced tools (cargo_genie_query_agent, outages_genie_query_agent, …). An agent connects to one endpoint per commodity; its LLM routes a question to the right group Genie or fans a cross-group question across several and synthesizes. This resolves the pattern's core tension explicitly — "narrow, high-accuracy group-level Genie Agents underneath, and broad, commodity- and estate-wide conversational access on top" — pairing the proxy with specialized-agent decomposition underneath rather than building "one agent to rule them all" (which "degrades answer quality"). The centralization payoffs the pattern names are inherited from the substrate: auth/authorization via Unity Catalog (agents reach only permitted tables, native or federated), brittle-API insulation (agents see a stable natural-language intent surface), and a single bridge for internal and external consumers. The named best practice — "Namespace your composite tools clearly" — is the routing-accuracy lever for the composed surface. Engineering owns only "one thin, reusable proxy layer."

  • sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker — agentgateway as the MCP choke-point at the identity altitude. Zalando configures agents to use agentgateway as their MCP endpoint, making it the mandatory gate through which every tool call flows. Beyond the usual centralization payoffs, this instance foregrounds two identity-layer capabilities the proxy enables: (1) token-exchange interception — the gateway validates the agent's user-agent token, asks the broker to exchange (RFC 8693) it for a provider token, and swaps the Authorization header so the agent never holds a provider credential; (2) per-tool-call policy via OPA on the gateway's ExtProc extension point ("both broker exchange policy and gateway tool-call policy must permit a request"). The post states the centralization thesis verbatim: routing every call through the gate "gives us a central audit point and shields agents from integration work." A clean instance of the pattern where the "brittle-API insulation" payoff is identity/OAuth-ceremony insulation — OAuth flows are kept out of both agents and MCP servers.

Merged aliases

  • mcp-as-context-bridge- mcp-as-fallback-for-shell-less-agents
Last updated · 766 distilled / 2,225 read