My HubSpot agent asked for approval on everything. That was the problem. Here's the fix, and the hole I found.

The problem I left open

A gate on every write is safe on day one. By day thirty, it’s noise. When the agent asks me to approve changing one contact’s job title, then another, then another, I stop reading. I click. At that point the gate still exists, but the review doesn’t, and a click-through gate is worse than no gate because it looks like oversight.

The fix isn’t fewer gates. It’s gates that scale with risk, so the prompts I do see are the ones worth reading.

Three tiers, decided before anything runs

Every write is now classified before it touches HubSpot. The server checks, in order, and the first match wins.

• Full gate. Deletes and merges, and any write whose original values couldn’t be captured for undo. You type the exact record count, and a wrong count is refused.
• Confirm. Tools with side effects that deleting can’t reverse: workflow changes, refunds, forms, reports and dashboards. A refund moves money that deleting the refund record won’t return. Also any write that touches a sensitive field (deal amount, deal stage, owner, lifecycle stage) and any batch over 100 records. One approval, no count.
• Auto. Everything else: small, reversible, non-sensitive changes. They apply immediately and hand back a one-line undo command.

That last tier changes my July claim, and I want to be precise about it: small reversible edits now apply without a prompt. What they can’t do is escape undo or the audit log. Every auto-applied change records the original values first. If a write only captured some of them, it drops out of auto and waits for a person.

The limits live in a settings file per portal, and the lists that protect you only grow. A portal can add sensitive fields and add tools that always need a human. It can’t remove the ones the server ships with. The numeric settings, like the 100-record ceiling, can be tuned per portal, so tighten them if your data warrants it.

Approval inside the conversation

The old flow took two steps: the agent proposes a change, then a separate approve call executes it. In clients that support it, approval is now one step. The request pauses and Claude shows a form: which tool, how many records, which tier, and whether the change can be undone (“Captured 12 records for undo,” or “No values captured, this write will not be undoable”). Tick approve, type the count if the tier needs it, done.

Clients that can’t show the form still get the classic preview and approve flow, which is also what makes approvals work across sessions. How the form looks depends on the client; the server only describes what to ask.

One smaller change serves the same goal. The server now checks what your HubSpot plan includes and hides the tools you can’t use, like workflows on a portal without them. Fewer tools on the list means fewer wrong ones for the agent to reach for. If the check is inconclusive, the tools stay listed and explain the problem when called, rather than vanishing after one network hiccup.

The hole in my own gate

While building the tiers, I audited every tool that can write to HubSpot. Thirteen of them weren’t going through the gate at all.

They included the raw API tool when used to write, all five workflow tools, refunds, imports, exports, forms, reports, dashboards and scheduled emails. Calls to them went straight to HubSpot: no preview, no approval, no undo snapshot, no audit entry. My July post said the only way to change the CRM was to approve the exact change first. For those thirteen tools, that wasn’t true when I wrote it.

It’s fixed. Every one of them now goes through classification like everything else, and most land in confirm or full gate. The same audit turned up two smaller honesty problems. An update that captured no original values was still labelled undoable; it now fails closed and warns at approval time. And the duplicate finder only looked at the first 100 records; it now reads them all.

The test suite went from 11 tests to 628, and every change to the repository now has to pass it. The gap existed because nothing checked that every writing tool was actually gated. Now something does.

What I’d tell anyone building a gate

• Match ceremony to risk. A gate that asks about everything trains people to approve everything.
• Undo is the price of speed. Nothing auto-applies unless its original values are captured first.
• Settings should only add protection. The protective lists should never shrink through configuration.
• Audit your own claims. “Every write is gated” is a sentence, not a test. Write the test.

The server is open source under MIT at github.com/promptmetrics/hubspot-mcp. Try it against a developer test portal, never your live one, and if you find another hole, tell me. Clearly I need the help.