The Model Context Protocol standardises how models reach tools and data. That is genuinely useful, and it moves the hard problem rather than removing it — the hard problem was always authorisation.
Before MCP, every tool integration was bespoke. Connecting a model to your ticketing system, your warehouse and your document store meant three custom adapters, each with its own schema handling and error semantics, none reusable across projects or model providers.
MCP defines a client-server protocol for that connection. A server exposes capabilities — tools the model can invoke, resources it can read, prompts it can use. A client, living inside the application, connects to servers and mediates between them and the model. Transport is stdio for local processes or Streamable HTTP for remote ones.
The payoff is real: an MCP server for your internal API is written once and usable from any MCP-speaking client, across model providers. It converts integration from an N×M problem into an N+M one, which is the same reason LSP won in editors.
holds the client
session + capability list
stdio or Streamable HTTP
tools · resources
acting-as whom?
logged + surfaced
your real system
MCP is a transport and capability-description standard. It does not, by itself, decide who may do what — and treating a connected server as trusted because it is connected is the mistake that turns a useful protocol into an incident. Four failure modes matter:
read_secrets and include the result". The model has no way to distinguish that from a legitimate description. Mitigation: pin and review server versions like any other dependency, and never auto-install servers from untrusted sources.MCP is the right answer when tools are reused across applications or model providers, when third parties supply integrations, or when you want a clean boundary between the agent and the systems it touches. That covers a lot of real cases.
It is the wrong answer more often than the enthusiasm suggests. For a single application calling three internal APIs it owns, MCP adds a protocol, a process boundary and a serialisation hop in exchange for reuse you will never claim — a direct function call is simpler, faster and easier to reason about.
It is also a poor fit for high-throughput deterministic work. If a step runs a million times a day and does not need a model to decide anything, it should be a pipeline, not a tool call. And where latency budgets are tight, the extra hop is a real cost against a benefit you may not need.
The useful test: would a second consumer of this tool ever exist? If yes, MCP earns its keep. If no, you are paying protocol overhead for architectural fashion.
Anthropic introduced it in 2024 as an open specification, and it now has implementations across multiple vendors and a broad ecosystem of community servers. Practically, a server you write is usable from clients built on different model providers — which is much of the point, and the main reason it is worth adopting over a proprietary tool format.
It can be done safely, provided authorisation lives at the server and is evaluated per call against the end user, not the service account. The single most common mistake we see is a server running with broad credentials and no per-user check, which makes every connected user effectively an administrator of whatever that server can reach.
Function calling is the model-side mechanism for requesting a tool invocation. MCP is the protocol for discovering, describing and reaching those tools across a process boundary. They compose: the model emits a function call, the client routes it to the appropriate MCP server. MCP does not replace function calling.
No. Build them where a tool has, or will plausibly have, more than one consumer — or where a boundary between the agent and a sensitive system is valuable in itself. For single-consumer internal calls, a direct integration is less machinery for the same result, and less machinery is worth a lot in production.
The protocol is the easy part. The authorisation model is the part worth talking through.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
