Which integrations are available for this server?

Provides read-only access to Google Search Console data, including search performance analytics (clicks, impressions, CTR, position), sitemap status and errors, and URL inspection (index coverage, canonical, mobile usability).

How do I use search-console-mcp?

1. Click on "Deploy 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., "@search-console-mcp show me top queries by clicks for last month" 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.

search-console-mcp

by jurgisgavenas

Overview Schema Source Related Servers Discussions Admin

Python

Remote

search-console-mcp

A read-only Model Context Protocol server for Google Search Console. Point it at a Search Console property and query your search-performance data, sitemaps, and URL index status from any MCP client (Claude Code, Claude Desktop, Cursor, …).

It exists to read and analyze Search Console data — nothing else. It cannot add sites, submit sitemaps, request indexing, or change anything.

Read-only by design

Read-only is enforced at three independent layers, so there is no single point of failure:

OAuth scope. Credentials are always downscoped to https://www.googleapis.com/auth/webmasters.readonly. Google's API rejects any write call made with this scope — regardless of the signed-in account's role. If you mint your credentials with this scope (the helper below does), even a leaked credential file cannot modify your account.
Tool surface. The server only implements read methods. There is no code path that mutates Search Console.
Network surface. The only host contacted is googleapis.com, via Google's official client libraries. No telemetry, no third-party endpoints.

Dependencies are limited to the official mcp, google-api-python-client, and google-auth packages.

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

Tools

Tool	What it returns
`list_sites`	Properties the account can access, with permission level
`search_analytics`	Performance report: clicks, impressions, CTR, position, grouped by query / page / country / device / date / search appearance, with filters
`list_sitemaps`	Sitemaps submitted for a property
`get_sitemap`	Index status and errors for one sitemap
`inspect_url`	URL Inspection: index coverage, last crawl, canonical, mobile usability (tight per-property quota)

Setup

1. Enable the API

In a Google Cloud project, enable the Google Search Console API.

2. Mint read-only credentials

Create an OAuth Desktop app client in that project and download its JSON. Then:

pip install "search-console-mcp[auth]"   # provides google-auth-oauthlib

python scripts/mint_token.py \
    --client-secrets /path/to/oauth_client.json \
    --output /path/to/gsc-readonly-credentials.json

A browser opens — sign in as the account that has access to the Search Console properties you want to read. Viewer / Restricted access is enough. The output file is an authorized-user credential limited to the read-only scope.

A service-account key also works (no minting step) — just set GOOGLE_APPLICATION_CREDENTIALS to it and add the service-account email as a user on each property. The OAuth path above is recommended for personal use.

3. Register the server

uvx runs it without an explicit install:

{
  "mcpServers": {
    "search-console": {
      "type": "stdio",
      "command": "uvx",
      "args": ["--from", "search-console-mcp", "search-console-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/gsc-readonly-credentials.json"
      }
    }
  }
}

See .mcp.json.example. Restart your MCP client, and the five tools above become available.

Develop

uv sync
uv run search-console-mcp   # starts the stdio server

License

MIT — see LICENSE.

Available Tools

5 tools

get_sitemapA

Returns details for a single sitemap, including index status and errors.

Args: site_url: Property URL, e.g. sc-domain:example.com. feedpath: Full URL of the sitemap, e.g. https://example.com/sitemap.xml.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes
`feedpath`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided. The description discloses that it returns 'index status and errors' but does not mention side effects (likely none), permissions, or rate limits. It provides moderate transparency for a read operation.

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 very concise: a single purpose sentence followed by parameter documentation. Every sentence adds value, and the structure is front-loaded. No unnecessary words.

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?

The description is largely complete for a simple getter tool with two parameters and no output schema. It explains what is returned and provides parameter examples. It does not cover error scenarios or permissions, but given the tool's simplicity, it is nearly complete.

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?

