Google Search Console MCP: giving Claude or Cursor your search data

Without it, a coding agent sees your code and nothing about how Google shows your pages. With it, the agent gets tools that call the Search Console API on your behalf and return rows it can read, sort and compare with the files it is editing.

Most servers wrap two parts of the API. The Search Analytics query method returns clicks, impressions, click-through rate and position, broken down by any of six dimensions: date, query, page, country, device and search appearance. The URL Inspection API returns Google's index status for one URL of a property you have verified.

Property names trip people up. A domain property is written sc-domain:yourproduct.com. A URL-prefix property is the full URL with a trailing slash, such as https://www.yourproduct.com/. Tell the agent which one you verified, or its first calls will fail with a permission error.

Pick by what you want the agent to do. For "which queries is /pricing shown for", raw rows are enough, and the local route costs nothing but setup time. For "what should I change first", rows are only the start: someone, the agent or a product, has to compare periods, pages and rivals first. As an example of the third route, Porteur exposes a bought report, which includes your Search Console figures when connected, over MCP at https://porteur.ai/mcp with a key from Settings.

Before installing any open-source server, read its code or at least its README and the scope it requests. It will hold a token to your Search Console data.

The steps are the same for every local server, whatever its language. Its README gives the exact command and the variable it reads for credentials.

1. 1

   Create a Google Cloud project

   In the Google Cloud console, create a project just for this, such as "search-console-mcp". Keeping it separate makes it easy to delete later.

2. 2

   Enable the Search Console API

   In the API library of that project, find the Google Search Console API and enable it.

3. 3

   Configure the consent screen

   Set up the OAuth consent screen as an external app in testing, and add your own Google account as a test user. Nobody else needs access.

4. 4

   Create an OAuth client

   Create an OAuth client ID of type Desktop app and download its JSON. Save it outside every repository, for example in ~/.config/gsc/, never in the project folder.

5. 5

   Ask for the read-only scope

   If the server lets you choose, set the scope to https://www.googleapis.com/auth/webmasters.readonly. An agent that reads data has no reason to hold write access to your properties.

6. 6

   Add it to your agent and sign in

   Register the server with Claude Code or Cursor, as below. On the first call it opens a browser window for Google's consent; approve it with the account that has access to the property.

In Claude Code, one command adds the server. Keep it in the default local scope while it holds anything secret:

# Claude Code, local scope (the default): stored in ~/.claude.json, never committed
claude mcp add gsc -- <command> [args]

# a remote server instead
claude mcp add --transport http gsc <url> --header "Authorization: Bearer <token>"

# check it is connected
claude mcp list

Cursor reads MCP servers from .cursor/mcp.json in the project, or ~/.cursor/mcp.json for all projects. Use the file in your home folder when the entry points to credentials:

{
  "mcpServers": {
    "gsc": {
      "command": "<command>",
      "args": ["<args>"],
      "env": {
        "<VARIABLE_THE_SERVER_READS>": "/Users/you/.config/gsc/client_secret.json"
      }
    }
  }
}

Test it with one plain request: "list the Search Console properties you can access". If your site is in the answer, the setup works.

The value is in asking questions the Search Console interface makes slow, and then acting on the answer in the same session. These six cover most of what a small site needs. Paste the block, then work through the answers one page at a time.

Property: sc-domain:yourproduct.com. Period: the last 28 days unless I say otherwise.

1. List the pages with an average position between 4 and 20, sorted by impressions.
   For each, give the three queries with the most impressions and their position.

2. Find queries with many impressions and a click-through rate well below the site's
   average. For each, the page shown and its current title.

3. Compare the last 28 days with the 28 days before. Which pages lost the most
   impressions, and which queries account for the loss?

4. List queries the site is shown for that no page title or h1 in this repository
   mentions. Read the titles from the code, then compare.

5. For /pricing, break down clicks and impressions by device and by country.

6. Inspect https://yourproduct.com/pricing with URL Inspection: what is its index status?

Use only figures returned by the Search Console tools. If a question needs data they
do not return, say so instead of estimating.

The first prompt finds pages close to the first page of results, where a clearer title or a better opening paragraph can move them. The second finds titles that are shown but not chosen. The third catches pages sliding before the fall shows in your signups. The fourth is the one only an agent in your repository can answer: it holds the search data and the code side by side, and finds searches you are shown for by accident that deserve a page's title and first paragraph.

Then act on one answer. "The page /guides/csv-import is shown for 'import csv into postgres' at position 12; rewrite its title and first paragraph for that query, and change nothing else" is a task the agent can do and you can judge 28 days later.

Search Console knows your site and nothing else. The server inherits every limit of the data behind it.

• Who else ranks for a query, and what their pages say. Search Console never shows other sites.
• How many people search for something. Impressions count how often your page was shown, not the size of the search.
• Searches you do not appear for at all. If no page of yours is shown, the query is not in your data.
• Anything about rare or anonymised queries, which are left out of the rows.
• The last two or three days, and anything older than sixteen months.

An agent asked one of these questions may still answer from memory. Put a line in your instructions, as in the prompts above, that it must use only figures returned by the tools and say when it has none.

• Use the read-only scope, webmasters.readonly. Full access lets a program submit and delete sitemaps and add or remove properties.
• Keep the OAuth client JSON and the token the server stores outside any repository, and add their folder to .gitignore if it is anywhere near one.
• Never put a token in .mcp.json. Project scope in Claude Code writes that file at the repository root and it is committed. Tokens belong in environment variables or the local scope.
• For a hosted connector, know who runs it, what it stores and how you revoke access. You can remove its access from your Google Account's security settings at any time.
• Remove servers you no longer use. Each one is a live token to your data.