Skip to main content
Glama

Per-ad performance

get_ad_performance
Read-only

Performance broken down by individual ad, not just by campaign - which specific responsive search ad (and its headlines/descriptions) is actually winning. get_campaign_performance only reports at the campaign level. Defaults to the last 30 days; filter to one campaign or ad group with the optional ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
endDateNo
adGroupIdNoRestrict to one ad group.
startDateNo
campaignIdNoRestrict to one campaign.
customerIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the default 30-day date window and the fact that results can be scoped by campaign or ad group id, neither of which the schema states for startDate/endDate defaults.

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

Conciseness4/5

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

Three front-loaded sentences with no filler; the ad-vs-campaign distinction leads and the default window trails. The parenthetical about headlines/descriptions earns its place by clarifying what the breakdown exposes, though the em-dash clause makes the opener slightly heavy.

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

Completeness4/5

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

With six optional parameters, no required params, no output schema, and low schema coverage, the description supplies the key operating context (granularity, default window, scoping filters). Remaining gaps are limit default and customerId semantics, which are minor for a read-only report tool.

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 only 33% (only campaignId and adGroupId are annotated). The description partially compensates by explaining the campaign/ad-group filter intent and implying the default date range, but leaves limit, customerId, and the date format for startDate/endDate undocumented in both places.

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 ('performance broken down by individual ad'), and sharply distinguishes itself from the sibling get_campaign_performance, which it names explicitly as campaign-level only. An agent can pick between the two without opening either schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use this for per-ad (responsive search ad) granularity, use get_campaign_performance for campaign-level roll-ups. It also states the default window (last 30 days) and the optional narrowing via campaign/ad group ids, so invocation conditions are covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources