Skip to main content
Glama
Sign In
get-mcp-ads

Google Ads by Get MCP Ads

by get-mcp-ads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

google ads get pmax asset diagnostics

google_ads_get_pmax_asset_diagnostics
Read-onlyIdempotent

Diagnose Performance Max asset groups by retrieving ad strength, asset coverage action items, primary status reasons, and optional performance metrics or top asset combinations.

Instructions

Read-only Performance Max asset group diagnostics. Returns ad strength, asset coverage action items, primary status reasons, optional performance metrics, and optional top asset combinations.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of returned items or rows. The declared bounds and default apply; use pagination for additional results.
endDateNoOptional end date YYYY-MM-DD for asset group metrics/top combinations
startDateNoOptional start date YYYY-MM-DD for asset group metrics/top combinations
campaignIdNoOptional Performance Max campaign ID filter
customerIdYesGoogle Ads customer ID (without dashes, e.g., 1234567890)
assetGroupIdNoOptional asset group ID filter
statusFilterNoNative status values used to filter the returned entities.
includeTopCombinationsNoAlso query asset_group_top_combination_view when available

Output Schema

NameRequiredDescriptionDefault
resultYesOriginal 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.

  1. Changed8 schema fields changedv2.1.1
    • 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 / 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"
+  }
+]
  2. First observedv2.0.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and the description's 'Read-only' merely restates that. The useful addition is the enumerated result content, but since an output schema exists this is largely duplicative, and behavior such as pagination, cost/rate characteristics, or the fact that metrics require the date range is not disclosed.

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 filler, with the read-only nature and the resource stated first and the returned content listed immediately after.

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 8 parameters (1 required), full schema coverage and an output schema, the definition is largely sufficient. Minor gaps remain around pagination behavior and the coupling between the optional metrics/combinations and the date range.

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 every parameter is already documented. The description only hints at the optional date-bounded metrics and top-combination behavior (which map to startDate/endDate and includeTopCombinations) without adding format or scoping detail, so baseline 3 applies.

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 — 'Performance Max asset group diagnostics' — and enumerates the content returned (ad strength, action items, status reasons, metrics, top combinations). This clearly separates it from the sibling asset-listing tool google_ads_get_pmax_assets, though that sibling is never named explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer 'use this to diagnose PMax asset groups' but there is no statement of when to prefer this over google_ads_get_pmax_assets or google_ads_run_gaql, and no prerequisites or exclusions are given.

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