MCP Server Development Cost: Build, Run and Maintain in 2026

MCP server development cost falls into three honest tiers, and the gap between them is not the code. A thin internal server that lets an agent read from one system is roughly 7 to 17 engineer-days. A production server with proper authorization, per-user permissions, audit logging and a security review is roughly 38 to 86 engineer-days. A regulated build spanning several systems is roughly 95 to 220. Multiply by your own fully loaded day rate, or by the day rate inside a vendor's quote, and you have a budget you can defend.

This article gives you the line items behind those ranges, the assumptions each one rests on, and the two costs that almost never appear in a proposal: what the server costs to run every month at published cloud prices, and what it costs to keep working as the protocol changes underneath it. Every price and every protocol claim here links to its source and carries a date, because both move.

Key takeaway: Hosting an MCP server is cheap — tens of dollars a month. The money is in authorization, permission mapping, testing, and the maintenance you sign up for when you own an integration in a protocol that has had four dated revisions since March 2025.

What an MCP server actually is (and what it is not)

The Model Context Protocol is an open standard for connecting AI applications to external systems. In the protocol's own words, an MCP host is the AI application, an MCP client is the component inside it that maintains a connection, and an MCP server is "a program that provides context to MCP clients" (Model Context Protocol architecture overview).

A server exposes three kinds of thing:

• Tools — executable functions the agent can invoke, such as a database query or a ticket update.
• Resources — data sources that provide context, such as a file's contents or a schema.
• Prompts — reusable templates that structure an interaction.

Servers run in one of two shapes. A local server uses the STDIO transport and runs on the same machine as the client, typically serving one client. A remote server uses the Streamable HTTP transport and typically serves many clients. That single choice moves the budget more than any other, because the remote shape drags in authorization, hosting, monitoring and a security review, and the local shape mostly does not.

What an MCP server is not is a piece of AI. It contains no model. It is an integration layer with a standard wire format. If you have ever paid for a systems integration, you already know most of what drives this cost: how many systems, how messy their APIs are, whether you are reading or writing, and whose permissions apply.

Do you even need to build one? Four cheaper options first

The cheapest MCP server is one you do not build. Work down these four questions before you scope anything.

1. Does an official server already exist? Many software vendors publish their own MCP servers, and the MCP Registry, launched in preview in September 2025, is "an open catalog and API for discovering publicly available MCP servers." Using a vendor's own server moves maintenance to the vendor. Your remaining cost is review, not construction.

2. Do you already have a clean API? Managed gateways can turn existing APIs into MCP tools without you writing a server at all. Azure API Management can connect and govern an existing remote MCP server and apply policies such as rate limiting and OAuth in front of it, and it can also expose a managed REST API as an MCP server. Amazon Bedrock AgentCore Gateway lets you integrate existing APIs and Lambda functions as tools, and charges $0.005 per 1,000 invocations such as ListTools and InvokeTool, with tool indexing at $0.02 per 100 tools per month (AgentCore pricing, checked September 2026).

3. Is the workflow completely fixed? If the same steps run in the same order every time, a scheduled job is cheaper, faster and easier to audit than anything with a model in the loop. We make this argument in more detail in our guide to how long it takes to build an AI agent: autonomy is the most expensive design choice on the menu.

4. Will more than one client use these tools? MCP earns its keep when several agents or applications need the same capabilities. If exactly one agent needs one integration and you control both ends, a direct function call is less code and less surface area. Revisit MCP when the second consumer appears.

What drives MCP server development cost

Six factors explain almost all the variance between quotes. When two proposals differ by four times, it is nearly always because they assumed different answers here.

Key takeaway: The largest unbudgeted item is enforcing each end user's real permissions. A server that queries with one shared account is a different product from one that answers as the person asking, even though both get called "an MCP server."

The build cost model, line by line

Here is the model in engineer-days, with the tiers defined so you can check which one your project fits. Tier 1 is a read-only internal server: STDIO or a private HTTP endpoint, one upstream system, one or two tools. Tier 2 is a remote production server with OAuth, five to eight tools including writes, per-user permissions and a security review. Tier 3 is a regulated build across several systems, twelve to twenty tools, full audit evidence and formal governance.

Each additional tool adds roughly half a day to a day if it only reads, and one to three days if it writes, because a write needs validation, an approval path and a way to undo it.

Turning days into dollars

To convert days into money you need a day rate. Here is a transparent one you can replace with your own.

The U.S. Bureau of Labor Statistics reports a median annual wage for software developers of $135,980 in May 2025. Over 2,080 working hours that is about $65 an hour in salary alone. BLS also reports that for private industry workers in June 2026, wages and salaries averaged $32.82 per hour worked and accounted for 70.0% of total employer compensation costs, with benefits making up the other 30.0%. Dividing by 0.70 gives a fully loaded internal cost of roughly $93 an hour, or about $745 per eight-hour day, before any allowance for management, tooling, recruiting or idle time.

At that rate the tiers work out as follows.

