What Is an MCP Server?

Model Context Protocol Explained

Last updated: March 2026 · 25 min read

Before MCP, every AI application that wanted to connect to an external tool — a database, a file system, a Slack workspace, a payment processor — had to build a custom integration from scratch. If you had 10 different AI tools and 50 different services, you needed 500 separate integrations. Each with its own authentication, data format, error handling, and maintenance burden.

MCP collapses this from an N×M problem into an N+M problem. Build one MCP server for your service, and every MCP-compatible AI model can use it. Connect your AI model to MCP once, and it can use every MCP server. The same way USB standardized how peripherals connect to computers, MCP standardizes how AI models connect to tools.

This guide covers everything about MCP: what it is, how it works architecturally, how to build your own MCP server in TypeScript and Python, security considerations, hosting options, and where the protocol is headed. Whether you are a developer building AI applications, a business wanting to make your product AI-accessible, or a technical leader evaluating the agentic web, this is the comprehensive reference.

What Problem Does MCP Solve?

The AI industry in 2024-2025 faced a fragmentation crisis. Every AI provider — OpenAI, Anthropic, Google, Microsoft, Meta — had its own way of connecting AI models to external tools. OpenAI had function calling and plugins. Anthropic had tool use. Google had extensions. LangChain had its own tool abstraction. CrewAI had another.

For tool providers, this meant building and maintaining separate integrations for each AI platform. For AI application developers, this meant writing glue code for every tool they wanted to use. For enterprises, this meant vendor lock-in — choosing one AI platform meant being locked into that platform's tool ecosystem.

This is the exact same problem the computing industry solved decades ago with standards like USB, HTTP, and SQL. Before USB, every peripheral manufacturer had to build a different connector for each computer brand. USB created a universal interface that any device could use with any computer.

MCP does the same thing for AI. It is a universal protocol that any AI model can use to connect to any tool. The server side (the tool) speaks MCP. The client side (the AI model) speaks MCP. They can communicate without either side knowing the implementation details of the other.

MCP Adoption in 2026

MCP was released by Anthropic as an open-source specification in November 2024. In just over a year, it has become the de facto standard for AI-tool integration. The adoption numbers tell the story:

Metric	Figure	Context
Monthly SDK downloads	97 million	npm + PyPI combined (as of Q1 2026)
GitHub stars (spec repo)	45,000+	modelcontextprotocol/specification
Public MCP servers	10,000+	Listed across registries (Smithery, mcp.so, PulseMCP)
Major adopters	Anthropic, OpenAI, Google, Microsoft	All four major AI labs support MCP
Client implementations	50+	Claude Desktop, VS Code, Cursor, Windsurf, Cline, etc.

The adoption timeline moved remarkably fast. Anthropic released MCP in November 2024. By January 2025, it had gained significant developer traction. In March 2025, OpenAI announced MCP support in ChatGPT — a significant endorsement from Anthropic's primary competitor. Google and Microsoft followed shortly after.

The protocol is now governed as an open standard with contributions from multiple organizations. The specification, SDKs, and reference implementations are all open-source under permissive licenses. This ensures no single company controls the standard, which has been critical for cross-industry adoption.

How Does MCP Work? Architecture Explained

MCP uses a client-server architecture with three distinct roles: hosts, clients, and servers. Understanding these roles is essential for building and integrating MCP servers.

The Three Roles

Communication Flow

MCP uses JSON-RPC 2.0 as its message format — the same lightweight protocol used by the Language Server Protocol (LSP) and many blockchain RPC interfaces. Here is the typical flow when a user asks an AI to perform an action:

1. User sends a message to the host (e.g., "Check my GitHub pull requests").
2. Host sends the message to the AI model along with a list of available tools from connected MCP servers.
3. AI model decides to use a tool and returns a tool call request (e.g., list_pull_requests with parameters {"repo": "my-org/my-repo", "state": "open"}).
4. Host routes the tool call to the appropriate client, which forwards it to the MCP server.
5. MCP server executes the tool (in this case, calls the GitHub API) and returns the result.
6. Client sends the result back to the host, which passes it to the AI model.
7. AI model incorporates the result into its response and replies to the user.

The user does not need to know any of this is happening. They ask a question, the AI model decides which tools to use, calls them through MCP, and returns a coherent answer. The protocol handles all the coordination.

What MCP Servers Expose

