Google Search Console MCP: How to Connect Your Search Data to an AI Agent

Last week I opened my own Search Console and found this: "google search console mcp" with 69 impressions, an average position of 66.7 and zero clicks. "search console mcp" had 44 impressions at 64.5. Also zero clicks.

Google was testing my site for a topic I had never written about. Lovely.

That is exactly the kind of thing I want an AI to find for me. Not by exporting a CSV, pasting it into a chat and hoping the model reads the right column. By asking the question and letting the agent pull the rows itself.

That is what a Google Search Console MCP setup gives you: your Google Search Console data, inside natural language conversations with your AI client.

The short version: a Search Console MCP server wraps the Search Console API as tools your AI client, or any AI agents you build, can call. You connect it once, then ask questions like "which pages lost clicks this month?" in plain English. The model still has to interpret the numbers correctly, which is where most of the problems live.

If you are new to MCP, start with my guide to building an MCP server. If you already know the basics, carry on.

What a Search Console MCP Server Actually Does

Model Context Protocol (MCP) is an open standard that lets an AI client call external tools during a conversation. An MCP server is the bit that exposes those tools. An MCP client is the app you talk to: Claude Desktop, Claude Code, Cursor, Codex CLI and friends.

A Search Console MCP server sits between that client and the Search Console API. When you ask a question, the client sends a tool call (something like search_analytics). The server turns it into an API request against your search console property, gets the returned data and hands it back as structured JSON. The model then reads that JSON and answers you.

AI client → MCP server → Search Console API → your search data

That is the whole trick. The data source does not change. The search analytics data is the same data you see in the Google Search Console UI. You just stop being the person who copies it around.

Typical tools on a GSC MCP server:

• List sites. Returns every property your Google credentials can see, with the exact site URL format to use.

• Search analytics. Clicks, impressions, CTR and average position, filtered and grouped by query, page, country, device and date. This is the one you will use 90% of the time.

• URL inspection. Indexing status, last crawl info and the Google-selected canonical for a single URL.

• Sitemap tools. List sitemaps, read a specific sitemap and see the errors and warnings on your submitted sitemaps.

One thing to be clear about: as far as I can tell, Google has not shipped an official Search Console MCP server. Every one you will find is community-built or comes from a vendor. That is fine, but it means you are trusting someone else's code with your Google credentials, so read it before you run it.

Two Ways to Connect Google Search Console to an AI Agent

There are two sensible routes. Both get your Search Console data into a conversation with an AI. The difference is who does the plumbing.

Option 1: install a Search Console MCP server yourself. You run an open-source server, set up a Google Cloud project and plug it into Claude Desktop, Claude Code, Cursor or Codex CLI. Free, fully under your control, and about 20 to 30 minutes of fiddling the first time.

Option 2: use a Search Console agent in Fetch Hive. Sign in, connect Search Console with one OAuth click and start asking questions. A few minutes, no Google Cloud project, no JSON files.

There is also a middle ground: hosted MCP connectors from other vendors. Remote MCP servers run over HTTP, so you paste a URL into your client, approve access with Google and you are done. The catch is that a third party now stores an OAuth token that can read every property your account can see, so check what scopes it asks for before you click allow.

I will walk through Option 1 first, because it shows every moving part. If you would rather skip the Google Cloud setup, jump straight to Option 2.

Option 1: Install a Search Console MCP Server Yourself

You run the server on your own machine over stdio, and the AI client starts it as a subprocess. Your credentials never leave your laptop. My self-hosted MCP server guide covers the general trade-offs of running servers locally.

What You Need Before You Start

