MCP Server Development UK.

What an MCP server is, in plain terms

The Model Context Protocol (MCP) is an open standard for connecting AI applications to the systems and data they need. In MCP terms your AI assistant (Claude, ChatGPT, Copilot Studio, an IDE) is the host, and an MCP server is the piece of software that sits in front of your systems and offers them to it in a standard shape.

The specification on modelcontextprotocol.io defines three things a server can offer: tools, which are functions the model can call such as find_customer or create_quote; resources, which are data the user or model can read, such as a price list or a policy document; and prompts, which are reusable templates for common jobs. Messages are JSON-RPC 2.0.

The point is that you build one well-governed server and every MCP-capable assistant can use it, instead of a separate integration for each AI product. Since December 2025 the protocol has been looked after by the Agentic AI Foundation under the Linux Foundation, which Anthropic, OpenAI and Block co-founded, so it is not tied to one vendor.

Read tools, write tools and who can use what

The MCP specification is blunt about risk: it says tools represent arbitrary code execution and that hosts must get explicit user consent before invoking any tool. We design on that basis. Most of the work in an MCP project is deciding what each tool is allowed to do.

• Start read-only. Searching orders, checking stock, reading a contract. Low risk and usually where most of the value is.
• Add write tools one at a time. Each has strict input validation, a clear description of its side effects and, for anything irreversible, a confirmation step or an approval queue.
• Honest tool annotations. We mark tools as read-only or destructive accurately. OpenAI's and Anthropic's directory reviews both check these hints, and clients use them to decide when to ask the user.
• Permissions follow the person. The server acts as the signed-in user, so a sales assistant sees their accounts and not the whole ledger.
• Untrusted content stays data. Text pulled from emails or uploads is returned as content, never treated as instructions, to limit prompt injection.

This is the same thinking we apply to AI agent development: the controls live in code, not in the prompt.

Authentication done to the spec

For remote servers, the MCP authorisation specification builds on OAuth 2.1. Your MCP server acts as an OAuth resource server and must publish OAuth Protected Resource Metadata (RFC 9728) so clients can discover which authorisation server to use. Clients use PKCE and send a resource indicator (RFC 8707), and the server must check that each access token was issued for it specifically. The spec also says servers must not accept or pass on any other tokens, which rules out the lazy pattern of forwarding the user's token straight to a downstream API.

In practice we usually put your existing identity provider in charge, such as Microsoft Entra ID or Google Workspace, so staff sign in with the account they already have and leavers lose access automatically. Where an AI client supports Client ID Metadata Documents or dynamic client registration we support those; otherwise we pre-register the client. Scopes are kept small, for example orders:read separate from orders:write.

Which AI clients can connect

• Claude: Anthropic's help centre says custom connectors using remote MCP are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). Claude connects from Anthropic's cloud, not from the user's device, so the server must be reachable over the internet or your firewall must allow Anthropic's published IP ranges.
• ChatGPT: OpenAI's developer platform now lists MCP servers inside what it calls plugins; see ChatGPT apps and Claude integrations for how listing and review work.
• Microsoft Copilot Studio: Microsoft Learn documents an MCP onboarding wizard and says Copilot Studio supports the Streamable HTTP transport only, not the older SSE transport. See Copilot Studio agents.
• Your own software: agents you build with the OpenAI, Anthropic or Gemini APIs can use the same server.

We test against each client you care about, because they differ in how they handle sign-in, confirmations and long-running calls.

Hosting, logging and keeping it running

An MCP server is a production web service and we treat it like one. We deploy it in a container on UK or EU infrastructure you control, behind TLS, with health checks and alerting. Every call is logged with the user, the client, the tool, the arguments (with personal data masked where needed) and the result, so you can answer the question "what did the AI do on Tuesday?" in seconds.

Rate limits stop one chatty assistant hammering your ERP. Calls to slow back-end systems go through a queue with timeouts. The protocol moves quickly, with several specification revisions since launch, so we pin SDK versions and include a review of new revisions in any maintenance agreement.

We run AI infrastructure ourselves: dijitul.ai is our UK-hosted gateway to the Claude API, so the hosting, logging and key-management problems here are ones we deal with day to day.

How an MCP project runs

It starts with a free chat about which systems you want AI to reach and what you are worried about. A short scoping stage produces the tool catalogue, the permission model and the list of AI clients to support. You then get a fixed-price quote. A typical first phase is read-only tools for one system, used by a pilot group, followed by write tools once the logs show the read side behaving. Where there is no usable API behind the system, we build one first. You own the code at the end.

What we deliver

• A tool catalogue: every tool, what it reads or changes, who may use it and what it returns
• An MCP server in TypeScript or Python using the official SDKs, over Streamable HTTP
• OAuth 2.1 sign-in against your identity provider (Microsoft Entra ID, Google or your own), with scoped tokens
• Read-only tools first, then write tools with confirmation steps, validation and rate limits
• An audit log of every tool call: user, client, arguments, result and timing
• Hosting with TLS, monitoring and alerting, on infrastructure you control
• Connection guides for Claude, ChatGPT and Copilot Studio, and handover documentation

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related