An MCP server can expose three types of capabilities, called "primitives":

Primitive	Description	Controlled By	Example
Tools	Executable functions the AI can call	AI model decides when to use	search_products, create_issue, send_email
Resources	Read-only data the AI can access	Client/user controls access	File contents, database records, API responses
Prompts	Reusable prompt templates	User selects which to use	"Summarize this PR", "Generate release notes"

Tools are the most commonly used primitive. Each tool has a name, a description (which the AI model reads to decide when to use it), and an input schema (defining what parameters the tool accepts). The AI model autonomously decides when to call a tool based on the user's request and the tool's description.

Resources are data that the server makes available for the AI to read. Unlike tools, resources are typically listed and selected by the client or user, not invoked autonomously by the model. Resources are useful for providing context — loading a file, fetching a customer record, retrieving documentation.

Prompts are pre-defined templates that guide the AI model's behavior for specific tasks. They can include tool calls, resource references, and structured instructions. Prompts are user-controlled — the user explicitly selects a prompt template, and the AI follows it.

Types of MCP Servers: Local vs Remote

MCP servers communicate with clients through different transport mechanisms depending on the deployment model. Understanding these transports is important for choosing the right architecture.

Local Servers (stdio Transport)

Local MCP servers run on the same machine as the AI client and communicate through standard input/output (stdio). The client spawns the server as a child process and exchanges JSON-RPC messages through stdin and stdout.

This is the most common transport for desktop applications. When you configure an MCP server in Claude Desktop, VS Code, or Cursor, you are typically pointing to a local executable (a Node.js script, a Python script, or a compiled binary) that runs via stdio.

// Example: Claude Desktop MCP server configuration
// Located at: ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "my-tool": {
      "command": "node",
      "args": ["/path/to/my-server.js"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

Advantages: Simple setup, no network overhead, no authentication needed (the process already runs with the user's permissions), works offline.

Use cases: IDE extensions, desktop AI assistants, local file system access, development tools, personal automation.

Remote Servers (HTTP Transport)

Remote MCP servers run on a web server and communicate over HTTP. There have been two HTTP transports in MCP's evolution:

Server-Sent Events (SSE) — Original HTTP Transport

The original remote transport used HTTP POST for client-to-server messages and Server-Sent Events (SSE) for server-to-client streaming. This worked but had limitations: it required long-lived connections, was difficult to load-balance, and did not work well with serverless platforms that have execution timeouts.

Streamable HTTP — Current Recommended Transport

Streamable HTTP is the newest and now recommended transport for remote MCP servers. It uses standard HTTP POST requests for all communication. The server can optionally upgrade responses to SSE for streaming, but this is not required. This makes it compatible with any HTTP infrastructure — CDNs, load balancers, serverless platforms, API gateways.

// Streamable HTTP endpoint
// POST /mcp — receives JSON-RPC requests, returns JSON-RPC responses
// Optionally returns Content-Type: text/event-stream for streaming

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_products",
    "arguments": { "query": "laptop", "max_results": 5 }
  }
}

Advantages: Works with any HTTP infrastructure, serverless-friendly, easy to load-balance, supports streaming when needed.

Use cases: Web services, SaaS product integrations, public APIs, AI-visible websites, multi-tenant applications.

Popular MCP Servers

The MCP ecosystem has grown rapidly since launch. Here are some of the most widely used MCP servers, organized by category.

Developer Tools

Server	Description	Key Tools
Filesystem	Read, write, search local files	read_file, write_file, search_files, list_directory
GitHub	GitHub API integration	create_issue, list_pull_requests, search_code, create_branch
Git	Local git operations	git_status, git_diff, git_log, git_commit
PostgreSQL	Database queries and schema	query, list_tables, describe_table

Business & Productivity

Server	Description	Key Tools
Slack	Slack workspace integration	send_message, search_messages, list_channels
Google Drive	File management in Drive	search_files, read_file, create_file
Stripe	Payment and billing operations	list_customers, create_invoice, get_balance
Linear	Project management	create_issue, list_issues, update_issue
Notion	Workspace and documentation	search_pages, create_page, query_database

Data & Search

Server	Description	Key Tools
Brave Search	Web search via Brave API	web_search, local_search
Fetch	Fetch and parse web content	fetch_url, extract_text
Puppeteer	Browser automation	navigate, screenshot, click, fill_form

