Production-Ready MCP #2: Gateway Architecture & Federated Registries

1. Introduction

1.1 The Evolution from Passive Chatbots to Autonomous Agents

The landscape of Generative AI has fundamentally shifted. Early Large Language Models operated as isolated text processors, sophisticated question-answering systems constrained to their training data. Modern agentic systems represent a paradigm transformation: LLMs now function as orchestrators of digital ecosystems, capable of reasoning, planning, and executing actions across databases, APIs, and development environments.

This evolution exposes a critical infrastructure gap. While models gained capability to interact with external systems, the software industry lacked a universal connectivity standard. Each AI platform required custom integrations for every data source, creating what Anthropic termed the "N × M problem": N agents requiring bespoke connectors for M tools, resulting in exponential integration complexity.

1.2 MCP: Standardizing the Chaos

The Model Context Protocol emerged as the industry's answer, a universal interface specification analogous to USB-C for AI applications. MCP standardizes how Hosts (AI applications like Claude Desktop or agent orchestrators) communicate with Servers (providers of context and tools such as database connectors, Slack integrations, or file system access).

The protocol's three primitives (Resources, Tools, and Prompts) enable dynamic capability discovery and negotiation. Resources provide passive data, Tools offer executable functions, and Prompts define interaction templates. However, MCP's base specification, while robust for point-to-point connections, does not natively address enterprise-critical requirements: federated authentication, data exfiltration prevention, horizontal scalability of stateful connections, and centralized governance.

1.3 The Infrastructure Imperative

Production MCP deployments require two critical architectural additions beyond the base protocol:

• MCP Gateways: Intelligent proxy layers that aggregate servers, enforce security policies, manage session state, and provide observability
• Federated Registries: Dynamic service discovery systems allowing agents to navigate available capabilities while respecting organizational boundaries and compliance requirements

Without these components, organizations face unmanageable credential sprawl, fragmented audit trails, and inability to apply consistent security controls across agentic workflows. This study provides comprehensive analysis of these infrastructure patterns and practical guidance for implementation.

2. The MCP Gateway Pattern

2.1 The N×M Connectivity Problem

In a naive MCP architecture, each agent connects directly to every server it requires. Consider an organization with 10 autonomous agents (coding assistant, customer support bot, data analyst, security auditor, etc.) accessing 20 enterprise systems (PostgreSQL, Salesforce, GitHub, Slack, Jira, etc.). Direct topology results in:

• 200 connection configurations requiring individual management
• Credential proliferation: Each agent needs credentials for each server
• Fragmented visibility: No central point for monitoring agent-to-system interactions
• Policy chaos: Impossible to uniformly enforce rate limits, data filters, or access controls

Think of it this way: Imagine an international airport where every airline passenger must personally negotiate entry with every destination country's embassy before booking a flight. You'd need visas, customs clearances, and health certificates managed individually for every possible trip. It's functional but scales terribly. The MCP Gateway is like introducing a passport system, a standardized credential that centralizes verification, allowing any authorized traveler to connect to any authorized destination through a unified security checkpoint.

