How to build and sell MCP servers as a client service

An MCP server is a small program that lets an AI app such as Claude or ChatGPT use a client's tools and data through one standard protocol. Developers sell the build, the security setup and the upkeep. Start with one tool, one auth method and a fixed-scope first project.

What you are actually selling

Model Context Protocol, or MCP, is described on its own site as an open-source standard for connecting AI applications to external systems. The official introduction compares it to a USB-C port: one standard connector instead of a custom cable for every device.

For a client, the benefit is simple. A company has a CRM, a database, a project tracker and some internal documents. Today someone copies data into a chat window by hand. An MCP server exposes those systems as tools, so Claude, ChatGPT, Cursor or VS Code can read and act on them directly. The same site lists Claude, ChatGPT, Visual Studio Code and Cursor among the clients that support it, so one server works across all of them.

You are not selling "AI". You are selling a connection between the client's systems and the AI apps their staff already use, built so it does not leak data or break the day an API changes.

Is there enough demand to build a practice on

Enough to start, and the numbers are public. In its December 2025 post about moving MCP to a new foundation, Anthropic reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript. It named Anthropic, Block and OpenAI as co-founders of the foundation, with Google, Microsoft, AWS, Cloudflare and Bloomberg among the supporters.

Hiring data points the same way. Upwork's 2026 In-Demand Skills report says demand for the top AI-related skills grew 109% year over year, with AI integration among the fastest growers at 178%. That category is the work an MCP project falls into.

What the data does not give you is a market price for MCP work. No public benchmark exists, and any list of "going rates" you read online comes from someone's own pipeline. Price your first projects from your scope and your time, and revise after three of them.

Four offers that sell

Pick one or two. A buyer who knows what they want will close on the first call.

Connect one system

The smallest sale. You build one server for one tool, such as a database, a billing system or an internal API. You deliver code, a deployment recipe, an auth setup and a short runbook. It is a good first project because the client can see the result in an afternoon.

Connect the team's stack

Several servers covering the tools a team uses every day: the CRM, the tracker, the docs. The work now includes shared secrets handling, logging and a way to add tools later. Sell it as a fixed scope after a paid discovery week.

Ship an official server for a software product

A software company wants to publish its own MCP server so its customers can plug the product into AI apps. This is product engineering: schema design, rate limits, docs, tests and a release process. The buyer is usually a head of engineering or product, and the sales cycle is longer. The official MCP Registry is where published servers are listed, built in the open by MCP contributors.

Run and extend it monthly

A retainer to monitor the servers a client already runs, add tools, rotate secrets and patch things when an SDK updates. It has the steadiest income and the least selling. Our post on why senior consultants are leaving hourly rates covers how to set one up.

The security work clients expect

This is where a professional build differs from a weekend one, and it is what a careful buyer asks about first. MCP publishes its own security best practices, and they read like a scope-of-work checklist.

Three items belong in every proposal:

• Token passthrough. The guidance says MCP servers must not accept any tokens that were not explicitly issued for that server. A server that forwards whatever token it receives can let a stolen token reach other systems and breaks the audit trail.
• Per-client consent for proxy servers. A server that sits in front of a third-party API has to ask the user before forwarding an authorization request. Skipping this opens the "confused deputy" attack the guide describes.
• Least-privilege scopes. The guide warns against wildcard or "all access" scopes and recommends a small starting scope that grows only when a tool needs more.

If the server runs on a user's own machine, the guide adds sandboxing and consent for the commands it can run. If it runs remotely, add HTTPS, input validation and logging of every tool call.

Put these in the written scope and in the price. A client who has been burned by an AI tool touching the wrong record will pay for an audit trail, and it is hard to add after the fact.

How to find the first buyers

There is no "MCP developer" filter on most work marketplaces yet, so look where the demand shows up.

• Registries and directories. If a company's competitor has a popular public server, the company may want its own private one.
• Open-source issue trackers. Search closed issues that mention MCP in repositories for tools your target clients use. Answer questions helpfully. Do not pitch in the thread.
• Communities for the AI apps themselves. Support channels for Cursor, Claude and similar tools are where teams ask who can build this for them.
• Your current clients. A client who already trusts you with a website or an integration is the easiest first sale. Ask what staff copy into chat windows every day.

Publish one useful open-source server first. It gives buyers something to inspect before they email you.

Scoping and pricing the first project

Start with a paid discovery step, then quote the build as a fixed price against what discovery found.

A shape that works for most small engagements:

1. Discovery, one week, fixed price. Map the client's tools, define which actions the AI is allowed to take, agree on auth and where it will run. The output is a written scope and a firm quote.
2. Build, fixed price against that scope. Include logging, error handling and a deployment recipe, not just the happy path.
3. Support window. Set a short period, such as 30 days, for fixes and one round of small additions. Name the end date in the contract.
4. Optional retainer, priced separately.

Two pricing mistakes show up again and again. The first is hourly billing, which punishes you for working fast on a well-scoped job. The second is anchoring on a no-code automation price. An MCP server includes auth, security review and a handover, so compare it with a small platform engineering project.

Write down what counts as a change. When the client adds a tool halfway through, that is a change order, not a free favour. Having the rule in the contract before work starts makes the conversation easy.

How Delivvo runs an MCP project from quote to handover

Delivvo runs the commercial side of the project so you can stay in the code. A technical engagement still needs a quote, a contract, a deposit, approvals and a clean handover, and those are where small projects lose money.

The flow:

1. The client fills in your inquiry form. You can add fields for the systems they want connected and the AI apps their team uses, and the answer lands on your lead board.
2. You send a quote built from packages and add-ons: a discovery sprint, a build, a support window and a monthly retainer as an optional add-on.
3. The client accepts, signs the contract and pays the deposit from the same link. The signing record and an archived PDF are saved, so the scope you agreed is the scope on file.
4. You split the balance with a payment schedule of up to 12 payments, for example one on discovery sign-off, one on the first working server and one on handover.
5. You deliver builds, runbooks and release notes through the client portal. The client opens it with a one-time code, no password, reviews each version and approves it, and the approval is recorded.

The concrete detail: the client pays you through your own gateway, and Delivvo takes 0%. On a project with a large deposit, that is a real saving over a platform that takes a cut. Every invoice and contract also carries a verification code, which helps when a buyer's security team asks for proof of what was agreed.

See the pieces on the proposals page, the payment schedules page and the client approvals page.

Next, look at Delivvo for teams or how the CRM fits around it.

FAQ