How to Build an MCP Server

TL;DR — Key takeaways

The MCP server registry grew from 1,200 to 9,400+ servers between Q1 2025 and April 2026 — yet most enterprise-critical workflows still require a custom build because they involve proprietary data public servers cannot access.
78% of enterprise AI teams have at least one MCP-backed agent in production, but fewer than one in five has a formal authorization model in place.
The CAPE Stack (Connect, Authorize, Prompt, Execute) gives non-technical leaders a four-question framework to scope MCP projects before a developer writes a single line.
The most common build failure is not in the code — it is writing tool descriptions so vague the AI selects the wrong function, and the team blames the model instead of the documentation.
Streamable HTTP replaced SSE as the MCP production transport in April 2025. If your developer references SSE-only tutorials, they are building against outdated specs.

Here is a situation that plays out in enterprise AI projects with surprising regularity. A company runs a successful AI pilot — Claude drafts, Copilot autocomplete, ChatGPT summaries. Then someone with real authority asks the obvious question: “Can the AI actually touch our systems?” A catalog manager wants the agent to update listings automatically. A COO wants it querying the ERP. A marketing director wants it connected to the CRM. Suddenly, prompt engineering is not enough.

That is the moment where MCP enters the conversation — and where most teams discover the gap between using AI and deploying AI as infrastructure. Building an MCP server is the bridge. It is not as technically demanding as it sounds, but it requires a different kind of thinking than any developer tutorial currently provides.

What an MCP Server Actually Does (Without the Developer Jargon)

The official definition — “an open protocol that standardizes how applications provide context to LLMs” — is accurate and nearly useless for a business conversation.

Think of an MCP server as a structured permission layer between an AI agent and your real-world systems. When you build one, you define a menu of capabilities: what the AI is allowed to read, what it can create or modify, and what it can never touch. The agent consults this menu every time it needs to act. No MCP server, no action — the AI stays confined to text generation.

Technically, MCP servers expose three capability types: Tools (callable functions), Resources (readable data streams), and Prompts (templated instruction sets). For most business deployments, Tools dominate. A pricing query tool. A catalog-search tool. An order-status tool. An inventory-check tool. Each is a function with a name, a description, and typed parameters — and each is a deliberate decision about what your AI is allowed to do. For context on how brands are already using these in production, the MCP use cases playbook covers fifteen real implementations.

The protocol uses JSON-RPC 2.0 for message passing and supports two transport mechanisms: stdio (local subprocess) and Streamable HTTP (remote network service). Since April 2025, Streamable HTTP is the production standard. More on that in the 2025-2026 changes section below.

Build vs. Use: The Framework Most Teams Apply Too Late

With 9,400+ public MCP servers in the official registry as of April 2026, the first question is not “how do I build one” — it is “do I actually need to?” For commodity integrations — Slack, GitHub, Google Drive, Salesforce, HubSpot, Notion — maintained, MIT-licensed public servers are available today. Building your own versions of these is an expensive hobby.

The actual decision tree is tighter than most teams admit:

Use a public server if the integration is commodity and involves no proprietary business logic.
Build a custom server if the workflow involves internal systems, custom data models, pricing rules, brand-specific logic, or compliance constraints a generic server cannot accommodate.
Use a managed MCP service if you need custom capability but lack engineering bandwidth — several vendors now offer hosted, configurable MCP infrastructure.

What we see at Epinium is that the strongest enterprise deployments run a hybrid: public servers for commodity connectors, custom servers for core operational workflows. The mistake is spending six weeks building a Slack MCP server from scratch when one already exists and ships weekly updates. The MCP examples for brand teams article documents eight of these hybrid implementations in detail.

The CAPE Stack: Four Questions to Answer Before Writing Code

Every think-piece about MCP is aimed at developers. This is exactly backwards. The most important MCP decisions are made by people who will never write a line of code — the product owner who scopes what the AI can touch, the compliance officer who defines what it cannot, the operations lead who determines which workflows to expose first.

Before your engineering team writes a single line, four strategic questions need answers. I have formalized these as the CAPE Stack — not because it is heroic, but because it defines the order in which enterprise MCP projects fail when steps are skipped.

C — Connect: What system, specifically, are you connecting to? Not “our ERP” but “SAP S/4HANA, read access to product master data, via REST API v3, sandbox environment first.” Precision here shrinks the attack surface and accelerates the build.

