How much does an MCP server actually cost to build?

6 May 2026 · mcpclaude-codepricingcost-analysisbuild-vs-buy

The question comes up roughly once a week in client conversations: “How much does it cost to build an MCP server?”

The answer is “it depends on what you mean by cost” — and unhelpfully, the four dimensions of cost don’t move together. An MCP server can be cheap to run and expensive to build, or vice versa, or expensive on both sides for non-obvious reasons. This post breaks down the four cost dimensions with real numbers from the four MCP servers we’ve shipped in 2026, and tries to give you a defensible answer for “should I build this myself or hire someone.”

The TL;DR: a bare-bones MCP server is genuinely cheap. A production-shape one with the right test coverage, error handling, security boundaries, and operational maturity is roughly 5–15× more expensive than the bare-bones version. That gap is where most “I’ll just build it myself over the weekend” projects die.

Dimension 1: per-call API billing (often $0–$5/month)

This is the dimension everyone obsesses over and almost never matters.

If your MCP server hits a third-party API (Twitter, OpenAI, Stripe, Linear, Slack), every tool call is a billable request against that API. Real numbers from our four servers:

Our entire monthly spend on third-party APIs across all four MCPs is under $10. For most use cases — internal team tools, read-only integrations, low-traffic prototypes — this dimension rounds to zero.

The exception: MCP servers that hit OpenAI / Anthropic / other LLM APIs as part of the tool implementation. If your MCP fans out to an LLM call per request, you’re paying token costs on every invocation, and at high request volumes that’s real money. Cap with a per-call budget and a max_tokens parameter. Otherwise, ignore this dimension.

Dimension 2: hosting (often $0/month, sometimes $5–$50)

MCP servers are usually stdio subprocesses spawned by the Claude Code client. They run on whatever machine Claude Code is running on. Hosting cost: zero.

The exception is when you’re running an MCP server as an HTTP service so multiple clients can connect — for example, a team-wide mcp-jira that everyone in engineering shares. Then you need a server somewhere. Costs:

• Cloudflare Workers: free tier covers most low-traffic team servers. We host all of mcpdone.com on a Worker for $0.
• Fly.io / Railway / Render: $5–$15/month per always-on instance.
• Self-hosted on your existing infra: marginal cost (cents in CPU/RAM).

Hosting is genuinely cheap for MCP work. If you’re being quoted “$X/month for hosting” by anyone selling you an MCP server, push back — there’s no $X here.

Dimension 3: build time (the dimension that matters most)

This is where the gap between “weekend project” and “production-shape” becomes obvious.

The bare-bones version (1–3 days): - Single server.py with @mcp.tool() decorators - Functions that hit your API, parse, return a dict - A README with install instructions - Manual smoke test (“works on my machine”)

A senior engineer can ship this in 1–3 days. It works for the original author, on the original machine, with the original credentials.

The production-shape version (5–10 days): - All of the above, plus: - Comprehensive unit tests (mocked third-party APIs) — usually 30–50 tests for a non-trivial MCP - Integration / smoke tests against the live API - Wrapper-layer tests covering the FastMCP-specific bug classes (yes, those) - Structured error envelopes that give the model something to repair, not raw exceptions - Lazy config loading with clear error messages on misconfiguration - Read-only-by-design enforcement (where applicable) - Cost-per-call documented in tool docstrings - Type hints for accurate schema generation - A live smoke script at the project root for pre-deploy verification - README with full install/troubleshooting/cost sections - Optional: 30-day support agreement

We benchmark our four internal MCP servers at 5–8 days each, end-to-end, including review pass + delivery prep. That’s full-time engineering days.

Where the time actually goes (in our projects):

• ~20% scaffolding + initial tool implementation
• ~30% test suite (the part most weekend builds skip)
• ~15% error handling + structured envelopes
• ~10% docs + README
• ~10% security review (auth scoping, secret handling, deny-list enforcement)
• ~10% review pass (a fresh session reading the codebase cold)
• ~5% delivery prep (smoke test, demo, support setup)

If you (or whoever quotes you) is showing 1–2 days, they’re skipping 50%+ of this work. That work doesn’t go away — it just gets paid for later, in production bugs and support tickets.

