The Model Context Protocol (MCP) is reshaping how AI applications connect to the world. Introduced by Anthropic in November 2024, MCP provides a standardized, open-source framework for Large Language Models (LLMs) to interact with external tools, data sources, and workflows. Instead of every AI platform building custom integrations for every backend system, MCP proposes a universal adapter pattern—an MCP server sits between the AI client (like Claude, ChatGPT, or GitHub Copilot) and the data or service.

But as with any emerging standard, the gap between a working prototype and a production-ready server is vast. In this article, we'll dissect the MCP server architecture, walk through a concrete implementation, explore real-world pitfalls, and outline patterns for secure, scalable deployments.

Understanding the MCP Server Architecture

At its core, MCP follows a clean client-server model. The MCP Host (the AI application) connects to one or more MCP Servers, each of which exposes a well-defined set of capabilities. Communication happens over a transport layer that abstracts the underlying connection mechanism—either stdio for local processes or Streamable HTTP for remote servers.

flowchart LR
    A[AI Client<br/>e.g., Claude Desktop] -->|MCP Protocol| B[MCP Host]
    B --> C{MCP Transport Layer}
    C -->|stdio| D[MCP Server A<br/>Local File System]
    C -->|Streamable HTTP| E[MCP Server B<br/>Remote Database]
    C -->|Streamable HTTP| F[MCP Server C<br/>External API]
    D --> G[Resources & Tools]
    E --> H[Resources & Tools]
    F --> I[Resources & Tools]

    style A fill:#4a90d9,color:#fff
    style B fill:#f5a623,color:#fff
    style C fill:#7ed321,color:#fff
    style D fill:#d0021b,color:#fff
    style E fill:#d0021b,color:#fff
    style F fill:#d0021b,color:#fff

Diagram: MCP Architecture showing transport abstraction and multiple server connections.

This transport abstraction is a key design decision. The same server implementation can run locally via stdio for development or be deployed as a remote HTTP service for production. The modelcontextprotocol.io specification defines this clearly, allowing developers to choose the right transport for their security and scalability needs.

The Resource-Tool-Prompt Triad

Every MCP server exposes three core primitives, as documented in the official SDK documentation:

1. Resources: Data that can be read—files, database records, API responses. These are the "what" the AI can access.
2. Tools: Functions the AI can invoke—search, calculate, send email. These are the "how" the AI can act.
3. Prompts: Pre-written templates for common interactions. These guide the AI's behavior.

This triad provides a structured, discoverable interface. When an AI client connects to an MCP server, it can introspect the available resources, tools, and prompts, enabling dynamic adaptation without hardcoded integrations.

Building a Production-Ready MCP Server

Let's move from theory to practice. Below is a minimal but complete MCP server implementation in TypeScript, based on the official SDK. This server provides a simple weather lookup tool.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// 1. Create server with capability declaration
const server = new Server(
  {
    name: "example-weather-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {}, // Declares that this server provides tools
    },
  }
);

// 2. Define the tool interface
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_weather",
      description: "Get current weather for a city",
      inputSchema: {
        type: "object",
        properties: {
          city: { type: "string" },
          units: { type: "string", enum: ["metric", "imperial"] },
        },
        required: ["city"],
      },
    },
  ],
}));

// 3. Implement tool logic with error handling
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_weather") {
    const city = String(request.params.arguments?.city);
    const units = String(request.params.arguments?.units || "metric");

    // In production, call a real weather API here
    // Add retry logic, rate limiting, and monitoring
    try {
      const temperature = units === "metric" ? 22 : 72;
      const condition = "Sunny";

      return {
        content: [
          { 
            type: "text", 
            text: `Weather in ${city}: ${condition}, ${temperature}°${units === 'metric' ? 'C' : 'F'}` 
          }
        ],
      };
    } catch (error) {
      // Return structured error information
      return {
        isError: true,
        content: [{ type: "text", text: `Failed to fetch weather: ${error.message}` }],
      };
    }
  }
  throw new Error("Tool not found");
});

