← Back to library

Gateways are All You Need — Karan Sampath, Anthropic

Watch videoView transcript

AI Engineer17m 48sTranscript ✅Added May 18, 2:40 pm GMT+8

Creator/speaker: Karan Sampath, Anthropic
Duration: 17:48
Evidence used: extracted transcript/comments, key frames, and external sources listed below.

Actionable Insights

  1. **The practical takeaway: if MCP usage is growing inside an enterprise, build a governed g. The practical takeaway: if MCP usage is growing inside an enterprise, build a governed gateway/control plane before every team invents auth, routing, logging, and deployment separately. But do not pretend gateways solve every local-tool and existing-API problem. Start by turning this into a small, reversible pilot: write down the exact input, expected output, owner, and success metric before changing the wider workflow. The useful detail from the analysis is: Practical synthesis: the gateway idea is useful, but the analysis should position it as applying established API gateway/control-plane patterns to agent tool ecosystems — not as a wholly new infrastructure category. Sampath argues that enterprise MCP adoption is blocked by observability, access control, security, credential management, and deployment friction. Treat the first run as an evaluation, not a migration: capture before/after examples, note where the method saves time or improves quality, and keep the old path available until the new one passes repeated checks. Watch for the main failure mode here: overgeneralizing the creator’s demo beyond the evidence. If the video or comments only showed a narrow case, keep the rollout narrow and require fresh proof before broad adoption.

Architecture checklist

  1. Inventory MCP and API tool surfaces.

    • Remote MCP servers.
    • Local stdio MCP servers.
    • Existing REST/GraphQL APIs.
    • CLI/dev tools that agents use locally.
    • Data stores and sensitive systems.

  2. Decide what belongs behind a gateway.

    • Good candidates: remote enterprise services, shared internal tools, data access, observability/search systems, workflow automation.
    • Bad/partial candidates: purely local tools needing developer-machine context, one-off scripts, tools whose value is already served by stable REST/GraphQL APIs.

  3. Implement the gateway as a root of trust.

  4. Use official/reference MCP material carefully.

  5. Connect Claude Code/agent clients through managed MCP where appropriate.

claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp list
claude mcp get github
claude mcp remove github
  1. Define acceptance tests for each tool.
    • Tool description cannot exfiltrate data via prompt injection.
    • Tool returns scoped data for the authenticated user only.
    • Gateway logs include actor, agent/client, tool, params hash, result size, latency, policy decision.
    • Sensitive operations require confirmation or human approval.
    • Local-only tools have a separate policy, not a hand-wavy “gateway later.”

Experiments to run

  • Build one gateway path for a low-risk internal read-only service and compare onboarding time vs direct MCP server deployment.
  • Run red-team prompts against tool descriptions and returned resources.
  • Compare agent success using MCP tool descriptions vs existing OpenAPI/GraphQL docs for the same domain.
  • Measure whether centralized access control reduces security review time without increasing incident rate.

Integration cautions

  • The strongest comments argue MCP may duplicate REST/GraphQL/API gateway patterns. That criticism is partly correct: do not rebuild existing API governance for no gain.
  • Gateways can become bottlenecks if every tool change requires a central platform team.
  • Local MCPs are a real gap. A network gateway does not automatically govern tools running on a developer laptop.
  • MCP tool descriptions are untrusted inputs; the MCP spec itself says tool safety and user consent matter.

Core thesis

Sampath argues that enterprise MCP adoption is blocked by observability, access control, security, credential management, and deployment friction. His solution is a gateway: a trusted middle layer between many MCP servers and many MCP clients that centralizes auth, routing, observability, tunnels, registry, and developer tooling.

The thesis is sound for remote/shared enterprise MCPs. It is less complete for local tools and for organizations that already expose well-governed APIs with machine-readable schemas.

Comment insights

The comments are unusually skeptical and technically valuable:

  • Multiple commenters say MCP is reinventing REST/GraphQL/API gateways. This is a serious challenge to the talk’s framing.
  • Some argue LLMs can already read Swagger/OpenAPI docs and call APIs, so MCP may add maintenance burden.
  • Several comments accept the gateway pattern but call it a “textbook solution,” not a new idea.
  • A recurring concern: local MCPs/dev tools do not fit a purely centralized gateway model.
  • A positive comment says “MCP gateway gang,” showing some practitioner agreement.

Practical synthesis: the gateway idea is useful, but the analysis should position it as applying established API gateway/control-plane patterns to agent tool ecosystems — not as a wholly new infrastructure category.

Deep research

