Skip to main content
Glama
ceotind

Google Ads MCP Reader

by ceotind
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Open Google MCP

A read-only Model Context Protocol (MCP) server for Google Ads (via GAQL), Search Console, and Google Analytics 4. Designed for AI assistants and LLM agents to safely read campaign performance, search analytics, website traffic, and more.

Tools

Google Ads

Tool

Input

Description

list_accessible_customers

—

Discover Google Ads account IDs

get_resource_metadata

resource_name

Explore selectable/filterable/sortable fields for a resource

search

customer_id, resource, fields, conditions?, orderings?, limit?

Execute read-only GAQL queries

Google Search Console

Tool

Input

Description

gsc_get_capabilities

—

Get categorized tool list with auth status

gsc_list_properties

—

List all GSC properties (start here)

gsc_get_site_details

site_url

Verification/ownership for a property

gsc_get_search_analytics

site_url, days?, dimensions?, row_limit?

Top queries with clicks, impressions, CTR, position

gsc_get_performance_overview

site_url, days?

Executive summary with daily trend

gsc_compare_search_periods

site_url, period1_start/end, period2_start/end

Compare two date ranges

gsc_get_advanced_search_analytics

site_url, start_date?, end_date?, dimensions?, search_type?, row_limit?, start_row?, sort_by?, sort_direction?, filters?

Filtered, sorted, paginated analytics

gsc_inspect_url

site_url, page_url

Debug a URL's crawl/index status

gsc_get_sitemaps

site_url

List sitemaps with status and errors

Google Analytics 4

Tool

Input

Description

ga4_get_capabilities

—

Get categorized tool list with auth status

ga4_list_properties

—

Discover all accessible GA4 properties

ga4_get_metadata

property_id

Browse available dimensions and metrics

ga4_run_report

property_id, dimensions?, metrics?, start_date?, end_date?, filters?, order_bys?, limit?

Run a standard report with filtering and ordering

ga4_run_realtime_report

property_id, dimensions?, metrics?, limit?

Get real-time data (last 30 minutes)

Google Keyword Planner

Tool

Input

Description

generate_keyword_ideas

customer_id?, keywords?/url?, geos?, language?, network?, page_size?

Keyword ideas with search volume, competition, bid ranges

generate_keyword_historical_metrics

customer_id?, keywords, geos?, language?

Historical metrics for exact keywords

generate_keyword_forecast_metrics

customer_id?, keywords, match_types?, currency_code?, start/end_date?, budget/bid?

Simulated campaign forecast (impressions, clicks, CPC, cost)

suggest_geo_target_constants

names, country_code?, locale?

Look up geo resource names (e.g. Ireland → geoTargetConstants/2372)

Keyword Planner tools reuse the same service account + developer token as the Ads tools. customer_id is optional — it falls back to GOOGLE_ADS_DEFAULT_CUSTOMER_ID, then GOOGLE_ADS_LOGIN_CUSTOMER_ID from .env. The account needs Keyword Planner access (Tools → Planning → Keyword Planner in Google Ads); manager (MCC) accounts usually don't have it — use a child customer ID. The developer token must have at least basic access (explorer-level tokens are rejected: "apply for basic or standard access" — ads.google.com → Tools → API Center → Request higher access).

Manager Account Auto-Routing

If search targets a manager (MCC) account and finds no data directly, it automatically:

  1. Detects the account is a manager

  2. Finds child accounts

  3. Runs the query on each child

  4. Returns combined results with _source_customer_id marking which account each row belongs to

Related MCP server: Google Ads MCP Server

Setup

Prerequisites (all paths)

Option A: Docker (recommended — no Python required)

1. Clone

git clone https://github.com/ceotind/open-google-mcp.git
cd open-google-mcp

2. Create and authorize a service account

