Which integrations are available for this server?

Provides tools to query Google Search Console for search performance data, list properties, and inspect URL indexing status.

How do I use gsc-mcp-server?

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., "@gsc-mcp-server List my Search Console properties" 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-server

by jlnkrth

Overview Schema Related Servers Score Discussions

JavaScript

Local

gsc-mcp-server

npm version

MCP server for Google Search Console. Query search performance, list properties, inspect URLs, and list sitemaps from Cursor, Claude Desktop, or any MCP-compatible client.

npm: @jlnkrth/gsc-mcp-server

Use the scoped package name @jlnkrth/gsc-mcp-server. The unscoped name gsc-mcp-server on npm is a different package.

Quick start

Situation	Auth	Run MCP server
Cloned this repo (inside project folder)	`npm run auth`	`npm start`
Installed from npm (any other directory)	`npx -y -p @jlnkrth/gsc-mcp-server gsc-mcp-auth`	`npx -y @jlnkrth/gsc-mcp-server`

Set GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET before auth (see Google Cloud setup).

Using a Google passkey to sign in? That's fine — passkey only applies to signing into Google in the browser during auth. You still need your own GCP OAuth client ID and secret.

Related MCP server: mcp-gsc

Tools

Tool	Description
`gsc_list_sites`	List Search Console properties accessible to your Google account
`gsc_search_analytics`	Query clicks, impressions, CTR, and position with dimensions and filters
`gsc_inspect_url`	Inspect a URL's index status, crawl state, and mobile usability
`gsc_list_sitemaps`	List submitted sitemaps with status, errors, and indexed counts

`gsc_search_analytics` filters

Parameter	Description
`query_filter`	Shorthand: queries containing this string
`page_filter`	Shorthand: page URLs containing this string
`dimension_filters`	Full GSC filter objects (advanced)

Prerequisites

Node.js 18+
A Google Cloud project with the Search Console API enabled
An OAuth 2.0 Desktop client (client ID + secret)
A Google account with access to the Search Console properties you want to query

Google Cloud setup

Go to Google Cloud Console.
Create or select a project.
Open APIs & Services → Library and enable Google Search Console API.
Open APIs & Services → OAuth consent screen — configure the consent screen. If the app is in Testing mode, add your Google account under Test users or sign-in will fail.
Open APIs & Services → Credentials → Create Credentials → OAuth client ID.
Application type: Desktop app.
Add http://localhost:3336/callback as an authorized redirect URI (if prompted).
Copy the Client ID and Client secret.

Install and authenticate

From npm

export GOOGLE_CLIENT_ID="your-client-id.apps.googleusercontent.com"
export GOOGLE_CLIENT_SECRET="your-client-secret"

npx -y -p @jlnkrth/gsc-mcp-server gsc-mcp-auth

From source

git clone https://github.com/jlnkrth/gsc-mcp-server.git
cd gsc-mcp-server
npm install

cp .env.example .env
# Edit .env with your credentials, then:
export $(grep -v '^#' .env | xargs)
npm run auth

The auth flow opens a browser on port 3336. Tokens are saved to ~/.config/gsc-mcp/tokens.json by default (override with GSC_TOKEN_PATH).

MCP client configuration

Cursor

Add to ~/.cursor/mcp.json (merge with existing servers):

{
  "mcpServers": {
    "google-search-console": {
      "command": "npx",
      "args": ["-y", "@jlnkrth/gsc-mcp-server"],
      "env": {
        "GOOGLE_CLIENT_ID": "YOUR_CLIENT_ID",
        "GOOGLE_CLIENT_SECRET": "YOUR_CLIENT_SECRET",
        "GSC_TOKEN_PATH": "/Users/you/.config/gsc-mcp/tokens.json"
      }
    }
  }
}

Keep mcp.json private — it contains your OAuth client secret. Do not commit it to git.

For local development, point command at Node directly:

{
  "mcpServers": {
    "google-search-console": {
      "command": "node",
      "args": ["/absolute/path/to/gsc-mcp-server/src/index.js"],
      "env": {
        "GOOGLE_CLIENT_ID": "YOUR_CLIENT_ID",
        "GOOGLE_CLIENT_SECRET": "YOUR_CLIENT_SECRET"
      }
    }
  }
}

See examples/cursor-mcp.json.

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (see examples/claude-desktop.json).

After changing MCP config, fully quit and restart your client so the server reloads tokens.

Example prompts

Once connected, you can ask your AI assistant:

"List my Search Console properties"
"What are the top 20 queries by clicks for https://example.com/ in the last 28 days?"
"Show me blog pages with the most impressions last week" (use page_filter)
"Is https://example.com/blog/my-post indexed?"
"List sitemaps for sc-domain:example.com"

