The question arrives in almost the same words every time. We want to connect Claude to the system we run the business on, what will it cost. Usually there is a spreadsheet attached, a long list of features down the left, and one blank column titled budget.
That blank column is rarely the hard part. The hard part sits a few rows above it, unwritten.
Why the MCP server cost question arrives in the wrong shape
Something shifted in 2026. Founders who had never written a line of integration code started asking for one specific thing, by name, in plain language: connect the assistant to the system we actually work in.
According to the Model Context Protocol documentation, MCP is "an open-source standard for connecting AI applications to external systems", and the site's own analogy is a USB-C port for AI applications. An MCP server is a program that provides context to MCP clients. That is the entire idea. The same documentation puts the current protocol version at 2026-07-28 and the data layer on JSON-RPC 2.0, which tells you how small the moving parts really are. If you want the wider map of how servers, skills and plugins fit together, I set it out in the opening article of this series.
For years I answered the cost question as a scoping problem. Write a tighter specification, count the tools, multiply by a rate, add a buffer for surprises. I no longer believe that model is right. The number moves far more with a single decision than with the tool count, and that decision is which actions the assistant may take without asking a human first.
What actually drives the cost of an MCP server?
Five things drive the cost of an MCP server: how many systems it wraps, how many tools it exposes, how many of those tools change state rather than read it, whether the target system already has a stable API, and who inside the business is allowed to decide the approval rules. The first and the last move the number most.
Start with the count of systems. One system per server is the cheapest decision on the table, and founders resist it because wrapping three systems at once feels more ambitious. The reference server repository maintained by the MCP steering group lists seven implementations, among them Filesystem, Git, Fetch and Time, and each of those wraps exactly one domain. A server that reaches into the order system, the accounting system and the helpdesk has three sets of credentials, three failure modes and three owners who must agree before anything ships.
Tool count matters less than people expect. A first server that genuinely earns its place usually needs 4 to 8 tools in my estimate, not thirty, and the honest test is whether somebody would miss the tool if you removed it tomorrow.
State-changing tools are where the cost lives. Reading is cheap to build and cheap to review, because the worst case is a wrong answer on a screen. Writing is different. A tool that issues a refund, moves a booking or sends a message to a customer needs a confirmation step, an audit trail, and a written rule about its limits. The specification supports this directly through elicitation, which "allows servers to request additional information from users … or ask for confirmation of an action".
Then there is the target system itself. If it already exposes a documented API that your team has called before, the wrapping work is ordinary engineering. If the only way in is a screen, a CSV export or an undocumented endpoint somebody found in a browser network tab, the estimate doubles and the risk is not in your control.
The last driver is the one nobody puts in the spreadsheet. Somebody has to decide what the assistant may do unsupervised, and that person is almost never the developer. I have written separately about secrets, permissions and human approval, and the short version is that the rule has to exist in writing before the tool exists in code.
| The code is the cheap part. The conversation about what the assistant may do without asking is the expensive part. |
A phased shape that keeps the first invoice small
The shape below is how I would sequence a first build, and the ranges in it are my estimates from IndiaNIC's delivery work rather than a published benchmark. Treat them as a planning aid. A business with a documented API and a decisive process owner lands at the short end; a business with neither lands past the long end, and the reason will not be the code.
Phase one is the phase people want to skip. Do not skip it. A read-only server tells you within a week whether the assistant is being asked a question it can actually answer, and that is the cheapest negative result you will ever buy.
The moment I watch for sits inside phase two. A developer has the write tool working against a test account, the process owner is leaning over the desk, and somebody asks whether a refund above a certain size should still go through without a second pair of eyes. The room goes quiet. That silence is the schedule. Nobody in it is writing code, and the answer has to come from the business rather than from the server.
One worked example, from our own shelf. We built and open-sourced byline, an MCP server and CLI that turns an idea into a published article, and its governing rule is a single sentence: nothing fails silently, so every tool returns a result or an error naming the API and its HTTP status. That rule belongs to phase three, not phase one. It is also the rule that makes the difference between a demo and something a team will still trust in month six.
How do I measure the return on an MCP server?
Measure three things, and measure them before the server exists: interruptions removed, minutes per task before and after, and jobs that failed without anybody noticing. All three can be counted by hand in a single week. None of them needs a dashboard, and none of them is a currency figure with a decimal point in it.
Interruptions removed is my favourite, because it is the one people feel. Count how many times in a week somebody pings a colleague to ask a question a system already knows the answer to. Stock for a line item, status of an order, whether an invoice was paid. Each of those pings costs two people their attention, and attention is the budget nobody tracks.
Minutes per task is the boring one that survives scrutiny. Pick the three tasks the server is meant to touch, time them by hand on five real examples before anything is built, then time the same five after. Do it with a stopwatch and a notebook if necessary.
Jobs that failed unseen is the measure that surprises founders. Before automation, a failed export or a missed reconciliation often surfaces days later through a customer complaint. A server built so that nothing fails silently turns that into a message at the moment of failure, and the value of moving a discovery from Thursday to Monday morning is real even though it never appears as a saving.
| Take the baseline first. If you measure nothing in the week before the build starts, every number you produce afterwards is an opinion with a chart attached. One week of hand-counted timings is worth more than a year of instrumentation added later. |
Three ways an ROI estimate goes wrong
The first failure is counting features. A spreadsheet with nineteen tools on it looks like more value than a spreadsheet with four, and the widely held view that a larger tool surface means a larger return is simply wrong. I will accept the cost of being wrong about that in public. Every extra tool adds a review, a failure mode and a permission question, and the four-tool server that somebody uses every morning beats the nineteen-tool server that nobody opens twice.
The second failure is pricing the code and ignoring the approval conversation. In our delivery work the approval question is consistently the part that consumes the most calendar time, and I say that as a judgement from experience rather than as a measurement. It is also the part that cannot be outsourced, because no vendor can decide on your behalf which refunds, bookings or payments may move without a human looking.
The third failure is the absence of a baseline. A team that cannot say what the task cost before cannot say what it saves after, and the gap gets filled with a confident percentage that nobody can defend. I would rather hand a board a hand-counted range than a precise number built on nothing.
What to do in the next two weeks
Pick one system. Not the most important one, the one with the most interruptions around it.
Then spend week one measuring, with no code at all. Count the pings, time the three tasks on five real examples each, and list the jobs that failed last month without anybody noticing until later. In week two, name the two people: one developer who already knows that system, and the person who owns the process. Ask that second person one question and write the answer down. Which actions may the assistant take without asking me first?
If the answer is "none yet", you have a read-only server and a successful first phase. That is a good place to be. The reference implementations are a sensible place to study the shape before committing a rupee or a dollar to your own, and readers can also browse published servers on the MCP Registry.
The next question worth putting to your team is not technical at all. It is whether this first server should be built in-house, where the process knowledge already lives, or with a partner who has shipped the pattern before. That is the conversation I would have before the budget column gets filled in, and it is the one I will take up next. If you would rather have it with the team that builds MCP servers and AI agents into other people's workflows for a living, talk to us.
Frequently asked questions
How long does a first MCP server take to build?
My estimate from IndiaNIC's delivery work is four to eight weeks of elapsed time for a server wrapping one system, split across a read-only phase of three to five working days, one write path in one to two weeks, and hardening in two to four weeks. That is an estimate from experience, not a published benchmark.
How many people do I need to build an MCP server?
Two. One developer who already knows the target system and its API, plus the person who owns the process being automated and can decide the approval rules. A larger team usually signals that the server is wrapping more than one system, which is the single most reliable way to make a first build expensive.
What should I measure to prove an MCP server paid for itself?
Measure interruptions removed, minutes per task before and after, and jobs that failed without anybody noticing. Count all three by hand in the week before the build begins, because a baseline taken afterwards is guesswork. Avoid currency figures with false precision; a defensible range beats a confident decimal every time.
