The protocol takes a day. Auth, response shaping, and evals take the other six weeks. Here's where the hours go, our real price bands, and the bills that arrive after launch.
The protocol part of an MCP server takes about a day. You import the SDK, register three tools, point the Inspector at stdio, and it works. Every client we quote assumes that day is the expensive part — the JSON-RPC framing, the transport, the initialize handshake — and every one of them budgets for the wrong week.
The cost is in the contract you're signing with a model that has no memory of your architecture, no fear of calling the wrong thing, and infinite patience for retrying a broken request. Every tool you expose is a standing promise about whose data comes back, how many tokens it costs, and what happens when the input is garbage. That's why our quotes scale with tool count, not endpoint count: a 200-endpoint REST API can be a six-tool server, and those six tools are the entire bill.
Scaffolding in the Python or TypeScript SDK, wiring stdio, and exposing four read tools over an API you already own is two or three days including tests. We've done internal ones in an afternoon. The demo is genuinely good — Claude Desktop, a question about your own data, a correct answer in four seconds — and that demo is where budgets get set. It's also a lie of omission: you drove it, and you already knew which tool you wanted.
Point a real model at real traffic and the failure modes surface in the first hour. It calls list_customers with no filter and drops 4,000 rows into context. It passes a customer ID it hallucinated three turns earlier out of a truncated summary. It gets a 422 whose body says 'validation failed' and resends the identical payload six times, because nothing in the error named the field. None of that is protocol work, and all of it is why week two costs more than week one.
Auth is the biggest line item on anything customer-facing. If the server holds one service account and takes tenant_id as a tool argument, you have shipped a cross-tenant breach with a friendly interface: the model will eventually pass an ID it read in an earlier turn, and the leaked rows sit in the transcript forever. Doing it properly means OAuth 2.1 with PKCE, per-user tokens, identity re-derived from the token on every tool call instead of cached at session start, and scoping pushed into the WHERE clause rather than the system prompt. One to two weeks on a multi-tenant system; three if your API assumed a trusted internal caller and every handler needs a principal threaded through it.
Response shaping is second. A 200-field object is fine for a React component that ignores 190 of them and terrible for a context window that pays for all 200 and reasons worse across the noise. You write a projection layer per tool: drop fields, cap rows around 50, add cursor pagination the model can follow (an opaque next_cursor beats offset arithmetic it will get wrong), and summarize long free-text before it ships. On one client's server, cutting the default payload by 70% cut per-conversation token spend roughly in half, with no measurable drop in answer quality.
Third is the eval loop, cut first and regretted most. Error strings are prompts: "invalid customer_id: expected UUID, call find_customer with a name first" gets recovered from on the next turn; "400 Bad Request" produces the same call again. Proving that takes a fixture suite of real transcripts where you assert which tool ran with which arguments, executed against a live model, and diffed when you change one word of a description. Descriptions are code and nobody reviews them like code. Two to three days to build, and it's the difference between surviving a model upgrade and degrading quietly until a customer emails.
Internal, read-only, one system, four to six tools: $6k–$12k and two to three weeks. That buys tool design, response shaping, error copy written for a model, a small eval suite, and both stdio and remote HTTP transport. It's the right first project for most teams, and internal ops extracts more value per dollar than anyone, because those users already know what the data means.
Customer-facing and multi-tenant with OAuth, writes, and audit logging: $30k–$75k and six to ten weeks. The spread is two variables — whether your API already enforces per-user scoping, and how many write tools you need. A write tool costs roughly two to three times a read tool: confirmation semantics before it fires, an idempotency key so a retry doesn't refund the same order twice, and a rollback path someone has actually tested. Single-tenant with a few writes lands between, $15k–$30k. Hosting is a rounding error at $50–$200 a month.
The spec has revised repeatedly since it landed — SSE giving way to streamable HTTP, auth restructured onto standard OAuth discovery, tool annotations added — and each revision broke something for somebody. Budget 10–15% of build cost annually just to track the spec and the SDK. Then add client divergence: Claude Desktop, Cursor, and your own runtime disagree on long tool lists, elicitation, and streaming, so "it works" always needs "in which client" after it. Each supported client is another row in the test matrix.
Tokens are the cost nobody forecasts. Every tool definition loads into context before the user's first question. Twenty tools with paragraph-length descriptions and nested schemas is 4,000–6,000 tokens of preamble per conversation, paid whether the model touches them or not. We've watched teams add one tool per sprint until the preamble cost more than the answers did. Tool surface is a budget, and pruning it belongs on someone's calendar quarterly with the call logs open.
Start read-only and start narrow. Ship five tools that wrap workflows instead of twenty that wrap endpoints: the model doesn't want get_order, get_order_items, and get_shipment, it wants order_status, because chaining three calls is three chances to pass the wrong ID. Log every call from day one — tool name, arguments, latency, result size — then after a month delete the tools with zero invocations and rewrite the ones with high error rates, which is a description problem, not a model problem. Every server we've rebuilt got cheaper to run and better at its job at the same time, mostly by removing things.
A software studio that ships and maintains its own products — KeepChats, Gwora and Cairn — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar