Google Ads MCP Server

Create Call Asset

create_call_asset

Creates a call asset (clickable phone number for Google Ads) and returns its resource name so you can attach it to a campaign.

Instructions

Creates a call asset (clickable phone number shown with ads). Returns its resource name; attach it to a campaign with link_asset_to_campaign.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`customer_id`	Yes	The Google Ads account.
`country_code`	No	Two-letter country code of the number.	US
`phone_number`	Yes	The business phone number, e.g. "(480) 555-0100".
`validate_only`	No	If True, only validates the request.
`call_conversion_action_id`	No	Optional conversion action to count calls from this asset against (e.g. a "Calls from ads" action). If omitted, the account-level setting is used.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.2Oct 1, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Only destructiveHint=false is annotated, so the description carries most of the burden. It usefully discloses the return value (resource name) and the downstream workflow step, but says nothing about permissions, account-level scoping, or whether repeated calls duplicate assets — modest but real added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero padding, and the core definition plus the actionable next step are both front-loaded. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-resource creation tool with a rich schema, an output schema, and one annotation, the description covers purpose, returned handle, and the required follow-up call. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters including validate_only and call_conversion_action_id are already fully documented. The description adds no parameter-level syntax or format detail, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a call asset') and immediately clarifies what that resource is ('clickable phone number shown with ads'), so no sibling tool like create_ad_group or create_campaign could be confused with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the follow-up action and the sibling that performs it ('attach it to a campaign with link_asset_to_campaign'), giving a clear workflow context. It does not state when this tool would be inappropriate or what alternatives exist, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.