Dimension 4: ongoing maintenance (often $0, sometimes substantial)

Once the server ships, what does it cost to keep alive?

For static, read-only integrations (e.g., mcp-content-opportunity hitting public APIs): essentially zero. The server runs unchanged for months. We’ve made one update to that one in three months, and it was a feature add, not a fix.

For integrations against APIs with backwards-incompatible changes (Twitter API tier shifts, OAuth token rotation, new rate limits), you’ll patch a few times a year. Each patch is 2–4 hours.

For integrations into actively-evolving client codebases (an MCP that wraps a company’s internal API): the maintenance cost is proportional to how fast the wrapped API changes. We’ve seen client-internal MCPs need monthly updates because the API shape was still being designed. That’s not a server problem — that’s a “you wired your MCP to a moving target” problem (see Lesson 6 of our shipping-4-MCPs post: wire to the layer that survives).

Realistic ongoing cost for a well-built MCP: 4–10 engineer-hours per year. Less than a single working day.

A worked example: mcp-twitter in 2026

Concrete numbers for the most recent server we shipped:

• Build time: 6 working days, ~38 hours total
• Day 1: scaffold, OAuth client, config module
• Days 2–3: reader functions + 36 unit tests
• Day 4: server wiring, error envelopes, smoke test
• Day 5: review pass, README, .mcp.json registration
• Day 6: shipped, hit a wrapper-layer bug, fixed it, added 6 wrapper tests + open-sourced the lint
• Ongoing API spend: ~$0.51/month at our usage (50–100 calls/month, mostly read_tweet and search_recent)
• Hosting: $0 (stdio subprocess, runs alongside Claude Code)
• Maintenance estimate (next 12 months): 4–6 hours, probably triggered by a Twitter API tier change

If we’d shipped only the “bare-bones” version on Day 1, the build cost would have been ~10 hours instead of 38. We’d also still have the wrapper-layer bug, no tests, no live smoke check, and a README of “see the source code.” Total reduction in build cost: ~75%. Total increase in user-side pain when something broke: 100%.

That’s the trade-off. Bare-bones is cheap to build and expensive to use. Production-shape is the inverse.

The hidden cost: shipping bugs

Every weekend-project MCP server we’ve reviewed has at least one of these bugs:

• Wrapper-layer bug: sync @mcp.tool() calling asyncio.run() inside FastMCP’s loop → RuntimeError on first call. (We shipped this. Cost to fix: 3 hours including building the lint that catches future occurrences.)
• Crash on missing config: server dies at import time when an env var is absent → user sees “MCP server failed to start” with no recoverable hint. (Cost to fix: 2 hours per server, repeated.)
• Raw exceptions to the model: tool raises ConnectionError("connection refused") → model has no idea what to do, user sees a confusing error. (Cost to fix: 4–6 hours to write structured error envelopes the first time, then it’s a pattern.)
• Schema-generation flubs: parameter typed as Any or untyped → model passes wrong types → tool fails or behaves unexpectedly. (Cost to fix: under an hour, but only if you notice.)

Each of these is invisible until the server is in real use. That’s why most “weekend MCP” projects look fine in their author’s setup and fall apart when handed to anyone else. The bug surface isn’t measurable from inside the original developer’s session.

Build vs buy: a concrete framework

Three paths to having an MCP server, in increasing order of cost-per-server and decreasing order of time-to-value:

Path 1: Use an off-the-shelf MCP server from awesome-mcp-servers.

• Cost: $0
• Time: 1 hour to evaluate + install
• Risk: variable code quality, often abandoned, wrapped against APIs you don’t actually need
• Right when: there’s an existing MCP for exactly your need + you’ve reviewed the code

Path 2: Build it yourself.

• Cost: 5–10 engineer-days at production-shape (or 1–3 days at bare-bones, with 5–10 days of bug-fixing later)
• Time: a few weeks of elapsed calendar time given competing priorities
• Risk: you don’t know the bug classes yet, so you’ll learn them by shipping each one
• Right when: your team has free engineering capacity AND will use this MCP enough to amortise the build cost AND has at least one engineer who’s read the FastMCP source

