What Is MCP? Model Context Protocol for Developers

Before MCP, connecting an LLM to a tool meant custom code for each integration. If you wanted Claude Desktop to query your database, you wrote a Claude-specific plugin. If you wanted the same capability in Cursor, you wrote a different integration. Each client had its own format for tool definitions, argument passing, and result handling.

MCP standardizes this. A tool author writes one MCP server, and it works with any MCP-compatible client: Claude Desktop, Cursor, Windsurf, your own custom app. The server exposes tools, resources, and prompts through a well-defined protocol, and the client discovers and uses them without custom glue code.

This is the same pattern that made HTTP successful. Web servers do not need to know whether the client is Chrome, Firefox, or a mobile app. They speak a common protocol. MCP does the same for AI tool integration.

The protocol has three components:

• MCP Host: The application the user interacts with. Examples: Claude Desktop, an IDE with AI features, your own chatbot.
• MCP Client: A component inside the host that manages the connection to MCP servers. It handles protocol negotiation, capability discovery, and message routing.
• MCP Server: A lightweight service that exposes specific capabilities. It runs locally or remotely and responds to requests from the client.

An MCP server can expose three types of capabilities:

• Tools: Functions the LLM can call (like function calling, but standardized). Example: a tool that queries your Supabase database.
• Resources: Data the LLM can read. Example: the contents of a file, a database schema, or a webpage.
• Prompts: Reusable prompt templates with parameters. Example: a code review prompt that takes a file path as input.

The client discovers these capabilities at startup and makes them available to the LLM.

Here is a minimal MCP server in TypeScript that exposes a single tool for converting KES to USD:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({
  name: 'currency-converter',
  version: '1.0.0',
});

// Define a tool
server.tool(
  'convert_kes_to_usd',
  'Convert an amount from Kenyan Shillings to US Dollars',
  {
    amount: z.number().describe('Amount in KES'),
  },
  async ({ amount }) => {
    // In production, fetch live rates from an API
    const rate = 0.0077; // approximate KES to USD rate
    const usd = (amount * rate).toFixed(2);
    return {
      content: [
        {
          type: 'text' as const,
          text: `KES ${amount.toLocaleString()} = USD ${usd} (approximate rate)`,
        },
      ],
    };
  }
);

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

Save this as index.ts, install the MCP SDK (npm install @modelcontextprotocol/sdk zod), and you have a working MCP server.

To use your MCP server with Claude Desktop, add it to the configuration file:

// claude_desktop_config.json
{
  "mcpServers": {
    "currency-converter": {
      "command": "npx",
      "args": ["tsx", "/path/to/your/index.ts"]
    }
  }
}

On macOS, this file lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Linux, check ~/.config/Claude/.

After restarting Claude Desktop, the currency converter tool appears in the tool list. When you ask Claude "How much is 50,000 KES in dollars?", it calls your MCP server, gets the result, and responds with the converted amount.

The same server works with Cursor, Windsurf, or any other MCP-compatible client. You write the server once and connect it everywhere.

Use MCP when:

• You want the same tool to work across multiple AI clients without rewriting integrations.
• You are building internal tools that your team uses through Claude Desktop or an IDE.
• You want to give an LLM access to local resources (files, databases) that the model cannot reach through its API.
• You are building a product and want third-party developers to extend it with custom tools.

MCP is not needed when:

• You are building a single-purpose chatbot with a fixed set of tools. Standard function calling through the model's API is simpler and more direct.
• You need high-throughput, low-latency tool execution. MCP adds a protocol layer. For performance-critical paths, direct API integration is leaner.
• You are prototyping and want to move fast. MCP is a protocol, and protocols add structure. For a weekend project, just write the integration inline.

MCP is a young protocol. The ecosystem is growing rapidly, with community-built servers for databases, APIs, file systems, and development tools. Expect the tooling and documentation to improve significantly over the coming months.