Written for technical decision makers evaluating whether MCP belongs in their architecture. It covers what these servers do, what they cost, and — importantly — when a direct integration is the better answer.
The problem MCP solves
AI assistants become genuinely useful the moment they can see real data. Every organisation reaches that realisation and immediately hits the security question, correctly.
| Naive approach | What goes wrong |
|---|---|
| Give the AI database credentials | It can read and modify everything; no audit trail |
| Give it a broad API key | Far more permission than any assistant should hold |
| Copy data into the AI | Immediately stale; data leaves your control |
| Build a bespoke integration per tool | Repeated work; inconsistent security posture |
An MCP server is the alternative: a controlled doorway exposing specific, validated operations, with permission mapping and logging built in.
What a server actually contains
- Tools — individual operations the AI may invoke. "Get order status by order number." Each with a schema defining valid inputs.
- Input validation — an order number must look like one. The AI cannot pass arbitrary queries through.
- Permission mapping — the server checks who is asking and constrains results to what that person could see directly.
- Backend adapters — the code talking to your database, CRM or API.
- Audit logging — who requested what, what was returned, when.
- Transport — local for desktop use, or authenticated HTTP for team-wide deployment.
The single most important design rule: never expose a general-purpose tool. A "run this query" tool defeats the entire purpose — you have rebuilt the broad-credentials problem with extra steps. Each tool should do one narrow thing with validated inputs, which is what makes the security model defensible.
Where it delivers value
| Use case | Who benefits | Typical tools exposed |
|---|---|---|
| Order and shipment lookup | Support teams | Status by order, tracking by shipment |
| Inventory queries | Sales teams | Stock by SKU and location |
| Customer history | Account managers | Recent orders, open tickets |
| Internal documentation | All staff | Policy and process search |
| Ticket creation | Support teams | Create ticket with structured fields |
| Reporting | Management | Named, pre-defined reports |
The pattern is always the same: work someone currently does by opening a system, finding a record, and reading it out. That is the work an MCP tool removes.
When you do not need one
Honest guidance: if one AI client needs one integration and governance is not a concern, a direct API integration is simpler and sufficient. MCP earns its place when you have multiple assistants, multiple systems, per-user permissions, or an audit requirement — that is, when the governance layer is the point.
- A single tool, a single system, no permission complexity — direct integration.
- Your data lives in unstructured spreadsheets — fix the data first.
- Questions are genuinely varied rather than repetitive — the payback is not there.
- No one has actually asked for AI access to these systems yet.
Cost and effort
| Scope | Typical effort | Main driver |
|---|---|---|
| Read-only, one documented API | 2–3 weeks | Tool design and validation |
| Read plus write, with approvals | 4–6 weeks | Confirmation flows, audit |
| Multiple systems, per-user auth | 6–12 weeks | Permission mapping across systems |
| Legacy system with no clean API | Considerably more | Building the adapter layer first |
The variable that dominates is not MCP itself — it is what sits behind it. A modern documented API is straightforward; a legacy platform needs an integration layer built before MCP has anything to expose.
Security considerations that matter
- Least privilege per tool — narrow operations, validated inputs, no general query capability.
- Permission mapping to the real user — the assistant should see exactly what that person could, never more.
- Treat retrieved content as untrusted — text from documents or tickets may contain instructions attempting to manipulate the assistant. This is a genuine attack class.
- Confirmation on consequential actions — reading can be automatic; anything that sends, deletes, refunds or spends should pause for approval.
- Rate limiting — an agent in a loop can generate enormous request volume.
- Reviewable logs — an audit trail nobody reads is decoration.
A sensible first project
- Pick one repeated lookup your team performs manually many times a day.
- Expose it read-only with a single validated tool.
- Deploy to a small internal group and watch the logs.
- Measure time saved and read what people actually asked — it usually differs from what you expected.
- Expand on evidence, adding tools the usage data justifies.
Considering MCP for your systems? Tell us what your team looks up repeatedly — we will say plainly if a direct integration would serve you better. See our MCP server service, MCP vs direct API, and MCP security practices.