Which integrations are available for this server?

Provides tools to interact with Google Search Console, enabling retrieval of search analytics data, site summaries, top queries, top pages, dimension breakdowns, and URL inspections for verified properties.

How do I use flin-google-search-console-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flin-google-search-console-mcp Show me the search analytics for my site in the last 28 days" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

flin-google-search-console-mcp

by flin-agency

Overview Schema Related Servers Score Discussions

Python

Local

flin-google-search-console-mcp

Read-only MCP server for Google Search Console, built to work well in Claude Desktop with a browser-based OAuth flow and local token storage.

Claude Desktop Quickstart

If your goal is simply "make this work in Claude Desktop", follow these steps in order.

1) Make sure the Google account has Search Console access

The Google account you use during login must already have access to at least one Search Console property.

Accepted access levels for the API include owner, full, and read access.

2) Create or choose a Google Cloud project

In Google Cloud:

Create a new project or select an existing one.
Enable the Google Search Console API for that project.

Official references:

In Google Cloud, configure the OAuth consent screen for the same project.

For most personal or team setups:

choose External
keep the app in Testing while you validate the integration
add your own Google account as a test user

Important:

If the app is External and still in Testing, users must be listed as test users
Google documents that test-user authorizations in testing mode can expire after 7 days

This MCP only requests one read-only scope:

https://www.googleapis.com/auth/webmasters.readonly

Official references:

4) Create OAuth credentials of type `Desktop app`

Create an OAuth client in the same Google Cloud project:

Go to Credentials
Click Create client
Choose Desktop app
Copy the generated:
- client ID
- client secret

You do not need to manually wire redirect URIs into Claude Desktop for this MCP. The desktop OAuth flow uses a local loopback callback handled by the running MCP process.

5) Add the MCP to Claude Desktop

The minimum Claude Desktop configuration is:

{
  "mcpServers": {
    "flin-google-search-console-mcp": {
      "command": "uvx",
      "args": ["flin-google-search-console-mcp@latest"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_oauth_client_id",
        "GOOGLE_CLIENT_SECRET": "your_oauth_client_secret"
      }
    }
  }
}

If you want a default property so you do not have to pass site_url every time:

{
  "mcpServers": {
    "flin-google-search-console-mcp": {
      "command": "uvx",
      "args": ["flin-google-search-console-mcp@latest"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_oauth_client_id",
        "GOOGLE_CLIENT_SECRET": "your_oauth_client_secret",
        "GOOGLE_SEARCH_CONSOLE_SITE_URL": "sc-domain:example.com"
      }
    }
  }
}

For local development from a checkout:

{
  "mcpServers": {
    "flin-google-search-console-mcp-local": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/absolute/path/to/flin-google-search-console-mcp",
        "flin-google-search-console-mcp"
      ],
      "env": {
        "GOOGLE_CLIENT_ID": "your_oauth_client_id",
        "GOOGLE_CLIENT_SECRET": "your_oauth_client_secret"
      }
    }
  }
}

Replace /absolute/path/to/flin-google-search-console-mcp with your local checkout path.

6) Restart Claude Desktop

After saving the MCP configuration, fully restart Claude Desktop so it reloads the local server definition.

Start with these prompts:

Run health_check for the Google Search Console MCP and show the full result.

List my Search Console sites.

On the first authenticated tool call, the MCP opens a browser window. Sign in with the Google account that has Search Console access and approve the request.

After that:

the token is stored locally
future access tokens refresh automatically
you do not need to paste a refresh token into Claude Desktop config

Related MCP server: google-search-console-mcp-python

What the MCP stores locally

The MCP stores a local token JSON file after the first successful login.

Default locations:

macOS: ~/Library/Application Support/flin-google-search-console-mcp/token.json
Linux: ~/.config/flin-google-search-console-mcp/token.json
Windows: %APPDATA%\flin-google-search-console-mcp\token.json

If you want to override the location:

{
  "mcpServers": {
    "flin-google-search-console-mcp": {
      "command": "uvx",
      "args": ["flin-google-search-console-mcp@latest"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_oauth_client_id",
        "GOOGLE_CLIENT_SECRET": "your_oauth_client_secret",
        "GOOGLE_SEARCH_CONSOLE_TOKEN_PATH": "/absolute/path/to/flin-google-search-console-mcp-token.json"
      }
    }
  }
}

Multiple Google accounts

You can connect multiple Google accounts and choose the account per tool call.

By default, named account tokens are stored next to the default token. To choose a dedicated token directory, set GOOGLE_SEARCH_CONSOLE_TOKEN_DIR:

{
  "mcpServers": {
    "flin-google-search-console-mcp": {
      "command": "uvx",
      "args": ["flin-google-search-console-mcp@latest"],
      "env": {
        "GOOGLE_CLIENT_ID": "your_oauth_client_id",
        "GOOGLE_CLIENT_SECRET": "your_oauth_client_secret",
        "GOOGLE_SEARCH_CONSOLE_TOKEN_DIR": "/absolute/path/to/search-console-tokens"
      }
    }
  }
}

Then pass account in tool calls:

{
  "tool": "list_sites",
  "args": {
    "account": "work"
  }
}

The first call for a new account opens the OAuth browser flow and stores a separate token, for example work.json. Account names may contain only letters, numbers, _, -, and ..

First Prompts To Verify Everything Works

Use these in Claude Desktop after the server is configured.

Health check

Run health_check for the Google Search Console MCP and show the full result.

Confirm available properties

List my Search Console sites and tell me whether sc-domain:example.com is available.

Quick summary

Run get_site_summary for site_url sc-domain:example.com from 2026-04-01 to 2026-04-20 and show clicks, impressions, ctr, and position.

Top queries

Run get_top_queries for site_url sc-domain:example.com from 2026-04-01 to 2026-04-20 with row_limit 25 and show the top queries by clicks.

Top pages

Run get_top_pages for site_url sc-domain:example.com from 2026-04-01 to 2026-04-20 with row_limit 25 and show the top pages by clicks.

URL inspection

Run inspect_url for site_url sc-domain:example.com and inspection_url https://example.com/.

Property Format: Domain vs URL-prefix

This is one of the most common setup mistakes.

Examples:

Domain property: sc-domain:example.com
URL-prefix property: https://www.example.com/

Use the exact property string returned by list_sites. Do not guess.

What This MCP Exposes

health_check
list_sites
get_site_summary
query_performance
get_top_queries
get_top_pages
get_dimension_breakdown
inspect_url

Which Tool To Use

Recommended call order:

health_check
list_sites
get_site_summary
get_top_queries or get_top_pages
query_performance for custom dimensions and filters
inspect_url for indexability and canonical checks on a specific URL

Search Analytics Notes

query_performance uses the Search Analytics API under the hood
Search Analytics returns top rows, not guaranteed full exports
The MCP maps Google's positional keys[] rows into named dimensions objects

Supported knobs include:

dimensions
filters
search_type
aggregation_type
data_state
row_limit
start_row

Example Tool Calls

Site summary

{
  "tool": "get_site_summary",
  "args": {
    "site_url": "sc-domain:example.com",
    "start_date": "2026-04-01",
    "end_date": "2026-04-20"
  }
}

Top queries

{
  "tool": "get_top_queries",
  "args": {
    "account": "work",
    "site_url": "sc-domain:example.com",
    "start_date": "2026-04-01",
    "end_date": "2026-04-20",
    "row_limit": 25
  }
}

Query performance with filters

{
  "tool": "query_performance",
  "args": {
    "site_url": "sc-domain:example.com",
    "start_date": "2026-04-01",
    "end_date": "2026-04-20",
    "dimensions": ["page"],
    "filters": [
      {
        "dimension": "device",
        "operator": "equals",
        "expression": "MOBILE"
      }
    ],
    "row_limit": 50
  }
}

URL inspection

{
  "tool": "inspect_url",
  "args": {
    "site_url": "sc-domain:example.com",
    "inspection_url": "https://example.com/blog/seo-agent"
  }
}

Source Setup

If you want to run the MCP from source:

uv sync --extra dev
cp .env.example .env
# Fill .env values
uv run flin-google-search-console-mcp

Published Package

Run the latest published package directly:

uvx flin-google-search-console-mcp@latest

Troubleshooting

missing_configuration

GOOGLE_CLIENT_ID or GOOGLE_CLIENT_SECRET is missing from the MCP config

oauth_required

no usable token exists yet
the first browser-based login has not been completed
the stored refresh token is no longer usable and the browser flow must run again

permission_denied

the Google account used during login does not have access to the Search Console property

No sites returned

verify that the Google account really has Search Console access
confirm you logged into the correct Google account in the browser

Google shows an unverified or testing warning

this is usually expected while the app is in testing mode
make sure your Google account is added as a test user on the OAuth consent screen

More Docs

Release on GitHub + PyPI

This repository publishes automatically with GitHub Actions:

CI: .github/workflows/ci.yml
Release: .github/workflows/release.yml triggered by git tags v*

1) Configure PyPI Trusted Publisher

In PyPI project settings for flin-google-search-console-mcp, add a Trusted Publisher with:

Owner: flin-agency
Repository: flin-google-search-console-mcp
Workflow: release.yml
Environment: pypi

2) Cut a release

git add -A
git commit -m "release: v0.1.0"
git tag v0.1.0
git push origin main --tags

Available Tools

8 tools

get_dimension_breakdownC

Get a single-dimension Search Analytics breakdown.

ParametersJSON Schema

Name	Required	Default
`start_date`	Yes
`end_date`	Yes
`dimension`	Yes
`site_url`	No
`search_type`	No	web
`data_state`	No
`row_limit`	No
`start_row`	No
`filters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only notes 'single-dimension'. It does not address pagination, filtering behavior, data freshness, or any side effects, leaving the agent underinformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it sacrifices necessary detail. It could be restructured to front-load core information while adding brief parameter context.

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

Completeness1/5

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

Given 9 parameters, 3 required, no annotations, and no parameter descriptions, the description is severely incomplete. Even with an output schema present, the tool's complexity demands far more context than provided.

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

Parameters1/5

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

Schema description coverage is 0%, and the tool description does not mention any parameters. Since 9 parameters exist with no semantic hints, the description fails to add meaning beyond the raw schema.

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?

The description clearly states the action 'Get' and the resource 'single-dimension Search Analytics breakdown', indicating a focused query. However, it does not explicitly distinguish from sibling tools like get_top_pages or get_top_queries, though the mention of 'dimension' provides some differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It is purely a statement of function without context.

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

get_site_summaryC

Get aggregate performance metrics for a property over a date range.

ParametersJSON Schema

Name	Required	Default
`start_date`	Yes
`end_date`	Yes
`site_url`	No
`search_type`	No	web
`data_state`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only mentions fetching metrics but omits idempotency, auth requirements, or any side effects. Minimal behavioral context is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence, which is concise. However, it lacks sufficient detail for a tool with 5 parameters and an output schema, so conciseness comes at the cost of completeness.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, output schema exists), the description is too terse. It does not explain what metrics are returned or how parameters affect aggregation, missing the opportunity to leverage the output schema context.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description adds little: only 'over a date range' hints at start_date/end_date. The optional parameters site_url, search_type, and data_state are not explained, leaving the agent to infer their purpose from names alone.

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?

The description clearly states the tool retrieves aggregate performance metrics for a property over a date range, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like query_performance, which may have overlapping functionality.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives such as get_dimension_breakdown or get_top_pages. The agent receives no contextual clues for tool selection.

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

get_top_pagesC

Get top page rows for a property over a date range.

ParametersJSON Schema

Name	Required	Default
`start_date`	Yes
`end_date`	Yes
`site_url`	No
`search_type`	No	web
`data_state`	No
`row_limit`	No
`start_row`	No
`filters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, and the description offers no behavioral details beyond the basic action. It does not disclose that the tool is read-only, how pagination works (despite row_limit and start_row parameters), or any rate limits or authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, but it sacrifices clarity and completeness. It is front-loaded with the core action but lacks essential details, making it minimally adequate.

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

Completeness2/5

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

Given the tool's complexity (8 parameters, no annotations, output schema present but not described), the description fails to address pagination, filtering, or the meaning of 'top pages' in context. Sibling tools exist but are not compared, leaving the agent underinformed.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no explanatory value for any of the 8 parameters. While some parameter names are self-explanatory (e.g., start_date, end_date), others like search_type, data_state, and filters require additional context that is missing.

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?

The description uses verb 'Get' and resource 'top page rows', clearly indicating the tool retrieves top page data. It implies a date range and a property, but does not explicitly differentiate from sibling tools like get_top_queries or get_dimension_breakdown, leaving some ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. No context on prerequisites, limitations, or typical use cases is given, leaving the agent to infer from the name alone.

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

get_top_queriesC

Get top query rows for a property over a date range.

ParametersJSON Schema