graph TB
    subgraph problem["PROBLEM: Direct N×M Mesh Topology"]
        Agent1["Agent 1
Coding Assistant"]
        Agent2["Agent 2
Support Bot"]
        Agent3["Agent 3
Data Analyst"]

        Server1["PostgreSQL
Server"]
        Server2["Slack
Server"]
        Server3["GitHub
Server"]
        Server4["Salesforce
Server"]

        Agent1 -.-> Server1
        Agent1 -.-> Server2
        Agent1 -.-> Server3
        Agent2 -.-> Server1
        Agent2 -.-> Server2
        Agent2 -.-> Server4
        Agent3 -.-> Server1
        Agent3 -.-> Server3
        Agent3 -.-> Server4

        Issues["Issues:
N×M configurations
Credential sprawl
No central policy
Fragmented audit"]
    end

    subgraph solution["SOLUTION: Gateway-Mediated Architecture"]
        AgentA["Agent 1"]
        AgentB["Agent 2"]
        AgentC["Agent 3"]

        Gateway["MCP Gateway
Unified endpoint
Central auth
Policy enforcement
Observability"]

        ServerA["PostgreSQL"]
        ServerB["Slack"]
        ServerC["GitHub"]
        ServerD["Salesforce"]

        AgentA --> Gateway
        AgentB --> Gateway
        AgentC --> Gateway

        Gateway --> ServerA
        Gateway --> ServerB
        Gateway --> ServerC
        Gateway --> ServerD

        Benefits["Benefits:
Single endpoint
Centralized security
Unified monitoring
Policy consistency"]
    end

    classDef problemStyle fill:#2d1b1b,stroke:#ef4444,stroke-width:2px
    classDef solutionStyle fill:#1b2d1b,stroke:#10b981,stroke-width:2px
    classDef gatewayStyle fill:#1e293b,stroke:#6366f1,stroke-width:3px

    class problem problemStyle
    class solution solutionStyle
    class Gateway gatewayStyle
                    

2.2 Gateway Core Responsibilities

An MCP Gateway functions as an intelligent reverse proxy specialized for JSON-RPC traffic over persistent connections. Its responsibilities extend far beyond simple routing:

2.3 The Ambassador Pattern in Agentic Context

MCP Gateways represent an adaptation of the Ambassador Pattern from distributed systems design. In this pattern, an out-of-process proxy (the "ambassador") handles cross-cutting concerns (networking, retries, circuit breaking) on behalf of the primary application.

For agentic AI, this separation is critical. LLMs should focus on reasoning and decision-making, not infrastructure complexity. When an agent invokes "execute tool X", the Gateway Ambassador:

1. Resolves where tool X is hosted (service discovery)
2. Establishes secure connection (mTLS, OAuth)
3. Handles transient failures (retries with backoff)
4. Records the interaction (audit logging)
5. Monitors performance (distributed tracing)

This decoupling allows platform teams to evolve infrastructure (upgrade authentication systems, add new servers, change routing logic) without modifying agent code or retraining models.

2.4 Backend-for-Agents (BFA): Specialized Gateways

An emerging pattern adapts the Backend-for-Frontend (BFF) concept to AI: the Backend-for-Agents (BFA). While a traditional BFF creates specialized backends for different user interfaces (mobile vs. web), a BFA creates specialized gateways for different agent personas or security contexts.

Examples:

• HR Agent Gateway: Exposes only HR-relevant tools (employee directory, PTO systems), preventing the HR bot from accidentally accessing financial databases
• Read-Only Analyst Gateway: Filters out mutation operations, ensuring data analysts can query but never modify production data
• External Contractor Gateway: Strict subnet allowing access only to public documentation and sandbox environments, never production systems

This pattern reduces the "context pollution" problem where agents receive capability lists containing hundreds of irrelevant tools, wasting valuable context window space and increasing confusion in model decision-making.

3. Federated Registry Architecture

3.1 The Service Discovery Problem

Static configuration of MCP servers becomes untenable at enterprise scale. Consider an organization with hundreds of microservices, each potentially exposing MCP capabilities. Hardcoding server endpoints in agent configuration creates operational nightmares:

• Server endpoint changes require reconfiguring all consuming agents
• New tool deployment requires manual updates to agent capability lists
• Decommissioned servers leave stale references causing runtime failures
• Discovery of available tools requires tribal knowledge or documentation searches

The solution is dynamic service discovery through an MCP Registry.

3.2 Registry Metadata Structure

MCP Registries function as searchable catalogs of available servers and their capabilities. Each registry entry contains structured metadata (typically JSON) describing:

• Endpoint information: URL, supported transports (Streamable HTTP, stdio)
• Capability manifest: Available tools, resources, and prompts with descriptions
• Security requirements: Authentication schemes, required OAuth scopes
• Operational metadata: SLA commitments, rate limits, geographic availability
• Compliance tags: Data classification levels (public, internal, confidential), regulatory frameworks (SOC 2, HIPAA, GDPR)

Agents query the registry before establishing connections, dynamically discovering which tools are available and permitted for their security context.

3.3 Federated Architecture: Public vs. Private Registries

The MCP ecosystem adopts a federated model to balance open collaboration with enterprise security:

graph TB
    subgraph public["Public Registry (Upstream)"]
        PubReg["MCP Registry
registry.modelcontextprotocol.io"]
        PubServers["Public Servers:
Google Drive connector
Slack integration
GitHub tools
Weather API"]
    end

    subgraph corp["Corporate Network"]
        PrivReg["Private Registry
(Downstream)"]

        subgraph approved["Approved Public Tools"]
            Mirror1["Google Drive
(security reviewed)"]
            Mirror2["Slack
(security reviewed)"]
        end

        subgraph internal["Internal Proprietary Tools"]
            Internal1["SAP ERP connector"]
            Internal2["Customer Database"]
            Internal3["Internal Analytics"]
        end

        Agent["Corporate Agent"]
    end

    PubReg --> PubServers
    PubReg -.->|"Selective sync
(after security review)"| PrivReg
    PrivReg --> Mirror1
    PrivReg --> Mirror2
    PrivReg --> Internal1
    PrivReg --> Internal2
    PrivReg --> Internal3
    Agent -->|"Discovery query"| PrivReg

    Firewall["Corporate Firewall"]
    PubReg -.-> Firewall
    Firewall -.-> PrivReg

    classDef publicStyle fill:#1e293b,stroke:#8b5cf6,stroke-width:2px
    classDef privateStyle fill:#1e293b,stroke:#10b981,stroke-width:2px
    classDef agentStyle fill:#1e293b,stroke:#6366f1,stroke-width:3px

    class PubReg,PubServers publicStyle
    class PrivReg,Mirror1,Mirror2,Internal1,Internal2,Internal3 privateStyle
    class Agent agentStyle
                    

3.4 Synchronization and Approval Workflows

Private registries implement selective mirroring of public registry content through approval workflows:

1. Discovery: Security team browses public registry for useful community-contributed servers
2. Review: Candidate servers undergo security audit (source code review, dependency analysis, network behavior inspection)
3. Approval: Vetted servers are marked for synchronization and appear in private registry
4. Continuous Sync: Private registry polls public registry for updates to approved servers using timestamp-based incremental sync (e.g., ?updated_since=2025-11-01)
5. Revocation: If a previously approved public server is found vulnerable, it's removed from private registry, and agents lose access immediately

4. Market Implementations Analysis

4.1 Microsoft Azure: Identity-Centric Approach

Microsoft's MCP implementation leverages its mature Azure ecosystem, particularly Azure API Management (APIM) and Microsoft Entra ID (formerly Azure AD). The strategic differentiator is seamless integration with enterprise identity infrastructure.

Key Features:

• Automatic API Translation: APIM ingests OpenAPI specifications and dynamically exposes existing REST APIs as MCP tools, eliminating need to rewrite backend services
• Entra ID Integration: Native OBO flow support with automatic token exchange, conditional access policies (require MFA, restrict by location), and Azure RBAC integration
• Azure API Center: Centralized registry combining MCP servers with traditional APIs, providing unified discovery and governance portal
• Enterprise Policies: Inherited Azure Policy framework applies compliance controls (data residency, encryption standards) to MCP traffic transparently

Use Case Fit: Organizations heavily invested in Microsoft 365 and Azure will find this the path of least resistance. The ability to expose Dynamics 365 ERP or SharePoint as MCP tools without custom development is compelling for enterprise adoption.

4.2 Docker: Security-by-Isolation

Docker's MCP approach prioritizes runtime security through container isolation, targeting both developer experience and production safety.

Key Features:

• Containerized Servers: Every MCP server runs as an isolated container with no direct host network or filesystem access except explicit bind mounts
• Secrets Injection: Gateway intercepts tool calls and injects credentials at runtime via environment variables, preventing hardcoded secrets in containers
• Supply Chain Security: Automatic signature verification of container images against Docker Content Trust before execution
• One-Click Catalog: Docker Desktop integration allows developers to browse curated MCP servers and install with single command, automatically managing container lifecycle

Use Case Fit: Development teams prioritizing rapid experimentation with strong security guardrails. The container-per-server model prevents a compromised tool from affecting others or the host system. Particularly relevant for multi-tenant SaaS platforms exposing MCP to customers.

4.3 Kong: Traffic Intelligence & Observability

Kong adapts its API gateway expertise to MCP, treating agentic traffic with the same rigor as mission-critical API infrastructure.

Key Features:

• Semantic Caching: Gateway caches tool responses based on semantic similarity of requests, not just exact matches, reducing backend load and LLM token costs
• Advanced Observability: Native integrations with Datadog, Splunk, Prometheus for tracking token usage, tool latency percentiles, and error rate analysis
• Sticky Session Mastery: Production-grade session affinity implementation for Kubernetes with health-aware failover
• AI Guardrails: Plugin ecosystem for prompt injection detection, PII redaction, and content filtering applied at wire speed

Use Case Fit: Organizations with existing Kong infrastructure or those requiring fine-grained traffic control and deep observability. Ideal for high-throughput scenarios where caching and rate limiting directly impact operational costs.

4.4 Cloudflare: Edge Computing & Stateful Scale

Cloudflare's approach leverages its global edge network and novel Durable Objects primitive to solve stateful connection scalability.

Key Features:

• Durable Objects: Globally distributed, persistent compute instances that can "hibernate" when idle (releasing CPU but maintaining state in memory), then wake instantly when traffic arrives, enabling cost-efficient management of thousands of concurrent MCP sessions
• Edge Deployment: MCP servers deployed to Cloudflare's edge network, reducing latency for globally distributed agents
• WebSockets Serverless: First-class support for long-lived WebSocket connections in serverless environment via hibernation model
• Managed MCP Servers: Cloudflare-hosted servers (e.g., headless browser for web scraping) available as managed services on global network

Use Case Fit: Applications requiring global scale and minimal latency for distributed agent workforces. Particularly attractive for consumer-facing AI products where geography-specific compliance (data residency) and performance are critical.

5. Scalability & Resilience Patterns

5.1 Session Affinity Challenges

MCP's stateful nature creates load balancing complexity. After initial capability negotiation, the session ID binds client and server. Routing subsequent requests to a different backend (lacking session context) causes protocol failure.

Traditional solutions like IP-based sticky sessions are fragile in modern networks due to NAT traversal and mobile client roaming. Cookie-based affinity works but requires Layer 7 load balancers with application awareness. The recommended approach is header-based affinity using the X-MCP-Session-ID header, allowing intelligent routing even across multiple gateway tiers.

5.2 Circuit Breaker Pattern for Long-Running Tools

AI tools can be unpredictable in execution time. A "generate financial report for Q4" tool might complete in seconds or run for minutes depending on data volume. Without safeguards, cascading failures occur when multiple agents block waiting for slow tools.

Gateways implement Circuit Breakers. If a tool exceeds timeout thresholds or failure rate limits, the circuit "opens" and subsequent calls to that tool fail immediately with descriptive errors rather than blocking. After a cooldown period, the circuit enters "half-open" state, allowing test requests to probe if the issue resolved.

Think of it this way: Imagine an office building where one elevator keeps breaking down, trapping people inside for hours. Without a circuit breaker, employees keep trying that elevator, creating queues and wasting time. A circuit breaker is like posting an "Out of Service" sign after the second breakdown. People immediately use the stairs or other elevators instead of waiting hopelessly. After maintenance, the sign comes down (half-open), and one person tests if it's working before everyone piles in.

sequenceDiagram
    participant Agent as MCP Agent
    participant Gateway as Gateway
(Circuit Breaker)
    participant Tool as Backend Tool

    rect rgb(20, 50, 30)
        Note over Agent,Tool: CLOSED State: Normal Operation
        Agent->>Gateway: 1. Tool invocation
        Gateway->>Tool: Forward request
        Tool-->>Gateway: Success response
        Gateway-->>Agent: Return result
        Note right of Gateway: Success counter: 0 failures
    end

    rect rgb(40, 20, 20)
        Note over Agent,Tool: CLOSED to OPEN: Failure Threshold
        Agent->>Gateway: 2. Tool invocation
        Gateway->>Tool: Forward request
        Tool--xGateway: Timeout (no response)
        Note right of Gateway: Failure 1/5

        Agent->>Gateway: 3. Tool invocation
        Gateway->>Tool: Forward request
        Tool--xGateway: Timeout
        Note right of Gateway: Failure 2/5

        Agent->>Gateway: 4. Tool invocation
        Gateway->>Tool: Forward request
        Tool--xGateway: Timeout
        Note right of Gateway: Failure 5/5
OPEN CIRCUIT

        Agent->>Gateway: 5. Tool invocation
        Gateway-->>Agent: Fast-fail: Circuit open
        Note right of Gateway: OPEN State:
No backend calls
    end

    rect rgb(40, 30, 20)
        Note over Agent,Tool: HALF-OPEN: Testing Recovery
        Note right of Gateway: After cooldown (30s)
        Agent->>Gateway: 6. Tool invocation
        Note right of Gateway: Circuit HALF-OPEN
        Gateway->>Tool: Test request (limited)
        Tool-->>Gateway: Success
        Gateway-->>Agent: Return result
        Note right of Gateway: Test passed
Circuit CLOSED
    end

    rect rgb(20, 50, 30)
        Note over Agent,Tool: Back to CLOSED: Normal Operation
        Agent->>Gateway: 7. Tool invocation
        Gateway->>Tool: Forward request
        Tool-->>Gateway: Success
        Gateway-->>Agent: Return result
    end
                    

5.3 WebSockets vs. Server-Sent Events Revisited

While Part 1 of this series discussed the evolution from SSE to Streamable HTTP, production gateways must also support WebSockets for specific use cases:

• Bidirectional Streaming: WebSockets enable true full-duplex communication, allowing servers to push notifications to agents without client polling
• Cancellation Support: WebSockets allow immediate interruption of long-running operations (e.g., agent decides a query is taking too long and cancels mid-execution)
• Lower Latency: Persistent connection eliminates HTTP handshake overhead on every request, critical for high-frequency tool invocations

However, WebSockets require more complex connection management (ping/pong heartbeats, reconnection logic). Best practice is dual-transport support: WebSockets for high-performance production agents, Streamable HTTP for simpler clients and development environments.

6. Security Considerations

While gateway architecture and service discovery provide operational benefits, security remains paramount in enterprise deployments. This section introduces key security concepts that inform gateway design, with comprehensive treatment reserved for Part 3 of this series.

6.1 Authentication and Authorization Basics

MCP Gateways act as policy enforcement points for authentication and authorization. Modern implementations leverage OAuth 2.0 with token-based authentication, ensuring that backend systems verify not just that a request is authenticated, but that it carries the appropriate user context and permissions.

A critical pattern is the On-Behalf-Of (OBO) flow, where the gateway exchanges user tokens to propagate identity through the system. This prevents "Confused Deputy" attacks where an agent with elevated privileges could be tricked into performing unauthorized actions on behalf of unprivileged users.

6.2 Container Isolation and Supply Chain

Production implementations like Docker's MCP Gateway demonstrate best practices for runtime isolation. MCP servers execute in ephemeral containers with restricted network access and no direct filesystem privileges. Image signature verification ensures only vetted, signed images execute, preventing malicious servers from entering the environment.

6.3 Content Inspection and Data Protection

Advanced gateways from vendors like Kong include plugins for deep packet inspection, scanning JSON-RPC traffic for prompt injection attempts and sensitive data leakage. These mechanisms complement authentication by providing defense-in-depth against content-based attacks.

7. Future Evolution & Protocol Roadmap

7.1 Asynchronous Operations (SEP-1686)

Current MCP is fundamentally synchronous: invoke tool → wait → receive result. For long-running operations (data migrations, complex analytics, batch processing), this model breaks due to HTTP timeout constraints and resource waste from blocked connections.

Specification Enhancement Proposal 1686 introduces formal Task abstraction:

1. Agent initiates operation, immediately receives task_id
2. Agent can poll task status, subscribe to progress notifications via SSE, or register webhooks
3. Server executes asynchronously in background worker process
4. Agent retrieves results when notified of completion

Architectural Impact: Requires message queue integration (RabbitMQ, AWS SQS, Google Pub/Sub) and durable task state storage. Gateways become orchestration layers managing task lifecycle, not just request proxies.

7.2 Protocol Statelessness (SEP-1442)

The holy grail of MCP scalability is eliminating persistent session state. SEP-1442 proposes modifying the protocol so all execution context travels with requests or uses recoverable state mechanisms (e.g., capability negotiation results cached in Redis with TTL).

Impact if implemented: Enables pure serverless deployment (AWS Lambda, Google Cloud Run) without sticky session requirements. Gateways become stateless load balancers. Costs drop dramatically as compute auto-scales to zero during idle periods.

7.3 Multi-Party Consent & Federated Authorization

Emerging requirement in regulated industries: operations requiring approval from multiple stakeholders before execution. Example: AI agent in healthcare attempting to modify patient treatment plan requires both attending physician approval and patient consent.

Future MCP extensions may integrate with policy engines (Open Policy Agent, AWS Verified Permissions) and workflow orchestrators (Temporal, Cadence) to support multi-party authorization flows directly at the protocol level.

8. Conclusion

The Model Context Protocol represents a foundational shift in how AI systems integrate with enterprise infrastructure. However, the protocol specification alone is insufficient for production deployment. The transition from experimental agent prototypes to mission-critical systems demands sophisticated infrastructure: Gateways that mediate connectivity, manage session complexity, and provide operational visibility; Registries that enable dynamic capability discovery while respecting organizational boundaries and compliance requirements.

This examination of gateway architecture and service discovery reveals several critical imperatives:

1. Gateway-Mediated Architecture is Mandatory: The N×M connectivity problem makes direct agent-to-server topologies operationally untenable at enterprise scale. Gateways provide the centralization necessary for policy enforcement, observability, and operational control.
2. Adopt Proven Distributed Systems Patterns: The Ambassador and Backend-for-Frontend patterns translate effectively to agentic infrastructure. Treat gateways as specialized ambassadors that isolate agents from infrastructure complexity.
3. Federate Registries for Organizational Boundaries: Public registries enable ecosystem collaboration, while private downstream registries provide control over approved tools and proprietary capabilities. Selective mirroring balances openness with governance.
4. Choose Implementations Based on Strengths: Microsoft for identity integration and enterprise ecosystem fit, Docker for isolation and developer experience, Kong for traffic management and observability, Cloudflare for edge deployment and global scale.
5. Design for Protocol Evolution: Asynchronous operations and statelessness are on the roadmap. Build extensible architectures that can adapt to future enhancements without requiring complete rewrites.

The convergence of standardized protocols (MCP), intelligent mediation layers (Gateways), and dynamic discovery systems (Registries) forms the infrastructure backbone for the emerging "Internet of Agents," an ecosystem where autonomous AI systems collaborate efficiently with enterprise data and systems. Part 3 of this series will examine the security and governance patterns necessary to operate this infrastructure safely in production environments.

9. References

1. Anthropic. (2025). "Introducing the Model Context Protocol." Anthropic News. Retrieved from https://www.anthropic.com/news/model-context-protocol
2. Model Context Protocol. (2025). "Specification 2025-06-18." Official MCP Documentation. Retrieved from https://modelcontextprotocol.io/specification/2025-06-18
3. Xenoss. (2025). "Is MCP ready for enterprise adoption? Use cases, security, and implementation challenges." Xenoss Blog. Retrieved from https://xenoss.io/blog/mcp-model-context-protocol-enterprise-use-cases-implementation-challenges
4. Microsoft Learn. (2025). "Expose REST API in API Management as MCP server." Azure API Management Documentation. Retrieved from https://learn.microsoft.com/en-us/azure/api-management/export-rest-mcp-server
5. Docker. (2025). "MCP Gateway - Docker Docs." Docker AI Documentation. Retrieved from https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/
6. Docker. (2025). "MCP Security: Risks, Challenges, and How to Mitigate." Docker Blog. Retrieved from https://www.docker.com/blog/mcp-security-explained/
7. Kong Inc. (2025). "AI MCP Proxy - Plugin." Kong Documentation. Retrieved from https://developer.konghq.com/plugins/ai-mcp-proxy/
8. Kong Inc. (2025). "AI Guardrails: Ensure Safe, Responsible, Cost-Effective AI Integration." Kong Blog. Retrieved from https://konghq.com/blog/engineering/ai-guardrails
9. Cloudflare. (2025). "Durable Objects from Cloudflare." Cloudflare Workers. Retrieved from https://workers.cloudflare.com/product/durable-objects
10. Cloudflare Developers. (2025). "Transport - Model Context Protocol." Cloudflare Agents Documentation. Retrieved from https://developers.cloudflare.com/agents/model-context-protocol/transport/
11. Check Point Software. (2025). "MCP Security - Risks and Best Practices." Check Point Cyber Hub. Retrieved from https://www.checkpoint.com/cyber-hub/cyber-security/what-is-ai-security/mcp-security/
12. Elastic Security Labs. (2025). "MCP Tools: Attack Vectors and Defense Recommendations for Autonomous Agents." Elastic Security Labs. Retrieved from https://www.elastic.co/security-labs/mcp-tools-attack-defense-recommendations
13. MintMCP. (2025). "Understanding MCP Gateways for AI Infrastructure." MintMCP Blog. Retrieved from https://www.mintmcp.com/blog/understanding-mcp-gateways-ai-infrastructure
14. Microsoft Learn. (2025). "Ambassador pattern - Azure Architecture Center." Microsoft Azure Documentation. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/patterns/ambassador
15. Araujo, M. D. B. (2025). "The Back-end for Agents Pattern (BFA)." Medium. Retrieved from https://medium.com/@mdbaraujo/the-back-end-for-agents-pattern-bfa-32e69baf8da3
16. Curity. (2025). "Design MCP Authorization to Securely Expose APIs." Curity Resources. Retrieved from https://curity.io/resources/learn/design-mcp-authorization-apis/
17. WorkOS. (2025). "MCP Registry Architecture: A Technical Overview." WorkOS Blog. Retrieved from https://workos.com/blog/mcp-registry-architecture-technical-overview
18. Model Context Protocol Blog. (2025). "Introducing the MCP Registry." MCP Blog. Retrieved from http://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
19. Portkey. (2025). "Retries, fallbacks, and circuit breakers in LLM apps: what to use when." Portkey Blog. Retrieved from https://portkey.ai/blog/retries-fallbacks-and-circuit-breakers-in-llm-apps/
20. Model Context Protocol. (2025). "Roadmap - Development." MCP Development Documentation. Retrieved from https://modelcontextprotocol.io/development/roadmap