MCP (Model Context Protocol): What It Is and Why It Matters for AI Development

The Problem MCP Solves

Before MCP, connecting an AI model to your product's data meant one of two things. You either stuffed everything into the context window (expensive, brittle, limited by token counts) or you wrote a custom function calling schema for each specific model and integration you needed. Understanding what MCP is at the protocol level gives useful grounding before looking at the client and server architecture.

The second approach works until you have three different AI hosts calling three different versions of the same tool with three different schemas. Then you are maintaining redundant integration code, and any change to the underlying data source requires updates in multiple places.

MCP solves this with a single, well defined protocol. You build one MCP server that exposes your tools, resources, and prompts. Any MCP compatible host connects to it and gets everything. The protocol handles discovery, schema negotiation, and the actual tool call lifecycle.

Think of it as the USB standard for AI integrations. Before USB, every peripheral had its own connector. USB standardized the physical and protocol layer so any device worked with any port. MCP does the same for AI tool connections.

Core Architecture

MCP has three main components: hosts, clients, and servers.

Hosts

A host is any application that embeds an LLM and wants to give it access to external tools. Claude Code is a host. OpenClaw is a host. A custom chat interface you build is a host. The host is responsible for:

• Managing MCP server connections
• Injecting available tools, resources, and prompts into the LLM context
• Routing tool call results back to the model
• Handling authentication with servers

Clients

The MCP client is a library embedded in the host. It implements the protocol: connecting to servers, discovering capabilities, sending tool call requests, and returning results. Anthropic publishes official MCP client libraries for TypeScript and Python.

Servers

MCP servers are where your actual business logic lives. A server exposes three types of capabilities:

Tools are functions the model can call to take an action or fetch data. A tool has a name, a description (used by the model to decide when to call it), and a JSON Schema input definition.

Resources are data the model can read: files, database records, API responses. Unlike tools, reading a resource does not trigger an action. It just returns data into the context.

Prompts are reusable prompt templates that users can invoke by name. They are less commonly used but useful for standardizing how certain tasks are kicked off.

The transport layer between client and server is either stdio (the server is a local process, communication is through stdin and stdout) or HTTP with SSE (the server is a remote service).

Building an MCP Server

Here is a minimal TypeScript MCP server that exposes a tool to query a database:

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

const server = new Server(
  {
    name: "product-data-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// Declare available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "get_customer",
        description:
          "Fetch a customer record by ID. Returns name, email, plan, MRR, and churn risk score.",
        inputSchema: {
          type: "object",
          properties: {
            customer_id: {
              type: "string",
              description: "The unique customer identifier",
            },
          },
          required: ["customer_id"],
        },
      },
    ],
  };
});

// Handle tool calls
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_customer") {
    const { customer_id } = request.params.arguments as { customer_id: string };

    // Your actual database query here
    const customer = await db.customers.findById(customer_id);

    if (!customer) {
      return {
        content: [
          {
            type: "text",
            text: `No customer found with ID ${customer_id}`,
          },
        ],
        isError: true,
      };
    }

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(customer, null, 2),
        },
      ],
    };
  }

  throw new Error(`Unknown tool: ${request.params.name}`);
});

// Start the server
const transport = new StdioServerTransport();
await server.connect(transport);

The server declares its tools in ListTools, handles calls in CallTool, and communicates over stdio. Connect this to Claude Code by adding it to your .claude/settings.json:

{
  "mcpServers": {
    "product-data": {
      "command": "node",
      "args": ["./mcp-servers/product-data/dist/index.js"],
      "env": {
        "DATABASE_URL": "${DATABASE_URL}"
      }
    }
  }
}

Now Claude Code can call get_customer with a customer ID during any conversation, and it will hit your real database.

Adding Resources

Resources let the model pull in structured data without calling a tool. Here is how you add a resource that exposes recent error logs:

import {
  ListResourcesRequestSchema,
  ReadResourceRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// In your server setup, add resources to capabilities
const server = new Server(config, {
  capabilities: {
    tools: {},
    resources: {},
  },
});

server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "logs://errors/recent",
        name: "Recent Error Logs",
        description: "Last 100 application errors with stack traces",
        mimeType: "application/json",
      },
    ],
  };
});

server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  if (request.params.uri === "logs://errors/recent") {
    const errors = await getRecentErrors(100);
    return {
      contents: [
        {
          uri: request.params.uri,
          mimeType: "application/json",
          text: JSON.stringify(errors, null, 2),
        },
      ],
    };
  }

  throw new Error(`Unknown resource: ${request.params.uri}`);
});

MCP in Claude Code

Claude Code's MCP integration is one of the most mature host implementations available. When you add an MCP server to your Claude Code configuration, it:

1. Spawns the server process on startup
2. Calls ListTools, ListResources, and ListPrompts to discover capabilities
3. Includes discovered tools in the system prompt so the model knows what is available
4. Routes tool calls to the correct server process when the model invokes them
5. Injects tool results back into the conversation

The practical effect is that Claude Code gains persistent access to your custom tools for the entire session, not just for one request. If you are debugging a production issue, Claude Code can call your get_customer tool, check error logs via a resource, and query your metrics endpoint, all in a single reasoning loop without you having to paste data into the conversation.

See Claude Code Complete Guide for MCP configuration details.

MCP in OpenClaw

OpenClaw uses MCP servers to give agents access to external tools during messaging channel conversations. An OpenClaw agent configured with your product's MCP server can answer user questions by querying live data, not just by reasoning from training data.

The key difference from Claude Code is that OpenClaw is a persistent server. The MCP server connections are maintained across conversations, so the agent does not need to rediscover tools on every message. This is important for latency: MCP server initialization adds overhead, and you do not want that on every incoming WhatsApp message.

OpenClaw handles this by keeping a pool of active MCP connections per workspace and reusing them across requests. See What Is OpenClaw Complete Guide for workspace configuration details.

Why We Build MCP Servers for Client Products

When we ship an AI integration for a client at HouseofMVPs, we almost always build it as an MCP server rather than direct function calling or context stuffing.

The reasons are practical:

Reusability across hosts. A client who starts with Claude Code integration often wants to add an OpenClaw agent six months later. If the tools are MCP servers, the second integration is a configuration change, not a rebuild.

Clean separation of concerns. The MCP server owns its own database connection, authentication, and business logic. The AI model calls it through a defined interface. When the business logic changes, you update the MCP server without touching the prompt engineering.

Testability. An MCP server is a regular TypeScript or Python application. You can unit test it, integration test it, and run it standalone without an LLM in the loop. This matters enormously when the tool is doing anything consequential, like writing to a database or sending emails.

Rate limiting and observability. Because all model tool calls go through the MCP server, you can add logging, rate limiting, and metrics at the server layer. You know exactly which tools the model is calling, how often, and with what arguments.

Versioning. You can run multiple versions of an MCP server simultaneously. When you change a tool schema, you version the server and migrate hosts one at a time. This is much cleaner than updating function definitions inline in prompts.

For any product that needs AI agents interacting with real data, MCP is the right abstraction layer. See AI Integration Services for how we structure these engagements, or read the AI Agents Development overview for context on where MCP fits in a full agent architecture.

The AI Readiness Assessment can help you identify which parts of your current product are good candidates for MCP based tool exposure. For hands-on plugin development that builds on the same tool patterns MCP uses, see the OpenClaw plugin tutorial.