Loading ToolBench
Read-only MCP server for Google Ads: GAQL queries, resource schema and catalog, recommendations, keyword planning and forecasts, change history, multi-account via MCC.
Google Ads MCP demonstrates solid naming conventions (all tools start with action verbs: google_ads_*) and comprehensive parameter schemas with type definitions. All 11 tools have descriptions and input schemas visible in the code. However, descriptions are inconsistent in depth, some are 50-80 chars (good), others exceed 150 chars (verbose). Parameter descriptions are present but often generic (e.g., 'Customer ID (10-digit or hyphenated format)' repeated across tools). Output schemas are not explicitly documented in tool definitions; the _reply() wrapper infers structure but does not declare it to the MCP client. Error handling is present (GoogleAdsException caught, _fail() provides hints) but recovery guidance is generic. No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Composition is strong, tools are single-purpose and chainable (e.g., list_accessible_customers → query). Security is well-handled: credentials injected via env, no secrets in params, GAQL validation prevents mutations.
Generate forecast metrics (traffic, cost, conversions) for keywords.
Generate keyword ideas based on seed keywords, URL, or category.
Retrieve budget status and spending information for a customer account.
Retrieve change history for a customer account (who changed what, when).
Retrieve the account hierarchy (MCC structure) starting from the login customer.
Retrieve historical search volume and trend data for keywords.
Retrieve recommendations for a customer account (e.g. budget, keywords, ads).
Output schemas not declared in tool definitions. The _reply() wrapper constructs responses with 'status', 'operation', 'summary', 'result', 'target', 'proof', 'warnings', 'recovery' fields, but these are not exposed to the MCP client as documented return types. LLMs cannot plan downstream operations without knowing what fields to expect.
Tool annotations missing. All 11 tools are read-only (no mutations), but readOnlyHint is not set in tool definitions. This forces LLMs to infer safety from descriptions, increasing hallucination risk for destructive operations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Retrieve the schema (fields, types, segments, metrics) for a Google Ads resource.
List all customer accounts accessible to the authenticated user (via MCC hierarchy).
List all available Google Ads resources and their field schemas.
Execute a GAQL (Google Ads Query Language) SELECT query against a customer account.
Parameter descriptions are repetitive and generic. 'Customer ID (10-digit or hyphenated format, e.g. '1234567890' or '123-456-7890')' appears verbatim in 8 tools. Descriptions should explain WHEN to use the tool and what it returns, not just restate the parameter format.
Pagination not explicitly documented. Tools like google_ads_query accept max_rows, google_ads_get_recommendations accepts page_size, but the tool descriptions do not state whether results are capped, whether pagination is supported, or what happens if the limit is reached. The _reply() wrapper detects partial results but does not expose this to the LLM in a standard way.
Error recovery guidance is generic. The _fail() function returns 'Retry once after a delay' or 'Correct credentials, permissions, identifiers, or parameters before retrying.' but does not suggest specific next steps (e.g., 'Call google_ads_list_accessible_customers to verify customer_id' or 'Check GOOGLE_ADS_DEVELOPER_TOKEN env var').