An MCP server is a small service that exposes selected parts of your business systems to AI agents through the Model Context Protocol, an open standard for connecting AI applications to tools and data. A business needs one when agents should act inside its systems, such as looking up an order or drafting a support reply, not just read its public website.
Before MCP, every AI tool that wanted to talk to your systems needed its own custom integration. MCP gives them one shared contract. You build the server once, and any MCP-capable client, from a desktop assistant to your own agent, can discover and use what it offers.
What the Model Context Protocol is
The protocol, documented at modelcontextprotocol.io, defines how an AI application (the client) talks to a server that provides capabilities. A server can offer three kinds of thing:
- Tools: actions the model can call, such as "look up order", "create draft reply" or "check stock". Each has a name, a description and a typed input schema.
- Resources: data the client can read, such as a product catalog, a policy document or a customer record.
- Prompts: reusable templates a user can pick, such as "summarize this ticket".
The model reads the tool descriptions and decides which to call. That is why the descriptions matter as much as the code: a vague description leads to the wrong tool being picked.
When you need an MCP server, and when an API is enough
An MCP server does not replace your API. It usually sits in front of it, choosing which operations to expose to agents and describing them in a way a model can use.
| Plain API | MCP server | |
|---|---|---|
| Built for | Developers writing code | Agents choosing tools |
| Discovery | Docs and OpenAPI | Listed by the protocol |
| Best when | Integrations are known in advance | Many agents or clients need the same actions |
| You still need | Auth, limits, logging | The same, plus approval for writes |
You probably want one when:
- several agents or AI clients need the same actions on your systems;
- you want your staff to use those actions from the assistant they already work in;
- you are building your own agents and want their tools defined once, testably, instead of inside each agent.
You probably do not, yet, when your goal is only to be read and quoted by AI assistants. For that, the reading layer does the work: llms.txt, Markdown on request and structured data. And if you only need one fixed integration between two systems, a scripted workflow is often simpler and cheaper to run than an agent.
Design the tools like a product
- One operation per tool, against one system. "update_order_address" is safer and clearer than a generic "run_query".
- Typed inputs with limits, so the server can reject bad calls before they touch anything.
- Descriptions that say when to use the tool and when not to.
- Errors an agent can act on, such as "order not found", rather than a stack trace.
We write eval cases for each tool from real examples before building it. They show whether a model picks the right tool with the right inputs, and they catch regressions when descriptions change. Our agent engineering work is built around that.
Keeping it safe
An MCP server is a door into your systems. Treat it like one.
- Least privilege. Expose only the tools the task needs, and give each connection credentials scoped to exactly that. A support agent does not need refund rights on every order.
- Authentication. The protocol's specification describes an authorization approach based on OAuth for servers reached over HTTP. Use it, or an equivalent, for anything beyond a local, single-user setup.
- Validate on the server. Never trust that the model sent sensible input. Check every value, every time.
- Human approval for writes. Reads can be broad; anything that changes a record, sends a message or moves money should wait for a person until you have evidence it is safe to automate.
- Log every call, with inputs, outputs and who approved it, so you can answer "why did it do that?"
- Watch for injected instructions. Content an agent reads, like an email or a web page, can contain text aimed at the model. Tool permissions, not the model's judgment, should be what stops harm.
Making your server discoverable
A proposal in the MCP project describes a server card: a small JSON document at /.well-known/mcp/server-card.json that tells clients a server exists, how to connect to it and what it offers. It is still a proposal, so the exact fields may change. If you run a public MCP server, publish a card and list it in your ai-catalog. If you do not run one, do not publish a card just to pass a checker; an agent that follows it to nothing is worse off than one that never found it.
Where to start
A first MCP server should be small. Pick one workflow, expose two or three read tools and at most one write tool, and put the write behind approval. Run it with a handful of staff for a few weeks, read the call logs, and extend it only where the logs show real use. Starting narrow keeps the security review manageable and gives you evidence before you widen what agents can touch.
Next step
Write down the three actions you would most want an agent to take on your systems, and what a person should approve for each. That list is the start of a tool design. The free agent-readiness scan shows where your public site stands today, and if you want the server built with evals and approval gates from the first version, tell us the task.