Let AI clients use your systems, without handing over the keys.
We build Model Context Protocol servers that let Claude and other MCP clients read your data and act in your systems through an interface you define. Every call is authenticated as a real user, checked against their permissions and logged. We have shipped real MCP servers, not prototypes.
Who this is for, and who it is not.
A good fit if
- Your team copies data out of your admin panel into Claude, and it should come from the source instead.
- You run a Laravel app, WooCommerce store or internal API that holds the answers people keep asking for.
- You want staff to use AI on live orders, customers or tickets without giving it a database password.
- A customer or partner has asked whether your product works with Claude, and you need a real answer.
Probably not the right call if
- Your users will never install an MCP client, so a chat feature inside your own product will serve them better.
- The data lives in a SaaS tool that already ships an official MCP server covering what you need.
- Your system has no permissions model yet and nobody can say who should see what. That comes first.
What changes for your team.
Answers come from live records, not exports
People ask about an order, a customer or a stock level and the model reads the current record. Nobody maintains a spreadsheet copy that is already out of date.
Access follows the permissions you already have
A sales rep sees what a sales rep sees in your app, whichever client they use. Disabling a user in your system cuts off their MCP access as well.
Every action has a user and a timestamp
When someone asks who refunded that order or changed that price, the audit log answers. Write actions are few, deliberate and traceable.
The parts that make it hold up in production.
A tool surface agreed in writing
A written list of the tools, resources and prompts the server exposes, with the input schema and permission each one needs. Anything not on the list is unreachable, however the model phrases the request.
Per-user OAuth sign-in
Remote servers use OAuth, so each person signs in as themselves, against your existing accounts where possible. Tokens are accepted only if issued for this server, with scopes that separate reading from writing.
Read tools and guarded write tools
Read tools return only what the caller may see, with sensitive fields removed. Write tools validate every argument on the server and can stage a change for a person to confirm before it is applied.
Rate limits enforced on the server
Limits per user, per tool and per client, enforced by the server rather than trusted to the client. A model stuck in a loop gets a clear error instead of hammering your database.
An audit log you can query
Each call is recorded with the user, client, tool, arguments and outcome, with secrets and personal data redacted to rules you set. The log lives in your infrastructure, not ours.
A versioned tool surface
Tool names and schemas are versioned, and breaking changes ship as new tools alongside the old ones until clients move over. Tests run the server through real MCP clients, not only unit tests.
A strict layer between the model and your systems.
Clients talk to the MCP server over the protocol. The server talks to your application through the same permission checks your own interface already uses.
-
Where people use it L4Claude Claude Code IDE agents Other MCP clients
-
Transport and sign-in L3Streamable HTTP stdio (local) OAuth Scoped tokens
-
The MCP server L2Tools Resources Prompts Rate limits Audit log
-
What you already run L1Laravel app WooCommerce store CRM MySQL Internal APIs
From first call to running in production.
Each step ends in something you can look at. Scope grows after something is live, not before.
-
01
Decide what to expose, and what not
We list what people actually ask for, then mark each action as read, write or not exposed. Bulk deletes, payouts and anything irreversible usually stay out, and we write down why.
-
02
Ship read tools first
The first release is read-only, on real data, for a small group of real users. We watch which tools the model picks and where it guesses wrong, then tighten descriptions and schemas.
-
03
Add write tools one at a time
Each write tool gets its own scope, server-side validation, rate limit and audit entry. Where a mistake is costly, the tool stages the change and a person confirms it.
-
04
Test in real clients, then run it
We test in the clients your team actually uses, because their support for protocol features differs. After launch we follow spec revisions and client releases and keep the server compatible.
Published prices, fixed before we start.
€1,000
delivered within a week
We read the system you already have and tell you what is actually wrong with it, what it would take to fix, and what it would cost.
€5,000 – €20,000
typical project
Fixed scope, fixed price, agreed before anyone writes code. Most of what we do sits in this band.
from €750
per month
We take the system over and keep it alive. This is the part most people discover they needed about six months after launch.
What moves the price for MCP Servers
- The number of write tools, since each one needs its own validation, scopes, confirmation path and tests.
- Whether sign-in can use your existing accounts or needs an authorisation server set up for the purpose.
- How clean the underlying system is, because an app with no API and no permissions model needs that work first.
- Whether the server runs locally for a few engineers or remotely for a whole team or your own customers.
What we work with
Questions we get asked.
Only what a tool returns in answer to a specific request, and only to the model behind the client the user is working in. The server decides what each tool can return, so fields that should never reach a model are removed before they leave your systems. Your data at rest stays where it is.
It can only call the tools we exposed, with arguments that pass validation, as a user who holds the required scope. It can still pick the wrong tool or misread a request, which is why irreversible actions stay out and costly writes wait for a person to confirm. Tool descriptions are guidance for the model; the checks on the server are the security boundary.
In principle, any client that implements the protocol. In practice MCP is still evolving, and clients differ in which features and transports they support and in how they handle sign-in. We test in the clients you name and build the core on the features they share.
Local servers run on a user's machine over stdio, take credentials from that machine and suit engineers working with their own access. Remote servers run over Streamable HTTP on your infrastructure, with OAuth sign-in, and suit teams and customers. Most business cases end up remote, hosted in your own cloud account.
The protocol, the clients and your own application all keep changing. On a Run retainer we follow spec revisions and client releases, review the audit log for misuse and failing calls, and add or retire tools without breaking existing users. The code is in your repository from the first commit, so your team can take it over at any point.