Schema coverage is 0%, but the description adds meaningful details: site_url example 'sc-domain:example.com' and feedpath example 'https://example.com/sitemap.xml'. This clarifies the expected format and adds value beyond the schema's property names.

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 'Returns details for a single sitemap, including index status and errors.' The verb 'Returns' and resource 'single sitemap' are specific. It distinguishes from the sibling list_sitemaps which lists multiple sitemaps.

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?

Usage context is implied but not explicitly stated. The description assumes the user has a specific sitemap URL. No guidance on when to use this tool versus alternatives like inspect_url or list_sitemaps, nor any prerequisites or exclusions.

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

inspect_urlA

Inspects a URL's index status via the URL Inspection API (read-only).

Reports Google's index coverage, last crawl, canonical, mobile usability, and rich-results state for a single URL. Subject to tight per-property daily quotas set by Google.

Args: site_url: Property URL the inspected URL belongs to, e.g. sc-domain:example.com. inspection_url: The fully-qualified URL to inspect. language_code: BCP-47 language code for the result, default en-US.

ParametersJSON Schema

Name	Required	Default
`site_url`	Yes
`inspection_url`	Yes
`language_code`	No	en-US

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description discloses read-only nature, reports various data, and tight per-property quotas. It does not cover error handling or rate limits explicitly, but the quota warning adds useful transparency.

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?

Description is front-loaded with purpose, followed by reported data, a quota note, and parameter definitions. Every sentence serves a purpose without redundancy.

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?

Despite no output schema, description covers main behavioral aspects and parameter details. However, it lacks information on return format, error scenarios, or interpretation of results, limiting completeness for a 3-param tool.

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?

With 0% schema coverage, description adds value by providing an example for site_url, describing inspection_url as fully-qualified, and noting language_code default. This goes beyond schema's basic type info.

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 inspects a URL's index status via the URL Inspection API, listing specific data points (index coverage, last crawl, etc.). It is distinct from sibling tools like get_sitemap or search_analytics.

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 for checking a single URL's status but does not explicitly compare to siblings or state when not to use it. The quota mention provides context, but guidance is indirect.

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

list_sitemapsA

Lists the sitemaps submitted for a property.

Args: site_url: Property URL, e.g. sc-domain:example.com.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes

TDQS

A3.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 omits behavioral traits such as read-only nature, permission requirements, rate limits, or pagination. The agent lacks critical information about the tool's behavior.

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 short and front-loaded with the main action. The 'Args:' section is somewhat redundant given the schema, but overall it remains concise and focused.

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?

While the tool is simple with one parameter, the description does not specify the return format, pagination, or any limits. With no output schema, the agent lacks complete information to handle the response.

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?

The description adds value by explaining the site_url parameter with an example (sc-domain:example.com), supplementing the sparse schema where schema description coverage is 0%. This clarifies the expected input format.

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 lists sitemaps for a property, with a specific verb and resource. It is distinct from sibling tools like get_sitemap, which likely retrieves details of a single sitemap.

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 provides an example of the site_url format but does not specify when to use this tool versus alternatives like get_sitemap or inspect_url. Usage context is implied but not explicit.

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

list_sitesA

Lists all Search Console properties the authenticated account can access.