A single service account authenticates Google Ads, Search Console, and Google Analytics 4.

  1. Go to GCP Console → APIs & Services → Credentials → Create Credentials → Service Account

  2. Download the JSON key file, then copy these fields into .env:

    • GOOGLE_SERVICE_ACCOUNT_EMAIL

    • GOOGLE_SERVICE_ACCOUNT_KEY (the private_key — keep the \n escapes)

    • GOOGLE_SERVICE_ACCOUNT_KEY_ID

    • GOOGLE_SERVICE_ACCOUNT_CLIENT_ID

    • GOOGLE_SERVICE_ACCOUNT_PROJECT_ID

  3. Google Ads: add the service account email in your manager account (Settings → Account access → Service account users)

  4. Search Console: add the same email to your property (Settings → Users and permissions → Add user, grant Full access)

  5. Google Analytics 4: add the same email to your GA4 property (Admin → Account Access Management → Add user → Viewer)

3. Configure .env

cp .env.example .env
# Edit .env with the service account values + developer token

Variable

Description

GOOGLE_ADS_DEVELOPER_TOKEN

Your Google Ads API developer token

GOOGLE_SERVICE_ACCOUNT_EMAIL

Service account email

GOOGLE_SERVICE_ACCOUNT_KEY

Private key (with \n newlines)

GOOGLE_SERVICE_ACCOUNT_KEY_ID

Private key ID

GOOGLE_SERVICE_ACCOUNT_CLIENT_ID

Client ID

GOOGLE_SERVICE_ACCOUNT_PROJECT_ID

GCP project ID

GOOGLE_ADS_LOGIN_CUSTOMER_ID

Optional — for MCC account routing

GOOGLE_ADS_DEFAULT_CUSTOMER_ID

Optional — default customer_id for Keyword Planner tools (falls back to LOGIN_CUSTOMER_ID)

GA4_CREDENTIALS_PATH

Optional — dedicated GA4 credential file

4. Build and start the container (once)

docker compose build
docker compose up -d open-google-mcp

This starts a single long-lived container. Client configs attach to it with docker compose exec instead of docker compose run, so a new container is not created every session. (Don't use docker compose run for a client — it spawns a new container each launch and --rm never removes a long-running stdio server, so containers pile up.)

5. MCP client config

Claude Desktop:

{
  "mcpServers": {
    "open-google-mcp": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "open-google-mcp", "python", "-m", "open_google_mcp"],
      "workdir": "/path/to/open-google-mcp"
    }
  }
}

opencode:

{
  "mcp": {
    "open-google-mcp": {
      "type": "local",
      "command": ["docker", "compose", "exec", "-T", "open-google-mcp", "python", "-m", "open_google_mcp"],
      "workdir": "/path/to/open-google-mcp",
      "enabled": true
    }
  }
}

Cursor:

  • Name: open-google-mcp

  • Type: command

  • Command: docker compose exec -T open-google-mcp python -m open_google_mcp

  • Working directory: /path/to/open-google-mcp

Option B: Python (local install)

1. Clone and install

git clone https://github.com/ceotind/open-google-mcp.git
cd open-google-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

2. Create and authorize a service account

Same steps as Option A above — a single service account works for Ads, GSC, and GA4.

  1. Go to GCP Console → APIs & Services → Credentials → Create Credentials → Service Account

  2. Download the JSON key file, then copy these fields into .env:

    • GOOGLE_SERVICE_ACCOUNT_EMAIL

    • GOOGLE_SERVICE_ACCOUNT_KEY

    • GOOGLE_SERVICE_ACCOUNT_KEY_ID

    • GOOGLE_SERVICE_ACCOUNT_CLIENT_ID

    • GOOGLE_SERVICE_ACCOUNT_PROJECT_ID

  3. Google Ads: add the service account email in your manager account

  4. Search Console: add the same email to your property with Full access

  5. Google Analytics 4: add the same email to your GA4 property with Viewer access

3. Configure .env

cp .env.example .env

Variable

Description

GOOGLE_ADS_DEVELOPER_TOKEN

Your Google Ads API developer token

GOOGLE_SERVICE_ACCOUNT_EMAIL

Service account email

GOOGLE_SERVICE_ACCOUNT_KEY

Private key (with \n newlines)

GOOGLE_SERVICE_ACCOUNT_KEY_ID

Private key ID

GOOGLE_SERVICE_ACCOUNT_CLIENT_ID

Client ID

GOOGLE_SERVICE_ACCOUNT_PROJECT_ID

