Module 5: Model Context Protocol (MCP)

Lesson 3: MCP in Distributed Systems

MCP is not limited to your local machine. Its true power lies in its ability to coordinate tools and data sources across Distributed Networks. An architect uses MCP to build a "Spiderweb" of intelligence where different servers handle different parts of the enterprise.

In this lesson, we explore the two primary transport methods for MCP and how to design for Distributed Reliability.

---

1. Transport Methods: Stdio vs. HTTP

An MCP Server can talk to the Client in two ways:

A. Stdio (Standard Input/Output)

The Client launches the Server as a Subprocess.

• Pros: Extremely fast (no network latency); very secure (local process).
• Cons: Only works if the Server and Client are on the same machine.
• Use Case: Claude Desktop connecting to your local file system.

B. SEE/HTTP (Event Streams)

The Client connects to a remote Server via a URL.

• Pros: Can connect to data sources anywhere in the world; allows for central "MCP Hubs."
• Cons: Higher latency (network round-trips); requires authentication/TLS.
• Use Case: A centralized "Company Knowledge" server that all employees' agents connect to.

---

2. Distributed Architecture: The "MCP Gateway"

For large organizations, we use an MCP Gateway pattern.

1. All data sources (DBs, Jira, Slack) have their own local MCP Servers.
2. An "MCP Gateway" aggregates these into a single endpoint.
3. The Architect's agent connects only to the Gateway.

Why?

• Security: You only manage one set of credentials for the Gateway.
• Caching: The Gateway can cache results to reduce cost.

---

3. Designing for Latency in a Distributed MCP

When your MCP server is "Distributed" (HTTP), every tool call adds 200ms - 2,000ms of latency.

Architect's Solution:

• Use Local Stdio for high-frequency tools (e.g., File editing).
• Use Remote HTTP for low-frequency data (e.g., Monthly reports).

---

4. Visualizing Distributed MCP

graph TD
    Client[Central AI Agent]
    subgraph "Local - Stdio"
    Client --- Tool1[Filesystem Server]
    Client --- Tool2[Terminal Server]
    end
    subgraph "Cloud - HTTP"
    Client -.->|Auth| Gateway[MCP Gateway]
    Gateway --- Tool3[Supabase Server]
    Gateway --- Tool4[Jira Server]
    end

---

5. Summary

• Stdio is for local speed and security.
• HTTP is for distributed scale and centralized access.
• Use a Gateway Pattern to manage complexity in large networks.

In the next lesson, we look at the core value of the protocol: Context Injection.

---

Interactive Quiz

1. Compare Stdio vs. HTTP transport in MCP.
2. What is an "MCP Gateway" and when would you use it?
3. How does network latency affect the "Agent Loop" (Module 2)?
4. Scenario: You want to give an agent access to your private company emails. Would you choose Stdio or HTTP for the server? Why?

---

Reference Video: