MCP is the wire format between an agent and your tools. That is the whole pitch. The Model Context Protocol is a standard way for an LLM to discover and call functions that live outside the model. Before MCP, every team hand-wrote glue between their agent and each API. Now there is one protocol, and the glue is reusable.
An MCP server is a process that exposes capabilities to an agent. It advertises three things: tools (functions the agent can call), resources (data the agent can read), and prompts (templated instructions). The agent connects, asks "what do you have," and gets a typed list back. Most of the value is in tools.
What a tool actually is
A tool is a name, a description, and a JSON Schema for its inputs. That is it. Here is the shape:
```json
{
"name": "get_invoice",
"description": "Fetch an invoice by ID. Call this when the user asks about a specific bill.",
"input_schema": {
"type": "object",
"properties": {
"invoice_id": { "type": "string" }
},
"required": ["invoice_id"]
}
}
```
The agent reads the description to decide when to call it. The schema constrains what it can pass. Write the description as a trigger condition, not a feature blurb. "Call this when the user asks about a bill" beats "Invoice retrieval utility." Vague descriptions are why agents call the wrong tool.
Transport: stdio or HTTP
There are two ways an agent talks to a server. Pick by where the server runs.
Stdio transport runs the server as a local subprocess. The agent spawns it, talks over stdin and stdout. Use this for local tools: filesystem access, a CLI you already have, anything on the same machine. No network, no auth, no ports.
HTTP transport runs the server as a remote endpoint over a URL. The agent connects across the network. Use this for shared services: a company database, a SaaS API, a tool many agents hit. This is where you add auth and rate limits. Most production deployments end up here.
The protocol is the same either way. Only the pipe changes.
When you do not need to build one
Most teams overbuild here. Before you write a server, check three things.
A server may already exist. GitHub, Linear, Asana, and most large SaaS tools ship hosted MCP servers. Point your agent at the URL, store the credential, done.
The capability may belong in the prompt. If the agent needs a fact, not an action, put it in context. A tool is for doing, not for knowing.
The task may be a one-off. If you call it once and never again, a plain script beats a server. Servers earn their keep through reuse.
When building one is worth it
Build a custom MCP server when all of these hold.
The capability is yours. You have an internal API, a proprietary database, or a workflow no vendor exposes. There is no off-the-shelf server, so you write one.
Multiple agents will use it. A server is reusable infrastructure. One server, many agents, one place to fix a bug. If exactly one agent calls it once, that math does not work.
You need a security boundary. A dedicated tool gives your code a typed, gateable hook. You can validate inputs, require confirmation for destructive actions, and log every call. A raw shell command gives you none of that. "Send a wire transfer" should be a tool you control, not a string the model assembles.
The action is hard to reverse. Anything that deletes data, sends a message, or moves money belongs behind a tool with an approval gate. The tool is where you put the guardrail.
What this looks like in practice
We build agents on this protocol. A support agent we built answers in 12 minutes, down from 4 hours, because it calls real tools against real systems instead of guessing from a knowledge base. The tools are scoped, logged, and reversible where they need to be. That is the work: not the model, the plumbing around it.
The failure mode we see most is a team wiring an agent to a bash tool and calling it done. Broad access, no audit trail, no way to gate the dangerous calls. It demos well and breaks in production. The fix is boring and correct: promote the risky actions to typed tools, leave the safe reads broad.
This is the Agents cluster of what we do, and it maps to our OpenClaw Installation, where we stand up an agent and the MCP servers it needs against your stack. Fixed price, you own the code, we exit. See pricing for where that starts.
If you have a workflow you think an agent should run and you are not sure whether it needs a custom server or an existing one, that is a good 30-minute conversation. Book a call and we will tell you straight.