Most MCP servers read. A small number write, and an even smaller number cause consequences outside the repository: they send an SMS, create an invoice, or change a deal stage. Those servers are the ones worth slowing down for.
This page covers three we have reviewed — Stripe, Twilio, and HubSpot — and the access pattern we would use before giving an agent any of them.
The short answer
Give an agent read access first, observe what it actually queries, and only then consider writes — one capability at a time, with a test account. The pattern that fails is granting a broad token because the setup is easier, then discovering the blast radius during an incident rather than before one.
Stripe: payments are a query API until they are not
The Stripe MCP server exposes customers, invoices, subscriptions, and balance data. In practice, the useful questions are read-shaped: what plan is this customer on, when did the last payment fail, which invoices are open.
Read-only access is straightforward: a restricted key limited to the resources you need, on a test-mode account first. The failure mode is a key with write scope plus a model that interprets "fix the failed payment" as an instruction. If you need write access, do not grant it to the same key the agent uses for research.
Two habits make this safer:
- Use restricted keys with an allowlist of resources. Stripe's own key scoping is fine-grained enough to separate reading invoices from creating refunds.
- Start on test mode. The data looks real, the charges are not. An agent that behaves correctly in test mode is worth trusting with one endpoint in live mode, not all of them.
Twilio: messages have recipients
The Twilio MCP server covers messaging, phone numbers, and account resources — and it can generate new tools from an OpenAPI spec, which is a useful escape hatch but also a reminder that the tool surface is not fixed.
We would start with delivery logs and number lookups. Those answer the questions that come up during an incident: did the message arrive, which number sent it, what was the error code. Sending is a different category of action: a live message reaches a person, costs money, and cannot be recalled.
The dangerous pattern is an agent with a send capability and an ambiguous instruction loop. It retries a failed send, the recipient gets four messages, and the incident is now about the agent rather than the original problem. If you need automated sends, add an idempotency key and a rate limit at the application layer, not in the prompt.
HubSpot: records are people's work
The HubSpot server exposes contacts, companies, deals, and engagement history, with caching and vector search to stay inside rate limits. It is the least dangerous of the three in the abstract — a wrong CRM update is recoverable — and the most dangerous in practice, because CRM data is political.
Read access is genuinely useful: "who last talked to this account and when" is a question a sales team asks daily. Bulk writes are where it goes wrong. Per-record tool calls do not scale to a list of a thousand contacts, and an agent trying to process such a list will either take hours or partially fail.
Our rule: read-only for CRM, and if a write is needed, a human makes it. The agent can draft the update; it should not apply it.
The scope pattern that works
| Server | Start with | Avoid |
|---|---|---|
| Stripe | Restricted read key on test mode | Write scope on a research key |
| Twilio | Delivery logs and number lookups | Send capability without idempotency |
| HubSpot | Contact and deal reads | Bulk record updates |
The common thread is that each server has a read surface that solves most questions and a write surface that solves few. Most teams grant both because the integration is one token either way.
What to log before you forget
An agent touching money or messages needs an audit trail that does not depend on the model's own summary. Log the tool name, the arguments, the response status, and the timestamp — outside the agent.
This is not paranoia. When something goes wrong, the first question is always "what did it call", and the second is "with what parameters". A local log file answers both in seconds; a session transcript answers neither reliably.
Frequently asked questions
Can an agent be trusted with Stripe write access? For one narrow endpoint with a restricted key and a test-mode rehearsal first, possibly. As a general capability, no: the failure mode is a financial action that a human cannot undo.
What is the minimum useful Twilio setup? Read-only delivery logs and number lookups. That answers incident questions without giving the agent the ability to message anyone.
Why is HubSpot riskier than it looks? Because CRM records reflect human relationships. A wrong bulk update damages trust inside a company even when the technical recovery is easy.
Last checked: 9 November 2026.
Related: MCP servers worth installing, the MCP install checklist, and our editorial policy.