MCP Server Security: What We Exposed and What We Didn't

When we built Chartsy's MCP server, the interesting decisions were not about what to expose. They were about what to leave out.

Handing an AI assistant read access to a company's revenue data is a genuinely different risk profile from handing it a dashboard login. Conversations get shared, pasted, forwarded, and retained in places a dashboard session never goes. MCP server security is therefore less about authentication — that part is standard — and more about deciding, tool by tool, what should never travel in a chat transcript at all.

This is a write-up of the three constraints we imposed on ourselves, why each one costs something real, and what we would tell anyone else building or evaluating an analytics MCP server.

The threat model is not what people expect

The obvious worry is an attacker stealing a token. That is real, and the mitigation is ordinary: revocable credentials, scoped to one account, treated like passwords.

The less obvious worry — and the one that actually shaped the design — is accidental disclosure by an authorised user. A founder asks their assistant about churn, gets a helpful answer listing at-risk customers by name and email, and pastes the whole thing into a Slack channel that includes contractors. Nobody was attacked. Nothing was breached. Customer PII just left the building anyway.

In practice, the most effective control against that scenario is not a permission setting. It is not having the data in the response in the first place.

Constraint 1: read-only, with no exceptions

Every tool on our server is read-only. There is no tool that creates, edits, or deletes anything in Chartsy, and no tool that reaches back into Stripe or Paddle.

That last part matters more than it sounds. Chartsy holds read-only connections to your billing providers. It would have been technically straightforward to expose some of that reach over MCP. We did not, because it would mean the blast radius of a leaked MCP token was no longer "someone can read your metrics" but "someone has a foothold in your payments stack."

The cost: you cannot ask your assistant to update a goal or tag a customer. Those stay in the product. We think that is the right trade, and we would rather explain a missing feature than an incident.

Constraint 2: identifiers, never identities

Customers come back as payment-processor IDs. Names and emails are never sent over MCP. The website analytics tools return counts only, with no visitor emails.

This is the constraint people push back on most, and the pushback is fair: cus_QXm2... is not a satisfying answer to "who is about to churn?" You have to take that ID back into Chartsy to see who it is.

We kept it anyway, for three reasons:

It makes the accidental-disclosure scenario benign. A transcript full of processor IDs is not a customer list.
The extra step is small and rare. You look up an ID when you are about to act on it, which is much less often than you query.
It keeps the surface honest under GDPR. Nothing that counts as personal data flows into an AI client by default — the same principle behind Chartsy's GDPR mode.

The cost: a genuinely worse experience for one specific workflow — triaging at-risk accounts. We accepted it.

Constraint 3: calculated metrics, not raw records

The tools return MRR, churn rates, refund ratios, visit totals, concentration percentages. They do not return raw card data, individual invoices, or transaction records.

This one has a security benefit and a correctness benefit, and honestly the correctness benefit is the bigger of the two. A language model handed a list of charges and asked for MRR will produce a number. It will be wrong in ways that are hard to notice — discounts, prorations, annual plans amortised incorrectly, refunds ignored. (How MRR is actually calculated covers each trap.) Returning the calculation instead of the ingredients means the answer matches your dashboard by construction.

The design decision that came out of this

Once we committed to metric-level tools, a second problem appeared: assistants fragment. Ask a broad question and the client makes eleven separate calls, each with a slightly different window, and the numbers do not reconcile.

So we built a single business-snapshot tool — one call returning MRR, MRR by plan and country, churn and new subscribers per month, top customers, concentration, refunds, goals, at-risk customers, event usage, and site traffic, all over one shared time window of up to 36 months. It also returns derived flags: warnings about revenue concentration, churn spikes, and refund ratios, each with a code, a severity, and a message.

The lesson generalises: if your server has a common broad question, give it a single tool. Otherwise the assistant will invent an inconsistent answer out of many narrow ones.

What we would tell anyone evaluating an analytics MCP

A short due-diligence list, in rough order of importance:

Is every tool read-only? Ask for the full tool list, not a summary.
Does any response contain names, emails, or other personal data? If yes, under what circumstances?
Can the credential be revoked and regenerated without disconnecting other integrations?
Are the metric definitions published? If you cannot find out what "churn" means in that system, you cannot trust the number.
Does the server re-expose upstream access to connected systems like Stripe?
What does your own AI client do with the data — retention, model access, team visibility? This half is not the vendor's to answer.

Point six is the one teams skip. For the equivalent questions about billing connections, see is it safe to connect Stripe or Paddle to an analytics tool?. The vendor controls what leaves their servers. Everything after that is your client's policy, and it is worth reading before you connect anything.

Conclusion

MCP server security for analytics comes down to a simple principle: the response is the attack surface. Authentication is table stakes; the decisions that matter are about what you refuse to put in a payload that will end up in a chat transcript.

Read-only across every tool, processor IDs instead of names, calculated metrics instead of raw records — each of those cost us a feature someone has asked for. We would make the same three calls again.

If you are evaluating an analytics MCP for your own business, the tool list is the document to ask for.

Read the full Chartsy MCP tool list →

Frequently asked questions

Is it safe to connect an MCP server to my business data?

It depends on what the server returns. Look for read-only tools, no personal data in responses, revocable tokens, and no re-exposed access to upstream systems. Then check what your own AI client does with the data it receives.

Can an MCP server modify my Stripe or Paddle account?

It should not be able to. Chartsy's server has no write tools and no path back into connected billing providers. Verify this in any vendor's documentation, because a server that proxies upstream API access has a much larger blast radius.

What happens if my MCP token leaks?

With a read-only, ID-only server, someone could read your metrics — bad, but bounded. Regenerate the token immediately. This is why write access and personal data in responses matter so much: they turn a bounded leak into an unbounded one.

Why do some MCP servers hide customer names?

To make accidental disclosure harmless. Chat transcripts get pasted and forwarded far more casually than dashboard sessions. A response full of payment-processor IDs is not a customer list, so a leaked transcript is not a PII leak.

Does GDPR apply to data sent over MCP?

If personal data flows to a third party, yes. The simplest mitigation is to never send it — which is why Chartsy's MCP tools return processor IDs and counts rather than names and emails. Confirm your AI client's own handling separately.