MCP Server: What It Is, How It Works, and How to Build One

An MCP server is a lightweight service that exposes tools, data sources, and capabilities to AI models through the Model Context Protocol — a standardized protocol that Anthropic released as open-source in November 2024. Think of it as an api for your AI: instead of building custom integrations between every llm and every external system, you build one MCP server and any mcp client can use it.

Before MCP, connecting an AI assistant to a database, a GitHub repo, or a CRM meant writing custom code for each combination of model and tool. That's the NxM problem — N models times M tools equals an unmaintainable mess of connectors. MCP reduces that to N+M: each model implements the mcp client once, each tool implements the mcp server once, and they all talk the same language.

Google Cloud calls it a "bridge that allows AI to move beyond static knowledge and become a dynamic agent." That's accurate. An MCP server turns any external system into something AI agents can discover, query, and act on in real-time.

The architecture: hosts, clients, and servers

MCP follows a client-server architecture inspired by the Language Server Protocol (LSP) that powers IDE features like autocomplete and debugging across programming languages. The components:

MCP host — the ai application where the llm lives. This could be Claude Desktop, an ai-powered ide like Cursor, or a chatbot you're building. The host is what the user interacts with.

MCP client — built into the host, this handles the connection to mcp servers. It discovers what mcp tools are available, sends tool calls from the llm, and returns results. Think of it as the translator between the model's requests and the server's capabilities.

MCP server — the service that provides actual functionality. Each server typically focuses on one integration: a GitHub server for repo access, a PostgreSQL server for sql queries, a Slack server for messaging. Servers expose their capabilities through a schema that clients can discover at runtime.

Transport layer — the communication pipe between client and server, using JSON-RPC 2.0 messages. Two options:

• stdio (standard input/output) — for local servers running on the same machine. Fast, synchronous, no network overhead.
• sse (Server-Sent Events) — for remote server deployments. Supports real-time streaming over HTTP.

User → MCP Host (LLM) → MCP Client → Transport → MCP Server → External System

The key insight: the llm doesn't call external systems directly. It generates structured tool calls, the mcp client routes them to the right server, and the server handles authentication, permissions, and the actual backend work.

What MCP servers expose

An MCP server can provide three types of capabilities:

Tools — functions the AI can call. A database server might expose query, insert, and schema tools. A GitHub server exposes tools for listing repos, reading files, creating issues. Each tool has a defined schema describing its parameters and return types, so the llm knows exactly how to use it.

Resources — read-only data sources the AI can access. Templates, docs, datasets, config files. Unlike tools, resources don't perform actions — they provide context.

Prompts — pre-built prompt templates that guide how the AI should interact with specific capabilities. A code review server might include prompts for security analysis, performance review, or style checking.

How to build an MCP server

The official sdk is available in Python and TypeScript. Here's a minimal Python example that creates a server exposing a single tool:

from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-demo-server")

@server.tool("get_weather")
async def get_weather(city: str) -> list[TextContent]:
    """Get current weather for a city."""
    # Your actual API call here
    return [TextContent(type="text", text=f"Weather in {city}: 72°F, sunny")]

if __name__ == "__main__":
    import asyncio
    asyncio.run(server.run_stdio())

That's a working mcp server. Run it with stdio and any mcp client can discover and call the get_weather tool. The server handles schema discovery automatically — clients learn what tools are available, what parameters they accept, and what they return.

For a more realistic setup with authentication and oauth:

@server.tool("query_database")
async def query_database(sql_query: str) -> list[TextContent]:
    """Run a read-only SQL query against the production database."""
    # Validate the query (no writes allowed)
    if not sql_query.strip().upper().startswith("SELECT"):
        return [TextContent(type="text", text="Error: only SELECT queries allowed")]
    
    results = await db.execute(sql_query)
    return [TextContent(type="text", text=json.dumps(results))]

The access control is in your server code. You decide what the AI can and can't do. MCP handles the communication protocol; you handle the permissions and business logic.

Config: connecting servers to clients

To connect an mcp server to Claude Desktop (or any host), you add it to the config file:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    },
    "postgres": {
      "command": "npx", 
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://..."
      }
    }
  }
}

Each entry specifies a command to start the server (typically via npx for the official servers), any access tokens needed, and environment variables. The cli handles discovery — when the host starts, it launches each configured server and queries its capabilities.

For remote server deployments, you'd use the sse transport instead of stdio, pointing to a URL rather than a local command. This is how you'd run mcp servers in production for ai applications that need to scale.

The ecosystem right now

