Connector count is the wrong headline

Most ad MCP servers compete on breadth — how many platforms and clients they list. Breadth is easy to claim and easy to copy. The harder question, and the one that decides whether you can trust the thing with a live ad account, is: when the AI proposes a change, what stands between that proposal and your money?

The five questions to ask any ad MCP server

Run these against SpendSignoff and against anything you are comparing it to.

• What OAuth scopes does the AI client actually get? SpendSignoff grants mcp.read and mcp.draft only — there is no mcp.approve scope, so the AI structurally cannot push spend.
• Where does the spend decision live? In SpendSignoff it lives in the app behind a two-step Approve & push live → Confirm control, never inside the AI conversation.
• Is there a per-account spend cap? SpendSignoff enforces a rolling 24h spend envelope server-side, independent of what any client requests.
• Is there a tamper-evident record? SpendSignoff writes a KMS-signed, append-only audit log with one-click rollback for every approved change.
• What happens when a platform misbehaves? SpendSignoff has a circuit breaker that pauses drafting on anomalous responses or pacing.

Where SpendSignoff sits

SpendSignoff is propose-only in V1. Google Ads and Meta are live today; LinkedIn and TikTok are coming. It does not win on the longest connector list — it wins on the fact that the write path is gated by a human and recorded in a signed log, and that the AI cannot bypass either.