Environment variables

Variable	Required	Description
`GOOGLE_CLIENT_ID`	Yes	OAuth 2.0 Desktop client ID
`GOOGLE_CLIENT_SECRET`	Yes	OAuth 2.0 Desktop client secret
`GSC_TOKEN_PATH`	No	Token file path (default: `~/.config/gsc-mcp/tokens.json`)
`GOOGLE_LOGIN_HINT`	No	Pre-fill email in the OAuth browser sign-in

Troubleshooting

Symptom	Fix
`Not authenticated`	Run `npx -y -p @jlnkrth/gsc-mcp-server gsc-mcp-auth` (or `npm run auth` if inside a clone), then restart your MCP client
`npx` fails inside cloned repo	Use `npm run auth` / `npm start` locally, or run `npx` from another directory
Google sign-in fails / access denied	If OAuth app is in Testing mode, add your Google account as a test user in GCP
No `refresh_token` in saved tokens	Revoke the app at Google Account permissions, then re-run auth
Port 3336 in use	Free the port or stop the conflicting process, then re-run auth
`403` / permission denied on API calls	Confirm the signed-in Google account has access to the property in Search Console
MCP client can't find `npx`	Use the full path to `node` and `src/index.js` in your config
Google OAuth fails after passkey sign-in	`GOOGLE_CLIENT_ID` / `SECRET` must be real GCP values — not placeholders. Check redirect URI `http://localhost:3336/callback`

Google Analytics MCP — official GA4 server
DataForSEO MCP — official DataForSEO server

Contributing

See CONTRIBUTING.md for local development, tests, and publishing.

License

MIT

Available Tools

4 tools

gsc_inspect_urlA

Inspect a URL's indexing status in Google Search Console. Shows whether the URL is indexed, crawl issues, and mobile usability.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes	Site URL as registered in GSC
`inspection_url`	Yes	The full URL to inspect

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, but the description discloses the key outputs: indexing status, crawl issues, and mobile usability. It does not mention any side effects or prerequisites, though this is a read-only inspection.

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

Conciseness5/5

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

Two sentences, front-loaded with the action, and every clause provides useful information 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 simple two-parameter tool with no output schema, the description is complete enough: it states what the tool does and what information it returns.

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 coverage is 100%, with both parameters having clear descriptions. The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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 'Inspect' and names the resource 'a URL's indexing status in Google Search Console', clearly distinguishing it from siblings like listing sites, search analytics, and 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?

The description implies the tool is for checking individual URL indexing, but it does not explicitly state when to use it over alternatives or any exclusions. Clear enough for basic use, but no direct guidance.

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

gsc_list_sitemapsA

List all sitemaps submitted for a site in Google Search Console. Returns paths, types, dates, and errors/warnings.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes	Site URL as registered in GSC

TDQS

A4/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 does state the return values (paths, types, dates, errors/warnings), which is useful, but it does not mention prerequisites such as site verification/auth, potential rate limits, or failure modes. This is a typical read operation, but the lack of such context leaves a 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 efficiently conveys the tool's purpose and return content. Every word adds value, and there is no redundancy or 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?

Given the tool's low complexity (one required parameter, no output schema) and the description's mention of return fields, the description is fairly complete. However, it could have noted that the site_url must be a verified property in GSC, which is a relevant prerequisite for usage. This slight omission prevents a perfect score.

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 has 100% coverage for the single parameter site_url, which is described as 'Site URL as registered in GSC'. The tool description does not add significant extra meaning beyond that, except for implying the sitemaps are submitted for that site. Since the schema already documents the parameter, a baseline of 3 is appropriate.

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 purpose: listing all sitemaps submitted for a site in Google Search Console, and specifies the return content (paths, types, dates, errors/warnings). This distinguishes it from sibling tools like gsc_list_sites, which list sites, and gsc_search_analytics, which handles 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 Guidelines4/5

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

The description provides clear context that the tool is for listing sitemaps of a specific site, but it does not explicitly mention when to use it over alternatives or indicate any exclusions. Given the specificity of the tool name and description, usage is implied; however, no direct guidance on choosing this vs sibling tools is provided.

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

gsc_list_sitesA

List all sites (properties) in Google Search Console accessible to the authenticated Google account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses that the tool lists sites accessible to the authenticated account, indicating a read-only, authenticated operation. It does not detail return format or pagination, but for a simple list tool the behavior is adequately transparent.

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

Conciseness5/5

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

The single sentence is concise, front-loaded, and contains no filler. Every word adds value, making it an exemplary minimal description.

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?

Given the tool's simplicity—no parameters, no nested objects, no output schema—the description fully covers its function. Contextual completeness is high for the scope of the 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?