Path 3: Hire someone to build it.

• Cost: $300–$2000 depending on scope and provider
• Time: 5–10 calendar days
• Risk: variable provider quality
• Right when: you don’t have the engineering capacity, or you do but the opportunity cost of building this in-house is higher than the contract price, or you want a vendor on the hook for the money-back guarantee

For reference: our $499 Build tier is one custom MCP server, scoped to your specific integration, delivered in 5 days with the testing/error-handling patterns above baked in. We’re at the cheap end of Path 3 — most agencies charging consulting rates would quote 2–4× this. We can be cheap because we use Claude Code for delivery; our incremental cost per server is genuinely low.

(Cost transparency: at our current pricing, Path 3 from us is comparable to or cheaper than Path 2 if you value an engineering day above ~$50. For US/EU teams, Path 3 is almost always cheaper. For SA/EU teams with junior engineering capacity, Path 2 can sometimes win.)

When DIY genuinely wins

We’re biased — we sell Path 3. But Path 2 (build it yourself) is the right answer when:

• Your MCP is integrated tightly with internal workflows that you can’t easily explain to a vendor (subagent communication, hooks-driven side effects, deep dependency on your team’s CLAUDE.md conventions)
• The MCP is a learning vehicle. If your team is going to build five MCPs, the first one is partly an investment in capability. Pay the tuition.
• You have engineering capacity that’s truly free (people on the bench, a tech-debt week, a hackathon)
• The integration is sufficiently novel that a vendor would have to do the discovery work anyway — at which point you’re paying them to learn, and you can learn cheaper

When hiring genuinely wins

Path 3 wins when:

• You’re integrating with a system the vendor has built before. We’ve shipped MCPs around HN, Reddit, SQLite, Gmail/IMAP, and Twitter. Asking us to do another HTTP-API integration is asking us to repeat work we already know how to do well — that’s where vendor margins make sense.
• Time-to-value matters. A 5-day vendor delivery beats a 5-week internal build that gets re-prioritised three times.
• You want someone on the hook for the money-back guarantee. Internal teams can’t really stand behind that — if their MCP doesn’t work, they fix it. A vendor refunds you.
• The integration touches sensitive data and you want a vendor whose patterns include explicit security review (deny-lists, scope locking, structural read-only enforcement).

What you’re actually paying for in Path 3

When you pay $499 for a custom MCP server, you’re paying for the difference between bare-bones and production-shape. The bare-bones version is something a junior engineer can do in a week. The production-shape version is the same thing plus:

• 30+ unit tests covering the inner functions
• Wrapper-layer tests covering the FastMCP-specific bug classes
• Live smoke test against the real integration
• Structured error envelopes that the LLM can act on
• Read-only-by-design enforcement (where applicable)
• Lazy config loading + recoverable error states
• Schema generation that’s accurate (typed parameters, sensible defaults)
• A README with install / config / troubleshooting / cost sections
• 30 days of support for whatever breaks first

The bare-bones-to-production-shape gap is roughly 75% of the total work. Charging for that gap — and being on the hook when it isn’t there — is where vendor margins live.

The most useful thing I can tell you

Build a bare-bones version yourself, first. Don’t pay anyone for the first MCP if your team is curious. Spend 1–3 days on it. Ship it internally. Use it for two weeks.

Then decide whether the second one is also a build-yourself, or whether you’ve now seen enough of the failure modes to know that the production-shape version is what you actually want — and at that point, hiring saves you the tuition cost on every subsequent server.

We almost always tell prospective clients to do this. The ones who come back are ready buyers, not curious shoppers. The ones who don’t come back built their own production-shape version on the second try, which is a fine outcome — they just learned what we charge for.

The four MCP server samples (the public three; mcp-twitter is internal but the patterns are documented across our blog series) are MIT-licensed at github.com/Alienbushman/mcpdone-samples. The cross-project test lint hook is at mcp-guardrails.

If you’ve gotten through this post and decided you’d rather skip the tuition, the $499 Build tier is what you want. Money-back if the code doesn’t run in a clean environment, and the first 3 clients get 40% off in exchange for a public testimonial. Email hello@mcpdone.com with your tier + project.