Tool Calling: How an LLM Actually Changes Your Bids

Tool calling is the mechanism by which a language model acts rather than merely answers. The model emits a structured request — a tool name plus arguments, conforming to a published schema — and separate software validates that request, executes it, and returns the result to the model as text. The model composes; the machinery performs.

Hold on to the negative space of that definition, because it carries the security model: the model never holds your credentials, never opens a connection to the Google Ads API, never touches the account. When an AI "changes your bids", what actually happened is that it asked — in a structured, loggable, gateable format — and something else did the changing.

How tool calling works

The loop has three beats. Request: the model decides a tool is needed and emits the call — update_campaign_budget with a campaign ID and a new amount. Execute: the client and server validate the call against the tool's schema and their own rules, then perform it against the real API. Return: the result comes back as text in the conversation, and the model continues with real data in context.

The schema is the underrated document in that loop. Every tool publishes its name, its purpose and its typed inputs — which means the tool list of any connector is a complete, readable statement of what an AI can ever do through it. Not marketing claims: the actual capability surface. AdCopilot's underlying server defines 36 tools; hosted connectors expose 32, and the four remove_* tools are never among them — so through that connector, a deletion is not a forbidden request, it is an inexpressible one. Capability absence beats capability rules, because there is nothing to jailbreak.

In MCP specifically, this pattern is standardised: an MCP server publishes the tools, any compatible client discovers them, and the same request-execute-return contract holds across Claude, ChatGPT, Copilot and the rest. One protocol, one auditable shape for every action.

Why the separation makes AI supervisable

The separation is what makes AI account access supervisable in practice. Because every action is a discrete call, three controls attach naturally: approval — clients surface write calls before execution, showing the exact tool and arguments, so spend-affecting changes wait for your click; validation — the server enforces its own policy regardless of what the model asks, refusing calls that break the rules in any phrasing; and logging — each call lands in an audit trail with tool, account, outcome and timestamp, so the AI's work history is a record rather than a recollection.

Which yields the practical habit: read what your client shows you. When a call is proposed, the display names the tool, the account and the arguments — that is the entire change, stated precisely, before it happens. Approving a tool call you have read is a different act from trusting an AI you cannot see into; the whole enforcement stack behind that difference is documented on the security page.

The model proposes. The machinery disposes. Everything trustworthy about AI in ad accounts is built in the gap between those two verbs.