A — Authorize: Who and what is allowed to invoke each tool? MCP does not ship with built-in authorization today — that is on the 2026 spec roadmap. You implement it yourself via OAuth 2.0 scope restrictions or API key rotation policies. Skipping this step is how write operations end up exposed to any agent that connects.

P — Prompt: How will the AI know when to use this tool versus another? The tool description in your MCP server file is the primary routing signal. Vague descriptions produce tool-selection errors. “Get product info” fails in production. “Retrieve all attributes for a single SKU from the product master, including inventory level, pricing tier, and content completeness score” works. This is a content problem, not a code problem.

E — Execute: What are the side effects, and who approves them? Read-only tools can run with full AI autonomy. Write operations need explicit human-in-the-loop checkpoints. Define this before the first deployment, not after the first incident.

97M

MCP SDK monthly downloads as of March 2026 — a 970× increase in 18 months

Source: Digital Applied, 2026

How to Actually Build Your First MCP Server

A functional MCP server for a focused business use case — say, a read-only catalog query tool — is typically 150 to 300 lines of Python or TypeScript. The official SDKs handle protocol negotiation, tool registration, and transport. Your engineering effort goes into the business logic behind each tool function: authentication to the external API, data transformation, error-handling policy. That is where build time actually accumulates.

MCP Deployment Approaches Compared

Dimension	Use Public MCP	Build Custom MCP	Managed MCP Service
Time to first deploy	Hours–days	2–6 weeks	1–2 weeks
Proprietary logic	None	Full	Partial (config-based)
Compliance control	Limited	Full	Depends on SLA
Maintenance burden	Community	Internal team	Shared / vendor
Authorization control	Limited	Full (DIY)	Built-in (varies)
Best for	Commodity tools	Core workflows	Mid-scale teams

MCP Server Development in 2025-2026: What Actually Changed

April 2025: Streamable HTTP Replaces SSE as the Production Transport

The original 2024 MCP spec used Server-Sent Events (SSE) as the primary remote transport. The April 2025 revision made Streamable HTTP the standard. SSE remains supported for backwards compatibility, but all new servers should target Streamable HTTP. If your developer is referencing late-2024 tutorials, verify which transport they are building against before sign-off.

December 2025: AAIF Governance and Vendor-Neutral Standardization

Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, co-founded with Block and OpenAI, with backing from Google, Microsoft, AWS, and Cloudflare. MCP is now governed as an open standard, not a single-vendor protocol. For enterprise procurement teams, the vendor-neutrality argument became substantially stronger overnight.

Early 2026: Universal AI Platform Support

By March 2026, every major AI platform supports MCP: Claude (native), ChatGPT (April 2025), Google Gemini API, Vertex AI Agent Builder, Cursor, Windsurf, JetBrains AI Assistant, the Vercel AI SDK, and the OpenAI Agents SDK. A server you build today is portable across your entire AI stack regardless of which models you adopt next year.

2026 Roadmap: First-Class Authorization Is Coming

The AAIF 2026 roadmap prioritizes OAuth 2.1-based authorization as a native protocol feature. Until it lands, authorization is your implementation responsibility. This is the single largest security gap in current enterprise MCP deployments — and the most consistently underestimated item in build timelines.

Epinium data

Brands in our ecosystem that deploy custom MCP servers for catalog operations see a 60–70% reduction in time between content brief and live listing update — typically from 4–5 working days to under 18 hours. The bottleneck moves from execution to decision-making, which is where the real productivity gain lives.

FREE DIAGNOSIS

Is your business ready to deploy MCP?

We map your current AI stack, identify which workflows are MCP-ready, and design your build vs. use roadmap — in a free 30-minute session with a dedicated AI Director.

How Transform works → ✓ 30 min ✓ Free ✓ Dedicated AI Director

Frequently Asked Questions About Building MCP Servers

What tools should I build first in an MCP server?

Start with read-only tools that have high query frequency: product lookups, inventory checks, order status, customer profile reads. These deliver immediate AI utility with zero risk of unintended data modification. Once your team can see what the AI is calling and why, layer in write tools with human-in-the-loop confirmation. Never start with write tools — the overhead of approving every single action defeats the efficiency gain before you see a real return.

