Google Search Console MCP server

What it does

This server lets an agent read a site's Search Console data: clicks, impressions, CTR and position by query, page, country, device or date, the index status of single URLs, and the sitemaps and properties the account can see. It can also add and remove properties and sitemaps, and send Indexing API notifications. It is @mikusnuz/gsc-mcp, an MIT-licensed community package, not one made by Google. Statio runs version 1.3.4 with an OAuth client and a refresh token for the Google account the agent should act as.

Tools

Version 1.3.4 lists 13 tools, and none of them sets annotations. The last column comes from the HTTP call each one makes in the source.

The three Indexing API tools only apply to pages with JobPosting structured data or livestreams with a BroadcastEvent, and the tools make the caller say which. For any other site they have nothing to do, and url_inspection_inspect is the tool for checking whether a page is indexed.

Set it up

You need three values: an OAuth client ID, its secret, and a refresh token for a Google account that has access to the properties.

1. In the Google Cloud console, create or pick a project and enable the Google Search Console API. Enable the Indexing API too only if you publish job postings or livestreams.
2. Set up the OAuth consent screen, then under Credentials create an OAuth client ID. Google's Ads API docs describe the pairing: a Desktop app client works with the gcloud CLI, and a Web application client uses the OAuth 2.0 Playground.
3. Get the refresh token with the scopes the agent needs. With a Desktop client and gcloud:

gcloud auth application-default login \
  --client-id-file=client_secret.json \
  --scopes=https://www.googleapis.com/auth/webmasters.readonly

Google's docs describe webmasters.readonly as read-only access and webmasters as read and write. The package's README asks for webmasters and indexing, but on the refresh token path it never asks Google for scopes itself. The access token gets whatever the refresh token was granted, so the scopes you approve here are the real limit. An agent that only reports needs webmasters.readonly. Add webmasters only for an agent that should submit sitemaps, and indexing only for job or livestream pages. gcloud writes the client_id, client_secret and refresh_token to ~/.config/gcloud/application_default_credentials.json.

Claude Code, directly:

claude mcp add google-search-console \
  -e GSC_CLIENT_ID=your-client-id.apps.googleusercontent.com \
  -e GSC_CLIENT_SECRET=your-client-secret \
  -e GSC_REFRESH_TOKEN=your-refresh-token \
  -- npx -y @mikusnuz/gsc-mcp@1.3.4

Cursor, directly, in ~/.cursor/mcp.json or .cursor/mcp.json:

{
  "mcpServers": {
    "google-search-console": {
      "command": "npx",
      "args": ["-y", "@mikusnuz/gsc-mcp@1.3.4"],
      "env": {
        "GSC_CLIENT_ID": "${env:GSC_CLIENT_ID}",
        "GSC_CLIENT_SECRET": "${env:GSC_CLIENT_SECRET}",
        "GSC_REFRESH_TOKEN": "${env:GSC_REFRESH_TOKEN}"
      }
    }
  }
}

Run directly, the package also accepts a service account through GSC_SERVICE_ACCOUNT_KEY_PATH, a path to the key file. Add the service account's email to each property in Search Console first. The client tutorials, How to add MCP servers to Claude Code and How to set up MCP servers in Cursor, explain config scopes and how to keep the secret and token out of files you commit.

Through Statio: install Google Search Console from the catalog, paste the client ID, client secret and refresh token under the server's Credentials, and grant tools under Permissions. Statio's entry uses the refresh token only, not a service account key file. A new server has no grants, so nobody can call it until you add some. The desktop app then writes your client configs. The manual entry is the local proxy URL with the server name from your dashboard, http://127.0.0.1:7777/google-search-console/mcp, added in Claude Code with claude mcp add --transport http google-search-console <url> or as a "url" in Cursor. Tools missing after that? Start a fresh session, then work through How to debug an MCP server that won't connect.

What to hold back

Start with the account. The refresh token acts as the Google user who approved it, and sites_list returns every property that user can see, for every client if it belongs to an agency or a consultant. No tool grant narrows which property a call reaches. If an agent should see one site, mint the token as an account that has access to that site only.

sites_delete is the write to keep from every agent. Google's reference describes it as removing the site from the user's set of Search Console sites, and an agent that "cleans up old properties" can take a live one out of the account it reports from. sites_add is the quieter version: it fills the account with unverified properties.

sitemaps_delete and sitemaps_submit change what Search Console reports for a site. An agent that deletes the sitemap it thinks is stale, or submits a URL that 404s, leaves errors for whoever reads the report next. Sitemap work is usually a person's job after a deploy, not something an agent needs mid-task.

indexing_publish and indexing_batch_publish draw on the Cloud project's Indexing API quota, which Google sets at 200 publish requests a day by default, and they only apply to job and livestream pages. For any other site, grant neither and leave the indexing scope off the token.

search_analytics_query only reads, but what it reads is commercially sensitive. Query data shows which searches bring you traffic and which pages earn it, and up to 25,000 rows can land in the agent's context in one call. Treat a summary the agent writes from it like any internal report. The queries themselves are typed by the public, so read them as untrusted text like any other input the agent didn't write.

Google rate limits the reads per site and per user: 1,200 Search Analytics calls a minute, and 2,000 URL inspections a day per site. An agent that inspects every URL in a large sitemap uses up the day's inspections for anyone else working on that property.

With Statio you grant each tool separately, so a reporting agent can hold search_analytics_query, url_inspection_inspect and the list tools while no agent holds sites_delete. MCP permissions covers how grants and denies combine.

Questions