Supporting sources:

  • Anthropic’s MCP launch post says MCP aims to replace fragmented integrations with a universal open standard connecting AI systems to data sources, with servers and clients and prebuilt connectors for systems like Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Source: https://www.anthropic.com/news/model-context-protocol
  • MCP introduction docs define MCP as an open-source standard connecting AI applications to external systems and describe broad support across Claude, ChatGPT, VS Code, Cursor, and others. Source: https://modelcontextprotocol.io/docs/getting-started/intro
  • MCP specification confirms JSON-RPC 2.0 messaging, hosts/clients/servers, tools/resources/prompts, and security principles requiring user consent, data privacy, tool safety, and access controls. Source: https://modelcontextprotocol.io/specification/2025-06-18
  • Claude Code MCP docs show practical support for HTTP, SSE, and local stdio MCP servers, dynamic tool updates, reconnection, plugin-provided servers, and management commands. Source: https://docs.anthropic.com/en/docs/claude-code/mcp
  • The modelcontextprotocol/servers repository warns that reference servers are educational and not production-ready. This supports the need for enterprise hardening before broad deployment. Source: https://github.com/modelcontextprotocol/servers

Contradicting/limiting evidence:

  • MCP’s own security section says the protocol cannot enforce all security principles; implementors must build consent, authorization, access controls, and privacy safeguards. This undercuts any implication that MCP alone is safe.
  • Existing REST/GraphQL/OpenAPI ecosystems already solve much of auth, schema, routing, rate limit, and observability. MCP gateways may be an adaptation layer, not a replacement.
  • Claude Code docs explicitly include local stdio servers, which complicates a purely remote gateway control plane.

Verdict

Claim: Enterprises need observability, access control, security, and credential management for MCP adoption.

Verdict: Agree.
Confidence: High.
Practical takeaway: do not let unmanaged MCP servers proliferate around sensitive systems.

Claim: A gateway/root-of-trust is the best way to scale enterprise MCPs.

Verdict: Agree for remote/shared MCPs; mixed overall.
Confidence: Medium-high.
Overclaimed: “all you need” is too strong. You still need local-tool policy, data governance, threat modeling, tool design, and maybe direct API approaches.

Claim: Registries are useful but incomplete for enterprises.

Verdict: Agree.
Confidence: High.
Practical takeaway: a registry tells you what exists; it does not by itself solve authorization, telemetry, credential scoping, or deployment.

Claim: MCP gateways let non-technical teams build their own MCP servers safely.

Verdict: Mixed.
Confidence: Medium.
Agree: a gateway can remove boilerplate and centralize controls.
Caution: business teams still need review of tool semantics, data access, prompt-injection exposure, and operational ownership.

Claim: MCP is necessary versus existing APIs.

Verdict: Mixed / context-dependent.
Confidence: Medium.
Practical takeaway: use MCP when standardized tool/resource/prompt semantics improve agent integration; use existing APIs directly when they are already well-described, governed, and agent-usable.

Screen-level insights

  • 0:37 “About me” slide: Establishes Karan Sampath as Anthropic/FDE working with enterprises on MCP. It supports that the talk is field-experience based, not just theoretical.
  • 1:08 “Overview” slide: Shows Anthropic, the official registry URL registry.modelcontextprotocol.io, and logos like GitHub, Slack, Notion, Google Drive. This visual matters because it frames MCP as an ecosystem with many servers, making the governance problem plausible.
  • 1:40 “Enterprise State of Play” slide: The frame includes enterprise framing and logos such as Braintrust, WorkOS, OpenAI. Although not all text is legible, it connects to the transcript’s “observability, access control, security” hydra.

Visible UI/tools: MCP registry, Anthropic, GitHub/Slack/Notion/Google Drive ecosystem logos, gateway diagrams described in transcript, OAuth/access-control/proxy/tunnel/sub-registry/CLI components.

Verification notes

Verification passes performed:

  1. Source/evidence audit: Cross-checked MCP claims against Anthropic’s MCP launch post, MCP intro/specification, Claude Code MCP docs, and the MCP servers repository warning. Evidence supports MCP standardization and enterprise control needs.
  2. Transcript/comment/frame fidelity audit: Matched the analysis to transcript sections on observability/access/security, gateway definition, components, benefits, and future decoupling; comment skepticism is represented directly.
  3. Hallucination/overclaim audit: Rejected the literal “all you need” framing. Highlighted local MCPs and existing API infrastructure as residual gaps.
  4. Actionable Insights audit: The top section includes architecture checklist, commands, experiments, evaluation criteria, and cautions with direct links to MCP docs/repos/tools.

Residual uncertainty: the talk references Anthropic internal/external gateway examples but does not provide public benchmark data proving deployment speed, safety improvement, or agent success rates.

  • Actionable Insights audit: expanded to the newer detailed format with fuller implementation notes, evaluation checks, and cautions where the existing evidence supports elaboration.