Which integrations are available for this server?

Provides read-only access to Google Search Console data, including tools for listing sites, checking sitemap status, running search analytics queries (clicks, impressions, CTR, position), and inspecting URL index status.

How do I use gsc-readonly-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., "@gsc-readonly-mcp show me top search queries for 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.

gsc-readonly-mcp

by brodesigns

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

gsc-readonly-mcp

Read-only MCP server for the Google Search Console API. Search analytics, sitemap status, URL inspection, property listing, nothing else.

Design choice: no write scope, not even gated. No submit_sitemap, no delete_sitemap, no way to change anything in Search Console. If you need those, look elsewhere; this project stays deliberately small so it is easy to audit in one sitting.

Tools

Tool	Does
`list_sites`	Lists every property the service account can access
`list_sitemaps`	Sitemap status for a property (errors, warnings, indexed count)
`search_analytics_query`	Clicks, impressions, CTR, position, grouped by query/page/date/etc.
`inspect_url`	Index status, canonical URL, mobile usability for one URL

Related MCP server: ga-gsc-analytics

Setup

1. Create a service account and download its JSON key

Google Cloud Console → create or select a project.
APIs & Services → Library → enable Search Console API.
APIs & Services → Credentials → Create Credentials → Service Account.
Open the new service account → Keys → Add Key → Create new key → JSON. The file downloads automatically.
Open the file, note the client_email field (...@...iam.gserviceaccount.com).

2. Grant that service account access in Search Console

Search Console → open the property.
Settings → Users and permissions → Add user.
Paste the client_email from step 1. Use Full if you need search_analytics_query (Restricted users hit a permission error on that endpoint), Restricted is enough for list_sites/list_sitemaps.

3. Store the key file somewhere outside any git repo

mkdir -p ~/.config/gsc
mv ~/Downloads/your-key-*.json ~/.config/gsc/service-account.json
chmod 600 ~/.config/gsc/service-account.json

4. Configure your MCP client

Claude Code:

claude mcp add gsc-readonly \
  -e GSC_SERVICE_ACCOUNT_KEY_FILE=~/.config/gsc/service-account.json \
  -e GSC_SITE_URL="https://example.de/" \
  -- npx -y @brodesigns/gsc-readonly-mcp

Or in .mcp.json:

{
  "mcpServers": {
    "gsc-readonly": {
      "command": "npx",
      "args": ["-y", "@brodesigns/gsc-readonly-mcp"],
      "env": {
        "GSC_SERVICE_ACCOUNT_KEY_FILE": "/absolute/path/to/service-account.json",
        "GSC_SITE_URL": "https://example.de/"
      }
    }
  }
}

GSC_SITE_URL is optional; every tool also accepts a site_url argument that overrides it, useful if the same MCP server should cover several properties.

Important: use the property URL exactly as Search Console shows it. Domain properties look like sc-domain:example.de, URL-prefix properties look like https://example.de/. Passing the wrong form fails silently or with a permission error even though the account has access.

Why this exists

Built after a security review of an existing community MCP server for the same API turned up a high-severity-looking automated scan result (mostly false positives on legitimate env-var reads, plus non-runtime dev-dependency CVEs) and a feature set larger than needed for read-only SEO workflows. This project intentionally covers less ground in exchange for being small enough to read end to end in a few minutes.

Security