GCP project ID

GOOGLE_ADS_LOGIN_CUSTOMER_ID

Optional — for MCC account routing

GOOGLE_ADS_DEFAULT_CUSTOMER_ID

Optional — default customer_id for Keyword Planner tools (falls back to LOGIN_CUSTOMER_ID)

GA4_CREDENTIALS_PATH

Optional — dedicated GA4 credential file

4. Run

source .venv/bin/activate
source .env
python -m open_google_mcp

Or use the wrapper script (loads .env automatically):

./server.sh

5. MCP client config

Claude Desktop:

{
  "mcpServers": {
    "open-google-mcp": {
      "command": "/path/to/open-google-mcp/server.sh"
    }
  }
}

opencode:

{
  "mcp": {
    "open-google-mcp": {
      "type": "local",
      "command": ["/path/to/open-google-mcp/server.sh"],
      "enabled": true
    }
  }
}

Cursor:

  • Name: open-google-mcp

  • Type: command

  • Command: /path/to/open-google-mcp/server.sh

Google Ads — Usage Examples

List Ads accounts

list_accessible_customers

Discover fields for a resource

get_resource_metadata(resource_name="campaign")

Get active search campaigns with performance

search(
  customer_id="1234567890",
  resource="campaign",
  fields=["campaign.id", "campaign.name", "campaign.status",
          "campaign.advertising_channel_type", "metrics.clicks",
          "metrics.impressions", "metrics.cost_micros"],
  conditions=["campaign.status = 'ENABLED'",
              "segments.date DURING LAST_30_DAYS"],
  orderings=["metrics.clicks DESC"],
  limit=10
)

Get child accounts under a manager

search(
  customer_id="1234567890",
  resource="customer_client",
  fields=["customer_client.id", "customer_client.descriptive_name", "customer_client.manager"]
)

Google Search Console — Usage Examples

List GSC properties

gsc_list_properties

Get search analytics

gsc_get_search_analytics(
  site_url="https://example.com",
  days=28,
  dimensions="query",
  row_limit=10
)

Get performance overview

gsc_get_performance_overview(
  site_url="https://example.com",
  days=28
)

Compare two time periods

gsc_compare_search_periods(
  site_url="https://example.com",
  period1_start="2025-01-01",
  period1_end="2025-01-31",
  period2_start="2025-02-01",
  period2_end="2025-02-28",
  dimensions="query",
  limit=10
)

Advanced analytics with filters

gsc_get_advanced_search_analytics(
  site_url="https://example.com",
  dimensions="query,device",
  search_type="WEB",
  row_limit=50,
  sort_by="impressions",
  sort_direction="descending",
  filters='[{"dimension":"country","operator":"equals","expression":"usa"}]'
)

Inspect a URL

gsc_inspect_url(
  site_url="https://example.com",
  page_url="https://example.com/blog/post"
)

List sitemaps

gsc_get_sitemaps(site_url="https://example.com")

Google Analytics 4 — Usage Examples

Start here — discover properties

ga4_list_properties

Returns your property ID (e.g. 123456789) — use it in all other GA4 tools.

Browse available dimensions and metrics

ga4_get_metadata(property_id="123456789")

Returns 300+ dimensions and 100+ metrics available for reporting.

Run a basic report (property-level summary)

ga4_run_report(
  property_id="123456789",
  metrics="activeUsers,sessions,newUsers",
  start_date="28daysAgo",
  end_date="today"
)

Top countries by users

ga4_run_report(
  property_id="123456789",
  dimensions="country",
  metrics="activeUsers",
  start_date="28daysAgo",
  end_date="today",
  limit=10,
  order_bys=[{"metric": "activeUsers", "desc": true}]
)

Top pages with views

ga4_run_report(
  property_id="123456789",
  dimensions="pagePath",
  metrics="screenPageViews,activeUsers",
  start_date="28daysAgo",
  end_date="today",
  limit=10,
  order_bys=[{"metric": "screenPageViews", "desc": true}]
)

Traffic sources breakdown

ga4_run_report(
  property_id="123456789",
  dimensions="sessionDefaultChannelGrouping",
  metrics="activeUsers,sessions",
  start_date="28daysAgo",
  end_date="today",
  limit=10,
  order_bys=[{"metric": "activeUsers", "desc": true}]
)

Filter by country (e.g. only Ireland)

ga4_run_report(
  property_id="123456789",
  dimensions="city",
  metrics="activeUsers",
  start_date="28daysAgo",
  end_date="today",
  filters={"field": "country", "type": "string_filter",
           "value": "Ireland", "match_type": "EXACT"},
  limit=10
)

Device breakdown

ga4_run_report(
  property_id="123456789",
  dimensions="deviceCategory",
  metrics="activeUsers,sessions",
  start_date="28daysAgo",
  end_date="today"
)

Real-time report (last 30 minutes)

ga4_run_realtime_report(
  property_id="123456789",
  dimensions="country,deviceCategory",
  metrics="activeUsers",
  limit=10
)

Date formats

You can use relative or absolute dates:

  • Relative: today, yesterday, 7daysAgo, 28daysAgo, 30daysAgo

  • Absolute: 2026-01-01 (YYYY-MM-DD format)

Google Keyword Planner — Usage Examples

customer_id is optional everywhere — set GOOGLE_ADS_DEFAULT_CUSTOMER_ID in .env and omit it in calls.

Keyword ideas for a seed term

generate_keyword_ideas(
  keywords=["salsa classes dublin", "salsa dancing"],
  geos=["geoTargetConstants/2372"],   # Ireland — find via suggest_geo_target_constants
  language="english"
)

Historical metrics for exact keywords

generate_keyword_historical_metrics(
  keywords=["salsa classes dublin", "bachata classes dublin"],
  geos=["geoTargetConstants/2372"]
)

Forecast a campaign for next month

generate_keyword_forecast_metrics(
  keywords=["salsa classes dublin", "salsa dancing"],
  match_types=["PHRASE", "EXACT"],
  currency_code="EUR",
  daily_budget_micros=20000000,   # €20/day
  max_cpc_bid_micros=500000       # €0.50 max CPC
)

Find a geo constant

suggest_geo_target_constants(names=["Ireland"], country_code="IE")

GAQL Tips

  • Field names must be fully qualified: campaign.id, not id

  • Date format: YYYY-MM-DD with dashes

  • Relative dates: DURING LAST_7_DAYS, LAST_30_DAYS, THIS_MONTH, THIS_QUARTER

  • For change_event resource, limit must be ≤ 10000

  • Conditions are AND-combined

  • Use get_resource_metadata first to discover valid fields

Development

python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest          # unit tests — no network or credentials required

The Keyword Planner logic lives in src/open_google_mcp/keyword_planner.py (pure request builders and result flatteners, fully unit-tested). A live smoke test against the real API is available:

source .env && python scripts/smoke_keyword_planner.py [customer_id]

License

MIT

Available Tools

6 tools
get_resource_metadataA

Discover which fields are SELECTable, FILTERable, and SORTable for a Google Ads resource. Always call this before search() — using incorrect field names causes API errors. Compatible metrics.* and segments.* fields are included for reporting queries.

Args: resource_name: The resource to explore (e.g. 'campaign', 'ad_group', 'keyword_view', 'search_term_view', 'customer_client').

Returns: A dict with resource name and three sorted arrays of fully-qualified field names. Example for resource='campaign': selectable: ['campaign.id', 'campaign.name', 'campaign.status', 'metrics.clicks', 'metrics.impressions', ...] filterable: ['campaign.id', 'campaign.status', ...] sortable: ['campaign.id', 'metrics.clicks', ...]

ParametersJSON Schema
NameRequiredDescriptionDefault
resource_nameYes

TDQS

A4.8/5.0
Behavior4/5

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

No annotations provided, but description fully explains input, output structure with example, and includes compatible fields. No side effects noted, which is appropriate for a read-only discovery tool.

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?

Front-loaded with purpose and usage, followed by structured Args and Returns sections. Every sentence adds value with no redundancy.

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?

