Production MCP Architecture

Recall Module 16’s own real Pinterest case study — a central registry, domain-specific servers, human-in-the-loop approval. This module builds the complete, real, enterprise pattern that architecture represents, and the genuine, operational discipline around it.

The real, complete enterprise architecture

flowchart TD
    A[AI Agent Platform] --> B[MCP Gateway]
    B --> C[GitHub MCP]
    B --> D[Database MCP]
    B --> E[CRM MCP]
    C --> F[GitHub API]
    D --> G[Database]
    E --> H[CRM]
    B --> I[Auth / Policy Enforcement]
    B --> J[Audit Logging]
    B --> K[Server Registry]

Why a real gateway layer earns its place

Recall Module 3’s own real, multi-client architecture — a Host genuinely manages one Client per Server directly. At real, enterprise scale, connecting every real agent directly to every real server individually genuinely becomes unmanageable — recall Module 1’s own n×m problem, resurfacing at a different, real layer. A gateway centralizes real, shared concerns — authentication, policy enforcement, audit logging — so individual servers don’t each need to reimplement them.

Real retries, timeouts, and circuit breakers

Recall your own resilience coursework’s real discipline directly — the same, genuine patterns apply here.

We’ll wrap a real MCP tool call with genuine, deliberate resilience, rather than trusting a single, real attempt.

import asyncio
from fastmcp import Client
from fastmcp.exceptions import ClientError

async def call_with_retry(server_path: str, tool_name: str, arguments: dict, max_attempts: int = 3):
    for attempt in range(1, max_attempts + 1):
        try:
            async with asyncio.timeout(5.0):  # a real, deliberate timeout, recall Module 15's own diagnostics
                async with Client(server_path) as client:
                    result = await client.call_tool(tool_name, arguments)
                    return result.data
        except (ClientError, TimeoutError) as e:
            if attempt == max_attempts:
                raise  # a real, honest failure after genuinely exhausting retries
            await asyncio.sleep(2 ** attempt)  # real, deliberate exponential backoff

Recall your LangChain course’s own real retry discipline — the same, genuine principle applies to any real, remote MCP connection: a transient, real network failure shouldn’t immediately become a user-facing error.

Real versioning — what happens when a tool schema changes

Recall Module 4’s own real capability negotiation — this is precisely where it matters most at production scale. When a real server’s tool schema genuinely changes — a new, required parameter, a renamed field — every real, connected client needs a way to detect this before a call silently fails or behaves unexpectedly.

The real, honest discipline: version your real MCP servers explicitly, recall serverInfo.version from Module 4’s own real initialization response, and treat a genuine, breaking schema change as a real, new major version, exactly the same discipline your API design coursework already taught for REST APIs.

Real registry and discovery — an honest, current distinction

This is worth being precise about, since it’s genuinely easy to overstate. Recall Module 16’s own real, verified MCP Registry API data — a real, official registry does exist, tracking real, published servers. It’s worth being honest, though: this is real, ecosystem tooling for discovering publicly available servers, not a mandatory, protocol-level requirement every deployment must use. A real, internal enterprise deployment — recall Pinterest’s own real, central registry from Module 16 — commonly builds its own, private registry instead, specifically for its own, internal servers.

Real observability at production scale

Recall Module 15’s own real logging discipline — production adds one, genuine additional requirement: auditability. Every real, write-capable tool call — recall Module 14’s own real distinction between read and write tools — deserves a real, permanent, queryable audit record: who initiated it, when, with what real arguments, and what the actual, real outcome was.

Common mistakes worth avoiding

Connecting every real agent directly to every real server, without a gateway, at genuine enterprise scale. Recall this module’s own opening diagram — shared, real concerns like auth and audit logging belong centralized, not reimplemented per server.

Treating a transient, real network failure as a permanent one. Recall this module’s own real retry example — genuine, deliberate backoff and a bounded number of attempts, echoing your own resilience coursework, prevents one, momentary blip from becoming a real, user-facing failure.

Assuming the public MCP registry is the only real way to discover servers. Recall this module’s own honest distinction — real, internal enterprise deployments commonly need their own, private, real registry instead.

What you should take away from this module

• A real gateway centralizes shared, enterprise concerns — auth, policy, audit logging — precisely the same n×m-to-n+m benefit Module 1 introduced, now applied to enterprise infrastructure itself.
• Real retries, timeouts, and circuit breakers apply to MCP connections using the exact same, genuine resilience discipline your prior coursework already taught.
• A tool schema change deserves the same, real versioning discipline as any REST API’s breaking change.
• The public MCP registry is real, useful ecosystem tooling — not a mandatory requirement every, real internal deployment must use.

Where this goes next

The final module brings this entire course together into one, complete, real system: the Capstone — Enterprise MCP-Powered AI Assistant, built file by file, exactly the way a real, production deployment actually would be.