Are MCP connectors safe? The four questions worth asking

Connecting an MCP server to your AI client 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.

For reference, ours exposes 36 tools, of which 6 write, and all six touch advertising campaigns and budgets. Every connector page lists the writing tools for that connector by name. If a vendor cannot tell you that number, they are 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 behaviour 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 single change can move a budget by at most ±50%, cannot exceed 10,000 in the account currency, cannot touch more than 5 campaigns, and a workspace gets at most 20 writes in a day. A call that would breach one is refused before anyone is asked about it. Those numbers are published with their reasons precisely so they can be held against us.

Worth saying plainly: this is not a differentiator. Other MCP servers in this category enforce something similar and market it in almost the same words. Treat it as the floor. What varies is whether the numbers are published at all, which is the part you can check.

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. Read access and write access should be separate authorisations rather than one connection with a flag, and a call that would change something should wait for a person. What that person approves matters too: it should be the exact payload that runs, not a general permission for the model to proceed. Otherwise you have approved an intention and received an action.

An approval should also expire. The numbers a proposal was based on go stale; ours lapse after 30 minutes rather than applying yesterday’s reasoning to today’s account.

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 your AI client. That client 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 your client 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?	Values in code, published, with reasons	“The model is instructed not to”
Who approves a change?	A person, approving the exact payload, with an expiry	“It is fully autonomous”
What does the client keep?	A pointer to the client’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.