For a simple one-parameter tool with no annotations or output schema, the description provides complete context: purpose, usage, parameter explanation, return format, and examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description compensates with detailed explanation of the single parameter 'resource_name', including example values and a list of common resources.

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?

Description clearly states the tool discovers which fields are SELECTable, FILTERable, and SORTable for a Google Ads resource, with explicit examples. It distinguishes itself from siblings like 'search' by being a preparatory tool.

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?

Explicitly advises 'Always call this before search()' and explains that using incorrect field names causes API errors, providing clear when-to-use guidance.

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

gsc_compare_search_periodsA

Compare search performance between two date ranges and surface what changed. Use this for: month-over-month analysis, campaign impact assessment, seasonal trend detection. Returns which queries improved or declined with click/impression changes.

Args: site_url: Exact GSC property URL from gsc_list_properties. Format: 'https://example.com/' or 'sc-domain:example.com'. period1_start: Start of baseline period, format YYYY-MM-DD (e.g. '2026-01-01'). period1_end: End of baseline period, format YYYY-MM-DD (e.g. '2026-01-31'). period2_start: Start of comparison period, format YYYY-MM-DD (e.g. '2026-02-01'). period2_end: End of comparison period, format YYYY-MM-DD (e.g. '2026-02-28'). dimensions: Group by — 'query', 'page', 'device', etc. (default: 'query'). limit: Max items to return, sorted by biggest change (default: 10).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
site_urlYes
dimensionsNoquery
period1_endYes
period2_endYes
period1_startYes
period2_startYes

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries full burden for behavioral transparency. It mentions returns improved/declined queries with click/impression changes, sorts by biggest change, and includes a limit. However, it lacks details on statistical significance, pagination, or whether results are aggregated, which would enhance transparency.

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?

The description is well-structured with a header, a bullet for usage, and an Args section. It is clear and front-loaded, with each sentence adding value. Slightly verbose in parameter examples, but overall concise for the level of detail needed.

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?

Given 7 parameters, no output schema, and no annotations, the description covers purpose, usage, and parameters well. However, it does not describe the output structure beyond 'returns which queries improved or declined', leaving gaps in understanding the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter, including format examples (e.g., site_url format, YYYY-MM-DD for dates), defaults (dimensions, limit), and sources (gsc_list_properties). This adds significant meaning beyond the basic schema titles.

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 clearly states the tool compares search performance between two date ranges and surfaces changes, and explicitly lists use cases (month-over-month, campaign impact, seasonal trends). It distinguishes from sibling tools like gsc_get_performance_overview by focusing on comparative analysis.

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?

The description provides explicit usage guidance with 'Use this for:' and lists specific scenarios. However, it does not explicitly state when not to use it or contrast with alternatives like gsc_get_performance_overview, which could further improve clarity.

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

gsc_get_performance_overviewA

Get an executive summary with daily trend — totals for clicks, impressions, CTR, and avg position plus a day-by-day breakdown. Use this for: quick snapshots, dashboards, spotting traffic spikes or drops. For detailed query-level data, use gsc_get_search_analytics.

Args: site_url: Exact GSC property URL from gsc_list_properties. Format: 'https://example.com/' or 'sc-domain:example.com'. days: How many days to look back (default: 28).

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
site_urlYes

TDQS

A4.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It describes output as totals and daily breakdown, and implies a read-only operation. It does not mention auth or error handling, but given the simplicity, it is adequately transparent.

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 concise paragraphs: first clearly states purpose and usage, second documents parameters. Every sentence adds value, and information is front-loaded.

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?

With no output schema, the description fully explains return values (totals and daily breakdown). Also mentions dependency on gsc_list_properties for obtaining the site_url. No gaps for the tool's scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It explains site_url format precisely, referencing gsc_list_properties, and notes the default for days. Both parameters are well-described.

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 clearly states it provides an executive summary with daily trends for clicks, impressions, CTR, and average position, plus a day-by-day breakdown. It distinguishes itself from the sibling tool gsc_get_search_analytics by noting that the latter is for detailed query-level data.

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?

Explicitly states when to use: quick snapshots, dashboards, spotting traffic spikes or drops. Also provides a clear alternative: for detailed query-level data, use gsc_get_search_analytics.

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

