Model Context Protocol
MCP server development: give AI access to your systems without giving it the keys
MCP is the standard way to let an assistant read your data and act in your systems. The protocol is the easy part. What decides whether you can put it in front of a customer is the authentication, the scoping and the audit trail around it — and that is engineering, not configuration.
- ScopedLeast privilege by default
- AuditedEvery call attributable
- EUData residency
What we build
The server, and everything that makes it safe to expose
An MCP server is a small amount of protocol and a large amount of judgement about what a model should be allowed to do.
MCP servers over your systems
Your CRM, ERP, ticketing, data warehouse, document store or internal API, exposed as tools and resources an assistant can actually use.
Authentication and identity
The server acts as a named user with their permissions, not as a shared superuser. Remote servers use the protocol's OAuth-based authorisation rather than a static token in a config file.
Scoping and approval gates
Read separated from write, destructive actions behind an explicit confirmation, and hard limits on what a single call can touch.
Audit trail
Every tool call logged with who asked, what ran, what came back and what changed — the record a security review will ask for and an incident will need.
Injection-resistant tool design
Returned data is treated as data, not instructions. Tool contracts are narrow and typed, so text retrieved from a ticket cannot talk the model into calling something else.
Client integration
Wiring the server into the assistants and IDEs your team already uses, or into your own agent, and keeping it working as the protocol moves.
How an MCP engagement runs
Start with one workflow that is worth automating
Pick the workflow
We look for the task where people are already copying data between a system and a chat window. That is the one with proven demand and a measurable before.
Design the tool surface
Which actions exist, what each one is allowed to touch, and what requires a human to say yes. This conversation is the security review, held early enough to be cheap.
Build and instrument
The server, its authentication, its logging, and a test suite that pins each tool's contract so a later change cannot quietly widen it.
Roll out and widen
Ship to a small group, watch the audit log for what people actually do with it, then add the next system. The second server is much faster than the first.
Why this needs engineers
The demo works on day one. The problem is what it is allowed to do on day ninety
Most MCP servers we are asked to review were built quickly, and it shows in one specific way: they hold a single admin credential and expose every action it can perform. That is fine on a laptop. It is not something you can put in front of a support team, because the model is now acting with more authority than any of the people using it.
Fixing it after the fact is expensive, because permissions turn out to be a design decision rather than a setting. Which identity is the call made as, what happens when a tool is asked to touch a record outside its scope, how a destructive action gets confirmed, and what the log has to contain to reconstruct an incident — these belong in the first sprint.
That is the work we do. It is the same discipline any integration into a system of record needs; MCP has only made the integration easy enough that the discipline is now the whole job.
Common questions
What buyers ask about MCP
What is MCP?
The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. Instead of building a bespoke integration for every assistant, you build one MCP server for a system and any compatible client can use it. Anthropic published the protocol and it is now supported across a range of assistants, IDEs and agent frameworks.
How is this different from just building an API?
You are usually not replacing an API — you are putting an MCP server in front of one. The difference is who the consumer is. An API is written for a developer who reads the documentation; an MCP tool is written for a model that will infer intent from a name and a schema, so the naming, the granularity and the error messages carry much more weight.
The other difference is the threat model. An API client does what its code says. A model can be talked into things by the data it reads, which is why the tool surface has to be narrow and the permissions real.
Is it safe to connect this to production systems?
It can be, and the answer is architectural rather than reassuring. The server authenticates as the individual user and inherits their permissions, read is separated from write, destructive actions require explicit confirmation, and every call is logged with enough context to reconstruct it. Where that is not achievable for a given system, we say so and scope it to read-only instead.
Can you audit an MCP server we already have?
Yes, and it is a common starting point. We review the tool surface, the credentials it holds, what a single call can reach and what the logs would show after an incident, then give you a prioritised list. Anything that is already right we leave alone.
The protocol is young. What happens when it changes?
It does change, and that is planned for rather than hoped about: the protocol layer is kept thin and separate from your business logic, so a spec revision is a change in one place. This is also why we build the tool contracts under test — the suite is what tells you an upgrade broke something, before your users do.
Do we need an MCP server at all?
Not always, and we will tell you during the first conversation. If one team needs one report, a scheduled export is cheaper and more predictable. MCP earns its place when several people need several systems, conversationally, and the integration cost per system is what has been stopping you.
Tell us which system you want an assistant to reach
Thirty minutes with a senior engineer, and an honest answer about whether MCP is the right shape for it.