How to Build a Custom MCP Server

AI assistants are remarkably capable — until you ask them about your business. They can't see your orders, your inventory, your tickets, or your documents, because none of that lives inside the model. The Model Context Protocol (MCP) fixes that: it's an open standard that lets AI tools like Claude securely connect to your own systems and take real action in them.

This guide explains what MCP is in plain language, why it matters, what you can build with it, and how a custom MCP server actually works — including a minimal working example. By the end, you'll understand enough to scope your own server, and you can grab our free ready-to-paste builder prompt at the bottom to have an AI coding assistant build one for your exact use case.

What is MCP?
Why MCP matters for your business
What can you build? Example use cases
How an MCP server works
Designing good tools — where quality is won
A minimal MCP server in TypeScript
Connecting your server to an AI client
Frequently asked questions
Build one for your use case

What is MCP?

The Model Context Protocol is a standard way for AI applications to talk to external systems. Think of it like USB-C for AI: instead of building a custom integration for every combination of AI tool and business system, you build one MCP server for your system, and every MCP-compatible AI client can plug into it.

Three roles are involved:

Host — the AI application the person is using (Claude, an IDE assistant, a chat interface).
Client — the connector inside the host that speaks the protocol.
Server — the piece you build. It sits in front of your system (a database, an ERP, a ticketing tool, a file store) and exposes a small set of well-defined capabilities.

Under the hood it's a simple request/response protocol: the AI asks your server "what can you do?", your server answers with a list of tools, and from then on the AI can call those tools with structured, validated inputs. Your server decides exactly what's allowed — nothing more.

Why MCP matters for your business

Before MCP, connecting an AI assistant to internal systems meant one-off integrations: a custom plugin for one chat tool, a different bot for another, glue code everywhere. Every new AI tool restarted the project from zero.

With MCP, the equation flips:

Build once, use everywhere. One server for your order system works in Claude, in AI-powered IDEs, and in any future MCP client — no rework.
The AI gets real data, not guesses. Answers come from live lookups against your systems instead of the model's memory, which cuts hallucination on business questions dramatically.
You keep control. The server only exposes the operations you define. If you don't build a "delete" tool, no AI can ever delete anything — absence of a capability is a stronger guarantee than any warning.
Your team stays in their tools. People ask questions in plain English and the AI does the lookups, cross-references, and updates behind the scenes.

What can you build? Example use cases

An MCP server can front almost any system with an API or database. Common patterns we see:

Internal knowledge lookup — "What's our PTO policy?" answered from your actual handbook and docs, with sources, instead of a generic guess.
Order and ERP status — "Where is order 4519, and is anything on that PO backordered?" resolved by live queries against your ERP or order database.
Customer and CRM context — "Summarize everything we know about this account before my 2 pm call" pulled from your CRM, tickets, and notes in one pass.
Document processing — the AI reads incoming invoices, quotes, or spec sheets and files structured data into your systems through controlled write tools.
Ops automation — creating tickets, logging touchpoints, scheduling follow-ups: the AI does the clicking, your server enforces the rules.

The common thread: the AI supplies the language understanding and reasoning, your MCP server supplies the facts and the guardrails.

How an MCP server works

An MCP server exposes up to three kinds of capability. In practice, tools do nearly all the work:

Tools — actions the AI can decide to take: find_orders, get_customer, create_ticket. Each tool has a name, a description, and a typed input schema. The AI reads those and figures out when and how to call each one. This is 95% of every real server.
Resources — data the user attaches as context, like picking a document from a list. Read, not executed.
Prompts — reusable message templates a user can trigger by hand. Rarely needed at the start.

Servers run over one of two transports:

stdio — the AI client launches your server as a small local program. Zero network setup, no auth to build. Perfect for personal tools and development.
Streamable HTTP — your server runs at a URL and serves many users. This is the choice for team-wide or company-wide servers, and it's where authentication (typically OAuth against the identity provider you already use) comes in.

A typical exchange looks like this: the user asks their AI assistant a question → the AI decides one of your tools can help → the client sends a tools/call request with validated arguments → your server runs the query against your system → the result goes back → the AI weaves it into its answer or takes the next step.