• A Search Console property. Either a URL-prefix property (https://www.example.com/) or a domain property (sc-domain:example.com).

• A Google Cloud project. Free. You need it to enable the API and create credentials.

• An MCP client. Claude Desktop, Claude Code, Cursor or Codex CLI all work with local MCP servers.

• Node.js or Python, depending on the server you pick.

Step 1: Enable the Search Console API in Google Cloud

Open the Google Cloud Console in a browser window and create a new Google Cloud project, or pick an existing one. Make a note of the project ID. You will want it later if Google complains about a quota project.

Go to APIs & Services, then Library, search for "Google Search Console API" and click Enable.

That is it for this step. Skip this and every call fails with an authorization error, however perfect your credentials are.

A quick correction to something you will see in a lot of guides: you do not need the Indexing API. Google only supports it for pages with JobPosting or BroadcastEvent structured data. It is not a general "please recrawl my blog post" button, and indexing tools that pretend otherwise are setting you up for disappointment.

Step 2: Pick an Authentication Method

You have two choices of authentication method. Both work. They suit different people.

OAuth client (sign in as yourself). Best for a solo practitioner or a small team. Your access matches your existing Search Console permissions.

1. Configure the OAuth consent screen under APIs & Services. Add yourself as a test user.

2. Go to the credentials page, choose Create Credentials, then OAuth client ID.

3. Select desktop app as the application type.

4. Download the JSON file. That is your OAuth client.

The first time the server runs, a browser window opens, you approve access, and it saves a token so future sessions skip the login. Only you should be able to read that token file.

If you already use the gcloud CLI, some servers also accept application default credentials. If you see a "requires a quota project" error with those, run gcloud auth application-default set-quota-project with your project ID.

Service account (machine credentials). Better for agencies, scheduled jobs and anything that runs without a person around.

1. In IAM & Admin, create a service account.

2. Open it, go to the keys tab, add a key and choose JSON.

3. Copy the service account email.

4. In Search Console, open Settings, then Users and permissions, and add that email as a user on each property.

Service account authentication is less fiddly once it works, because there is no consent screen and no token refresh. The trade-off is a long-lived key file sitting on disk. Treat it like a password.

Some READMEs tell you to add the service account as a project administrator or owner. For reading performance data you do not need that. Give it the least access that does the job.

Step 3: Install a Search Console MCP Server

There are plenty of options on GitHub. Two I would look at:

• ahonn/mcp-server-gsc: Node.js, service account, one well-documented search analytics tool with row limits up to 25,000 and a "quick wins" mode.

• metehan777/google-search-console-mcp: Python, OAuth with a desktop app client, adds URL inspection and sitemap tools.

The Python one installs the classic way: git clone https://github.com/metehan777/google-search-console-mcp.git, create a virtual environment, then pip install -e . inside it.

The Node one does not need cloning at all. npx fetches and runs it.

Before you run either, check two things. Which OAuth scope does it request? And does it have write access? webmasters.readonly is all you need for analysis. The full webmasters scope can add and delete properties and sitemaps, which is not something I want a language model doing because it misread my question.

Step 4: Add the Server to Your AI Client

For Claude Desktop, open claude_desktop_config.json and add a block under mcpServers. For the Node server with a service account:

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "mcp-server-gsc"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/Users/you/keys/gsc-service-account.json"
      }
    }
  }
}

Use an absolute path. Not ~/keys, not ./keys. Relative paths are the number one cause of missing credentials errors, because the client starts the server from a directory you did not expect.

If you already have other servers in that file, merge this block in next to them. Do not paste over the whole file. Ask me how I know.

For Claude Code, the claude mcp add command does the same thing from the terminal:

claude mcp add gsc -e GOOGLE_APPLICATION_CREDENTIALS=/Users/you/keys/gsc-service-account.json -- npx -y mcp-server-gsc

Cursor and Codex CLI each have their own MCP config file, but the shape is the same: a name, a command, arguments and environment variables. Claude MCP configuration is the most common example in READMEs, so translate from that.

Restart the client after any change to the client configuration. Most "it is not working" moments are "it has not reloaded".

Step 5: Check the Returned Data Against the UI

Start boring. Ask: "List my Search Console properties."

