If you have asked around about building an MCP server, you have probably been quoted somewhere between $3,000 and $300,000. Both numbers are real, and both are for something the buyer described identically: "let AI assistants talk to our system."

The spread is not vendors guessing. It is that "MCP server" names a protocol, not a scope. Below is the breakdown I use when scoping one, and why the protocol itself is almost never the expensive part.

The protocol is the cheap part

The Model Context Protocol is a way for an AI assistant to discover what your system can do and then do it. A tool is a name, a JSON schema for its inputs, and a function. If you have a working API, wrapping three read-only endpoints as MCP tools is an afternoon.

That afternoon is what a $3,000 quote is pricing. It is a genuine deliverable, and for plenty of teams it is the correct one.

Note

This site runs its own MCP server in production — nine tools, six reads and three writes, on a Cloudflare Worker. The tool definitions are a small fraction of that codebase. Rate limiting, auth between the two Workers, and the contract test that stops a tool shipping undocumented are most of it.

Everything past the afternoon is the cost.

What the budget actually goes on

1. Reads versus writes

A read-only server is a search problem. The worst case for a bug is a wrong answer, and the client can check it.

A server with write tools is a permissions problem. The worst case is an assistant cancelling the wrong booking, refunding the wrong invoice, or emailing the wrong list — and doing it confidently, at machine speed, on behalf of a user who typed one ambiguous sentence.

This one distinction is the biggest single driver in every quote I have seen. Expect writes to cost several times reads for the same surface area, because the work is no longer "expose the endpoint" but "decide what this is allowed to do, prove it, and be able to show afterwards what it did."

2. Who is calling

Three very different builds hide behind the same words:

Scenario	What it needs	Rough weight
Internal, one team, trusted network	Tool definitions, a shared secret	Days
External clients, per-user data	OAuth, per-user scoping, rate limits, audit log	Weeks
Public, unauthenticated reads	Everything above, plus abuse handling and cache strategy	Weeks, then ongoing

A public endpoint is not the cheap option because it skips login. It is the expensive one, because anything reachable without a credential will be found and hammered.

3. Capability design

This is the part almost nobody scopes and almost everybody pays for later.

An MCP tool is not an API endpoint with a different coat on. An endpoint is called by a developer who read the docs. A tool is called by a model that read a one-line description and is guessing. So the tool has to be shaped for a caller with no judgement:

Narrow. cancelBooking(manageToken) is safe. updateBooking(id, fields) invites an assistant to invent a field.
Unguessable where it matters. On this site, acting on a booking requires the management token from that booking's confirmation. There is deliberately no lookup by name or email, so an agent cannot discover a booking it was not handed.
Honest when empty. An empty slot list must mean empty. If the model can read "no results" as "try different arguments," it will, in a loop.

Redesigning tools after an assistant has misused them in front of a customer is the expensive way to learn this.

4. Running it

An MCP server is a live integration surface. The spec moves, the assistants that call it move, and your own API moves underneath it. Budget maintenance as you would for any other public API — and note that transport-level changes in the protocol have landed more than once since 2025, each needing a real upgrade rather than a version bump.

A realistic small build

For a founder or small team, the version that earns its keep usually looks like this:

3–6 read tools over data you already serve
1–2 write tools, each requiring a capability the user already holds
A rate limit on every unauthenticated path
An append-only log of every write, queryable after the fact
A contract test asserting the advertised tool list matches the registered one

That last line sounds like overhead until the first time someone adds a tool and forgets to document it. Your published tool list is what an assistant reads to decide whether to use you at all; if it drifts from reality, the model either misses capabilities you have or calls ones you removed.

Tip

Start read-only, in production, with real traffic. The tools you thought were essential and the tools assistants actually call are rarely the same set, and finding that out costs nothing before you have built the write path.

So what should you pay?

Ignore any quote given before these four questions are answered:

Which tools are reads, and which can change state?
Who authenticates, and as whom does the tool act?
What is the worst thing a confused assistant could do with this, and what stops it?
Who owns it in six months when the spec changes?

A scoped answer to those is worth more than a number. If a quote arrives without them, it is pricing the afternoon and hoping the rest does not come up.

I build MCP servers and other AI integrations as part of the build services here, and this site's own server is the reference implementation. If you want a second opinion on a quote you have already received, send me the scope — that conversation is free and frequently ends with "you do not need this yet."

The protocol is the cheap part

That afternoon is what a $3,000 quote is pricing. It is a genuine deliverable, and for plenty of teams it is the correct one.

Note

Everything past the afternoon is the cost.

What the budget actually goes on

1. Reads versus writes

A read-only server is a search problem. The worst case for a bug is a wrong answer, and the client can check it.

2. Who is calling

Three very different builds hide behind the same words:

Scenario	What it needs	Rough weight
Internal, one team, trusted network	Tool definitions, a shared secret	Days
External clients, per-user data	OAuth, per-user scoping, rate limits, audit log	Weeks
Public, unauthenticated reads	Everything above, plus abuse handling and cache strategy	Weeks, then ongoing

A public endpoint is not the cheap option because it skips login. It is the expensive one, because anything reachable without a credential will be found and hammered.

3. Capability design

This is the part almost nobody scopes and almost everybody pays for later.

Narrow. cancelBooking(manageToken) is safe. updateBooking(id, fields) invites an assistant to invent a field.
Unguessable where it matters. On this site, acting on a booking requires the management token from that booking's confirmation. There is deliberately no lookup by name or email, so an agent cannot discover a booking it was not handed.
Honest when empty. An empty slot list must mean empty. If the model can read "no results" as "try different arguments," it will, in a loop.

Redesigning tools after an assistant has misused them in front of a customer is the expensive way to learn this.

4. Running it

A realistic small build

For a founder or small team, the version that earns its keep usually looks like this:

3–6 read tools over data you already serve
1–2 write tools, each requiring a capability the user already holds
A rate limit on every unauthenticated path
An append-only log of every write, queryable after the fact
A contract test asserting the advertised tool list matches the registered one

Tip

So what should you pay?

Ignore any quote given before these four questions are answered:

Which tools are reads, and which can change state?
Who authenticates, and as whom does the tool act?
What is the worst thing a confused assistant could do with this, and what stops it?
Who owns it in six months when the spec changes?

A scoped answer to those is worth more than a number. If a quote arrives without them, it is pricing the afternoon and hoping the rest does not come up.

What an MCP Server Actually Costs to Build

The protocol is the cheap part

What the budget actually goes on

1. Reads versus writes

2. Who is calling

3. Capability design

4. Running it

A realistic small build

So what should you pay?

Hitting something like this in your own codebase?

What an MCP Server Actually Costs to Build

The protocol is the cheap part

What the budget actually goes on

1. Reads versus writes

2. Who is calling

3. Capability design

4. Running it

A realistic small build

So what should you pay?

Hitting something like this in your own codebase?