Which programming language is best for building an MCP server?

Python and TypeScript are the two primary options, each with an official SDK. Python is faster to prototype, better suited to data-heavy servers, and more familiar to analytics teams. TypeScript suits teams already running Node.js backends, offers stronger type safety, and has a larger base of community examples. Follow your team’s existing stack rather than the tutorial you happen to find first. Both SDKs reach functional parity for the capabilities most business MCP servers require.

How long does it take to build a production-ready MCP server?

A focused read-only server covering two or three tools can be prototyped in a day and hardened for production in a week. The timeline expands when scope is undefined. Teams that skip CAPE Stack scoping — beginning to code before finalizing authorization policy, tool boundaries, and error-handling behavior — routinely find themselves in a six-to-eight-week build for something that should have taken ten days. The code is not the bottleneck. The decisions before the code are.

Do I need to rebuild my existing APIs to work with MCP?

No. Your MCP server sits as a thin adapter layer in front of your existing APIs. If you have a REST endpoint returning product data, your MCP tool is a function that calls that endpoint, shapes the response for LLM consumption, and returns it. You are not replacing your API infrastructure — you are giving AI agents a standardized interface to call it. This is the most persistent misconception in enterprise MCP conversations, and it causes teams to over-scope their first build significantly.

How do I prevent an AI agent from invoking dangerous MCP tools?

Three mechanisms work together. First, transport-layer authorization — only authenticated agents can connect at all. Second, scoped tool exposure — only include tools relevant to the agent’s specific task; a marketing assistant should not see a delete-order tool simply because it exists in the server. Third, tool descriptions that embed explicit behavioral limits: “This tool is for read-only catalog queries only. Do not use for pricing updates.” LLMs honor explicit constraints in tool metadata more consistently than most teams expect, and this is well-documented in production deployments at scale.

What is the difference between MCP and standard function calling?

Traditional function calling is model-specific and stateless — tools are defined per-prompt, per-model, per-API-contract. MCP is model-agnostic, stateful, and standardized across vendors. A tool defined in an MCP server works identically whether the agent is Claude, ChatGPT, Gemini, or any MCP-compatible client. For enterprises running multi-model environments — which is essentially everyone building at scale in 2026 — that portability compounds in value as your AI stack evolves and model choices shift.

My team already has a BI platform. Do we still need MCP?

Yes, because the use cases are structurally different. BI tools give humans structured access to historical data for analysis. MCP gives AI agents programmatic access to live systems for action. They are complementary, not competitive. The more interesting question is whether you build an MCP server that connects to your BI platform’s API — so the AI can query your data warehouse, surface trends, and execute follow-on actions without a human intermediating each step. Several enterprises now run this pattern with Snowflake and BigQuery MCP servers in production.

Can non-technical teams maintain an MCP server after it is built?

With the right architecture, yes. Config-driven MCP servers — where tool definitions are stored as JSON or YAML and the core logic is minimal — can be updated by non-developers. Code-first servers with deep custom logic require developer involvement for every change. If you anticipate frequent modifications to tool scope or descriptions, invest in a config layer during the initial build. The engineering cost is marginal; the operational benefit over twelve months is significant.

How does MCP handle rate limiting from the APIs my server connects to?

The protocol itself does not — rate limiting is entirely your responsibility at the implementation layer. An AI agent can invoke a tool dozens of times in a single task chain without tracking API consumption. Best practice is implementing exponential backoff and request queuing inside each tool function, and surfacing rate-limit errors as meaningful tool responses rather than silent failures. Stripe and Atlassian both publish reference MCP implementations with this pattern documented, and both are worth reviewing before you write your first write-capable tool.

MCP is an infrastructure decision, not a software project. The teams that treat it as a developer side-project build systems no one in operations trusts enough to run autonomously. The teams that treat it as deliberate systems design — with authorization, governance, and tool scoping resolved before a commit exists — are the ones where AI agents are handling real workflows six months later. That gap is not about code quality. It is about who is in the room when the server gets scoped.

TRANSFORM BY EPINIUM

Turn your systems into AI-ready infrastructure

Brands we work with reduce catalog-to-live time by 60–70% after MCP deployment. Book a free 30-min diagnosis and we will map exactly where to start.

Book free diagnosis →

30 min · Free · Personalised diagnosis