Services
MCP Server Development Services: Scope, Cost, Vetting
Checked 2026-10-31
Loading poll...
An MCP server development service builds a Model Context Protocol server that exposes your system, such as a database, an internal API or a SaaS account, as tools an AI agent can call. A good project covers tool design, authentication, permissions, logging, tests, hosting and documentation. The directory is open and names no provider yet.
What an MCP server is for
MCP is a shared protocol. An MCP server lists the tools, resources and prompts it offers, and any compatible agent can discover and call them in one format. Without it, every agent needs its own glue code for every system. With it, you write the connection once and Claude Code, Cursor, OpenCode and others can use it. Our explainers cover the ground: what MCP servers are, MCP vs API and skills vs MCP.
You need a custom server in four situations.
Situation | Why a custom server |
|---|---|
An internal system with no public connector | There is nothing to install |
A SaaS tool whose public server is too broad | You want a narrower, read-only or audited version |
A workflow that spans several systems | One server can expose one coherent set of tools |
Several agent products need the same access | Build once, use everywhere |
If a maintained server already covers your case, use it. Browse the MCP servers directory and the lists on best MCP servers before paying for new code. For a single agent and a single service that you control, calling the API directly may be simpler, as the comparison page explains.
What a good engagement includes
Phase | What happens | What you should receive |
|---|---|---|
Scoping | Which tasks the agent must do, which systems it needs | A list of use cases, each with the tool it implies |
Tool design | Names, inputs, outputs and descriptions for each tool | A tool specification you can read |
Authentication | How the server proves who is calling, and to which system | A documented auth design, with least-privilege credentials |
Build | Server code, error handling, limits | Code in your repository |
Security review | Permissions, input validation, injection risk, logging | A short written review |
Testing | Calls from real agents, plus unit tests for each tool | A test suite and a record of client tests |
Hosting | Where it runs, how it is updated | A deployment you can operate |
Documentation | Setup lines for each agent, tool reference | Docs your staff can follow |
Handover | Accounts, keys, repository, runbook | Everything in your name |
Tool design is the craft. An agent chooses tools by their names and descriptions, so poor naming gives poor results. A good provider designs a few well-named tools around tasks, instead of wrapping every endpoint of your API one to one. Ask to see the tool specification before code is written, and read it as if you were the model: could you tell which tool to use?
Authentication needs a decision. Hosted servers often use OAuth or a bearer token, and a local server may take an API key from an environment variable. The Linear server documented elsewhere on this site, for example, accepts an OAuth token or an API key, and a key with only the Read permission gives read-only access. That is the shape to copy: the credential should carry the permission limit, so a bug in the server cannot exceed it.
Security: the part to take seriously
An MCP server is a door from a model into your systems. Vendors say plainly that the trust sits with you. Anthropic's security page states that it reviews connectors against listing criteria before adding them to its directory, but does not security-audit or manage any MCP server, and it encourages writing your own servers or using providers you trust. Cursor requires approval for every MCP connection and for each tool call unless you allowlist the tool.
A competent provider will design for these risks.
Risk | Control to expect |
|---|---|
The agent does something destructive | Read-only first, write tools added one by one, each with limits |
A hostile instruction in retrieved text steers the agent | Tool outputs treated as data, narrow tools, no tool that executes arbitrary text |
Credentials leak | Scoped keys, rotation, secrets kept out of code and prompts |
One user sees another's data | Per-user auth, not one shared key |
Nobody can tell what happened | Logging of every call with the caller, tool and arguments |
Large outputs flood the context | Pagination and size caps on every tool |
A server is added without review | A central allowlist, delivered through managed settings |
The last row is yours to own. Claude Code's docs say project-scoped servers live in .mcp.json, but servers at other scopes, claude.ai connectors and plugins can add servers too, so reviewing one file does not show every server a session can load. They describe managed MCP controls to restrict which servers run in an organization. See enterprise AI coding agent security for the wider picture.
What drives the cost
We will not quote rates, because we have no source for market prices and they vary. The drivers are these.
Driver | Effect |
|---|---|
Number of tools | Each tool needs design, code, tests and docs |
Quality of the upstream API | A clean, documented API is quick to wrap. A messy one is not |
Authentication model | Per-user OAuth costs more than a service key |
Write access | Write tools need more design, limits and review |
Hosting needs | Local-only is cheap. A hosted, multi-user server needs operations |
Clients to support | Each agent product has its own quirks and install steps |
Compliance | Audit logs, data residency and review add work |
Upkeep | When the upstream API changes, the server must change |
The upkeep line is the one that surprises people. A server is a dependency on someone else's API, and when that API changes, the server breaks. Ask who monitors it, and how a fix is paid for.
A useful way to size a project is to count the tasks, not the endpoints. If your agent must do five things, you probably need five to eight tools. A proposal for fifty tools is either for a much bigger job or a one-to-one wrapper that will confuse the model.
An illustration: from tasks to tools
The example below is invented to show the method. It is not a real project. Suppose a company wants an agent to help with its internal ticket system. The brief lists five tasks, and a good design maps each to a tool.
Task the agent must do | Tool | Access | Notes |
|---|---|---|---|
Find tickets about a topic |
| Read | Takes a query and a limit, returns titles and ids, capped page size |
Read one ticket in full |
| Read | Takes an id, returns fields and comments, long text truncated with a marker |
Summarise a customer's open tickets |
| Read | Takes a customer id, pagination built in |
Draft a reply |
| Write, draft only | Saves a draft for a person to send, never sends |
Change a ticket's status |
| Write, narrow | Allowed values only, each change logged with the caller |
Notice what is absent. There is no delete_ticket, no tool that sends mail, and no generic "run query" tool. The agent can do the five jobs and cannot do much else. That is the design discipline you are paying for. A proposal that begins with "we will expose your whole API" is the opposite.
Testing that is worth paying for
A server that passes its own unit tests can still fail with a real agent. Ask for three layers.
- Unit tests per tool: inputs, outputs, error cases, limits.
- Client tests: the server installed in the agents you use, with a written script of prompts and the expected tool calls, and a record of what happened.
- Abuse tests: a prompt that tries to make the agent call a tool it should not, a request for a huge result, a call with the wrong credential. Each should fail safely.
Add a regression check that runs when the upstream API changes. Even a daily call to each tool with a known input will tell you before your users do.
Operating a server after launch
Routine | Why |
|---|---|
Review the call log weekly | Odd calls are the earliest sign of a misused tool |
Rotate credentials on a schedule | Limits the value of a leaked key |
Re-run client tests when you update an agent | Agents change their MCP handling over time |
Track upstream API changes | A breaking change will break your tools |
Keep a list of approved servers | The central allowlist is only useful if current |
If you buy hosting from the provider, ask for the same routines as part of the support terms, and ask what the log report looks like.
How to judge a provider
We name no provider and rank none. Use this table on anyone you find.
What to look at | A good sign | A weak sign |
|---|---|---|
Tool design | They show a tool specification and explain naming | They wrap every endpoint |
Security | They start read-only and talk about scoped credentials | They ask for admin keys |
Testing | They test with real agents and show results | "It should work with any client" |
Ownership | Code in your repository from day one | Their repository, hosted by them only |
Docs | Install lines per agent, a tool reference, a runbook | A README |
Standards | They use the official SDKs and the current spec | A homemade protocol |
Maintenance | A stated plan for upstream changes | Silence |
Examples | They can point to servers they built that are public | No public work and no references |
Public examples are a fair test. Many providers publish a server as open source, and you can read the code. If none of the provider's work is readable, ask for a code sample under NDA.
Red flags
- Admin credentials. A server that needs a root key to function will fail a security review.
- No logging. You will not be able to answer "what did the agent do."
- One shared key for all users. Every agent action looks like the same person.
- A tool that runs free-form commands. It turns every prompt injection into a remote shell.
- No version pinning or tests. The first upstream change will break it.
- A proprietary lock. If only the provider can host or change the server, you have bought a subscription.
Questions to ask
Topic | Question |
|---|---|
Scope | Which tasks do the tools cover, and which are out of scope? |
Tools | How many tools, and how are they named and described? |
Auth | How is each caller authenticated, and what permissions does each credential carry? |
Writes | Which tools change data, and what limits do they have? |
Logging | What is logged, where, and for how long? |
Clients | Which agents do you test with, and can you show it? |
Hosting | Where does it run, and who updates it? |
Upkeep | Who fixes it when the upstream API changes, and at what cost? |
Ownership | Who owns the code, the credentials and the documentation? |
Exit | If we leave, can we run it ourselves? |
Build it yourself first?
Many teams can build a first server themselves. A small server with a few tools is a short project for a developer who has used an SDK. Our guide, how to build an MCP server, walks through it, and install an MCP server in Claude Code shows the client side. A provider earns their fee on the hard parts: per-user authentication, a security review, hosting, and the compliance trail. If your need is a read-only wrapper over one database, try it in-house first and bring in help if it grows.
How to request quotes here
The listings under /services/ are open, and no provider is listed yet. When they join, paid placement will be labelled and will not change ratings or order.
- Write a brief: the systems to connect, the tasks the agent must do, the agents you use, and your auth and data rules.
- State your security rules: read-only first, no shared keys, logging required.
- Send it once through get quotes. The plan is to match a brief to up to three providers.
- Compare quotes on tool design, security approach, ownership and upkeep, and then on price.
Providers can see claim your listing and plans and sponsored slots.
Our take
An MCP server is a small piece of software with a large blast radius. The cost is not in writing it, but in designing tools a model uses well, in scoping the credentials, and in keeping it working when the system behind it changes. Judge a provider on those three, ask to read their public work, and keep ownership in your hands. And before you pay, check that a maintained server does not already exist.
We have not tested or ranked any provider. Claims about vendors come from their documents as read on 2026-10-31.
Related pages
Get quotes, AI agent development services, MCP servers, MCP vs API, Linear MCP.
Questions
What is an MCP server development service?
A provider builds an MCP server that exposes your system, such as a database, internal API or SaaS account, as tools an AI agent can call, with authentication, permissions, logging and tests. Several agents can then use the same server.
Do we need a custom MCP server?
Only if no maintained server covers your system, or you need tighter control than a public one gives. Check the add-ons directory first. For one agent and one service you wrote, calling the API directly can be simpler.
What is the main security risk?
Too much access. Anthropic notes it does not security-audit or manage any MCP server, so you own the risk. Start read-only, scope credentials tightly, log every call, and approve servers centrally.
Are agencies listed here?
Not yet. The directory is open for listings and names no provider. You can send one brief through the quote form.
Loading poll...
