Specialism
Custom MCP server development services for the systems you already run
An assistant is only as useful as what it is allowed to reach. The work here is the connector, not the conversation: one authenticated, permission-scoped interface onto your CRM, your database and your internal APIs, instead of a bespoke integration rewritten for every model and every tool you try.
The standard
What an MCP server actually is
MCP stands for Model Context Protocol — an open standard, published by Anthropic in November 2024, for connecting AI applications to the systems where data and actions live.
A server is a small program you own that sits in front of one system and advertises what can be done with it. Any assistant that speaks the protocol can then discover that list and call it. Because the specification is open and published (opens in new window), the same server works across the assistants and development tools that have adopted it — which is the entire point. You write the integration once rather than once per vendor.
A server exposes three kinds of thing. Tools are functions the assistant can invoke — look up an account, create a ticket, run a defined query. Resources are read-only context it can pull in, such as a table schema or a reference file. Prompts are reusable templates for common interactions. Underneath, messages are ordinary JSON-RPC 2.0, which means nothing exotic to host and nothing exotic to debug.
Where the server runs decides how it is secured. A local server talks over standard input and output to a single client on the same machine. A remote one uses the Streamable HTTP transport, serves many clients at once, and is the shape almost every business case takes — which is why the protocol recommends OAuth for obtaining its tokens rather than a shared key pasted into a config file.
Where this work stops and agent design begins
This page is about the server: the protocol surface, the authentication in front of it, the permission attached to each tool, and where the thing is deployed. What the assistant does with those tools — how it reasons, what it may attempt unsupervised, when it stops and asks a person, how its behaviour is measured — is separate work and lives on custom AI agent development. If what you actually want is answers drawn from your policies, contracts and manuals, that is RAG chatbot development, and a protocol server is not the first thing to build. And if the connector is one step in putting Claude in front of a whole team, Claude AI implementation consulting covers the plan, the shared projects and the training around it.
What we build
Three kinds of server, by what sits behind them
The protocol work is nearly identical in all three. What differs — and what drives the estimate — is how much effort it takes to get a safe, permissioned path into the system underneath.
Over a database
A fixed set of parameterised queries rather than open SQL, with the schema published as a resource, row limits enforced server-side, and no path from a tool call to an arbitrary statement.
Over a SaaS API
Your CRM, helpdesk or billing platform reduced from dozens of endpoints to the handful of operations an assistant should have, named the way your team names them rather than the way the vendor does.
Over internal services
The order system, the scheduling engine, the line-of-business application nobody wants to touch — reached through whatever it does expose, with the awkwardness contained inside the server.
Method
What separates a weekend prototype from something you can leave running
Standing up a server that returns data takes an afternoon; the SDKs are good and the protocol is small. Everything that makes it safe to point at a production system is the actual project.
| Concern | How a prototype handles it | What we build instead |
|---|---|---|
| Authentication | No auth, or one long-lived token in a local config file | OAuth on the remote transport, with the real user's identity carried through to every call |
| Authorisation | The server can do anything its single service account can do | A scope per tool, so what the assistant may reach is a subset of what the person may reach — never a superset |
| Tool surface | One tool per API endpoint, all of them exposed | A short, task-shaped list in your own vocabulary, because a model choosing between sixty tools chooses badly |
| Input validation | Arguments passed straight through to the system behind | A JSON Schema on every tool, validated server-side before anything is read or written |
| Write safety | Writes look identical to reads and happen just as easily | Destructive operations isolated, made idempotent where possible, and gated on explicit human approval |
| Auditability | Console output that nobody keeps | Every call recorded with caller, arguments and result, so "what did it actually do" has an answer |
| Deployment | Runs on one laptop and stops when that laptop sleeps | Runs where your other services run, versioned, with the tool list changing deliberately rather than by accident |
Rate limits and quotas are yours now. A tool an assistant can call in a loop will be called in a loop. The platform behind it still has its own throttling rules — Microsoft's Graph API best practices (opens in new window) are a fair example of what most vendors expect — so batching, caching and back-off belong in the server rather than in the prompt. Governance is documented against the NIST AI Risk Management Framework (opens in new window), and the questions worth asking any vendor about this are collected in our guide to security questions to ask an AI automation vendor.
Scope and cost
How long does an MCP server take to build?
One server over one system, with a small tool set and a real authentication story, is usually a matter of weeks rather than months. The protocol is not the variable — the variable is how much work it takes to open a safe, permissioned path into the system underneath it. Legacy applications move that number more than anything else.
Pricing follows the same shape as everything else here: a fixed price per stage, agreed before that stage starts, after a free call in which we work out what the tool list should be. The way projects are scoped is written out in full, including what happens when a stage turns out to be harder than it looked.
Do we still need this if we already have an API?
Having one is what makes the work cheap, not what makes it unnecessary. An API is written for a developer who reads documentation; a tool list is read by a model that does not. The server is where dozens of endpoints become a handful of operations named after what the business calls them, where arguments get validated, and where permission is attached per tool rather than per token.
Related pages worth reading next: software companies exposing their own product data to internal assistants should start with AI automation for SaaS companies, which covers the operational processes a server like this usually gets built to serve, and workflow automation for the cases where a scheduled integration is the right answer and no assistant needs to be involved at all.
Questions
What clients ask before commissioning one
What is MCP, in one sentence?
The Model Context Protocol is an open standard for connecting AI applications to outside systems, so a server you write once can be called by any assistant that speaks it. Practically, it replaces a pile of one-off, model-specific integrations with a single interface that describes what your systems can do.
We already have a REST API — why add a server in front of it?
Because an API is written for a developer who reads documentation, and a tool list is read by a model that does not. The server narrows dozens of endpoints to a handful of task-shaped operations, names them the way your business does, validates arguments, and applies permissions per tool rather than per token.
Is exposing our systems this way a security risk?
It is exactly as risky as the permissions you grant it, which is why authorisation is designed before any tool is written. Remote servers authenticate the real user rather than sharing one service account, each tool carries its own scope, writes are separated from reads, and every call is logged with its caller and arguments.
Do you build the agent as well, or only the server?
Either, and they are separable on purpose. A server is a durable asset that outlives whichever assistant is fashionable this year, so some clients commission only that and point their existing tools at it. If you also want the reasoning, guardrails and evaluation around it, that is agent development and we scope it as its own stage.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.