The tool has zero parameters, so the baseline is 4. The description correctly avoids parameter details, as there are none to document.

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 action (list), the resource (sites/properties), and the scope (all accessible to the authenticated account). It distinguishes from siblings like gsc_search_analytics and gsc_list_sitemaps by specifying a distinct resource and operation.

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 its use for enumerating sites but does not explicitly state when to use it over alternatives. The sibling tools have distinct purposes, so usage is implied rather than guided.

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

gsc_search_analyticsB

Query Google Search Console search analytics. Returns clicks, impressions, CTR, and position. Dimensions: query, page, country, device, date, searchAppearance.

ParametersJSON Schema

Name	Required	Description
`type`	No	Search type: 'web' (default), 'image', 'video', 'news', 'discover', 'googleNews'
`end_date`	Yes	End date (YYYY-MM-DD)
`site_url`	Yes	Site URL as registered in GSC (e.g. 'https://example.com/' or 'sc-domain:example.com')
`row_limit`	No	Max rows (default 100, max 25000)
`start_row`	No	Starting row for pagination (default 0)
`dimensions`	No	Dimensions to group by: 'query', 'page', 'country', 'device', 'date', 'searchAppearance'
`start_date`	Yes	Start date (YYYY-MM-DD)
`page_filter`	No	Filter pages whose URL contains this string
`query_filter`	No	Filter search queries containing this string (case-insensitive)
`dimension_filters`	No	Optional filters, e.g. [{"dimension":"query","operator":"contains","expression":"keyword"}]

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full transparency responsibility. It does not state whether the operation is read-only, what permissions are required, how pagination works, or what the response structure looks like. It only mentions output metrics and dimensions, adding minimal behavioral context beyond the schema.

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 short and efficient, with three sentences covering the main action, the return values, and the dimensions. Each sentence adds essential information without redundancy or filler, and the main verb is front-loaded.

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?

The tool has 10 parameters, no output schema, and no annotations, yet the description is only a few sentences. It omits guidance on required parameters, pagination behavior, filtering capabilities, and response structure. The schema covers parameter semantics, but the description fails to provide the broader context needed for effective tool use.

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 all parameters are individually documented. The description restates the dimension list but adds no extra meaning about parameter usage, formats, defaults, or interactions beyond what the schema already provides.

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 queries Google Search Console search analytics and lists the returned metrics (clicks, impressions, CTR, position) and available dimensions. This distinguishes it from sibling tools like gsc_list_sites and gsc_inspect_url, which handle site lists and URL inspection rather than 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 Guidelines3/5

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

The description implies use for search analytics queries but does not explicitly state when to use it versus alternatives or provide exclusions. It does not reference any sibling tools or offer guidance on when this tool is preferred, so usage context is only implied.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource in Google Search Console: sites, search analytics, URL inspection, and sitemaps. There is no functional overlap, so an agent can easily select the correct tool for a task.

Naming Consistency5/5

All tool names follow the consistent pattern gsc_<verb>_<object> (e.g., gsc_list_sites, gsc_search_analytics). The prefix 'gsc_' and snake_case are applied uniformly, making the naming predictable.

Tool Count5/5

With only 4 tools, the server is tightly scoped to the core read-only operations of Google Search Console. Each tool earns its place, and the count feels appropriate for the service's purpose.

Completeness5/5

The set covers the primary GSC data surfaces: site enumeration, performance analytics, URL indexing status, and sitemap information. No obvious gaps exist for typical read-only use cases, making the surface complete.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

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-serp
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
CalmSEO
com.calmseo
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Marketing Search
2
google-ads
ai.adramp
Google Ads MCP server — manage campaigns, keywords, and metrics.
Marketing E-commerce & Retail
2
Serper A
io.github.pipeworx-io
Serper MCP — wraps the Serper Google Search API (serper.dev)
Search RAG Systems
342

Related MCP Servers

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 a day ago (2026-09-01 01:04 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)
267
1
MIT
search-console-mcp
Search Monitoring
jurgisgavenas
A
license
A
quality
C
maintenance
A read-only MCP server for Google Search Console that lets you query search performance data, sitemaps, and URL index status from any MCP client.
Updated 2 months ago (2026-06-23 10:56 UTC)
5
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 2 months ago (2026-07-15 20:12 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/jlnkrth/gsc-mcp-server'

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

gsc-mcp-server

Quick start

Tools

gsc_search_analytics filters

Prerequisites

Google Cloud setup

Install and authenticate

From npm

From source

MCP client configuration

Cursor

Claude Desktop

Example prompts

Environment variables

Troubleshooting

Related MCP servers

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`gsc_search_analytics` filters