codewithtoni
AI & MCP

What Is an MCP Server? A Developer's Guide (2026)

An MCP server is a small program that exposes tools, data, and prompts to AI models over the Model Context Protocol. Here's what that means and how to build one.

Antonio Kodheli··4 min read

An MCP server is a small program that exposes tools, data, and prompts to an AI model through a shared, open standard called the Model Context Protocol (MCP). Instead of hard-wiring every integration into every AI app, you write one MCP server and any MCP-compatible client — Claude, an IDE, a chatbot — can use it.

If you've ever wanted an AI assistant to read your database, call your API, or run an action in your app, an MCP server is how you give it that ability safely and reusably.

MCP server meaning, in one line

Think of MCP as "USB-C for AI". Before USB-C, every device needed its own cable. Before MCP, every AI integration was a bespoke, one-off connector. MCP defines a single, standard "port" so any model can plug into any tool.

An MCP server is the thing on the tool side of that port. The MCP client (the AI app) is on the other side.

What an MCP server actually exposes

The protocol defines three primitives. A server can offer any combination of them:

  • Tools — functions the model can call to do something: create_invoice, search_customers, deploy_site. These have typed inputs and return results the model reads.
  • Resources — data the model can read: a file, a database row, a live metric. Think of these as read-only context the client can pull in.
  • Prompts — reusable prompt templates the server offers to the client, so common workflows are one click instead of copy-paste.

The client discovers all of this at connect time. You don't tell the model "here are your tools" in a system prompt — the server advertises them, and the client wires them up automatically.

How it works under the hood

An MCP server and client talk over a simple transport — stdio for local servers (the client launches your server as a subprocess) or HTTP + Server-Sent Events for remote ones. Messages are JSON-RPC. The lifecycle looks like this:

  1. The client starts and connects to the server.
  2. It calls initialize and the server responds with its capabilities.
  3. The client asks tools/list, resources/list, prompts/list.
  4. When the model decides to use a tool, the client sends tools/call with arguments.
  5. Your server runs the function and returns a result the model reads.

You never write the "should I call this tool?" logic — the model does that. Your job is only to define the tools well and execute them.

How to build an MCP server (minimal example)

Here's the smallest useful TypeScript server using the official SDK. It exposes one tool that adds two numbers:

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: "demo", version: "1.0.0" });

server.tool(
  "add",
  { a: z.number(), b: z.number() },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  })
);

await server.connect(new StdioServerTransport());

That's a complete, working MCP server. Point an MCP client at it and the model can now call add. Real servers swap the toy function for database queries, API calls, or business actions — the shape stays identical.

The three rules that make a good server

  1. Name and describe tools for the model, not for you. The model picks tools from their names and descriptions. search_customers_by_email beats query.
  2. Validate every input. The model will occasionally send malformed arguments. Use a schema (Zod here) and fail loudly.
  3. Return small, structured results. Don't dump a 10,000-row table into context. Return what the model needs to make its next decision.

Why MCP servers matter

Before MCP, connecting an AI app to your tools meant custom glue code for each app-tool pair — an M×N problem. MCP turns it into M+N: write your server once, and every current and future MCP client can use it. That's why the ecosystem exploded — there are now MCP servers for GitHub, Slack, Postgres, Figma, filesystems, and thousands more.

For product teams, it means your app can become AI-accessible without you building a chatbot yourself: ship an MCP server, and users can drive your product from whatever assistant they already use.

Frequently asked questions

Is an MCP server the same as an API? No. An API is for programs; an MCP server is a thin, AI-friendly layer that wraps your API (or database) and describes it in a way models can discover and use.

What language do I write it in? Any — there are official SDKs for TypeScript, Python, and more. TypeScript and Python are the most common.

Do I need to host it? Local (stdio) servers run on the user's machine, no hosting needed. Remote (HTTP) servers are deployed like any web service.

Is it secure? The server controls exactly what it exposes. Only offer tools you're comfortable letting a model invoke, and validate inputs — the model is not a trusted caller.


MCP is the connective tissue between AI models and the real world, and writing a server is far simpler than most developers expect — a single file gets you started. If you want a batteries-included starting point with TypeScript, validation, and deployment already wired up, grab the starter below.

Want to skip the boilerplate? I maintain a production-ready MCP Server Starter with TypeScript, Prisma, and deploy config baked in.

Get the MCP Server Starter

Written by Antonio Kodheli

Full-stack web developer in Boston. I build modern web apps with TypeScript, Next.js, and the Claude API — and write about it here.