// 4. Connect via stdio transport
const transport = new StdioServerTransport();
await server.connect(transport);

console.error("Weather MCP server running on stdio");

Code example: A minimal MCP server with proper error handling and structured responses.

This example demonstrates several production considerations:

• Capability Declaration: The server explicitly declares it provides tools. This allows the AI client to understand what's available.
• Input Validation: The inputSchema defines expected parameters and their types.
• Structured Error Handling: Instead of crashing, the server returns an isError response with a descriptive message.
• Logging to stderr: The server logs to stderr, keeping stdout clean for the MCP protocol messages.

Production Pitfalls and Hard Lessons

The MCP ecosystem is maturing rapidly, but early adopters have already encountered significant challenges. Understanding these pitfalls is crucial for any team deploying MCP servers in production.

Data Leakage from Multi-Tenant Servers

In early 2026, Asana's MCP feature suffered a critical bug that exposed customer data from one organization to other MCP users. As reported by BleepingComputer, a software bug in the tenant isolation logic allowed cross-organization data access. This incident underscores a fundamental requirement: every MCP server operating in a multi-tenant environment must implement strict tenant isolation at the database and application layers.

Chained Vulnerabilities in Official Servers

Even Anthropic's own Git MCP server was not immune. Security researchers discovered chained flaws that enabled arbitrary file access and remote code execution, as detailed by SiliconAngle. The vulnerabilities were particularly dangerous because they could be triggered through normal tool invocations, turning a useful integration into an attack vector.

Lesson: Treat MCP servers as high-risk endpoints. They have direct access to backend systems and are invoked by AI models that may be prompted to exploit them. Regular security audits, input sanitization, and least-privilege principles are non-negotiable.

The Integration Purgatory Problem

Workato's research, announced via BusinessWire, revealed that many AI initiatives stall because MCP servers are not production-ready. Common issues include:

• Missing error handling and retry logic
• No rate limiting or circuit breakers
• Lack of observability (logging, metrics, tracing)
• Inadequate authentication and authorization

Workato launched production-ready MCP servers specifically to address this "integration gap" that keeps AI initiatives in pilot purgatory.

Enterprise Patterns for Secure MCP Deployments

Capability-Based Security

Production MCP servers should implement capability-based security, where each server declares exactly what resources and tools it exposes. The AI client then enforces that the server only accesses permitted data. This pattern, recommended by Security Boulevard, prevents excessive permissions and limits blast radius in case of compromise.

The Enterprise Registry Pattern

Microsoft's MCP Center, built on Azure API Center, provides a centralized registry for MCP servers. This enables:

• Governance: Centralized policy enforcement and approval workflows
• Discoverability: AI clients can find available servers dynamically
• Lifecycle Management: Versioning, deprecation, and retirement of servers

For organizations deploying multiple MCP servers, a registry pattern is essential for managing complexity at scale.

Transport Security Considerations

The choice between stdio and Streamable HTTP transport has security implications:

For remote servers, always enforce TLS, implement OAuth2 or API key authentication, and use network segmentation to limit exposure.

Key Takeaways

• MCP standardizes AI-tool integration through a clean client-server architecture with transport abstraction, backed by major players including Anthropic, OpenAI, and Microsoft.
• Production MCP servers must prioritize security—implement tenant isolation, capability-based permissions, and regular security audits to prevent data leakage and code execution vulnerabilities.
• Observability and resilience are non-negotiable—include error handling, rate limiting, retry logic, and monitoring from day one to avoid the "integration purgatory" that stalls AI initiatives.
• Choose your transport wisely—stdio for simplicity and local use, Streamable HTTP for remote deployments with proper authentication and TLS.
• Enterprise registries like Microsoft's MCP Center enable governance, discoverability, and lifecycle management for MCP server deployments at scale.