Search “MCP server development services” and you get a page of agency results that could be swapped for each other without anyone noticing. Same stack diagram, same list of industries served, same claim of end-to-end expertise in a protocol that is not yet two years old. None of them tell you what you are buying, which is the only thing worth knowing before you sign.
Here is the short version. The Model Context Protocol is open, the SDKs are free, and the protocol layer of your project is the easy part. You are paying for integration work against your own systems, and the price is set by how messy those systems are.
What an MCP server actually is
We’re gmware, a software development firm headquartered in Austin, TX with engineering centers in Bangalore and Mohali, India. Agent and LLM integration work is a standing service line for us. This post is the scoping conversation we have before quoting one, published rather than repeated.
What the protocol is, without the metaphor stack
The Model Context Protocol documentation describes MCP as “an open-source standard for connecting AI applications to external systems,” and offers the analogy directly: “Think of MCP like a USB-C port for AI applications.” One connector shape, so a capability you build once is reachable from many assistants instead of being wired separately into each.
The specification is more precise about the parts. Messages are JSON-RPC 2.0. Three roles: Hosts are the LLM applications that initiate connections, Clients are the connectors inside them, Servers are “services that provide context and capabilities.” Your server offers any of three features:
Resources are “context and data, for the user or the AI model to use.” Prompts are “templated messages and workflows for users.” Tools are “functions for the AI model to execute.”
That third one is where the money and the risk both live. A Resource is something the model reads. A Tool is something the model does, in your system, to your data.
Support is broad enough that building against the standard is not a bet on one vendor. The documentation names Claude and ChatGPT among assistants, and Visual Studio Code and Cursor among development tools, as clients that support MCP.
The spec change that dates older quotes
This is the part worth carrying into a vendor call.
The current specification revision is 2026-07-28. Its Base Protocol section lists “Stateless, self-contained requests” and “Per-request capability negotiation.”
Go back and read the 2025-06-18 revision and the same section says “Stateful connections” and “Server and client capability negotiation.”
That is not a version bump, it is a different architecture. A stateless, self-contained request model changes how you handle authentication, how you scale horizontally, how you deal with a dropped connection, and whether a long-running job can live inside a request at all. The current revision answers that last one with an opt-in extension rather than a session: Tasks, described as “asynchronous execution of long-running operations, with polling, mid-flight input, and durable handles.” Two other extensions are worth knowing by name because they will show up in scoping: Skills over MCP for structured agent-workflow instructions, and MCP Apps for interactive UI elements rendered inline in a conversation.
So the useful question in a sales call is not “do you know MCP.” It is which revision this proposal targets, and if it assumes a long-lived stateful session, why. Plenty of material written during the protocol’s first year describes the older shape as though it were permanent. A proposal built on it is not wrong exactly, it is just aimed at a spec that moved.
Where the cost actually comes from
There is no license to buy. The standard is open and the SDKs are free, so every hour on the invoice is integration work. Four things drive it, in roughly this order:
-
Tool count, and whether tools write. A read-only server over a stable API is a contained piece of work. The moment a tool mutates a system of record, you inherit validation, idempotency, partial-failure handling, and a rollback story. As a rule of thumb we scope a write tool at several times a read tool, and it is where a bad estimate usually hides.
-
Authorization, specifically per-user. A server that acts with one shared service credential is straightforward and, in most companies, unacceptable. A server that acts as the calling user, with that user’s permissions and an audit trail, is the real requirement and the real cost. Settle this before scoping. It is the single largest swing factor.
-
The quality of the system behind the server. MCP does not fix an undocumented API with unstable schemas and inconsistent error codes. It exposes it, to a consumer that will call it in orders you never anticipated. If the underlying API needs work first, that is a separate project with a separate estimate, and any vendor who folds it silently into an MCP quote is setting up a change order.
-
Non-functional requirements. Rate limiting, observability, tenancy isolation, data-residency constraints, and retention rules. Ordinary engineering, easy to leave out of a first estimate, never free.
Notice that none of these are protocol problems. This is why we push back on fixed prices quoted before anyone has read your API documentation. The honest sequence is a short paid scoping pass that produces a tool inventory and an auth decision, then a build estimate that stands up. A vendor who quotes a number for “an MCP server” without asking how your permissions model works is pricing a shape, not your project.
When you should not build one
The strongest argument against an MCP server is usually the size of your client list.
If exactly one agent will ever call this capability, and your team owns that agent, then a direct API call is less machinery and fewer moving parts. MCP is a standardization play. It pays when the count of consumers is greater than one, or when the consumers are not you: multiple assistants across the business reaching the same internal capability, or customers plugging your product into whatever assistant they already use. If you are building an internal agent end to end, the protocol is optional and you should treat it that way, and the same logic applies to the broader question of where agents belong in your operations.
The other reason to wait is an unstable interface underneath. Wrapping an API you are about to redesign means building the adapter twice.
Security is a design input, not a phase
The specification does not soften this. It states plainly that “tools represent arbitrary code execution and must be treated with appropriate caution,” and that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.” On consent, it is explicit: hosts “must obtain explicit user consent before invoking any tool.”
The consent requirement lands on the host application, which in most deployments is not software you control. That is the asymmetry worth internalizing. You cannot rely on the assistant to be the safety layer, because you did not write it and cannot audit it. So the server has to be safe on its own terms: narrowly scoped credentials, destructive operations gated behind an explicit confirmation step, every call logged with the identity that made it, and no tool that can quietly do something you would want a human to sign off on.
Treat tool descriptions as part of your attack surface too. They are instructions a model will read and act on, which makes them worth reviewing the way you review a permissions change, not the way you review a docstring.
What good scoping looks like
If you take one thing into your next vendor conversation, make it this list:
- Which specification revision does the proposal target? The answer should be 2026-07-28 or a stated reason.
- Read or write? Per tool, not in general.
- Whose permissions does the server act with? A shared service credential is a decision, not a default.
- What happens on partial failure? Especially for anything that writes.
- Who is the second consumer? If there isn’t one, ask again whether you need this at all.
- What does the underlying API need first? Priced separately, or it will surface as a change order.
A vendor who has good answers to six questions has read your system. A vendor who answers with a capability list has read a template. That distinction is most of the decision, and it is available to you before you spend anything.
How gmware scopes an MCP server
Our scoping pass is short and deliberately paid: read your API documentation, inventory the candidate tools, split them read versus write, and settle the authorization question. That produces a tool list and an auth decision, which is enough to estimate a build that holds rather than a build that drifts. It can produce the recommendation not to build one at all, which is a cheaper place to land that than month three.
The work sits inside our AI agents and LLM integration practice and overlaps our wider AI and machine learning engagements. Reach out with your API docs and the list of assistants you want to reach, and we will tell you which of the six questions above you cannot yet answer.
If you are weighing this against building the agent itself, the same scoping logic applies further up the stack, and our notes on AI agent development cost and choosing an AI development company cover that ground. If the pattern you actually need is a plain systems integration rather than a model-facing one, API integration services is the more honest starting point.