Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

google_ads_health_check_all

Screen all Google Ads campaigns by primary status and run delivery diagnostics on up to 5 problem or warning campaigns to surface issues, warnings, and recommendations.

Instructions

Screen every campaign in the Google Ads account by primary_status and run detailed delivery diagnostics on up to 5 problem/warning campaigns. Returns {total_campaigns, enabled_count, paused_count, removed_count, healthy_campaigns (ELIGIBLE), warning_campaigns (other primary_status among ENABLED), problem_campaigns (NOT_ELIGIBLE/ENDED/REMOVED among ENABLED — each: {campaign_id, name, primary_status}), detailed_diagnostics:[{campaign_id, name, issues, warnings, recommendations}] (up to 5; problem-first, then warning; issues, warnings and recommendations are null when that campaign's diagnostics could not be retrieved), summary:{total_enabled, healthy, warning, problem, message}}. Read-only. For single-campaign delivery diagnosis use google_ads_campaigns_diagnose; for CPA-goal monitoring use google_ads_monitoring_cpa_goal.

Input Schema

NameRequiredDescriptionDefault
customer_idNoGoogle Ads customer ID as a 10-digit string without dashes (e.g. '1234567890'). Optional — falls back to GOOGLE_ADS_CUSTOMER_ID / GOOGLE_ADS_LOGIN_CUSTOMER_ID from the configured credentials when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  2. Addedv0.9.12
  3. Removedv0.9.6
  4. Addedv0.9.2
  5. Removedv0.9.1
  6. Addedv1.0.5

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it declares the tool read-only, caps detailed diagnostics at five campaigns, specifies problem-first then warning ordering, and explains when issue fields are null. It does not mention permission requirements, rate limits, or expected latency, which are the remaining behavioral gaps.

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?

The definition is dense but front-loaded: purpose first, return shape second, then read-only status and sibling alternatives. Despite its length, each sentence adds distinct information needed for a complex account-wide diagnostic tool.

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

Completeness5/5

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

There is no output schema, so the description appropriately explains the return structure in detail, including category definitions, diagnostic limits, null semantics, and summary fields. Combined with the fully described optional parameter, it is complete enough for an agent to invoke and interpret the 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?

There is only one optional parameter and schema description coverage is 100%, so the schema already fully documents customer_id, including its fallback behavior. The description adds no additional parameter semantics, which is acceptable given the schema coverage but not value-adding.

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?

The description states a specific verb and resource: it screens every Google Ads campaign by primary_status and runs detailed diagnostics on up to five problem/warning campaigns. It also distinguishes itself from nearby diagnostic and monitoring tools, so an agent can identify the tool's role without inspecting the 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?

It explicitly routes the agent: single-campaign delivery diagnosis should use google_ads_campaigns_diagnose, and CPA-goal monitoring should use google_ads_monitoring_cpa_goal. The account-wide screening use case is clear and the alternative tools and conditions are named.

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