The official servers repository on GitHub has reference implementations for common use cases:

• Filesystem — read, write, and search files
• GitHub — repos, issues, pull requests, code search
• PostgreSQL / SQLite — sql queries with read-only access control
• Slack — channels, messages, threads
• Google Drive — docs, sheets, file search
• Brave Search — web search from within an AI session

These are development tools and reference implementations, not production-ready services. But they show the pattern. The community has built hundreds more — everything from Jira connectors to Kubernetes management to custom datasets.

Anthropic's Claude Desktop and Claude Code both support MCP natively. OpenAI added MCP support to ChatGPT in early 2026. Google's Gemini supports it across their ai systems. Microsoft has integrated it into VS Code. The ecosystem has reached the point where building a custom mcp server is the standard way to give ai tools access to your internal systems.

MCP vs. function calling vs. plugins

All three solve the same problem — letting AI use external tools — but at different levels of standardization:

Function calling (OpenAI, Anthropic, Gemini) is model-specific. You define JSON schemas for each function, write handlers, and implement different versions for each model provider. It works but creates the NxM fragmentation problem.

Plugins (ChatGPT plugins, now deprecated) were platform-specific. They only worked in one chatbot's ecosystem and required approval processes.

MCP is a standardized protocol that works across models, hosts, and providers. Build once, use anywhere. The mcp client in Claude Desktop uses the same protocol as the one in Cursor or a custom chatbot you build yourself.

The real benefit isn't technical — it's that MCP servers are reusable. A Slack mcp server works with Claude, ChatGPT, Gemini, and any custom ai assistant that implements the protocol. That's the difference between building a plugin and building a connector.

Troubleshooting common issues

Server won't start: Check that your dependencies are installed and the command works outside of MCP. Run the server command directly in your terminal first. Most issues are missing Node.js packages or Python dependencies.

Authentication failures: MCP servers that connect to external systems need proper access tokens in their environment variables. Double-check your oauth tokens haven't expired and that the permissions scope matches what the server needs.

Tools not appearing: The mcp client discovers tools at startup. If you add new tools to a running server, restart the host application. Also verify the server's schema is valid — malformed JSON-RPC responses will silently fail.

Debugging transport issues: For stdio servers, check that the server process isn't writing anything to stdout except MCP protocol messages. Stray print statements break the protocol. For sse, verify CORS headers if the client and remote server are on different origins.

The official docs at modelcontextprotocol.io cover debugging in detail, including protocol logging and test harnesses.

Use cases worth building

The most valuable mcp servers connect natural language to internal systems that currently require specialized knowledge:

• Database explorer — let an ai assistant query your production data using natural language instead of raw sql. Add read-only access control so it can't modify anything.
• Internal docs search — index your company wiki, runbooks, and templates as MCP resources so AI can reference them during conversations.
• CI/CD status — give ai agents real-time visibility into build status, test results, and deployment state.
• Customer support backend — connect your codebase, ticket system, and knowledge base so an ai assistant can answer support questions with real context from your actual data sources.

The pattern is consistent: take something that requires context-switching between multiple systems and expose it through one mcp server that an ai assistant can use through natural language. These are the building blocks for automated workflows where AI doesn't just answer questions — it executes multi-step processes across your entire stack.

Where MCP is headed

MCP is less than two years old and already has support from every major AI provider. The automation it enables — ai agents that can actually do things in your systems, not just talk about them — is the reason the development tools category is being rebuilt around it.

If you're building ai applications that need to connect to external systems, MCP is the standardized protocol to learn. It won't be the last protocol, but it's the one that has industry-wide adoption right now. Cloudflare has already built "code mode" for MCP that reduces token usage by up to 99.9%, hinting at how the protocol will evolve for production workloads.

And if you need an mcp server for your stack, chances are someone's already built one — or you can write one in about fifty lines of Python. The barrier to entry is intentionally low. That's the whole point of a standardized protocol: spend your time on business logic, not integration plumbing.

Sources

• What is Model Context Protocol? — Google Cloud
• What Is MCP and How It Works — Descope
• MCP Specification — modelcontextprotocol.io
• MCP Servers Repository — GitHub

Related reading

• What is agentic AI? — the architecture that MCP connects to
• Build an AI agent — build an agent that uses MCP tools
• AI agent frameworks — frameworks that integrate with MCP servers
• Claude Code — an AI coding tool that supports MCP natively
• Self-hosted AI — run your own AI stack with MCP connectors
• AI agent tools — the tool landscape that MCP is standardizing