Skip to main content
Glama

Ads.Report.Campaign

ads.report.campaign

Retrieve campaign performance metrics for a Google Ads customer ID over a selected date range, defaulting to the last 7 days, to analyze ad results.

Instructions

Campaign performance report.

Input Schema

NameRequiredDescriptionDefault
date_rangeNoLAST_7_DAYS
customer_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden and discloses essentially nothing: no indication of required auth/account access, no pagination or row-limit behavior for what is presumably a metrics pull, and no statement of granularity (campaign-level vs segment). The only mitigation is the presence of an output schema, which covers return shape but not operational behavior.

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

Conciseness2/5

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

A single four-word fragment is front-loaded but far too thin for a report tool with two undocumented parameters and a dozen sibling report variants; this is under-specification rather than conciseness.

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

Completeness2/5

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

Given no annotations, 0% schema coverage, and a crowded report-tool namespace, the description is not complete enough to call the tool correctly without opening the schema and guessing. The output schema excuses it from explaining return values, but that is the only box checked.

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

Parameters2/5

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

Schema description coverage is 0%, with two parameters (customer_id required, date_range defaulting to LAST_7_DAYS) documented nowhere. The description adds no meaning about the customer ID format (account vs. sub-account) or the date_range accepted values and default, which are exactly the details an agent needs when arguments are undocumented.

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

Purpose3/5

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

It names a resource (campaign performance) and implies a report, but it is closer to a restated title than a specific verb+scope. It does nothing to distinguish itself from the many sibling report tools such as ads.report.search_terms, ads.report.conversions, or sa360.report.campaign — the agent cannot tell which report to pick from the description alone.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no alternative named. The agent is left to infer that this returns campaign-level metrics rather than GAQL queries (ads.gaql.query) or PMax/asset-group breakdowns (ads.report.pmax_asset_groups).

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

Deploy Server

Other Tools