Two honest caveats. First, this is the internal cost of engineering time only; it excludes product management, compliance staff time, and the cost of people in other teams who review and approve access. Second, an agency or consultancy bills a multiple of internal cost, because their rate carries overhead, sales, bench time, project management and warranty. Do not compare a vendor's quote to this table and conclude the vendor is overcharging — compare like with like by asking the vendor for the same line items in days.

Key takeaway: Ask every vendor to quote in engineer-days per line item, not as a single number. It is the only way to see which of the six cost drivers they assumed, and it turns a negotiation about price into a negotiation about scope.

What an MCP server costs to run each month

Compute is the least interesting part of the bill, and it is worth showing the arithmetic so nobody sells you a hosting story.

AWS Fargate. Published Linux/x86 on-demand pricing for US East (N. Virginia) is $0.000011244 per vCPU-second and $0.000001235 per GB-second (AWS Fargate pricing, checked September 2026). A single task with 0.5 vCPU and 1 GB of memory running continuously through a 730-hour month costs about $14.77 for CPU and $3.25 for memory, so roughly $18 a month. Add a public IPv4 address at $0.005 per hour (Amazon VPC pricing), which is about $3.65 a month, plus CloudWatch logs and data transfer at standard rates.

Google Cloud Run. Instance-based billing in us-central1 is $0.000018 per vCPU-second and $0.000002 per GiB-second, with a monthly free tier of 240,000 vCPU-seconds and 450,000 GiB-seconds (Cloud Run pricing, checked September 2026). One always-warm instance with 1 vCPU and 512 MiB over the same 730 hours costs roughly $45 a month after the free tier. Let it scale to zero on request-based billing and a lightly used internal server can land inside the free allowances entirely.

Prices are as of September 2026 and they change; check the linked pages before you build a business case on them. If your wider cloud bill is the real problem, that is a different exercise — see our work on cloud cost optimization.

The run cost that is not on the cloud bill

Every tool your server exposes is described to the model in every conversation that has the server connected. Anthropic's engineering team put numbers on this in November 2025: in a worked example where a large document flows through the context twice, moving from direct tool calls to code execution took a task from 150,000 tokens to 2,000 tokens, a saving of 98.7% (Code execution with MCP). Anthropic also notes that agents connected to very large numbers of tools "need to process hundreds of thousands of tokens before reading a request."

The practical lesson for a buyer is simple: tool count is a recurring cost, not a one-off. Twenty thinly specified tools can cost more per month in tokens than the container they run in. Insist that the design keeps the tool surface small and the descriptions tight, and ask how tool results are passed around rather than pushed through the model.

The maintenance line nobody budgets for

This is where MCP differs from a normal integration project, and it is the part most cost guides skip.

MCP uses date-based version identifiers "to indicate the last date backwards incompatible changes were made," and the current protocol version is 2026-07-28. Dated revisions since early 2025 include 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28. That is four in roughly sixteen months, and the most recent one was substantial.

The 2026-07-28 changelog removed protocol-level sessions and the Mcp-Session-Id header, removed the initialize handshake so that every request now carries its own protocol version and capabilities, made a server/discover request mandatory for servers, replaced the previous notification mechanism with subscriptions/listen, and removed SSE stream resumability. It also deprecated the Roots, Sampling and Logging features and deprecated OAuth 2.0 Dynamic Client Registration in favour of Client ID Metadata Documents. Deprecated features stay in the specification for at least twelve months under the project's feature lifecycle policy, which is a real grace period — but it is a countdown, not a reprieve.

Compatibility cuts the other way too. Microsoft documents that an external MCP server exposed through Azure API Management "must conform to MCP version 2025-06-18 or later." A server written against an older revision is not merely old; in some places it is unusable.

Budget for this explicitly:

• Protocol upkeep: two to eight engineer-days per breaking revision for a Tier 2 server, more if you support several clients.
• Upstream API churn: the systems behind your tools ship changes on their own schedule, not yours.
• Client compatibility testing: each client you support is a row in the test matrix, and support for individual features differs between them.
• Tool description drift: descriptions that worked well with one model generation often need retuning with the next.

A defensible planning figure is 15% to 25% of the original build effort per year for a server under active use — higher in the first year after a breaking protocol revision, lower for a frozen internal tool. Ask any vendor what happens when the specification changes, and get the answer in the contract rather than in an email.

The security work that changes the number

MCP's own security best practices document is the best scoping checklist available, because each attack it describes maps to concrete engineering work.

Token audience validation. The authorization specification states that MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience" and "MUST NOT accept or transit any other tokens." Passing a client's token straight through to a downstream API — "token passthrough" — is explicitly forbidden, because it breaks the audit trail and lets a stolen token use your server as a proxy for exfiltration.

The confused deputy problem. If your server proxies a third-party API with a static client ID while letting clients register dynamically, an attacker can ride an existing consent cookie to obtain authorization codes without the user approving anything. The mitigation is a per-client consent registry checked before the third-party flow, exact redirect URI matching, and single-use state values stored only after consent. That is a feature with a user interface, and it needs a week rather than an afternoon.

