Are MCP connectors safe? The four questions worth asking

Connecting an MCP server to Claude or ChatGPT is a real grant of access to a real account. The question in the title deserves a better answer than “yes, we take security seriously”, so here is the version we would want if we were on the other side of it.

The short answer: the protocol is not the thing to evaluate. MCP is a way of describing tools to a model: it neither adds risk nor removes it. What you are evaluating is one specific server, and four questions separate the ones worth connecting from the ones that are not.

1. What can its tools actually do?

A connector can do exactly what its tools allow and nothing else. Not what the vendor intends, not what the prompt asks for: what the tool list permits. That makes the tool list the real permission model, and it is the first thing to ask for.

The useful form of the question is a count, not a description. How many tools are there, and how many of them write? A server with forty read tools and none that write cannot damage an account no matter how badly a model misbehaves. A server with four tools, two of which change budgets, is a different proposition even though it sounds smaller.

A count is the quick version of the question; the answer that actually helps is the list, and the better answer still is a count you decide. Ours works like this: every account starts read-only, and connecting asks whether the assistant may propose changes there. An account left read-only cannot be changed through us at all, and stays that way. Say yes and the assistant still only proposes: you see the exact change first, and it is applied only when you approve it. A vendor who cannot tell you this plainly, before you connect, is describing intentions.

2. Where do the limits live?

There is a meaningful difference between a limit in code and a limit in a prompt.

A prompt instruction (“do not raise a budget by more than half”) is a request. Models mostly honour requests, which is exactly what makes the failures hard to plan for: the behavior is right until the day it is not, and there is nothing between the decision and the account.

A limit in code is checked whatever the model decided. In our case a Slack channel the model names is checked against the channels your install can actually reach, so a message cannot be aimed at a room the app was never let into. An email to an address you did not save waits for a person whatever the model decided. And when a change waits for your approval, the text you approve is the byte string that goes out.

3. Who approves a change?

Reading is reversible. Pull the wrong date range and you re-ask; nothing in the world moved. Writing is not: a paused campaign or a shifted budget takes effect immediately, and undoing it does not give back the delivery you lost.

So the two deserve different treatment, and it is worth knowing where that difference can and cannot live. Not always in the grant: Google hands out read and write on a single Ads scope, with no read-only variant. Its own documentation puts it flatly, “the scope for the Google Ads API is https://www.googleapis.com/auth/adwords”, and Google’s scope directory glosses that one scope as “see, edit, create, and delete”. So a consent screen showing you scopes has not answered the question. Where it can live is the tool list, which says plainly which tools change something, and the step between a model deciding to call one and the account changing. That step should be a person, and what they approve should be the exact change that runs, not a general permission for the model to proceed. Otherwise you have approved an intention and received an action.

4. What happens after the tool returns?

This is the question most comparisons skip, and it is the one no MCP server can answer for you.

When a tool returns, the result goes to the assistant you asked in. That assistant is operated by someone else, under your agreement with them. Whether the data is retained, for how long, and whether it contributes to anything else is set by that agreement, not by the server that supplied it, and not by any promise on a page like this one.

We say this rather than leaving it out because the alternative is letting you assume a guarantee that does not exist. Our side of the line is specific: we read from your account when a tool is called, return the result, and keep no copy; we run no model, so there is nothing of ours to train on your data; and the privacy policy states that the assistant you use is not one of our sub-processors, because it is not.

The shape of a good answer

Four questions, and none of them is about how advanced anything is:

Question	A good answer looks like	A bad answer looks like
What can the tools do?	A count, split into read and write, with the writing tools named	“It has full access to your account”
Where are the limits?	In code, not in a prompt	“The model is instructed not to”
Who approves a change?	A person, approving the exact change	“It is fully autonomous”
What does the assistant keep?	A pointer to its operator’s own terms, stated plainly	Silence

Ask them of us, and ask them of whoever else you are considering. A vendor that answers all four with numbers is telling you something checkable; one that answers with adjectives is telling you something else.

If you want the concrete version: the connectors page lists every account we connect and which of them work today, and each connector page names the tools that can change anything.