Two runtime dependencies: @modelcontextprotocol/sdk, google-auth-library (Google's own, minimal auth client), zod for schema validation.
No write scope requested from Google at all (webmasters.readonly).
No telemetry, no network calls beyond the Google APIs listed above.
Scanned with SkillSpector before each release; see SECURITY.md for the latest result, findings reviewed by hand.

License

MIT

Available Tools

4 tools

inspect_urlInspect URLA

Checks the index status of a single URL: is it indexed, what issues does Google report, mobile usability, canonical URL.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	No	Falls back to GSC_SITE_URL if omitted.
`inspection_url`	Yes	Full URL to inspect.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of explaining side effects. 'Checks' implies a read-only operation, but it does not state whether it is side-effect-free, whether auth or GSC property access is needed, or whether it consumes quota. It is not misleading, but it is minimal.

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 one efficient sentence that front-loads the action and then lists the concrete result categories. Every phrase contributes useful information with no redundancy.

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?

For a simple two-parameter inspection tool with no output schema, the description covers the main return aspects (indexed status, issues, mobile usability, canonical URL). It is slightly thin on behavioral context, but nothing essential to calling the tool correctly is missing.

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?

Schema description coverage is 100%, so the schema fully explains both parameters. The description adds no parameter-specific details beyond the schema, only reinforcing that a single URL is inspected.

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 uses a specific verb ('Checks') and a specific resource ('index status of a single URL'), while naming distinct result areas: indexed status, Google-reported issues, mobile usability, and canonical URL. This clearly distinguishes it from sibling tools like list_sites or search_analytics_query.

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 gives clear context: use this when you need the index status and related diagnostics for one specific URL. It does not explicitly name alternatives or exclusions, but the single-URL focus and sibling names make the intended use obvious.

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

list_sitemapsList sitemapsA

Lists all sitemaps submitted to Search Console for a property, including status (errors, warnings, indexed count).

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	No	Property URL, e.g. 'sc-domain:example.de' or 'https://example.de/'. Falls back to GSC_SITE_URL if omitted.

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden, but it does add useful behavioral information such as the sitemap status and indexed counts. It does not discuss pagination, error cases, or whether it returns all sitemaps at once. There is no contradiction with annotations since none were provided, so a 3 is appropriate.

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, dense sentence that covers the core functionality and the status details. It is front-loaded with the main action and resource, and every word adds value. Perfectly 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 one parameter, an optional one, and no output schema or nested objects, the description is reasonably complete. It provides the key outcome (status with errors and warnings), but might benefit from mentioning that the list is for one property and possibly the return format. However, given the simplicity, it's adequate.

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?

The schema describes the site_url parameter completely, including the fallback to GSC_SITE_URL. The description doesn't add extra meaning beyond the schema, but with 100% coverage, this is acceptable. No additional clarification needed, hence baseline 3.

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's purpose: listing sitemaps and their status for a property, with specific attributes (errors, warnings, indexed count). It uses a specific verb 'Lists' and resource 'sitemaps', distinguishing it from siblings like search_analytics_query or inspect_url.

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 when to use it (when needing an overview of sitemap health) but does not explicitly contrast with siblings or state when not to use it. For example, it doesn't say 'use inspect_url for a single URL'. The context is clear without being explicit.

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

list_sitesList Search Console propertiesA

Lists every Google Search Console property the service account has access to.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates the read-only nature implicitly by stating it lists properties, but does not explicitly mention lack of side effects, authentication requirements, rate limits, or pagination. It is adequate but minimal.

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, front-loaded sentence that uses every word efficiently. It communicates the action, resource, and scope without any fluff.

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?

For a tool with no parameters and no output schema, the description covers what it does and its scope. It does not mention return format or potential errors, but for a straightforward list operation the provided information is sufficient for an agent to decide whether to invoke it.

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 tool has zero parameters and the schema is an empty object (100% coverage), so there is nothing to describe. The baseline for zero parameters is 4, and the description adds no redundant parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Lists'), a clear resource ('Google Search Console property'), and a precise scope ('every ... the service account has access to'). It unambiguously distinguishes from siblings like list_sitemaps and inspect_url.

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 clear context about what the tool does, but does not explicitly mention when to use it vs. alternatives or any exclusions. However, the purpose itself is self-evident for a simple listing tool, so the implied usage is sufficient.

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

search_analytics_queryQuery search analyticsA

Clicks, impressions, CTR and position for a date range, grouped by dimensions (e.g. query, page). Core tool for SEO decisions.

ParametersJSON Schema

Name	Required	Description
`end_date`	Yes	YYYY-MM-DD
`site_url`	No	Falls back to GSC_SITE_URL if omitted.
`row_limit`	No	Default: 100
`dimensions`	No	Default: ['query']
`start_date`	Yes	YYYY-MM-DD

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 of disclosing behavioral traits. It states the output metrics and grouping, but it does not disclose that this is a read-only operation, nor does it mention authentication, pagination, rate limits, data freshness, or any side effects. For a query tool with no annotation safety profile, this is a significant gap.

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, concise sentence that front-loads the primary metrics (clicks, impressions, CTR, position) and then specifies the grouping. There is no filler or redundant content; every word earns its place.

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?

The description covers the core output metrics and the grouping behavior, which is essential. However, since there is no output schema, it does not specify the response format (e.g., array of objects with metric keys). It also omits any mention of error handling, site_url fallback behavior (though the schema covers it), or limitations such as data freshness or historical range restrictions. For a tool with five parameters and no annotations, this is adequate but not fully comprehensive.

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?

The schema provides 100% coverage for all five parameters, so the baseline is 3. The description adds context by clarifying that dimensions group the data and the date range defines the period, which enriches understanding of the dimensions and start_date/end_date parameters. However, it does not add syntax or format details beyond what the schema already includes.

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's function: returning clicks, impressions, CTR, and position for a date range, grouped by dimensions. It is distinct from the sibling tools (list_sites, list_sitemaps, inspect_url), which focus on site management and URL inspection, not analytics. The verb 'Query' and resource 'search analytics' are explicit, and the output metrics are enumerated.

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 labels the tool as 'Core tool for SEO decisions,' which implies it is for SEO analysis, but it does not explicitly state when to use it over the sibling tools or when not to use it. There is no mention of alternatives or exclusions, so the guidance is merely implied rather than explicit.

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.

4 tool updatesv0.1.2Sep 26, 2026
- First observedinspect_url
- First observedlist_sitemaps
- First observedlist_sites
- First observedsearch_analytics_query

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

A4/5.0

Scored 2026-09-26 12:55 across 4 tools

Disambiguation5/5

Each tool targets a distinct read-only resource and action: site properties, sitemaps, analytics aggregation, and single-URL inspection. There is no overlap that would make an agent misselect.

Naming Consistency4/5

list_sites and list_sitemaps follow a consistent list_ pattern, and inspect_url is a clear verb_noun action. search_analytics_query deviates slightly by placing 'query' after the resource, but the intent remains obvious.

Tool Count5/5

Four tools is well-scoped for a read-only Google Search Console server. Each tool covers a major API surface area without redundancy or unnecessary expansion.

Completeness5/5

The core read-only Search Console domains are covered: properties, sitemaps, performance data, and URL index inspection. Since write operations are outside the server's stated purpose, there are no meaningful gaps for its intended use.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

SearchConsole.aiOAuth
ai.searchconsole
Read-only Search Console analytics, URL inspection, indexing diagnostics, and sitemaps.
Search Monitoring
2
CrawlRavenOAuth
com.crawlraven
Read Search Console performance, keyword opportunities and annotations for your sites.
Search Monitoring Marketing
1
mcp A
com.googleapis.container
Provides read access to your GKE and Kubernetes resources.
Cloud Platforms Virtualization Monitoring
232
Chad Analytics
com.chadanalytics
Read-only website analytics, AI referrals, crawlers, goals, revenue, and funnels.
Monitoring Marketing
2

Related MCP Servers

gsc-mcp
Marketing Search
rachel-growthlever
A
license
Not graded
quality
C
maintenance
Provides read-only access to Google Search Console data, including search analytics, sitemap status, and URL inspection, for MCP clients like Claude.
Updated a month ago (2026-08-21 15:31 UTC)
3 npm
MIT
ga-gsc-analytics
Data Visualization Marketing
horiiiiii032929
F
license
Not graded
quality
C
maintenance
Enables read-only access to Google Analytics 4 and Google Search Console data, allowing users to run reports, query search analytics, and generate combined snapshots for reporting.
Updated a month ago (2026-08-24 09:44 UTC)
-
google-search-console-mcp
Marketing Search
getmcpads-com
A
license
B
quality
A
maintenance
Enables MCP clients to query Google Search Console search performance, inspect indexing, analyze sitemaps, and run SEO analyses such as cannibalisation detection, query clustering, and wins/losses, all with read-only access.
Updated 14 days ago (2026-09-13 09:44 UTC)
20
230 npm
Apache 2.0
GSC MCP
Search Marketing
muryulia
A
license
A
quality
B
maintenance
Enables read-only access to Google Search Console data, including property discovery, search analytics queries, and URL inspection, through a security-focused interface.
Updated 24 days ago (2026-09-03 06:08 UTC)
3
26 PyPI
MIT