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 search fields

google_ads_search_fields
Read-onlyIdempotent

Search the live GoogleAdsField catalog to discover queryable GAQL resources, attributes, segments, metrics, and compatibility before writing a raw GAQL query. Read-only.

Instructions

Search Google's live GoogleAdsField catalog. Discovers every queryable GAQL resource, attribute, segment, metric, enum value, and selectable-with compatibility relationship. Read-only and useful before a raw GAQL query.

Input Schema

NameRequiredDescriptionDefault
queryNoOptional raw GoogleAdsField SELECT query. When provided it replaces the structured filters.
categoryNoCategory selected from the provider dictionary or field catalogue.
pageSizeNoMaximum items requested per page. Follow the returned pagination information for remaining results.
sortableNoFilter the field catalogue by whether the field can appear in ORDER BY.
pageTokenNoOpaque continuation token returned by the preceding provider response.
filterableNoFilter the field catalogue by whether the field can appear in WHERE.
selectableNoFilter the field catalogue by whether the field can appear in SELECT.
nameContainsNoCase-sensitive field-name substring, e.g. conversion or asset_group

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. Changed2 schema fields changedv2.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • 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

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so 'read-only' in the description is redundant rather than additive. The genuinely useful context is that it hits Google's live catalog and covers compatibility relationships (selectable-with), but nothing is said about result volume or rate-limit behavior beyond the schema's pagination fields.

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 tight sentences with zero filler; the core action and the return surface are front-loaded, and the usage hint comes last where it belongs.

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 an output schema, full parameter documentation, and strong annotations, the description only needs to frame purpose and it does. A brief note on how the raw-query mode interacts with the filter parameters would make it fully self-sufficient.

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 eight parameters are already documented at the field level. The description adds no parameter-specific detail (e.g., that 'query' overrides all structured filters, or how the boolean flags compose), so the schema is doing all the work.

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 ('Search') and resource ('GoogleAdsField catalog') and enumerates exactly what it returns (resources, attributes, segments, metrics, enum values, selectable-with relationships). Clearly distinct from siblings like google_ads_run_gaql and google_ads_validate_query, which consume rather than enumerate the field catalogue.

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?

'Read-only and useful before a raw GAQL query' gives a concrete usage context that implies the pre-query discovery workflow. It doesn't explicitly name run_gaql or validate_query as the downstream alternatives or state when not to use it, so it falls short of full routing guidance.

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