Model Context Protocol
MCP: solid as a wire format, unfinished as a production standard
We run an MCP server for commitment tracking inside Go4Gr8, a multi-tenant AI coaching platform. This is what running it in front of real users taught us.
The short answer
MCP is ready to ship for tool definition and transport, the two things the spec actually finishes. Treat auth, versioning and server sprawl as your team's problem, because the protocol leaves all three open.
Choose it when more than one AI client needs the same tool and you want to write that tool once. Skip it for a single product with one model behind it. Plain tool calling does the same job there with one less moving part to operate.
What decides this
4 things that decide this
- 01Tool definitions and the JSON-RPC transport are the finished part of the spec. We have not hit a bug in either.
- 02The protocol names no standard way to scope a tool call to one tenant. We wrote that layer ourselves for Go4Gr8.
- 03There is no built-in server versioning. A tool's schema can change under a client with no signal that it did.
- 04One server per job keeps the blast radius small. A server wired to five systems is five systems one bad call can reach.
A standard way for a model to discover and call your tools
MCP is an open standard for connecting an AI application to outside systems. You write one server that exposes tools, data or prompt templates. Any MCP client can then call it, with no bespoke integration written for that client.
Messages travel as JSON-RPC 2.0, over stdio for a local process or streamable HTTP for a remote one. A client lists what a server offers, then calls a tool by name with arguments matching its schema. That handshake is the strong part of the spec. It does not decide who is allowed to make the call, and a production server earns its keep on exactly that gap.
What holds up, and what does not
Solid
- Tool schemas are discoverable at runtime, so adding a capability does not need a client release.
- JSON-RPC over stdio or streamable HTTP is a small, well-understood surface. We have not had a transport bug.
- A server you write once is usable by every MCP host: Claude, an IDE, another team's agent.
- Because the format is boring and typed, generating a client-side schema from it is mechanical.
Still hurts in production
- The spec carries no opinion about who may call a tool. Every server starts as a public endpoint until you scope it.
- There is no standard tenant model. Go4Gr8 is multi-organization, so we had to build tenant scoping into the server ourselves rather than get it from the protocol.
- Schema versioning is not addressed. A tool's arguments can change and a client keeps calling the old shape with no warning.
- A server tends to grow past its first job. One that starts scoped to commitment tracking accumulates unrelated tools unless someone actively resists it.
- Server shipsScoped to one job, no auth check yet
- Second tool addedConvenient, unrelated to the first
- No tenant checkServer cannot tell which org is calling
- Schema driftsArgument shape changes, client unaware
- Wrong data returnedNo error, just the wrong tenant's rows
Every failure here is a gap the spec leaves open, not a bug in it. Scoping, versioning and auth are application code you have to write, not a setting you turn on.
Commitment tracking inside Go4Gr8
Go4Gr8 gives executives AI sparring partners across three agent types: Compass, Strategic and Influence. Each one tracks the commitments a leader makes during a session. Follow-up runs through MCP tools rather than a hardcoded function call.
The platform is multi-tenant. Each organization manages its own users, so the tenant boundary had to sit inside the server. It gets checked on every call, not assumed from the session that opened it. We scope by organization in the server itself and log every call. Destructive tools stayed out of the first version until the pattern had run in front of real pilot users.
- 01Scope every tool to one tenant, checked server-side on the call, not trusted from the client.
- 02Log every call before you need the log, not after the first incident.
- 03Keep a server to one job. Commitment tracking stayed commitment tracking.
Where we run this
What teams ask before committing
01Is MCP production ready?
For tool definition and transport, yes. We have run a commitment-tracking server on it inside Go4Gr8 with no transport bugs. The spec gives you nothing for auth, tenant scoping or versioning. Those pieces are your team's job to build and test before real users reach the server.
02MCP or plain function calling?
Build an MCP server when more than one AI client needs the same tool, or you expect that to happen soon. For one product behind one model, plain tool calling is less machinery for the same result, with no server to operate or version.
03How many MCP servers should one product run?
As few as the job allows, each scoped to one system. A server that starts narrow tends to accumulate unrelated tools over time, and every tool added widens what a single compromised call can reach.
04Who is responsible for auth on an MCP server?
You are. The protocol specifies no standard for who may call a tool. Remote servers can use bearer tokens, API keys or OAuth. Choosing and enforcing one is application work, not something the spec does for you.
