What is MCP? The marketer's guide to Model Context Protocol

MCP in plain terms

The Model Context Protocol is a standardized way for an AI client — Claude, ChatGPT, Cursor, Windsurf, Gemini CLI — to call external tools. An MCP server publishes a menu of named tools, each with a typed schema describing what inputs it accepts and what it returns.

SpendSignoff is an MCP server. When you connect an AI client to it, the client gains access to tools like list_campaigns, get_account_snapshot, and propose_change. The model does not get your API key or a raw connection to Google Ads. It gets those specific tools and nothing else the server has not explicitly offered.

Why the connection shape matters

The dangerous version of "AI connects to your ad account" is an unrestricted write connection. The model can read, edit, create, delete — whatever the underlying API permits. A bad inference costs money.

MCP does not automatically prevent this. It is a transport standard, not a safety standard. Safety comes from which tools the server publishes and what each tool actually does. An MCP server could publish a spend_budget tool. SpendSignoff's server does not.

The read, draft, approve split

This split means the worst outcome from a bad model inference is a draft you reject. Not a doubled daily budget you discover in the morning.

• {mcp.read} — the model can retrieve live campaign data: budgets, bids, pacing, ROAS, conversion counts. Read-only, no side effects.
• {mcp.draft} — the model can stage a proposed change as a before→after diff. The diff sits in the approval queue untouched.
• Approve — a human action only, completed in the SpendSignoff dashboard with a two-step confirm. This step lives server-side and is never delegated to the model.

What MCP looks like in practice

After OAuth setup (one-time, five minutes), you open your AI client and type: "check my Google Ads campaigns and tell me which ones are pacing over budget." The client calls get_account_snapshot, receives structured campaign data from the SpendSignoff server, and reasons over it to give you an answer grounded in current numbers.

You then say: "draft a 15% budget cut on the two that are over." The client calls propose_change twice. Two drafts appear in your SpendSignoff approval queue with before→after diffs. You review and approve. The cuts happen. Total time: under three minutes.

{
  "tool": "propose_change",
  "input": {
    "account_id": "123-456-7890",
    "entity_type": "campaign",
    "entity_id": "campaign_987",
    "field": "daily_budget_micros",
    "current_value": 10000000,
    "proposed_value": 8500000,
    "reason": "Pacing 18% over 30-day target; ROAS 1.2x below account average"
  }
}

MCP versus older integration patterns

Before MCP, connecting an AI model to an API meant custom tool definitions, one-off authentication flows, and no standard for how the model communicated with the server. Every vendor implemented it differently. MCP standardizes this so a server built to spec works with any MCP-compatible client.

For you, this means you install SpendSignoff once and it works with Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf, and any other client that speaks MCP. You do not need a separate connector for each.