Most explanations of the Model Context Protocol are written for the people building servers. This one is written for the person who has to decide whether connecting one to their business is a good idea.
What is an MCP server?
An MCP server is a service that publishes a defined list of actions an AI assistant is allowed to take against a system, plus the authentication that decides who is allowed to take them. The assistant connects, asks what tools exist, and calls the ones it needs to answer a question or carry out a task.
MCP stands for Model Context Protocol, an open standard introduced by Anthropic in late 2024 and since adopted by other AI products. The protocol itself is unglamorous plumbing. Its significance is what it removes: before MCP, every AI product needed a custom integration with every business system, which meant most integrations were never built.
Why the standard exists
Think about what it takes to let an AI assistant answer "how did last week's campaign perform?"
The data sits in an ad platform, an analytics property, and a payments processor. Each has its own API, its own authentication, its own way of describing a conversion. Wiring one assistant to all three is a project. Wiring a second assistant to the same three is the same project again.
MCP standardises the connection layer so that work is done once per system rather than once per system per assistant. A company exposes an MCP server; any compatible assistant can be authorised against it. That is the entire pitch, and it is enough to matter.
How it works, without the protocol detail
Three moving parts:
The client is the AI assistant. Claude and ChatGPT both act as MCP clients, as do several coding agents.
The server is the service holding the data or capability. It advertises tools: named operations with defined inputs, such as get_revenue_summary or create_draft.
The connection is an authenticated channel between them. For remote servers this is normally HTTPS, with OAuth handling sign-in so the server knows which user is calling and what that user is entitled to.
When you ask a connected assistant a question, it reads the tool list, decides which calls would answer it, makes them, and writes an answer from what comes back. The model never gets direct access to your database. It gets access to a menu somebody else wrote.
That last point is the one to hold onto. An MCP server is a permission surface. Its design decides what an AI can do with your business, and no amount of careful prompting expands or contracts that boundary.
What MCP is not
Clearing these up saves a lot of confusion:
- Not an AI agent. An MCP server has no model and makes no decisions. It publishes tools and enforces rules.
- Not a database. It usually sits in front of one, exposing selected operations rather than raw tables.
- Not RAG. Retrieval-augmented generation searches a document corpus for relevant passages. MCP calls typed operations against live systems. A server can offer retrieval as one of its tools, which is why the two get conflated.
- Not AI memory. Memory is what an assistant retains about past conversations. MCP is how it reaches things outside the conversation entirely.
- Not inherently safe or unsafe. The protocol carries no opinion. A read-only server and a server that can issue refunds both speak it.
What an MCP server can actually do to your business
This is the question that matters commercially, and the honest answer is: as much or as little as the server allows.
A useful way to think about it is to sort every tool a server exposes into four buckets:
| Bucket | What it does | Risk if misused |
|---|---|---|
| Read | Returns data | Disclosure, if the scope is too broad |
| Diagnostic | Reports status, freshness, configuration | Low |
| Propose | Writes a suggestion into a queue for a human | Low — nothing happens without a decision |
| Execute | Changes a live system or a durable setting | Real, and proportional to what it can reach |
A server that is 90% read and diagnostic behaves very differently from one that is 40% execute, even though both are "an MCP server". Before connecting anything to a business system, ask which shape you are looking at.
Five questions to ask before connecting an MCP server
Adapted from the way security teams evaluate any third-party integration, tightened for this specific case.
1. What proportion of the tools can change something? Ask for the breakdown. A server that cannot tell you is a server whose author has not thought about it.
2. Where does human approval sit? "The AI proposes and a person approves" is a meaningfully different architecture from "the AI acts and you review the log afterwards". Ask which one you are buying, and whether the approval step can be skipped.
3. How narrowly is access scoped, and can the assistant widen it? A token should resolve to one tenant, one workspace, one account. Ask what happens if a tool call requests a different one. The correct answer is that it is refused, not honoured.
4. How do I revoke it, and how fast does that take effect? Revocation should be a single action with immediate effect. Ask whether credentials also expire on their own, which limits the damage from a token you forgot about.
5. Where does the data come from, and how fresh is it? An assistant reading a stale cache while sounding confident is worse than one that admits it does not know. Ask whether responses carry a source and a timestamp.
If a vendor cannot answer all five in specifics, that is the finding.
A worked example: what one production server exposes
Abstractions are easy to agree with, so here is a real census. The Zylx Studio MCP server classifies every tool it advertises by what that tool does to the workspace, and enforces the classification — a write-class call made with a read-only credential is refused, and the refusal names the missing permission. As of 9 August 2026 its catalogue looked like this:
| Classification | Tools | Meaning |
|---|---|---|
| Read only | 671 | Returns data. Changes nothing. |
| Diagnostic | 37 | Read-only status, freshness, and catalogue surfaces. |
| Creates a pending change | 107 | Writes a proposal into an approval queue. Nothing happens to the live system yet. |
| Requires approval | 11 | Approves or rejects a queued item. Refused unless a human identity is attached. |
| Executes | 87 | Acts on a live system or durable setting. Requires an explicitly write-scoped credential. |
| Rollback | 10 | Reverses a previous change. Also write-scoped. |
Roughly three quarters of the surface cannot change anything. The next largest group does not act either; it writes proposals a person decides on. The tools that touch a live system are a minority and are gated twice, by scope and by approval.
Those proportions are the actual answer to "is this safe to connect", far more than any assurance in a pitch deck. Ask any vendor for the same table.
Where the real risk sits
Three failure modes are worth naming, because they are the ones that show up in practice.
Over-broad scope. The most common problem is not a malicious tool, it is a credential that reaches more than the job needs. Prefer the narrowest scope that still works, and widen it deliberately.
Prompt injection through returned content. If a tool returns text from an outside source — a support ticket, a review, a web page — that text can contain instructions aimed at the assistant. OpenAI has been direct about this risk for connectors that can write, and it is the strongest argument for keeping consequential actions behind human approval rather than trusting the model to be sceptical.
Confident staleness. A server that returns cached data without saying so produces answers that are wrong in a way nobody catches. Freshness metadata is not a nicety. It is what makes an answer checkable.
Does your business need MCP?
A short decision path:
- The data rarely changes and one person needs it. Upload the document. You do not need a server.
- The data changes and you keep re-explaining it. MCP starts paying for itself here, because the assistant queries at the moment of the question instead of relying on what you last pasted.
- More than one assistant, or more than one person, needs the same context. This is the strongest case. Build the context once and authorise each assistant against it.
- You want AI to do things, not only answer. MCP is the right shape, and the approval architecture becomes the thing you should evaluate hardest.
- You have no system worth connecting yet. Fix that first. MCP gives an assistant access to whatever exists; it does not create business context that was never captured.
How Zylx uses MCP
Zylx Studio builds a Business Brain: persistent, structured business context assembled from the systems a company already runs, including Shopify, Google Search Console, GA4, Google Ads, Stripe, and Klaviyo. That context is kept current on a schedule rather than uploaded by hand.
MCP is how assistants reach it. One server, one permission model, one approval queue. Claude connects as a custom connector using OAuth or a scoped token. ChatGPT connects as a custom connector using OAuth. Both see the same Brain and the same boundaries, and a proposal raised in one is decided in the same queue as one raised in the other.
The order matters more than the plumbing. MCP is the transport. The value is whether there is anything worth transporting — which is a question about the context layer, not the protocol.
Sources
- Model Context Protocol specification and documentation
- Anthropic: third-party connectors with remote MCP
- OpenAI: building MCP servers
- Zylx first-party: the live tool catalogue and scope enforcement of the Zylx Studio MCP server, verified 9 August 2026.