You can discover more servers on registries like Smithery, mcp.so, and PulseMCP. The official MCP specification repository also maintains a curated list of reference servers.

Building Your First MCP Server in TypeScript

The fastest way to build an MCP server is with the official TypeScript SDK. This example builds a complete MCP server that exposes two tools: one to search a product catalog and one to get product details.

Step 1: Set Up the Project

mkdir my-mcp-server
cd my-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node
npx tsc --init

The @modelcontextprotocol/sdk package is the official MCP SDK. zod is used for input validation and schema generation — the SDK can automatically convert Zod schemas into JSON Schema for tool definitions.

Step 2: Create the Server

// src/index.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// Sample product data (in production, this would be a database)
const products = [
  { id: "1", name: "AI Visibility Audit", category: "service",
    price: 2500, description: "Complete audit of your website's AI readiness" },
  { id: "2", name: "MCP Server Build", category: "service",
    price: 5000, description: "Custom MCP server for your product" },
  { id: "3", name: "Agentic Web Package", category: "service",
    price: 8000, description: "Full 4-layer agentic web implementation" },
];

// Create the MCP server
const server = new McpServer({
  name: "product-catalog",
  version: "1.0.0",
  capabilities: {
    tools: {},
  },
});

// Tool 1: Search products
server.tool(
  "search_products",
  "Search the product catalog by keyword or category",
  {
    query: z.string().optional().describe("Search keyword"),
    category: z.string().optional().describe("Filter by category"),
    max_results: z.number().default(10).describe("Maximum results to return"),
  },
  async ({ query, category, max_results }) => {
    let results = products;

    if (query) {
      const q = query.toLowerCase();
      results = results.filter(
        (p) =>
          p.name.toLowerCase().includes(q) ||
          p.description.toLowerCase().includes(q)
      );
    }

    if (category) {
      results = results.filter(
        (p) => p.category === category.toLowerCase()
      );
    }

    results = results.slice(0, max_results);

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

// Tool 2: Get product details
server.tool(
  "get_product",
  "Get detailed information about a specific product by ID",
  {
    product_id: z.string().describe("The product ID"),
  },
  async ({ product_id }) => {
    const product = products.find((p) => p.id === product_id);

    if (!product) {
      return {
        content: [
          {
            type: "text",
            text: `Product with ID "${product_id}" not found.`,
          },
        ],
        isError: true,
      };
    }

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

// Start the server with stdio transport
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Product catalog MCP server running on stdio");
}

main().catch(console.error);

Step 3: Build and Test

# Build
npx tsc

# Test with the MCP inspector (official debugging tool)
npx @modelcontextprotocol/inspector node dist/index.js

The MCP Inspector opens a web interface where you can see your server's tools, call them with test inputs, and inspect the responses. It is the primary debugging tool for MCP development.

Step 4: Connect to Claude Desktop

Add your server to Claude Desktop's configuration file:

// ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
// %APPDATA%\Claude\claude_desktop_config.json (Windows)
{
  "mcpServers": {
    "product-catalog": {
      "command": "node",
      "args": ["/absolute/path/to/dist/index.js"]
    }
  }
}

Restart Claude Desktop. You will see the tool icons appear in the chat interface. Ask Claude "what products are available?" and it will call your search_products tool to answer.

Building an MCP Server for the Web (HTTP Transport)

For web services, you need an HTTP-based MCP server. Here is how to implement one as a Next.js API route using the Streamable HTTP transport — the same pattern we use on p0stman.com.

// app/api/mcp/route.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

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

// Define your tools
server.tool(
  "get_services",
  "Get a list of available services with descriptions and pricing",
  {},
  async () => ({
    content: [{
      type: "text",
      text: JSON.stringify({
        services: [
          { name: "AI Visibility Audit", price: "from £2,500" },
          { name: "MCP Server Build", price: "from £5,000" },
        ]
      })
    }]
  })
);

// GET: Return server info (public, no auth)
export async function GET() {
  return Response.json({
    name: "your-product",
    version: "1.0.0",
    protocol: "mcp",
    tools: ["get_services"],
    docs: "https://yoursite.com/agents.md"
  });
}

// POST: Handle tool calls (add auth for production)
export async function POST(req: Request) {
  const body = await req.json();
  // Route to the MCP server for processing
  // Implementation depends on your specific setup
  // See @modelcontextprotocol/sdk documentation for
  // full Streamable HTTP transport setup
  return Response.json({ /* MCP response */ });
}

In production, the POST handler should include authentication (Bearer token or OAuth 2.1), rate limiting, input validation, and error handling. The GET endpoint can remain public as it only returns server metadata.

Building an MCP Server in Python

Python is equally well-supported through the official mcp package. The Python SDK uses a decorator-based API that is concise and readable.

# Install: pip install "mcp[cli]"

from mcp.server.fastmcp import FastMCP

# Create server
mcp = FastMCP("product-catalog")

# Define tools using decorators
@mcp.tool()
def search_products(query: str = "", category: str = "") -> str:
    """Search the product catalog by keyword or category."""
    products = [
        {"id": "1", "name": "AI Audit", "price": 2500},
        {"id": "2", "name": "MCP Build", "price": 5000},
    ]

    results = products
    if query:
        results = [p for p in results
                   if query.lower() in p["name"].lower()]
    if category:
        results = [p for p in results
                   if p.get("category") == category]

    return str(results)


@mcp.tool()
def get_product(product_id: str) -> str:
    """Get details for a specific product by ID."""
    products = {"1": {"name": "AI Audit", "price": 2500}}
    product = products.get(product_id)
    if not product:
        return f"Product {product_id} not found"
    return str(product)


# Define resources
@mcp.resource("catalog://products")
def list_all_products() -> str:
    """Complete product catalog as a resource."""
    return str([
        {"id": "1", "name": "AI Audit", "price": 2500},
        {"id": "2", "name": "MCP Build", "price": 5000},
    ])


if __name__ == "__main__":
    mcp.run()

Test and run:

# Test with the MCP inspector
mcp dev server.py

# Install in Claude Desktop
mcp install server.py

The Python SDK's FastMCP class handles all the protocol details automatically. Type hints on the function parameters are converted to JSON Schema for tool definitions. Docstrings become tool descriptions. The SDK also supports resources, prompts, and context management through the same decorator pattern.

MCP Security Considerations

Security in MCP operates at multiple levels. The protocol includes built-in security features, but the implementation is ultimately the server developer's responsibility.

Authentication

For remote MCP servers, the specification recommends OAuth 2.1 as the authentication mechanism. This provides token-based authentication with scopes, refresh tokens, and standard security practices. For simpler deployments, Bearer token authentication (API keys) is common. Local stdio servers typically do not need authentication since they run with the user's own permissions.

Tool Approval

MCP clients are expected to implement a tool approval mechanism. Before an AI model can execute a tool for the first time, the user should be prompted to approve it. This prevents AI models from executing destructive or sensitive operations without explicit user consent. Claude Desktop, for example, shows a confirmation dialog each time a new tool is called.

Input Validation

Every tool should validate its inputs rigorously. AI models can generate unexpected inputs — malformed data, injection attempts, or parameters outside expected ranges. Use Zod (TypeScript) or Pydantic (Python) to define strict input schemas. Never pass AI-generated inputs directly to SQL queries, shell commands, or file system operations without sanitization.

Principle of Least Privilege

Each MCP server should have the minimum permissions necessary for its function. A server that reads product data should not have write access to the database. A server that sends Slack messages should not have admin permissions on the workspace. Scope API keys, database credentials, and service accounts to exactly what the server needs.

Rate Limiting

Remote MCP servers should implement rate limiting to prevent abuse. AI models can be prompted to call tools repeatedly, and without rate limits, this could result in excessive API usage, database load, or cost overruns. Implement per-user or per-token rate limits on your server endpoints.

Security Checklist

Where to Host an MCP Server

The hosting choice depends on your transport type, expected load, and existing infrastructure.

Platform	Best For	Transport	Pricing Model
Cloudflare Workers	Low-latency, global deployment	Streamable HTTP	Free tier, then per-request
Vercel	Next.js projects, serverless	Streamable HTTP	Free tier, then per-invocation
AWS Lambda	Enterprise, AWS ecosystem	Streamable HTTP	Per-invocation
Railway / Render	Long-running processes, SSE	SSE or Streamable HTTP	Per-minute compute
Self-hosted (Docker)	Full control, compliance requirements	Any	Infrastructure cost
Local machine	Desktop apps, development	stdio	Free

For most web-based MCP servers, Cloudflare Workers or Vercel are the recommended choices. Both support the Streamable HTTP transport, have generous free tiers, and deploy globally. If your MCP server is part of a Next.js application (like our recommendation for AI-visible websites), deploying it as an API route on Vercel is the simplest approach.

MCP vs Traditional APIs: When to Use Which

MCP does not replace REST or GraphQL APIs. It serves a different purpose. Here is when to use each:

Dimension	Traditional API (REST/GraphQL)	MCP Server
Primary consumer	Application code (frontend, backend)	AI models and agents
Discovery	OpenAPI/Swagger docs (human reads)	Built-in tool listing (AI reads)
Authentication	API keys, OAuth, JWT	OAuth 2.1, Bearer tokens
Input definition	OpenAPI schema	JSON Schema with AI-readable descriptions
Error handling	HTTP status codes	Structured error in JSON-RPC response
Granularity	CRUD endpoints per resource	Task-oriented tools (search, analyze, create)
Statefulness	Stateless per request	Optional session state across calls

Use a traditional API when: Your primary consumers are application code (web frontends, mobile apps, microservices). Your API needs fine-grained CRUD operations. You have existing API infrastructure and documentation.

Use an MCP server when: You want AI models to interact with your product. The "caller" is an AI that needs to understand what tools are available and when to use them. You want to participate in the agentic web ecosystem.

Use both when: You have an existing API that serves your application and want to add AI interactivity. The MCP server can wrap your existing API, translating between the AI-friendly MCP interface and your internal API. This is the most common pattern — your MCP server is a thin layer that calls your existing API under the hood.

The Future of MCP

MCP is still a young protocol, and several developments are shaping its future:

WebMCP: Browser-Native Tool Registration

WebMCP extends MCP into the browser. Chrome 146+ ships the navigator.modelContext API, allowing websites to register tools that the browser's built-in AI assistant can use. This means any website can expose tools to AI without the user needing to configure anything — the tools are discovered automatically when the user visits the page.

WebMCP is particularly powerful for e-commerce (AI can search products, check availability), SaaS (AI can use the product's features), and content sites (AI can search and retrieve specific content). It transforms passive web browsing into active AI interaction.

MCP Registries and Discovery

As the number of MCP servers grows, discovery becomes critical. MCP registries — directories where servers are listed with their capabilities — are emerging as the "app store" for AI tools. Registries like Smithery, mcp.so, and PulseMCP let developers find and connect to MCP servers. The specification is also developing a standardized registry protocol for automated server discovery.

Multi-Agent Orchestration

MCP is becoming the standard tool layer for multi-agent systems. When multiple AI agents work together on a task, they use MCP to access shared tools and data. The A2A protocol handles agent-to-agent communication, while MCP handles agent-to-tool communication. Together, they form the infrastructure for autonomous AI workflows.

Enterprise Adoption

Enterprises are beginning to build internal MCP servers to expose their proprietary systems to AI assistants. Instead of training AI on company data (with all the associated risks), they connect AI to company tools through MCP — the AI can query the CRM, check the ERP, search internal docs, all through standardized, permissioned, auditable tool calls. This is a fundamentally safer and more controllable approach to enterprise AI than fine-tuning or RAG alone.

Reference Implementation: p0stman.com's MCP Server

This website implements a production MCP server at /api/mcp. Here is how it is structured:

Tool	Description	Auth Required
get_services	Returns list of services with descriptions and pricing	No (public)
search_content	Search across all guides, comparisons, and case studies	No (public)
get_case_study	Retrieve a specific case study by slug	No (public)
check_availability	Check current availability for new projects	No (public)
submit_inquiry	Submit a project inquiry with details	No (public, rate-limited)

The server is implemented as a Next.js API route and deployed on Vercel. GET requests return server metadata (name, version, available tools). POST requests execute tool calls. The manifest is published at /mcp.json for discovery.

In addition to the backend MCP server, the site registers public tools via WebMCP in the browser. When a user visits p0stman.com in Chrome 146+, the browser's AI assistant can access get_services and search_content directly without any configuration.

The complete discovery stack — llms.txt, mcp.json, .well-known/agent.json, and the /api/ai/context endpoint — ensures AI tools can discover the MCP server and understand what it does before connecting. This is the full agentic web architecture in practice.

MCP Server Getting Started Checklist

Frequently Asked Questions