gsc_get_sitemapsA

List all sitemaps for a GSC property with submission status, error/warning counts, and indexed URL totals. Use this for: monitoring crawl health, finding sitemap errors, checking if new content was picked up, verifying sitemap submission.

Args: site_url: Exact GSC property URL from gsc_list_properties. Format: 'https://example.com/' or 'sc-domain:example.com'.

ParametersJSON Schema
NameRequiredDescriptionDefault
site_urlYes

TDQS

A4.3/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Describes output (status, error counts, indexed URLs) but does not disclose behavioral traits like error handling, rate limits, or prerequisites beyond property format.

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 sentences and a bullet list, front-loaded with purpose and use cases. Every line provides value.

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?

Single parameter is well-documented. Output is described in the first sentence. Lacks explicit return format or error info, but sufficient for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but description explains the site_url parameter format and source (from gsc_list_properties). Provides crucial context beyond the schema.

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?

Clearly states the tool lists all sitemaps for a GSC property with submission status, error/warning counts, and indexed URL totals. Distinguishes from sibling tools like gsc_compare_search_periods and gsc_get_performance_overview.

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?

Explicitly lists use cases (monitoring crawl health, finding sitemap errors, etc.). Does not explicitly mention when not to use or alternatives, but the use cases are clear.

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

list_accessible_customersA

Start here — Discover Google Ads customer IDs accessible by the authenticated user. Always call this first before search(). Returns resource names like 'customers/1234567890' — extract the numeric ID from the last segment to use in other tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

Discloses output format (resource names like 'customers/1234567890') and instructs to extract numeric ID for other tools. No annotations provided, so description carries full burden and does it well.

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 sentences, front-loaded with 'Start here', no wasted words.

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?

Covers purpose, usage order, output format, and integration with other tools. No gaps given zero parameters and existence of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; baseline score of 4 as description adds no param info (none needed).

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?

Clear verb 'list' + resource 'accessible customers'; distinguishes itself from search() by stating 'Always call this first before search()'.

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?

Explicitly states when to call ('Start here', 'Always call this first before search()'), but does not mention when not to use or alternatives.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: resource metadata exploration, GAQL search, customer ID listing, and three separate GSC functions (period comparison, performance overview, sitemap listing). The 'gsc_' prefix further distinguishes the Google Search Console tools from the Ads tools.

Naming Consistency3/5

Naming conventions are mixed: some tools use 'get_', one uses 'list_', one is bare 'search', and three use the 'gsc_' prefix but with different verb forms ('compare', 'get'). While snake_case is consistent, the lack of a uniform verb pattern makes the naming somewhat inconsistent.

Tool Count5/5

With 6 tools covering both Google Ads essentials (customer discovery, metadata, querying) and Google Search Console basics (overview, comparison, sitemaps), the count feels well-scoped for the combined domain.

Completeness2/5

The GSC tools reference a prerequisite 'gsc_list_properties' tool that does not exist, creating a dead end. For Google Ads, the 'search' tool is powerful but lacks higher-level convenience operations (e.g., getting campaign performance by ID). Overall, the surface has notable gaps.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • flin-google-ads-mcp

    flin-agency
    A
    license
    B
    quality
    C
    maintenance
    Read-only MCP server for Google Ads, enabling querying campaigns, ad groups, ads, insights, and keywords without create/update/delete operations.
    9
    MIT

  • Google Ads MCP Server

    RustamFaskhutdzinau
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides read-only access to Google Ads account data including campaigns, ad groups, keywords, and performance reports. Enables querying via GAQL through an MCP interface.
    MIT

  • google-marketing-mcp

    Bmiller4evr
    A
    license
    B
    quality
    C
    maintenance
    Read-only MCP server for Google Ads API, enabling natural language queries about campaigns, metrics, search terms, and change history without write access.
    6
    MIT

  • Google Ads MCP

    Vadim03-sol
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    A private, read-only MCP server that enables retrieval and analysis of Google Ads reporting data (campaigns, ad groups, keywords, search terms, cost, conversions) from authorized accounts through a locally operated server.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ceotind/open-google-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server