Model Context Protocol
Give an assistant real tools without giving it the keys
Our engineers built MCP commitment-tracking tools into Go4Gr8, a live leadership coaching platform. They decide what an assistant may touch before they wire anything up, and you interview them first.
What you are getting
4 things that decide this
- 01Senior engineers with MCP tools already running in production, not a weekend experiment with a protocol they read about.
- 02They scope permissions first. An assistant gets the narrowest tool that does the job, never a general key to your systems.
- 03You interview every engineer before they join, and they work in your repo and your standups rather than behind a ticket queue.
- 04You own the server, the tool definitions and the audit trail from the first commit. Interview anyone we put forward, and decline anyone.
What an MCP developer actually does here
The Model Context Protocol is an open standard for connecting AI applications to your systems. Its own documentation calls it a USB-C port for AI: one way to plug a model into data and tools, supported by Claude, ChatGPT, VS Code and Cursor.
Writing a server that lists a tool is a short afternoon. The engineering is in the boundary. On Go4Gr8 the assistant tracks the commitments a leader makes during coaching, through MCP tools, inside a multi-tenant platform where each user has their own agent. The tool can record a commitment for that user. It cannot read another organisation's coaching history, because the permission is decided in the server rather than requested in a prompt.
That is the difference worth paying for. A prompt is a suggestion. A permission is a rule.
What they decide before a single tool is written
Tools scoped to one job
A tool that books an appointment, not a tool that runs SQL. Narrow definitions are what stop a confused model doing damage.
Identity carried through
The assistant acts as a specific user, with their permissions. Without this, every request runs as an administrator by accident.
Actions that are safe to repeat
A retried tool call must not charge a card twice. Idempotency keys make a repeat safe instead of expensive.
An audit trail per call
What was called, by whom, with what arguments, and what came back. This is the first thing anyone asks for after an incident.
Evals on the tool layer
A scored set of cases checking the assistant picks the right tool. Model upgrades change behaviour, and this is how you find out first.
- AssistantAsks for a tool
- MCP serverYour code, your rules
- IdentityActing as which user
- PermissionAllowed, or refused here
- SystemThe call finally lands
Everything that matters happens in the middle three boxes. A server that only forwards the request has moved your security into a prompt.
Assistants given real tools
Go4Gr8
Custom AI sparring-partner platform for leadership coaching.
Read the case study →
ZhoopZhoop
AI receptionist and parts procurement for a multi-branch auto repair business.
Read the case study →
Little Tree Confections
n8n + AI meeting-to-action automation for an artisan bakery.
Read the case study →
“They have a problem-solving mindset, analytical skills, and deep technical knowledge.”
David Manley · CEO, Go Real Travel
How hiring works
- 01
Tell us what the assistant must reach
A free call about the systems it touches and the actions you would never want it taking. If a plain API is enough, we say so and you have lost nothing.
- 02
Meet the engineers
We shortlist people who have drawn a permission boundary before, and you interview them yourself. Turn any of them down without explaining why.
- 03
They embed
Your repo, your standups, your environments. One of our engineers owns the boundary design and answers for it by name.
- 04
They hand over
Tool definitions, the permission rules and the eval set, with someone on your team trained to extend them. Some clients keep us on the pager instead, under a service level we agree.
Stack
Protocol and models
Around it
Practices
Tell us what you will not let an assistant do
Bring the systems it needs to reach and the actions that scare you. The scoping call is free, and the boundary is the first thing we design.
01Is MCP stable enough to build on?
Stable enough that we run it in a client product, and it is an open standard supported by Claude, ChatGPT, VS Code and Cursor. It is also young, and the specification is still revised. We keep our tool definitions in one layer so a protocol change is a contained edit, not a rewrite.
02Do we need MCP, or will a plain API do?
A plain API is enough when one application calls one service in a fixed way. MCP earns its place when several assistants need the same tools, or when you want the option to change model vendor without rewriting every integration.
03What stops the assistant doing something expensive or destructive?
The server refuses it. Permissions are checked in your code before the call reaches the system, dangerous actions are not exposed as tools at all, and anything costly sits behind a human approval step. On Go4Gr8, commitment tracking runs inside a multi-tenant boundary for this reason.
04Can the assistant connect to our internal systems?
Yes, and that is usually the point. The server runs inside your network or your cloud account, so the model reaches your systems through tools you wrote rather than through direct database access.
05How do we know it still works after a model upgrade?
A scored eval set, run before the new model goes live. It checks the assistant still picks the right tool with the right arguments on cases you care about. The set lives in your repository, so it keeps working after we leave.
06What decides the cost of an MCP build?
Three things: how many tools you need, how many systems sit behind them, and how clearly your permission rules are already written down. A team that can say who may do what is cheaper to build for than one discovering it during the work. Scoping calls cost nothing. When the honest answer needs us inside your existing codebase, a paid two-week diagnostic replaces the guess with a fixed price.
