MCP servers that give Claude real access,
and a real boundary.
Start a projectThe hard part is not the protocol. It is deciding what the model may do.
Every figure below links to the case study that states it.
Tools, not a chat box
A CRM assistant given twelve typed tools spanning pipeline queries, record lookup and comms — each one a named operation with a schema, not a prompt hoping for the best.
0 recordswritten by a modelThe model never writes
Every write in that system came from an authenticated session, never from model output. The agent proposes; a person confirms. That boundary is the whole design.
236 policiesrow-level security, 58 tablesIsolation in the database
Tenant separation enforced by row-level security across 58 tables rather than by asking the model to be careful. A tool that leaks is a tool that returns zero rows.
14 agentsone orchestration layerMany servers, one orchestrator
Fourteen agents coordinated by a central orchestrator across signup events, scoring, outreach and activation — the multi-server shape MCP is actually for.
since Feb 2026shipping weekly, unwatchedRuns unattended
Eight agents running a technical blog with nobody watching since February 2026 — including the one whose job is to refuse to publish work that is not good enough.
scored + explainedevery match justifiedExplainable, not opaque
An agent that turns a raw job feed into scored matches has to show why it scored them. Tool results carry their reasoning so a human can overrule it.
Five systems we are usually asked to expose — and what stays human in each.
Internal REST and GraphQL APIs
The services you already run, exposed as typed tools instead of pasted into a prompt. Usually the fastest server to build, because the contract exists.
Anything that mutates stateProduction databases
Scoped, read-only-by-default access with the tenant boundary enforced in the database. The model sees the rows its caller is allowed to see and no others.
Schema changes, deletes, bulk updatesCRM, billing and support tools
Salesforce, HubSpot, Stripe, Zendesk. Records read freely; anything that touches a customer or a charge is proposed and confirmed.
Sending, charging, refunding, closingDocuments and object storage
Retrieval over the files a team actually works from, with permissions inherited from the store rather than reimplemented in the agent.
Publishing, sharing, deletingLegacy and SOAP systems
The thirty-year-old system nobody wants to touch, wrapped once behind a modern contract so every future agent talks to it the same way.
Writes, until the wrapper has earned trustHow an MCP server actually gets built.
- 01Scope the surfaceWhich operations, and which stay human
Most of the value of an MCP build is decided here. A server with six well-chosen tools beats one with forty, because every extra tool is another thing the model can pick wrongly under pressure.
- 02Design the tool contractsNames, schemas, and what an error says
Tool descriptions are prompt surface: the model chooses from them. Vague names produce wrong calls. Errors get written for a reader who has to recover, not for a log file.
- 03Auth and scopingWho is asking, and what they may see
The caller's identity carries through to the query. On FlyCRM that meant row-level security doing the enforcing — 236 policies across 58 tables — rather than the agent being asked to behave.
- 04The write boundaryPropose, confirm, then commit
Reads can be direct. Writes are proposed by the model and committed by an authenticated session. This is what let that build finish with zero records written by a model.
- 05Transport and deploymentstdio, HTTP, or a remote server
Local stdio for a developer tool, a remote HTTP server with OAuth for anything a team shares. The choice changes the auth story completely, so it is made early rather than discovered.
- 06Tests and observabilityProof it still works next month
Tool-level tests, plus logging of every call and its result. An agent nobody can audit is an agent nobody will be allowed to keep.
Why We Build on MCP
Three reasons, each one a thing we would otherwise be rebuilding per product.
One integration, every client
12 tools, reusedA server built once is available to Claude Desktop, Claude Code, your own app and whatever ships next year. The alternative is rewriting the same integration per surface.
The boundary is enforceable
0 model writesMCP gives you a place to put the rule. Tools are named operations with schemas, so "the model may read this and propose that" becomes code rather than a paragraph of instructions.
It composes
14 agentsSeveral servers behind one orchestrator is the normal shape once a system does more than one job — and it stays legible, because each server owns its own systems.
Frequently Asked Questions.
What is an MCP server, in plain terms?
MCP — the Model Context Protocol — is an open standard Anthropic released in November 2024 for connecting AI models to real systems. An MCP server is a small service that exposes some of your data and operations as typed tools an AI client can call. Instead of pasting data into a prompt or writing a bespoke integration per product, you describe the operations once and any MCP-capable client can use them.
How is this different from just calling your API from an agent?
You can do that, and for one integration in one product it is often the right call. MCP earns its place when the same systems have to be reachable from several clients, when you want the tool contracts described in one place rather than scattered through prompts, or when you need a consistent boundary between what a model may read and what it may change. The protocol is the standardisation, not the capability.
Is it safe to give an AI model access to production systems?
Only if the enforcement lives outside the model. Our default is that reads can be direct and every write is proposed by the model and committed by an authenticated session, with tenant isolation enforced in the database rather than in prompt text. On the FlyCRM build that meant 236 row-level security policies across 58 tables, an agent with twelve typed tools, and zero records written by a model.
How long does an MCP server take to build?
A focused server over an existing, well-documented API is usually two to four weeks including auth, tests and deployment. Wrapping a legacy or undocumented system takes longer, and the extra time goes into understanding the system rather than writing protocol code. Multi-server builds with an orchestration layer are scoped as a project rather than a single server.
Do you build remote MCP servers with OAuth?
Yes. Local stdio servers are fine for a single developer's tooling, but anything a team shares needs to be a remote server with real authentication, per-user scoping and audit logging. We decide transport at the start of the build, because it changes the auth design rather than being a deployment detail.
What do you need from us to start?
The systems you want reachable, who should be allowed to reach them, and which operations must never happen without a human. That last one is the important answer — it defines the write boundary, and it is faster to agree before the build than to retrofit afterwards.
Idea in your head? Let’s
bring it to life.
Got a project? A wild idea? Or just want to say hey?
We're here for all of it — reach out anytime.