How to Build a Custom MCP Server

AI tools like Claude are impressive until you ask them about your own business. They can't see your orders, your inventory, your tickets, or your documents. None of that lives inside the model. The Model Context Protocol (MCP) fixes that. It's an open standard that lets AI securely connect to your systems and do real work in them.

This guide covers what MCP is in plain language, why it matters, what you can build with it, and how a custom MCP server actually works. There's a working code example near the end. And if you want to build one yourself, grab the free builder prompt at the bottom. Paste it into an AI coding assistant and it will build a server for your exact use case.

Table of contents

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

What is MCP?

MCP is a standard way for AI tools to talk to your 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. Every AI tool that speaks MCP can plug into it.

Three pieces are involved, and you only build one of them:

• The AI app. Claude, an AI-powered IDE, a chat interface. This is where your team asks questions. It already speaks MCP out of the box, so there's nothing to build here. (If you read the official docs, this piece is split into a "host" and a "client." That distinction only matters if you're building an AI app yourself. You're not.)
• Your MCP server. The piece you build. It sits in the middle and exposes a short list of things the AI is allowed to do, like "look up an order" or "search the handbook."
• Your systems. Where the data actually lives. Your ERP, your database, your ticketing tool, your file store. Nothing changes here. Your MCP server talks to these the same way the rest of your software already does.

So the flow is simple: your team talks to the AI app, the AI app talks to your MCP server, and your MCP server talks to your systems. Under the hood it's a request and response loop. 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 AI 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 started the project over from zero.

With MCP, the math flips:

• Build once, use everywhere. One server for your order system works in Claude, in AI-powered IDEs, and in whatever MCP tool comes next. No rework.
• The AI answers from real data, not guesses. Answers come from live lookups against your systems instead of the model's memory. That cuts hallucination on business questions dramatically.
• You keep control. The server only exposes what you define. If you don't build a "delete" tool, no AI can ever delete anything. Leaving a capability out is a stronger guarantee than any warning label.
• Your team stays in their flow. People ask questions in plain English. The AI does the lookups, the cross-referencing, and the updates behind the scenes.

What can you build? Example use cases

An MCP server can sit in front of almost any system with an API or a database. Patterns we see all the time:

• Internal knowledge lookup. "What's our PTO policy?" answered from your actual handbook, with sources, instead of a generic guess.
• Order and ERP status. "Where is order 4519, and is anything on that PO backordered?" answered by live queries against your ERP.
• 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 brings the language understanding and reasoning. Your MCP server brings the facts and the guardrails.

How an MCP server works

An MCP server can expose three kinds of capability. In practice, tools do almost 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. You rarely need these at the start.

Servers run in one of two ways:

• stdio. The AI tool launches your server as a small local program. Zero network setup, no login system to build. Perfect for personal tools and development.
• Streamable HTTP. Your server runs at a URL and serves your whole team. This is the choice for shared servers, and it's where authentication comes in (typically OAuth against the login system you already use).

A typical exchange looks like this: someone asks their AI assistant a question. The AI decides one of your tools can help. It sends a request with validated arguments. Your server runs the query against your system and sends the result back. The AI works it into its answer or takes the next step.

Designing good tools

Here's the part most people miss. The AI chooses and uses your tools based entirely on their names, descriptions, and input schemas. That makes tool design the highest-leverage part of the whole build:

1. Write descriptions for the AI, not for a human. 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."
2. Design around workflows, not your API. One find_orders tool with filters beats five mirrored endpoints. Fewer, clearly-bounded tools win.
3. Type every input. Structured schemas mean bad calls get rejected before they ever touch your system, and field descriptions teach the AI where each value comes from.
4. 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 fix its own mistake. "Error 500" does not.
5. Keep results small. Return the fields needed for the task and nothing else. Oversized results slow the AI down and degrade its answers.
6. Don't expose what you can't afford. Start read-only. Add write tools deliberately, one at a time. Skip destructive operations entirely.

A minimal MCP server in TypeScript

Here's a complete, working server with one tool, using the official TypeScript SDK. If you don't write code, skip past it. The shape is what matters:

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 authentication if it runs over HTTP.

Connecting your server to an AI client

Once it's built, wiring it up is one line in most tools. In Claude Code, for example:

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

Then ask a real question. "What's the status of order SO-4519?" Watch the AI pick your tool and call it. That feedback loop, watching which tools the AI reaches for and what it passes them, is how you sharpen the descriptions until the server feels effortless.

Build one for your use case

The fastest way from reading this to shipping something real: grab the free MCP Server Builder Prompt below. Paste it into Claude Code or any AI coding assistant. It interviews you about your use case, proposes a tool design, and builds the server for you, with everything from this guide already baked in.