MCP server development: connect AI to your systems once, safely
We build Model Context Protocol servers that expose your CRM, databases, ticketing and internal APIs to Claude and other AI hosts, with least-privilege tools, scopes and audit logs.
A standard socket between AI hosts and your systems
Before MCP, every assistant needed its own bespoke integration with every system. The Model Context Protocol replaces that with one server per system that any compatible host can discover and call. The host asks the server what it offers; the server enforces what is allowed.
One server per system. The host sees tools and resources; the system sees a scoped service account; every call is logged in the middle.
What a server exposes
Tools, resources and prompts
An MCP server offers three kinds of thing. Deciding which of your capabilities belong in which category is most of the design work.
Tools
Actions the model can call with typed arguments: find a customer, create a ticket, run a named report. Each has a description the model reads, a schema the server validates and a scope the server enforces. See tool use and function calling.
Resources
Read-only content the host can load into context: a policy document, a schema, a customer record, a dashboard snapshot. Addressed by URI, cacheable, and never a side effect.
Prompts
Reusable, parameterised instructions the server publishes: "summarise this account for a renewal call", "triage this ticket". They encode your house style and your rules, once, for every host.
Transport and auth
Where the server runs and how it is trusted
Option
How it works
Fits
Watch-outs
Local (stdio)
The host launches the server as a process on the same machine
Developer tools, Claude Code, personal assistants, anything using local credentials
Each user runs their own copy; secrets live on laptops; hard to audit centrally
Remote (HTTP)
A hosted service the host connects to over the network
Shared company systems, agents in production, several hosts and users
Needs real authentication, rate limits, monitoring and a deployment pipeline
OAuth per user
The server acts as the signed-in user against the back-end
CRM and ticketing where permissions already exist per person
Token lifecycle and consent screens must be handled properly
Service account + scopes
The server holds one credential with narrow rights and enforces scopes itself
Databases and internal APIs without per-user auth
Scopes must be designed carefully; a broad service account defeats the purpose
We deploy remote servers to Cloudflare Workers, Azure or Docker on your infrastructure, in Python or Node.js, behind your identity provider.
Security
An MCP server is an attack surface. We build it as one.
The model that calls your server also reads emails, web pages and documents written by strangers. Some of those will contain instructions aimed at your tools. The server is where those instructions must fail.
Least privilege: read-only credentials by default, write tools separated and scoped, no raw query or shell tools.
Allowlists over blocklists: tables, fields, record types and actions the server may touch are enumerated, not inferred.
Input validation on every argument, parameterised queries, size and rate limits, timeouts.
Tool descriptions written to resist manipulation and tested with injection payloads from our prompt injection defence practice.
Human approval hooks for high-impact actions, and an audit log that answers "what did the AI do and why" for every call.
Secrets in a vault, never in prompts, logs or the model's context.
What goes wrong when a server is built in an afternoon
Example: a "quick" database server exposes a run-SQL tool with the application's full credentials. An agent reads a support ticket containing hidden instructions, obligingly runs a query that exports customer records, and returns them in its reply. Nothing in that chain was malicious code; the design made it possible. Scoped tools and an allowlist would have made it impossible.
Process
From system inventory to a tested server
Inventory
Which systems, which actions, which users, which hosts. What must never be possible.
Design the surface
Tools, resources and prompts with schemas, scopes and descriptions. Reviewed by security before a line is written.
Build and test
Server, contract tests, injection tests, load tests. Tested against the hosts you use, including Claude and Claude Code.
Deploy and watch
Hosted behind your identity provider with logging, rate limits and dashboards. Handover and documentation for your team.
MCP is an open protocol, originally published by Anthropic, that lets an AI host such as Claude, Claude Code or your own application discover and call tools, read resources and use prompts from a server over a standard interface. Build one server and any compatible host can use it. Our guide MCP explained goes deeper.
Why build an MCP server instead of a normal API integration?
An API integration is written for one application. An MCP server is written once for every AI host and agent you will run, with tool descriptions the model understands, standard discovery and a consistent place to enforce scopes and logging. For systems that several assistants will touch, it is less work and safer.
How long does an MCP server take to build?
A read-only server over one system with a handful of tools typically takes two to four weeks including tests and security review. Servers with write actions, approvals and several back-ends run four to eight weeks. The system's own API quality is the biggest variable.
Is it safe to let a model call our database?
Only through a server that never exposes raw access. We give the server a read-only database role, parameterised queries, row and column allowlists, rate limits and an audit log. Write actions are separate tools with explicit scopes and, where needed, human approval.
Which hosts can use the servers you build?
Any MCP-compatible host: Claude desktop and Claude Code, IDE assistants, agent frameworks and your own applications built on the Claude, OpenAI or Gemini APIs via an MCP client. We test against the hosts you actually use.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.