Name	Required	Default
`start_date`	Yes
`end_date`	Yes
`site_url`	No
`search_type`	No	web
`data_state`	No
`row_limit`	No
`start_row`	No
`filters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as whether the tool is read-only, any rate limits, pagination details, or data freshness. The minimal description leaves the agent without critical safety or performance information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but overly terse. It lacks structure and omits important details about parameters and usage. Better to front-load key information and provide more substance in a few sentences.

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

Completeness2/5

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

Despite having an output schema, the description does not cover the purpose of the numerous parameters (8 total, 2 required). It fails to provide context for the 'filters' or 'data_state' fields, making the tool hard to use correctly without external knowledge.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not add any meaning beyond the parameter titles. It fails to explain what each parameter does, including 'site_url', 'search_type', 'data_state', and 'filters'. The agent would rely solely on parameter titles, which are insufficient for complex optional fields.

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?

The description clearly identifies the action ('Get'), resource ('top query rows'), and context ('for a property over a date range'). It distinguishes from siblings like 'get_top_pages' by specifying 'queries' instead of 'pages'. However, it could be more precise about the 'property' parameter (likely 'site_url').

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_top_pages' or 'get_dimension_breakdown'. It lacks context about what scenarios it is best suited for or when not to use it.

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

health_checkA

Check configuration and authentication readiness for Google Search Console.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states the basic purpose without disclosing behavioral traits like error handling, idempotency, or what readiness entails. This is insufficient for an agent to understand side effects or outcomes.

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?

Single sentence, directly to the point, no fluff. Perfectly front-loaded and concise.

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?

Given the tool has no parameters and an output schema exists (though unknown), the description provides enough context that this is a configuration check. It could briefly mention typical success indicators, but overall adequate.

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?

Input schema has no parameters and 100% coverage, so the description adds minimal value beyond the schema. However, for a zero-parameter tool, baseline is 4; the description does not add misleading detail.

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 verb 'check' and the specific resource 'configuration and authentication readiness for Google Search Console'. It effectively distinguishes from sibling tools which focus on data retrieval and analysis.

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?

The description implies usage as a preliminary check before data tools, but does not explicitly state when to use or not use it, nor does it mention any specific context or prerequisites.

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

inspect_urlC

Inspect the indexed status of a specific URL under a property.

ParametersJSON Schema

Name	Required	Description	Default
`inspection_url`	Yes
`site_url`	No
`language_code`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states purpose, not behavioral traits such as response format, error handling, or permission requirements.

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?

Single sentence, directly to the point, with no superfluous words.

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

Completeness1/5

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

Despite having an output schema, the description is too minimal for a tool with three parameters (0% schema coverage) and no annotations, leaving the agent without critical usage context.

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

Parameters1/5

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

Schema coverage is 0%, and the description adds no explanation for any of the three parameters, including the required inspection_url format or the role of optional site_url and language_code.

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 verb 'inspect' and the resource 'indexed status of a specific URL' within a property, distinguishing it from sibling tools that deal with aggregate data.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like get_site_summary or get_top_pages. Does not mention prerequisites or exclusions.

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

list_sitesA

List Search Console properties accessible by the authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions 'accessible by the authenticated user', implying authentication needs, but does not disclose other behavioral traits like rate limits, pagination, or data freshness. Given the tool's simplicity, this is adequate but not thorough.

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?

A single sentence that is highly efficient and front-loaded. Every word contributes value without 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 parameterless tool with an output schema, the description sufficiently explains the return value (list of properties) and the context (accessible by user). It is complete given the tool's low complexity and the presence of sibling tools.

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?

There are no parameters, and the input schema is empty. The description adds meaning by clarifying that the list is limited to properties accessible by the authenticated user, which goes beyond the schema. Baseline 4 for zero parameters.

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 verb 'List' and the resource 'Search Console properties', with the scope 'accessible by the authenticated user'. This distinguishes it from sibling tools which focus on specific metrics or inspections.

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?

While the description implies use when needing a list of accessible properties, it does not explicitly mention when to use this tool versus alternatives like get_site_summary or query_performance. The existence of sibling tools provides context, but the description lacks guidance.

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

query_performanceC

Query Search Analytics performance data with explicit dimensions and filters.

ParametersJSON Schema

Name	Required	Default
`start_date`	Yes
`end_date`	Yes
`site_url`	No
`dimensions`	No
`search_type`	No	web
`aggregation_type`	No
`data_state`	No
`row_limit`	No
`start_row`	No
`filters`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose any behavioral characteristics such as read-only nature, authentication requirements, rate limits, or potential side effects. The phrase 'Query' implies a read operation but is not explicit.

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 description is a single clear sentence with no unnecessary words or repetition. Every word serves a purpose.

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

Completeness2/5

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

Given the tool's complexity (10 parameters, no annotations), the description is too brief. It does not convey the tool's full scope or how to use it effectively, even though an output schema exists.

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

Parameters2/5

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

With 0% schema description coverage, the description only mentions 'dimensions' and 'filters' but does not explain the meaning or constraints of any of the 10 parameters. It adds minimal value beyond the raw schema.

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?

The description clearly identifies the action ('Query') and resource ('Search Analytics performance data'), and mentions specifying 'explicit dimensions and filters', which hints at its functionality. However, it is somewhat generic and does not fully distinguish from siblings like 'get_top_queries' or 'get_dimension_breakdown'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what the tool does without contextualizing its appropriate usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0May 27, 2026
- First observedget_dimension_breakdown
- First observedget_site_summary
- First observedget_top_pages
- First observedget_top_queries
- First observedhealth_check
- First observedinspect_url
- First observedlist_sites
- First observedquery_performance

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: get_dimension_breakdown, get_site_summary, get_top_pages, get_top_queries cover different aspects of Search Analytics; query_performance offers flexible queries; inspect_url handles URL inspection; list_sites and health_check serve utility roles. No significant overlap.

Naming Consistency4/5

Most tools follow a 'get_' prefix (6 out of 8), with 'inspect_url', 'list_sites', and 'health_check' as exceptions. The naming is predominantly snake_case and readable, but the 'health_check' tool breaks the verb_noun pattern.

Tool Count5/5

With 8 tools, the server is well-scoped for a Google Search Console MCP. It covers data retrieval, URL inspection, site management, and health checks without being overly broad or too sparse.

Completeness4/5

The tool set covers key operations: performance analytics with various granularities (summary, top pages/queries, dimension breakdown, flexible query), URL inspection, site listing, and authentication check. Missing features like sitemap management or site addition/removal are minor gaps for typical use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
SearchConsole.aiOAuth
ai.searchconsole
Read-only Search Console analytics, URL inspection, indexing diagnostics, and sitemaps.
Search Monitoring
2
google-mcp
io.github.matiasbattocchia
Streamable HTTP MCP server for Google Calendar and Sheets with OAuth login.
Calendar Management Cloud Platforms Workplace & Productivity
24
kalicart-global A
io.github.giuseppesocci-bot
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
E-commerce & Retail Search
53

Related MCP Servers

Google Search Console Audit
AI & Machine Learning Marketing Browser Automation
acamolese
A
license
A
quality
A
maintenance
Read-only MCP server for Google Search Console: performance queries, URL inspection, indexing checks, sitemaps, and one-call HTML SEO audit reports.
Updated 16 days ago (2026-08-22 13:00 UTC)
17
7
MIT
google-search-console-mcp
Search Marketing
locomotive-agency
A
license
Not graded
quality
A
maintenance
MCP server for Google Search Console API that enables querying search analytics, managing sites, inspecting URLs, and supporting domain delegation via service accounts.
Updated 2 days ago (2026-09-05 02:37 UTC)
MIT
SearchConsole.ai
AndreyAzimov
A
license
Not graded
quality
B
maintenance
Read-only MCP server for Google Search Console data, enabling search analytics, URL inspection, indexing diagnostics, and sitemap management through MCP clients.
Updated 2 months ago (2026-07-19 21:59 UTC)
19
MIT
mcp-google-search-console
crunchtools
A
license
A
quality
B
maintenance
Secure MCP server for Google Search Console. Query search analytics (clicks, impressions, CTR, position), manage sitemaps, inspect URL indexing status, and manage site properties.
Updated a day ago (2026-09-06 02:35 UTC)
10
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/flin-agency/flin-google-search-console-mcp'

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

flin-google-search-console-mcp

Claude Desktop Quickstart

1) Make sure the Google account has Search Console access

2) Create or choose a Google Cloud project

3) Configure the OAuth consent screen

4) Create OAuth credentials of type Desktop app

5) Add the MCP to Claude Desktop

6) Restart Claude Desktop

7) Complete the first login inside Claude

What the MCP stores locally

Multiple Google accounts

First Prompts To Verify Everything Works

Health check

Confirm available properties

Quick summary

Top queries

Top pages

URL inspection

Property Format: Domain vs URL-prefix

What This MCP Exposes

Which Tool To Use

Search Analytics Notes

Example Tool Calls

Site summary

Top queries

Query performance with filters

URL inspection

Source Setup

Published Package

Troubleshooting

More Docs

Release on GitHub + PyPI

1) Configure PyPI Trusted Publisher

2) Cut a release

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

4) Create OAuth credentials of type `Desktop app`