MCP vs Custom APIs: When to Use Each in 2026

TL;DR

• MCP wins when multiple models will use the same tool, or when you need versioning + auth + discoverability for free
• Custom APIs win when the tool is called from exactly one place and the team owns both ends
• The two are not mutually exclusive, most production builds use both
• Default to MCP unless you can name the reason not to

What MCP solves

Before MCP became standard, every agent build reinvented the same wheel: how does the model call this tool? Each model had its own tool schema (OpenAI functions, Claude tool use, Gemini function calling). Each codebase had its own router. Every time you swapped models, you rewrote the glue.

Model Context Protocol fixed this. One spec, language-neutral, with three primitives: resources (read-only data the model can request), tools (actions the model can invoke), and prompts (parameterized templates). Any MCP-compatible client (Claude Desktop, Cursor, Claude Code, increasingly OpenAI’s products, custom apps) can use any MCP server without additional integration work.

In practice, an MCP server is the substrate that lets you build “agent that talks to our CRM” once and have it work in five different products tomorrow.

When custom APIs still win

MCP is not free. There is a server to host, a protocol to maintain, and an auth model to integrate with. Three cases where we still build a custom REST or RPC endpoint instead:

1. The tool is single-purpose, single-consumer

If only one agent will ever call this tool, the MCP surface is overhead. A typed function inside the agent’s own codebase is simpler.

2. Latency budgets are tight (< 50ms)

MCP adds a network hop and serialization overhead. For most use cases this is invisible. For real-time voice agents, it sometimes is not.

3. The tool is deeply coupled to the agent’s state

If the tool needs to read or mutate the agent’s internal memory or graph state, packaging it as an external server is forcing artificial boundaries.

The cost comparison

Numbers from a recent build that did both:

Aspect	Custom API	MCP Server
Initial setup	~2 hours	~6 hours
Lines of code	~150	~280
Reusable across models	No	Yes
Auth/rate-limiting built-in	No (DIY)	Yes (via SDK)
Versioning story	Manual	Standard
Discoverability	None	Free
Hosting cost (Cloudflare Workers)	~$5/mo	~$5/mo

The MCP server requires roughly 3 times the initial work, then pays back the moment you add a second consumer.

A real example: a recent build that picked both

A 6-week multi-agent build for a fintech client needed:

1. Read/write access to Salesforce, used by three agents
2. Read access to internal pricing engine, used by one agent
3. Read access to transaction logs, used by four agents
4. Write access to the agent’s own scratchpad, used by one agent, mutated in-loop

Decisions:

• Salesforce → MCP server. Three consumers, complex auth, the client will likely build more agents next quarter. Worth the up-front cost.
• Pricing engine → custom API. One consumer, low-latency requirement, deeply coupled to the agent’s reasoning flow.
• Transaction logs → MCP server. Four consumers; obvious win.
• Scratchpad → in-process function. Not even an HTTP call. Direct function on the agent’s graph state.

The build ended up with two MCP servers + one custom REST endpoint + a handful of in-process tools. That’s the realistic shape of production agents in 2026.

The decision framework

For each tool you are about to build, ask in order:

1. Will more than one agent / model use this? Yes → MCP. No → continue.
2. Will this tool outlive the agent that uses it? Yes → MCP. No → continue.
3. Is the agent’s vendor / model likely to change? Yes → MCP. No → continue.
4. Is the tool tightly coupled to in-loop state? Yes → in-process function.
5. Default: custom API for one-off use, MCP for anything you’d want to ship a Tuesday talk about.

Code: a simple MCP server vs the same as a custom API

MCP server (TypeScript, abbreviated):

import { Server } from '@modelcontextprotocol/sdk/server';

const server = new Server({ name: 'crm-tools', version: '1.0.0' });

server.tool('lookup_account', {
  description: 'Look up a customer account by ID',
  inputSchema: { type: 'object', properties: { accountId: { type: 'string' } }, required: ['accountId'] },
  handler: async ({ accountId }) => {
    const account = await crm.accounts.get(accountId);
    return { content: [{ type: 'text', text: JSON.stringify(account) }] };
  },
});

server.listen();

Equivalent custom REST endpoint:

import express from 'express';

const app = express();
app.use(express.json());

app.post('/lookup_account', async (req, res) => {
  const { accountId } = req.body;
  const account = await crm.accounts.get(accountId);
  res.json(account);
});

app.listen(3000);

The custom endpoint is shorter today. The MCP server is shorter in aggregate by the time you reach the third agent that needs to use it, because that third agent requires zero integration work.

FAQ

Doesn’t MCP add latency? A bit, typically 20-60ms per tool call. Invisible for most use cases; relevant for sub-second voice agents.

Can I use MCP with OpenAI/Gemini? Yes. The protocol is model-agnostic and adoption across vendors is accelerating in 2026.

Where do I host MCP servers? Cloudflare Workers, Vercel Functions, your existing API infrastructure, anywhere that can serve HTTP. We default to Workers for the edge latency.

What about security / auth? The MCP spec supports bearer auth, and most production servers add OAuth on top. Same model as any other API.

Is MCP overkill for a single internal tool? Yes, that is exactly the case for a custom API. Do not over-engineer.

---

The default in 2026 should be MCP, with a specific reason to opt out. The “but it is just an internal tool” reason is the one that causes problems two quarters later when the second agent needs it.