Provides read-only access to Google Search Console data, including listing accessible properties, querying Search Analytics for clicks, impressions, CTR, and position, and inspecting the indexed state of URLs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GSC MCP Show me clicks and impressions for example.com over 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 MCP is a small, security-focused Model Context Protocol server for first-party Google Search Console data. It exposes property discovery, Search Analytics, and URL Inspection through the official Google APIs.
The server is structurally read-only: it contains no write tools and requests
only Google's webmasters.readonly OAuth scope.
Tool | Purpose | Google request |
| List accessible Search Console properties |
|
| Query clicks, impressions, CTR, position, and dimensions |
|
| Read the indexed state of a URL |
|
The two POST endpoints are read operations. The implementation blocks site,
sitemap, Indexing API, arbitrary HTTP, and all other non-allowlisted requests.
Every tool is annotated with readOnlyHint=true and destructiveHint=false.
Related MCP server: SearchConsole.ai
Python 3.10 or newer
Google Search Console API enabled for your Google Cloud project
Application Default Credentials (ADC) with access to the properties you query
The read-only OAuth scope:
https://www.googleapis.com/auth/webmasters.readonly
Google's Search Console API requires OAuth 2.0 for private user data. Follow the official Search Console authorization guide and ADC setup guide. Keep OAuth client files, service-account keys, ADC files, and tokens outside the repository.
With uv:
uvx --from gsc-readonly-mcp gsc-mcpWith pipx:
pipx install gsc-readonly-mcp
gsc-mcpWith pip in a virtual environment:
python -m venv .venv
python -m pip install gsc-readonly-mcp
gsc-mcpThe PyPI distribution is named gsc-readonly-mcp; the installed command and
short project name are gsc-mcp / GSC MCP.
git clone https://github.com/muryulia/google-search-console-mcp.git
cd google-search-console-mcp
python -m venv .venv
python -m pip install -e ".[dev]"Run with either:
gsc-mcp
python -m gsc_mcp.serverThe process uses STDIN and STDOUT for MCP protocol messages. Diagnostics go to STDERR and exclude query strings, page rows, tokens, credential contents, and raw Google response bodies.
The server uses Google's standard ADC lookup. Common options are:
local user ADC created with the Google Cloud CLI and the read-only Search Console scope;
a service account that has been granted access to the target Search Console
property, selected through GOOGLE_APPLICATION_CREDENTIALS;
workload credentials in a supported Google Cloud environment.
Example environment variable names are provided in .env.example. The server
does not automatically load .env; pass variables through your shell,
secret manager, or MCP client configuration. Never commit a credential file.
On Windows or a managed network, REQUESTS_CA_BUNDLE or SSL_CERT_FILE may
point to a trusted external CA bundle. TLS verification is never disabled.
See docs/LOCAL_SETUP.md and
docs/TROUBLESHOOTING.md.
When uv is on PATH:
[mcp_servers.gsc_mcp]
command = "uvx"
args = ["--from", "gsc-readonly-mcp", "gsc-mcp"]
env_vars = [
"GOOGLE_APPLICATION_CREDENTIALS",
"SSL_CERT_FILE",
"REQUESTS_CA_BUNDLE",
"GRPC_DEFAULT_SSL_ROOTS_FILE_PATH",
]
enabled_tools = ["list_sites", "query_search_analytics", "inspect_url"]
startup_timeout_sec = 20
tool_timeout_sec = 120Replace the credential path with an external file owned by your user account:
{
"mcpServers": {
"gsc_mcp": {
"command": "uvx",
"args": ["--from", "gsc-readonly-mcp", "gsc-mcp"],
"env": {
"GOOGLE_APPLICATION_CREDENTIALS": "/secure/path/to/credentials.json"
}
}
}
}For a source checkout, point the client at the virtual environment's Python and
use -m gsc_mcp.server.
list_sitesInput is {}. Output preserves Google's exact siteUrl; URL-prefix and
sc-domain: properties are never converted into one another.
query_search_analyticsRequired inputs:
site_url
start_date
end_date
Optional inputs include dimensions, search type, filters, aggregation type, manual pagination, and bounded automatic pagination. One response can contain at most 100,000 rows. CTR remains a raw fraction and position remains Google's average position without rounding. Dates use Pacific Time.
Search Console returns top rows within internal limits and omits anonymized queries. A missing query is not evidence of zero demand, and results must not be described as a complete query universe.
inspect_urlRequired inputs are inspection_url and the exact site_url property;
language_code defaults to en-US. The URL must be under the supplied
property. The server sends it only as data to Google's fixed URL Inspection
endpoint and never fetches the user-supplied URL.
URL Inspection describes the version in Google's index. It is not a live-page test and never requests indexing.
python -m pip install -e ".[dev]"
ruff check src tests scripts
pytest
python -m buildThe test suite verifies the exact three-tool inventory, read-only annotations, fixed endpoint/method allowlist, bounded retries and pagination, property/URL identity, credential-safe errors, TLS enforcement, and real STDIO discovery.
The optional live helper returns a minimized summary and does not print query or page rows:
python scripts/live_acceptance.py \
--site-url "https://example.com/" \
--start-date "2026-07-01" \
--end-date "2026-07-31" \
--inspection-url "https://example.com/"A guarded OpenAI Secure MCP Tunnel workflow is documented in
docs/TUNNEL_SETUP.md. It is optional and is not needed
for ordinary local MCP clients.
GSC MCP is self-hosted. It does not provide a hosted backend, database, telemetry service, or credential store. Data flows between the local MCP client, this local process, and Google's fixed Search Console API endpoints.
Review SECURITY.md before deployment. Please report
vulnerabilities privately through GitHub Security Advisories rather than a
public issue.
Use GitHub Issues
for reproducible bugs and feature proposals. Read CONTRIBUTING.md
before submitting a change. Write-capable tools and broader OAuth scopes are
outside this project's scope.
MIT © 2026 Yuliya Murtazina.
Read-only. Return Google URL Inspection information for the version currently in Google's index. This is not a live URL test and never requests indexing.
| Name | Required | Description | Default |
|---|---|---|---|
| site_url | Yes | Exact Search Console property identifier. | |
| language_code | No | BCP-47 response language. | en-US |
| inspection_url | Yes | Fully-qualified URL under the supplied property. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description explains exactly what the tool returns (currently indexed version) and what it never does (live testing or requesting indexing). This adds meaningful behavioral context to the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the read-only nature front-loaded and each sentence providing distinct value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema, complete parameter descriptions, and annotations, the description covers the essential behavioral distinction from live URL testing. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with clear descriptions for each parameter. The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return Google URL Inspection information for the version currently in Google's index.' It also distinguishes the operation from a live URL test, clearly differentiating it from other possible inspection workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly excludes a key alternative use case: 'This is not a live URL test and never requests indexing.' This gives the agent clear guidance on when not to use the tool, though it does not explicitly name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. List every Google Search Console property available to the current ADC identity, preserving each exact property identifier and permission level.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, and open-world behavior. The description adds valuable context beyond annotations by specifying the identity used for authorization and noting that exact property identifiers and permission levels are preserved in the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that begins with 'Read-only' and communicates scope, identity, and output fidelity without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a rich annotation set, and an output schema, the description covers all necessary context: read-only behavior, identity scope, result scope, and permission-level preservation. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to clarify beyond the schema. The description appropriately focuses on scope and output behavior rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('every Google Search Console property') and scope ('available to the current ADC identity'). It clearly distinguishes itself from siblings like query_search_analytics and inspect_url by focusing on property inventory rather than analytics or URL inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the appropriate context for use: enumerating all accessible properties for the current identity. It does not explicitly mention alternatives or exclusions, but the distinct purpose compared to sibling tools makes the usage context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Query first-party Google Search Console performance data and return named dimensions with clicks, impressions, raw CTR fraction, and Search Console average position. Results are top rows, not a complete query universe.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | ||
| end_date | Yes | Inclusive PT end date in YYYY-MM-DD. | |
| max_rows | No | ||
| site_url | Yes | Exact Search Console property identifier. | |
| fetch_all | No | ||
| row_limit | No | ||
| start_row | No | ||
| dimensions | No | ||
| start_date | Yes | Inclusive PT start date in YYYY-MM-DD. | |
| search_type | No | web | |
| aggregation_type | No | auto |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description need not repeat all of that. It adds non-obvious context by stating results are top rows, not a complete query universe, which complements the openWorldHint annotation. Rate limits and exact result ordering are not covered, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the read-only guarantee, states the operation and outputs efficiently, and adds a meaningful caveat in the final clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The required parameters are described in the schema, the output schema covers return shape, and annotations cover safety traits. However, with 11 parameters, the description leaves important interactions underspecified, especially pagination/fetch_all vs row_limit and how filters are applied, so an agent may need extra inference to invoke the tool optimally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27%, so the description needed to compensate, but it does not. It loosely references 'named dimensions' and 'top rows,' which relates to dimensions and row-limit parameters, but it gives no guidance on filters, search_type, aggregation_type, fetch_all, max_rows, row_limit, or how multiple filters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: query first-party Google Search Console performance data. It also names the return content (named dimensions, clicks, impressions, raw CTR fraction, average position), making it clearly distinct from siblings list_sites 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only framing and 'first-party Google Search Console performance data' give clear context for when this tool is appropriate. It also flags that results are not a complete query universe, which is a useful selection caveat, though it does not explicitly name alternatives 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.
Each tool targets a distinct concern: site discovery, performance querying, and URL inspection. There is no overlap between listing properties, pulling analytics, or checking indexed URL status.
All tool names follow a consistent snake_case verb_noun pattern: list_sites, query_search_analytics, inspect_url. The naming clearly communicates the action and resource.
Three tools is lean but reasonable for a read-only Search Console server focused on core workflows. The count is not excessive, though adding a couple more relevant operations could make the set feel fuller.
The core Search Console needs are covered: site selection, performance data, and URL inspection status. Missing operations like sitemap submission or site management are notable but not critical for a read-only analytics-oriented server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only Search Console analytics, URL inspection, indexing diagnostics, and sitemaps.
SEO analytics from Google Search Console: keyword rankings, clicks, impressions, CTR. Read-only.
Read Search Console performance, keyword opportunities and annotations for your sites.
Provides read access to your GKE and Kubernetes resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/muryulia/google-search-console-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
