MCP server vs API: when each one is the right call

The one-paragraph answer

Build an MCP server when more than one AI client, or more than one model, needs the same tools, or when you want the tool layer owned and versioned separately from any one app. A plain API integration is enough when one application calls one model and the tool list is short. The question is who consumes the tools.

The rest of this article is how we reached that rule, and how it played out on a live music ticketing platform where we built an MCP server alongside AI agents and automated reporting pipelines.

What an MCP server is, in plain terms

An MCP server is a small service that exposes your tools and data to AI clients through the Model Context Protocol, an open standard. Build it once and Claude, Claude Code and any other MCP-capable client can use the same tools, with the same authentication and the same scopes, without a separate integration for each.

The useful mental model is a typed menu. Your platform already has actions, look up an event, list ticket sales, issue a refund. An MCP server lists some of those actions as tools, each with a name, a description the model reads and a schema for its inputs. The client discovers the menu, the model chooses from it, the server runs the action and returns a typed result. The actions themselves do not change; they gain a standard way to be called by an AI.

The two things people confuse it with are an API gateway and a REST API. A REST API is for programmers and speaks in endpoints and payloads. A gateway sits in front of APIs and manages traffic and auth. An MCP server is for models: its contract is written so a model can read it, and its unit is the task, not the endpoint.

Direct API integration or MCP server

The table below is the comparison we draw on the whiteboard in most first calls. It reads as if MCP wins on every row, and once a second consumer appears it usually does. Before then, the overhead row decides it, and the right answer is the smaller one.

When MCP is the wrong tool

An MCP server is the wrong tool for a single feature inside a single app, for a prototype still finding its tool list, and for a team with no one to run a service. In each case the server adds a deployment and a protocol between the model and the action, and the only consumer is code you already control.

The AI writing assistant we built is the clearest example from our own work. A rich-text editor where a writer highlights a passage and the model rewrites it in place: one application, one model, one action. The integration was a direct API call inside the Next.js app, and the whole feature shipped in 162 hours. An MCP server there would have been a service with one tool and one client, which is a service for nothing.

The other wrong case is the server that exposes everything. An MCP server generated from an existing API spec is a few hundred tools with the API's names and the API's permissions. The model has to read all of them on every call, the descriptions were written for programmers, and the write operations are a bad argument away. That server is a security review waiting to happen, and it performs worse than a short, considered list.

How we scoped one for a live ticketing platform

On the ticketing platform the server exposed the reads and writes the platform's own AI agents and reporting pipelines needed, and nothing else. The platform ran on Remix and AWS in full-stack TypeScript, and the actions already existed as application code; the server wrapped a short list of them as typed tools, each with its own scope.

Scoping went like this. We listed every action the agents and the reports would need, which was a short list, then split it into reads and writes. Reads became tools immediately: event details, ticket sales for a date range, attendance by venue. Writes were examined one at a time; most stayed off the menu because nothing needed them yet, and the few that went on sat behind scopes a reporting client would never be granted. Tool descriptions were written for a model to read, in plain words about what the tool returns and when to use it, rather than copied from code comments.

The payoff was that the same tools served the agents working on the platform's data and any MCP-capable client the team wanted to point at the platform later, with one place to add a tool when a new need appeared. The agents did not know they were talking to an MCP server, and did not need to.

Reporting pipelines as MCP tools

Automated reporting on the platform ran as scheduled pipelines over the same data model, so the weekly numbers arrived on their own instead of being exported and assembled by hand. The pipelines and the MCP tools shared the read layer: the query that produced a report row was the same query a tool returned to an agent.

That sharing is the quiet argument for the server. Once the reads are typed tools, a scheduled pipeline, an agent and a person asking a question in Claude are all consumers of the same definitions. A change to how ticket sales are counted is made once and every consumer sees it.

Questions we get about MCP

Can an MCP server call a plain REST API underneath? Yes, and it usually does. The server is a thin layer that turns a handful of API calls into tools a model can read. The API stays as it is.

Does the model have to be Claude? No. MCP is an open protocol with clients for several models and tools. We build the servers to work with any MCP-capable client; Claude and Claude Code are the ones we test with most.

How many tools should a server expose? As few as the current consumers need. A first server with a handful of reads and one approved write is typical; the menu grows when a real need appears.

What does an MCP server cost to build? The written plan and tool list are the discovery sprint, from $2,500. A fixed-scope build starts from $6,000 and is priced against that plan.

What we would do on your project

We list the actions your AI clients will need, split them into reads and writes, decide which writes wait for a person, and write the tool descriptions a model will read. If that list has one consumer, we will tell you to skip the server and integrate directly. That decision, with the reasoning, is the discovery sprint, from $2,500. Book a free architecture call to start; the ticketing platform case study shows the server in context, and the MCP server development service covers the full scope.