MCP
What is MCP, and when is it worth building a server?
Model Context Protocol in plain terms: what problem it solves, what it does not, and how to tell whether your team needs one.
6 min readByteWeave Studio
Before MCP, connecting an assistant to your systems meant writing the integration again for every assistant. Your ticketing system needed one adapter for one product, a different one for the next, and a third for the internal tool someone built. The work was not hard, it was just repeated, and it multiplied with every new client application.
Model Context Protocol is an open standard that collapses that. You describe your system once as an MCP server, and any client that speaks the protocol can use it.
What a server actually exposes
A server offers three kinds of thing. Tools are actions the model can invoke, each with a name, a description and a typed input schema — search tickets, create an order, run a query. Resources are data the client can read, addressed by URI, closer to files than to functions. Prompts are reusable templates a user can pick deliberately rather than the model choosing them.
Most servers are mainly tools. Resources matter when the client should be able to pull context without the model deciding to, and prompts matter when you want to ship a known-good workflow rather than hoping the model assembles one.
How it connects
Local servers run as a subprocess and talk over stdio, which is the simplest thing that works and needs no network or auth. This is how most developer tooling is deployed: the client launches your server, they exchange JSON-RPC over stdin and stdout, and everything stays on the machine.
Remote servers run over HTTP and are what you want when several people share one deployment, when it holds credentials that should not sit on laptops, or when it must reach systems inside your network. That path brings real authentication and the operational obligations of any other service.
When it is worth it
The case is strongest when more than one client will use the same capability, when the integration is genuinely reusable across tasks rather than serving a single feature, or when you want people to compose your system with others without you writing that combination.
It is weaker when you are building one product with one model call against one API. Wrapping that in a protocol adds a layer and buys nothing. The value of MCP is in the many-to-many case, and if you only have one client and one server you are paying the abstraction cost without collecting the benefit.
What it does not solve
MCP is a transport and a description format. It does not make a model good at using your tools. A server exposing forty vaguely named tools will produce worse results than five well described ones, because tool selection is a language problem and the descriptions are the prompt.
It also does not decide your security posture. A tool that can delete records will be called eventually, by a model that misread the situation. Scope credentials narrowly, separate read from write, and require confirmation for anything destructive. The protocol will faithfully carry whatever authority you hand it.
- MCP
- Model Context Protocol
- LLM
- Integrations
- Tooling
More reading
MCP
Building an MCP server for internal tools: what we got wrong first
Our first server mirrored our REST API and the model used it badly. Five changes that made the difference.
6 min read
Document AI
Why your invoice OCR works in testing and fails in production
The test folder is clean exports. The real intake is phone photographs. What changes between the two, and how to find out before a client does.
5 min read
LLM engineering
Why your RAG demo works and your RAG product doesn’t
A retrieval demo on twenty documents proves almost nothing about the same system on twenty thousand. The four things that break in between.
6 min read
Have a problem
worth solving?
Tell us what you're building. We'll help you figure out what's possible — and say so if we're not the right people for it.