The short comparison fits in one sentence: an API is used by someone writing code; an MCP (Model Context Protocol) is used by an AI assistant, and it usually wraps the API you already have. Everyone agrees that far. It gets interesting afterwards, when you stop reading about it and wire an assistant into a real tool with customer data inside. We just did that with our own ticketing system, and the hard calls weren't the ones in the comparison table: they were about permissions, identity, and what can walk out of the door with nobody watching.
The real difference: who's on the other side
An API and an MCP expose the same capabilities to different audiences, and that changes the design:
- An API assumes a program that already knows which endpoints exist
- An MCP describes its tools so the model can discover them on its own
- That makes each tool's name and description part of the logic, not documentation
- An MCP doesn't replace the API: it leans on it
💡 If you already have a well-built API, putting an MCP on top is days of work, not months. The API is the hard part, and you already have it.
Reading and writing are not the same permission
The decision that shaped our design the most. A tool that reads tickets and drafts a reply is harmless. One that sends emails a real customer:
- Read permission: list the inbox, open a thread, generate a draft
- Write permission: reply, change status, assign
- They are two separate permissions, granted separately
- With read-only, the assistant analyses and proposes but cannot send anything
💡 Start read-only. It's useful from day one and lets you watch how the assistant behaves before giving it the ability to talk to your customers.
An agent acts on someone's behalf
If the assistant writes in a ticket, that message carries a signature. Leaving it as an anonymous identifier breaks traceability exactly when you need it:
- Every agent credential is tied to the person who created it
- Whatever the assistant posts is attributed to that person
- It stays distinguishable as coming via the assistant, so it can be audited
- When someone asks "who answered this?", there is an answer
💡 One credential per person and per team, never a shared one. When you need to revoke, you'll want to revoke exactly one thing.
Permission is checked on use, not on creation
A permission that lives only inside a credential outlives its owner losing it. Checking at issue time isn't enough:
- The role is verified on every request, against the user system
- If that person loses access, the credential stops working instantly
- No waiting for expiry, no remembering to go and revoke it
- Same for a departure, a team change or a lost laptop
💡 Try removing your own permission and firing a request again. If it still works, the check is in the wrong place.
What must never go out on its own
An assistant can draft an excellent reply. That doesn't mean it should send it unread:
- The draft is generated and waits: it isn't sent
- Publishing requires declaring whether it's an internal note or a visible reply
- No default value: forcing the choice prevents the accident
- A person reviews before anything reaches a customer
💡 The field that decides whether the customer sees it should never have a default. That's the kind of oversight you only discover after it has happened.
What the assistant can do, not what it promises
Building this, we ended up removing a feature that sounded good: showing the list of external servers a process would talk to. It can't be sustained:
- A destination can be built at runtime, not written down in advance
- A harmless-looking tool can end up sending anywhere
- An incomplete list is worse than none: it creates false confidence
- Better to declare capabilities: "this can send data out", "this runs code"
💡 When a safety signal can't be guaranteed every time, removing it is more honest than showing it with a footnote.
Before wiring an assistant into your tool
Frequently asked questions
Does MCP replace APIs?
No. An MCP leans on the API you already have and presents it so a model can discover and use it. If your API is well built, the MCP is a layer on top; if it isn't, the MCP won't fix that.
When is an MCP worth building?
When you want an assistant to work on your tool conversationally, instead of coding each integration. If you just need two systems talking to each other and nobody will converse with them, a plain automation is simpler and more predictable.
Is it safe to give an AI access to customer data?
It depends on what it can do with that data, not on it being an AI. The same old questions: what permissions it has, on whose behalf it acts, who reviews what goes out, and how fast access can be cut. Answer those four and it's as safe as any integration.
Can the assistant reply to customers on its own?
Technically yes; we decided it shouldn't. The assistant drafts and proposes, a person reviews and sends. Draft quality isn't the issue: the issue is a mistake leaving the building unseen.
What happens when someone leaves the company?
Their credential stops working on the next request, because the permission is checked against the user system every time rather than stored inside the credential. Nobody has to remember to revoke anything.
The MCP-versus-API comparison resolves quickly: different layers for different audiences, with the API still the foundation. What reading doesn't resolve is everything else. Wiring an assistant into a tool that holds customer data is, above all, an exercise in permissions: what it can read, what it can write, on whose behalf, and what never goes out without a person looking at it. We built ours on our own support desk, and the calls that cost us the most didn't appear in any comparison table. If you're going to do it, start read-only: it's still useful from day one, and it saves you learning these things the hard way.