You should see each site URL exactly as Google stores it, for example sc-domain:example.com or https://www.example.com/. Use that exact format in every later question. Ask about https://example.com when the property is sc-domain:example.com and you will get an error or, worse, nothing.

Then ask something you can verify: "Clicks and impressions for the last 7 days." Open the Performance report in Google Search Console for the same dates and compare. They should match.

If they do not match, it is usually dates. The API returns finalized data by default, and the newest two or three days are often not final yet. Some servers let you request fresh data. Know which one you are getting.

Do this once properly and you will trust the setup. Skip it and one day the model will quote a number the API never returned.

Option 2: Use a Search Console Agent in Fetch Hive

WARNING: Shameless self-promotion incoming.

If the last five steps made you tired just reading them, this is the shortcut. In Fetch Hive, Google Search Console is a built-in MCP tool for agents. You connect your account once through the Google Search Console integration, and the agent calls the Search Console API for you.

1. Open the Search Console agent template and sign in, or create a free account.

2. Connect Google Search Console. One Google sign-in. Approve access and pick the property.

3. Ask your first question. "Which pages had more than 1,000 impressions and CTR under 1% last month?" works nicely.

That is it. No Google Cloud project, no service account email to add, no config file to break.

The bit I actually care about: every run is traced. You can see which tool calls the agent made and exactly which rows came back before you trust its answer. With search data, that matters more than the answer itself.

Prefer to stay inside Claude or ChatGPT? Connect the Fetch Hive MCP server to your AI assistant and you can run the same Search Console agent from there, without leaving the chat.

You do not need Fetch Hive to do any of this. Option 1 works fine and costs nothing. This is just the version with the plumbing already done.

READY-MADE AGENT, ZERO SETUP

Try it on your own Search Console.

Click the button and you will have a Search Console agent running in seconds. Connect your account, ask your first question. No Google Cloud project, no config files.

Agent

Verified by Fetch Hive

Search Console Site Analyst

For marketers and small business owners with a verified Google Search Console property. Ask a question about a site's search performance and get a date-aware, plain-language answer using only the relevant Search Console metrics, comparisons, and breakdowns; if the connected account cannot provide data, receive a clear explanation instead of made-up results.

Tools already connected in the template

OpenAI

Google Search Console

Try the agent

Opens in Fetch Hive. Free to start, no setup.

[NOTE FOR TOM, delete before publishing] If Fetch Hive agents can be used from Claude, ChatGPT or Cursor through the Fetch Hive MCP connector, add one line here: "You can also connect Fetch Hive to your own AI assistant and run the same agent from there." plus a bold link to the setup docs. I could not find public docs for that, so I left it out.

Questions Worth Asking Your Search Console Data

Whichever option you picked, this is the bit that makes the setup worth it: actually using your search performance and SEO data instead of admiring it. Some prompts I actually use:

• "Which queries rank between 8 and 30 with more than 500 impressions?" These are refresh candidates. Close enough to matter, far enough to be invisible.

• "Which pages have high impressions but CTR below 1%?" Usually a title or meta description problem, not a content problem.

• "Which pages lost the most clicks over the last 28 days compared with the previous 28?" Your traffic drop shortlist, sorted by damage.

• "Show queries where multiple pages compete for impressions." Cannibalization, without building a pivot table.

• "Which queries have impressions but no page clearly targeting them?" That is how this article got written.

• "Is /pricing indexed, and when was it last crawled?" URL inspection for indexing issues on one page.

• "List sitemaps and flag any with errors." Quick sitemap health check.

The good prompts all have numbers in them. "How is my SEO?" gets you a horoscope. "Pages with more than 1,000 impressions and CTR under 1% in October" gets you a to-do list.

Where It Goes Wrong

MCP gets the data into the conversation. It does not make the model a good analyst. Things I would keep in mind:

• Row limits. A single search analytics request returns at most 25,000 rows, and the default is 1,000. If the server does not page through results, a big site gets a partial answer delivered with total confidence.

• Data lag. Finalized data trails by a couple of days. "Yesterday" is often incomplete.

• History. Search Console keeps about 16 months of performance data. Year-on-year beyond that is not available, however nicely you ask.

• Hidden queries. Google filters out rare, anonymized queries for privacy. Query totals will not add up to page totals. That is expected, not a bug.

• Small numbers. 44 impressions is not a trend. Models love finding trends in noise. Ask for the raw numbers alongside any conclusion.

• Mobile usability. Older guides still list it. Google retired the Mobile Usability report and its tooling in December 2023, so do not build anything on it.

• Quotas. URL inspection is limited to 2,000 calls per property per day. Fine for spot checks, not for inspecting your whole site every morning.

Security: Keep It Read-Only

A Search Console token is not as scary as a database password. It is not harmless either. With full scope it can add and remove properties, delete sitemaps and see every site your account touches, which for an agency can be a lot of clients.

• Request webmasters.readonly. If a server or hosted connector asks for more, ask why.

• Prefer a dedicated service account with access to only the properties it needs, over your personal Google account.

• Keep the JSON file out of Git. Put it outside the repo and reference it with an absolute path.

• Do not hard-code API keys or key paths into config files you share with a team.

• Leave write tools switched off. Many servers have a flag to enable them. Leave it alone.

I go deeper on credentials, scopes and why tool descriptions are not a security boundary in my MCP server security guide.

When You Do Not Need MCP for This

MCP is great for ad-hoc questions. It is not always the right tool.

• One-off checks are faster in the Search Console UI. You do not need an agent to look at one graph.

• Recurring reports are better as a scheduled workflow. If you ask the same question every Monday, you want the answer waiting for you, not a chat you have to remember to start.

• Shared team reporting needs a consistent output. Five people asking AI assistants slightly different questions get five slightly different answers.

That recurring case is where a scheduled workflow beats both options above. We also built a Search Console low-CTR template that pulls your pages and queries for a date range, finds the high-impression, low-CTR ones and suggests title and meta description changes to test. Run it weekly and the to-do list is waiting for you on Monday morning.

READY-MADE WORKFLOW, ZERO SETUP

Get your low-CTR pages every week.

Click the button and this workflow is ready to run in seconds. Connect Search Console, pick a date range and schedule it for Monday mornings. Nothing to install.

Workflow

Verified by Fetch Hive

Search Console Low-CTR Landing Page Opportunities

For marketers and small business owners, analyze your verified site's Google Search Console performance over a chosen date range to find high-impression landing pages with weak click-through rates. Get a page-and-query table with evidence-based title and meta-description changes to test.

Tools already connected in the template

Google Search Console

OpenAI

Use this template

Opens in Fetch Hive. Free to start, no setup.

Practical Checklist

• Pick your route: install a server yourself (Option 1) or use a Fetch Hive agent (Option 2).

• Option 1: enable the Search Console API in a Google Cloud project.

• Pick OAuth for personal use, a service account for anything automated.

• Request webmasters.readonly. Leave write tools off.

• Read the server's code or README before giving it your Google credentials.

• Use absolute paths in the client configuration.

• Merge new servers into existing config. Do not overwrite.

• Run "list my properties" first and use the exact site URL it returns.

• Check one week of numbers against the UI before trusting anything.

• Put dates and thresholds in every question.

• Move anything you ask weekly into a scheduled workflow.

The Takeaway

A Google Search Console MCP server does not give you new data. It gives your AI agent the data you already had, without the export and paste.

That is genuinely useful. It also means the model can now be wrong about your numbers much faster.

Connect it read-only, check the first answers against the UI and ask specific questions. The data was always there. You just have to ask it something worth answering.

If you want the bigger picture on how MCP servers are hosted and secured, the Fetch Hive MCP hub is a good next stop.