Designing good tools — where quality is won

The AI chooses and drives your tools based entirely on their names, descriptions, and schemas. That makes tool design the highest-leverage part of the build:

Write descriptions for the AI, not for a human reader. Say when to use the tool and what to call first: "Always call list_projects first — every other tool needs a project id from it."
Design around workflows, not your API. One find_orders tool with filters beats five mirrored REST endpoints. Fewer, clearly-bounded tools outperform a big catalog.
Type every input. Structured schemas mean invalid calls are rejected before they ever touch your system, and field descriptions teach the AI where values come from.
Return errors the AI can act on. "Order 4519 not found in the last 90 days — try find_orders with a wider date range" lets the AI self-correct. "Error 500" does not.
Keep results compact. Return the fields needed for the task. Oversized payloads burn the AI's context and degrade its performance.
Don't expose what you can't afford. Start read-only. Add write tools deliberately, one at a time, and skip destructive operations entirely.

A minimal MCP server in TypeScript

Here's a complete, working stdio server with one tool, using the official TypeScript SDK:

import { McpServer } from '@modelcontextprotocol/server';
import { serveStdio } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod';

serveStdio(() => {
  const server = new McpServer({ name: 'order-lookup', version: '1.0.0' });

  server.registerTool(
    'get_order_status',
    {
      description:
        'Look up the current status of a customer order by order number. ' +
        'Use this whenever the user asks where an order is.',
      inputSchema: z.object({
        orderNumber: z.string().describe('The order number, e.g. "SO-4519".'),
      }),
    },
    async ({ orderNumber }) => {
      const order = await lookupOrder(orderNumber); // your database / API call
      if (!order) {
        return {
          isError: true,
          content: [{ type: 'text', text: `Order ${orderNumber} not found. Check the number and try again.` }],
        };
      }
      return {
        content: [{ type: 'text', text: JSON.stringify(order) }],
      };
    },
  );

  return server;
});

That's genuinely the whole shape of it: register tools with descriptions and schemas, implement each one as a small function against your system, and the SDK handles the protocol. A production server is this pattern repeated for a handful of tools, plus auth if it runs over HTTP.

Connecting your server to an AI client

Once built, wiring it up is a one-liner in most clients. In Claude Code, for example:

claude mcp add order-lookup -- node dist/server.js

Then ask the assistant a real question — "what's the status of order SO-4519?" — and watch it pick your tool and call it. That feedback loop, watching which tools the AI chooses and what it passes, is how you refine descriptions until the server feels effortless to use.

Frequently asked questions

What is the Model Context Protocol (MCP)?

MCP is an open standard that lets AI applications like Claude connect to external systems — databases, ERPs, CRMs, document stores — through servers that expose well-defined tools. You build one server for your system and any MCP-compatible AI client can use it.

Do I need to be a developer to build an MCP server?

It helps, but it's no longer required. AI coding assistants like Claude Code can build a complete, working MCP server from a well-structured prompt — you describe your use case and systems, and the assistant handles the code. That's exactly what the free builder prompt below is for.

What's the difference between an MCP server and a regular API?

An API is designed for programmers; an MCP server is designed for AI models. It wraps your systems in a small set of tools with rich descriptions and typed inputs that an AI can understand, choose between, and call safely — no custom integration code per AI tool.

Is it safe to connect an AI to my business systems?

You control the blast radius. An MCP server only exposes the operations you explicitly build — start read-only, add narrowly-scoped write tools deliberately, and never expose destructive operations. For shared servers, standard OAuth authentication ensures the AI can never do more than the signed-in user could.

Which AI tools support MCP?

MCP is supported by Claude (desktop and web), Claude Code, and a growing list of AI-powered IDEs and agent frameworks. Because it's an open standard, one server you build today keeps working as new clients adopt it.

Build one for your use case

The fastest way from reading to shipping: grab our free MCP Server Builder Prompt below. Paste it into Claude Code (or any AI coding assistant), and it will interview you about your use case, propose a tool design, and build the server for you — with the quality guardrails from this guide baked in.