Google Ads by Get MCP Ads

Overview Schema Source Related Servers Discussions Admin

google ads get pmax assets

google_ads_get_pmax_assets

Read-onlyIdempotent

List Performance Max asset group assets with campaign and asset-group context, including optional date-range performance metrics for auditing and optimization.

Instructions

List Performance Max asset group assets from asset_group_asset with asset group/campaign context and optional date-range performance metrics.

Input Schema

Name	Required	Description
`daily`	No	Segment dated performance by segments.date.
`limit`	No	Maximum number of returned items or rows. The declared bounds and default apply; use pagination for additional results.
`assetId`	No	Restrict reporting to one asset.
`endDate`	No	Optional end date YYYY-MM-DD for performance metrics
`metrics`	No	Additional asset-compatible GAQL metric fields. Used with a date range; delivery metrics are always included. Omit for the default delivery/conversion fields.
`fieldType`	No	Optional AssetFieldType enum filter, e.g. HEADLINE, LONG_HEADLINE, MARKETING_IMAGE
`startDate`	No	Optional start date YYYY-MM-DD for performance metrics
`campaignId`	No	Optional Performance Max campaign ID filter
`customerId`	Yes	Google Ads customer ID (without dashes, e.g., 1234567890)
`assetGroupId`	No	Optional asset group ID filter
`statusFilter`	No	Native status values used to filter the returned entities.
`assetGroupIds`	No	Restrict reporting to these asset groups.

Output Schema

Name	Required	Description	Default
`result`	Yes	Original tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv2.1.1Oct 30, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / assetGroupId / $ref
```
Removed value: -"#/properties/campaignId"
```
addedInput schema / properties / assetGroupId / pattern
```
Added value: +"^\\d+$"
```
addedInput schema / properties / assetGroupId / type
```
Added value: +"string"
```
removedInput schema / properties / assetGroupIds / items / $ref
```
Removed value: -"#/properties/campaignId"
```
addedInput schema / properties / assetGroupIds / items / pattern
```
Added value: +"^\\d+$"
```
addedInput schema / properties / assetGroupIds / items / type
```
Added value: +"string"
```
removedInput schema / properties / assetId / $ref
```
Removed value: -"#/properties/campaignId"
```
addedInput schema / properties / assetId / pattern
```
Added value: +"^\\d+$"
```
addedInput schema / properties / assetId / type
```
Added value: +"string"
```
removedInput schema / properties / endDate / $ref
```
Removed value: -"#/properties/startDate"
```
addedInput schema / properties / endDate / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
addedInput schema / properties / endDate / type
```
Added value: +"string"
```

changedOutput schema / properties / result / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv2.0.1Sep 23, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the source entity (asset_group_asset) and notes that performance metrics are optional and date-range driven, but it doesn't mention that delivery metrics are always included, that defaults apply, or anything about pagination behavior — those details live only in the schema.

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?

A single front-loaded sentence with no filler; the verb and resource come first and the qualifiers follow. It is slightly dense with parenthetical-style qualifiers but nothing is wasted.

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

Completeness3/5

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

The tool has 12 parameters, an output schema and full annotation coverage, so much of the burden is already carried elsewhere. Still, the description does not hint at the available filtering dimensions (status, asset field type, specific asset or asset-group IDs, daily segmentation, limits), which an agent would want signposted when choosing among the PMax-related siblings.

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 coverage is 100%, so all 12 parameters, including their enums, patterns and defaults, are already documented in the schema. The description only echoes the date-range/metrics and asset-group/campaign concepts without adding syntax or constraints, so the baseline of 3 is appropriate.

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

Purpose4/5

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

States a specific verb and resource: it lists Performance Max asset group assets from the asset_group_asset entity, and mentions the accompanying asset group/campaign context and optional date-range metrics. This is clear enough to separate it from siblings like get_pmax_placements or get_pmax_asset_diagnostics, though it never names those alternatives to sharpen the distinction.

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?

The description explains what the tool returns but never says when to use it versus the many nearby siblings (get_pmax_asset_diagnostics, get_pmax_placements, get_demand_gen_assets, list_image_assets, run_gaql). There are no exclusions or decision rules, only an implied 'use this to list PMax assets'.

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

Deploy Server