Returns each site's URL (e.g. sc-domain:example.com or https://example.com/) and the permission level on it.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Despite no annotations, the description discloses that the tool returns each site's URL and permission level. It does not mention pagination or rate limits, but for a simple list with no parameters, this is sufficient.

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 with no filler. First sentence front-loads the purpose, second provides additional return details. Every word earns its place.

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 no output schema, the description is complete. It specifies the output (URL and permission level) and the scope (authenticated account's accessible properties).

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?

No parameters exist, so schema description coverage is 100%. Baseline score of 3 applies; description does not need to add parameter details.

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 it lists Search Console properties the authenticated account can access, with specific verb 'Lists' and resource 'Search Console properties'. Distinguishes from sibling tools that deal with sitemaps, URLs, or analytics.

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 on when to use this tool versus alternatives. For example, it does not recommend using it before other tools like search_analytics to obtain site URLs.

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

search_analyticsA

Queries Search Console search-performance data (the Performance report).

Args: site_url: Property to query, exactly as it appears in Search Console, e.g. sc-domain:example.com or https://example.com/. start_date: Inclusive start date, YYYY-MM-DD. end_date: Inclusive end date, YYYY-MM-DD. dimensions: Group-by dimensions. Any of: query, page, country, device, date, searchAppearance. Omit for account totals. search_type: One of web, image, video, news, discover, googleNews. row_limit: Rows to return, 1-25000 (default 1000). start_row: Zero-based offset for pagination (default 0). dimension_filters: Optional list of filters, each a dict with keys dimension, operator (equals, contains, notContains, includingRegex, excludingRegex), and expression. data_state: final (default, finalized data) or all (includes fresh, not-yet-finalized data).

Returns: The raw API response, including a rows list with keys, clicks, impressions, ctr, and position.

ParametersJSON Schema

Name	Required	Default
`site_url`	Yes
`start_date`	Yes
`end_date`	Yes
`dimensions`	No
`search_type`	No	web
`row_limit`	No
`start_row`	No
`dimension_filters`	No
`data_state`	No	final

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions the data_state parameter for data freshness but does not disclose rate limits, authorization requirements, error handling, or side effects. The return format is described minimally.

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 a well-structured docstring with a brief overview and parameter list. It is efficient but could be slightly more concise by integrating parameter descriptions into a narrative. However, it remains clear and organized.

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?

With 9 parameters, no output schema, and no annotations, the description covers parameter semantics and basic return shape. It mentions pagination via start_row but lacks information on error behavior, rate limits, or field-level output details. Adequate but incomplete.

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?

The input schema has 0% description coverage, but the tool's description provides detailed explanations for each parameter, including examples (e.g., site_url formats), allowed values (dimensions, search_type), and default behaviors. This fully compensates for the schema gap.

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 queries Search Console search-performance data (the Performance report), with a specific verb and resource. It distinguishes from sibling tools (get_sitemap, inspect_url, etc.) by focusing on analytics 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, nor any when-not-to-use conditions. The description implies usage for performance data but lacks context on prerequisites or exclusions.

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.

5 tool updatesv0.1.0Jun 23, 2026
- First observedget_sitemap
- First observedinspect_url
- First observedlist_sitemaps
- First observedlist_sites
- First observedsearch_analytics

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-23 12:30 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect of Search Console: site listing, sitemap management, URL inspection, and analytics queries. No overlap in functionality.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern with lowercase and underscores: list_sites, list_sitemaps, get_sitemap, inspect_url, search_analytics. Perfectly consistent.

Tool Count4/5

5 tools is appropriate for a focused Search Console integration. It covers the core read operations without being overly heavy, though a few more write tools could be added.

Completeness3/5

The toolset covers listing, inspection, and analytics but lacks write operations like adding sites or submitting sitemaps, leaving notable gaps for full property management.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CalmSEOOAuth
com.calmseo
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Marketing Search
2
mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3

Related MCP Servers

gsc-mcp
Search Monitoring
jayrockliffe-defused
A
license
A
quality
C
maintenance
MCP server for querying Google Search Console data — search analytics, URL inspection, sitemap monitoring, and more — read-only tools for any MCP-compatible AI client.
Updated 5 months ago (2026-04-25 02:34 UTC)
7
Apache 2.0
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 4 days ago (2026-09-10 20:58 UTC)
MIT
mcp-gsc
Search Marketing
pijusz
A
license
Not graded
quality
A
maintenance
MCP server for Google Search Console, enabling querying search analytics, URL inspection, sitemap management, and more via natural language.
Updated a month ago (2026-07-31 13:27 UTC)
260 npm
1
MIT
gsc-mcp-server
Search Marketing
jlnkrth
A
license
A
quality
B
maintenance
MCP server for Google Search Console, enabling querying search performance, listing properties, and inspecting URL indexing status from MCP-compatible clients.
Updated 3 months ago (2026-06-23 18:55 UTC)
4
14 npm
1
MIT