Server-side request forgery. Metadata discovery involves fetching URLs that a malicious server controls, which can reach cloud metadata endpoints such as 169.254.169.254. Mitigations include enforcing HTTPS, blocking private and link-local IP ranges, validating redirect targets and routing discovery through an egress proxy.

State handle hijacking. Because MCP is now stateless, servers that need cross-call state mint their own handles. The specification is blunt: servers "MUST NOT treat possession of a state handle as authentication," and should bind handles server-side to the authenticated user.

Scope minimisation. Broad scopes granted up front expand the blast radius of any stolen token. The recommended pattern is a minimal initial scope set with incremental elevation through targeted challenges when a privileged operation is first attempted.

Prompt injection. OWASP's LLM01:2025 Prompt Injection entry covers the indirect case that matters most here: content your tools return from external sources can alter the agent's behaviour. OWASP's recommended controls — privilege restriction, human approval for high-risk operations, segregating untrusted content and adversarial testing — are design requirements for any server whose tools can write.

Platform rules add another layer. OpenAI's MCP documentation warns users not to connect to a custom MCP server unless they know and trust the underlying application, notes that custom servers receive whatever data the assistant supplies during an interaction, and states that write actions currently require manual user confirmation. Design for that, rather than discovering it during a launch review.

If you work in banking, insurance or healthcare, this work sits alongside your existing model risk, vendor and audit obligations, which is the subject of our AI compliance practice. None of this is legal advice; confirm your specific obligations with your compliance team or counsel.

Three worked budgets

A. Internal research assistant, read-only. One upstream system, two read tools, STDIO transport for a small team, credentials from the environment, no per-user permissions. Roughly 7 to 17 engineer-days, effectively no hosting cost, light maintenance. This is the right first project: it proves the workflow is automatable before anyone commits a real budget, which is the same logic behind a short prototype in our guide to AI agent development cost.

B. Customer-facing operations server, remote and write-capable. Streamable HTTP, OAuth with token audience validation, six tools of which three write, per-user permissions mapped from your identity provider, structured audit logging, an independent security review. Roughly 38 to 86 engineer-days, tens of dollars a month to host, and 15% to 25% of the build effort a year to maintain. The security review and the permission mapping are where estimates most often prove optimistic.

C. Regulated, multi-system server. Four upstream systems including a vendor platform you do not control, sixteen tools, full audit evidence with retention, a formal threat model, vendor due diligence and governance sign-off. Roughly 95 to 220 engineer-days. Most of the calendar here is not engineering, it is other teams' queues, so start the access and review requests in week zero.

When not to build an MCP server

Honest negative cases save more money than any optimisation.

• The data is not ready. If nobody can reliably say who is allowed to see which record, no protocol fixes that. Sort out the permission model first.
• You need determinism. Approvals, payments and anything with a regulatory deadline usually want a workflow, not an agent holding tools.
• One consumer, one integration. Write the function. Add MCP when the second consumer appears.
• The vendor is about to ship one. Ask their roadmap before you fund a server they will give you for free and then maintain.
• Nobody owns it after launch. An integration with no owner is a liability. If there is no maintenance budget, do not start.

What to ask before you sign

Take this to every vendor conversation. The answers, not the headline price, tell you what you are buying.

1. Quote each line of the cost model above in engineer-days. Which tier is this?
2. Is the transport local STDIO or remote Streamable HTTP, and why?
3. Which tools write? What is the approval and rollback path for each one?
4. Whose permissions apply when a tool runs — a shared service account, or each end user's?
5. How do you validate that access tokens were issued for this server specifically?
6. If the server proxies a third-party API, how do you handle per-client consent?
7. What exactly is logged for each tool call, where does it go, and for how long is it kept?
8. Which protocol revision are you targeting, and what happens to my server when the next breaking one lands?
9. Which clients will you test against, and how often?
10. How many tools are in scope, and what is the token cost of the tool definitions per conversation?
11. Is an independent security review inside or outside this price?
12. Who owns the code and the infrastructure at the end, and what does handover include?

The bottom line

MCP server development cost is mostly a question of scope discipline. The protocol itself is not expensive to implement; a competent engineer can stand up a read-only server in days. What costs money is everything that makes it safe to point at production: authorization done properly, each user's real permissions enforced, writes that can be approved and undone, evidence a reviewer will accept, and a plan for the next breaking revision.

So start small. Build the read-only server, connect it to a real workflow, and measure what people actually ask it to do. Then add write tools with that evidence in hand. If you want a second opinion on scope before you commit, or a build plan with the days broken out, we are happy to talk it through on a free discovery call about AI agent development. Our custom AI development work follows the same pattern by default: a working prototype first, a production budget second.

Have a scope in mind and want it pressure-tested? Talk to a specialist and you will hear back within one business day.