Provider REST API

Analytics

Connect Claude to Google Search Console

Query search traffic, inspect how Google indexed a URL, and manage sitemaps. Toolspoke puts 8 of its actions behind one MCP endpoint that Claude, Cursor, and Codex all speak.

Connection
Provider REST API
Authentication
Sign in with Google
Actions exposed
8
Cost per call (typical)
1 credit
Adapter
Maintained by Toolspoke

Connected in three steps

  1. 1

    Install Google Search Console

    Open the marketplace in your workspace, add Google Search Console to the project your agents work in, and it appears on the gateway immediately.

  2. 2

    Connect the credential

    Sign in to Google Search Console. Toolspoke holds the token encrypted and refreshes it when it expires.

  3. 3

    Point your agent at the gateway

    Give your client one address, https://toolspoke.com/mcp. Claude Code takes it as a command, Claude and Claude Desktop add it as a custom connector, and Cursor, Codex and VS Code each read it from a config file of their own.

.mcp.json
{
  "mcpServers": {
    "toolspoke": {
      "type": "http",
      "url": "https://toolspoke.com/mcp"
    }
  }
}

One block covers every tool you have installed. Google Search Console shows up in the client as soon as your policy allows it, and so does everything else you install later.

Where the address goes, per client

Claude Code

Run it in your project, then /mcp to sign in

claude mcp add --transport http toolspoke https://toolspoke.com/mcp
Claude and Claude Desktop

Settings, then Connectors, then Add custom connector

https://toolspoke.com/mcp
Cursor

~/.cursor/mcp.json, or .cursor/mcp.json for one project

{ "mcpServers": { "toolspoke": { "url": "https://toolspoke.com/mcp" } } }
Codex

~/.codex/config.toml

[mcp_servers.toolspoke]
url = "https://toolspoke.com/mcp"
VS Code

.vscode/mcp.json, or the MCP: Add Server command

{ "servers": { "toolspoke": { "type": "http", "url": "https://toolspoke.com/mcp" } } }

What Google Search Console asks for

Press connect and sign in to Google Search Console. Toolspoke keeps the token encrypted and refreshes it when it expires, so there is nothing to copy and nothing to rotate by hand.

The scopes it asks for

  • https://www.googleapis.com/auth/webmasters

What Claude can do in Google Search Console

8 actions, each one declared and named by the connector rather than discovered at runtime. A workspace policy grants a person all of them, a hand-picked selection, everything on the read side, everything on the write side, or none.

Reads
6Reads
Writes
0Writes
Destructive
2Destructive

Reads

6

Fetches data and changes nothing.

  • list_sites

    List every Search Console property the signed-in account can reach, with the permission level it holds on each - siteOwner, siteFullUser, siteRestrictedUser or siteUnverifiedUser. Call this first: every other operation takes a site_url, and this is where the exact string comes from. Properties come in two shapes and the difference matters - a URL-prefix property reads "https://example.com/" with the trailing slash, a domain property reads "sc-domain:example.com". Costs nothing and touches no report, so it is also this connector's health check.

  • get_site

    Read one property and the permission level this account holds on it. Use it to confirm a site_url string is exactly right, and that the account can do more than look, before spending a call on query_search_analytics or submit_sitemap. Get the site_url from list_sites rather than typing it - Search Console matches it exactly, and "https://example.com" without the trailing slash is a different string from "https://example.com/".

  • query_search_analytics

    The Performance report, as data: clicks, impressions, CTR and average position for a property over a date range, grouped by whichever dimensions you ask for. This is the main reason to install this connector. Group by "query" to see what people searched for, "page" for which URLs earned the traffic, "date" for a trend line, "country" and "device" for a split, and combine up to four - asking for ["query", "page"] returns one row per query-and-page pair. Google withholds some queries for privacy, so the rows never sum exactly to the totals an ungrouped query returns. Fresh data lags by roughly two days, so end the range there rather than today. Get the site_url from list_sites first. Row limits: 25000 per call, paged with start_row.

  • inspect_url

    Ask Google what it knows about one URL on a property you own: whether it is in the index, when it was last crawled, which sitemaps referenced it, what Google picked as the canonical, whether robots.txt or a noindex blocked it, and the mobile-usability and rich-result verdicts. This is the operation for "why is this page not showing up". The URL must belong to the property named in site_url, and the property must be verified for this account. Quota is 2000 inspections a day and 600 an hour per property, so inspect the pages a question is actually about rather than sweeping a site.

  • list_sitemaps

    List the sitemaps Search Console holds for a property: each one's path, when it was submitted, when Google last downloaded it, how many warnings and errors it produced, and how many URLs of each content type it declares. Call it before submit_sitemap to see whether a sitemap is already registered, and after to confirm Google picked it up. The `path` values it returns are the full sitemap URLs that get_sitemap and delete_sitemap take.

  • get_sitemap

    Read one sitemap's record: when it was submitted and last downloaded, whether Google flagged it as pending, how many warnings and errors it holds, and the URL counts it declares by content type. Prefer it over list_sitemaps when you already know the sitemap's URL and want only that one. The feedpath is the sitemap's full URL, taken from list_sitemaps.

Destructive

2

Deletes or permanently alters something. Worth granting on purpose.

  • submit_sitemap

    Register a sitemap with Search Console and ask Google to fetch it. Classified destructive because it reaches outside the workspace: it tells Google to go and crawl whatever that file lists, it changes what Search Console reports about the property from then on, and resubmitting an existing path replaces the record already there. The sitemap has to be live at that URL and inside the property before this is called - Google fetches it, it is not uploaded here. Answers with an empty body on success; call list_sitemaps or get_sitemap afterwards to see whether Google actually read it and what it made of it.

  • delete_sitemap

    Remove a sitemap from a property's Search Console record, along with its submission history and error counts. The file itself is untouched - this only tells Google to stop tracking it - but the record and its history are gone and cannot be restored by resubmitting. Get the feedpath from list_sitemaps, and confirm with list_sitemaps afterwards.

What it will not do

Enforced by the gateway rather than left to convention, which is why each of these can be stated flatly.

It cannot call anything else
The 8 actions above are the whole of it. A call to any other name is refused before it reaches Google Search Console rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time.
It reaches no further than your credential
Toolspoke holds no access to Google Search Console of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either.
It never hears from Google Search Console
Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Google Search Console. An agent has to ask.
It does not smooth over provider limits
Toolspoke does not retry, queue or back off around Google Search Console's own rate limits. A call that Google Search Console refuses comes back to the agent as a failed call.

Before you connect it

What can Claude do in Google Search Console?

8 named actions: 6 that only read and 2 that delete or permanently alter something. They include list_sites, get_site and query_search_analytics. Nothing outside that list is reachable: the connector declares each operation by name rather than proxying whatever an agent asks for.

What credentials does the Google Search Console connector need?

Nothing to paste. You sign in to Google Search Console over OAuth 2.0 and Toolspoke keeps the resulting token encrypted, refreshing it when it expires. It asks for https://www.googleapis.com/auth/webmasters, and can do nothing outside them.

Does the Google Search Console connector work with Cursor and Codex, or only Claude?

Any client that speaks MCP, and every one of them gets the same 8 actions. There is a single address, https://toolspoke.com/mcp. Claude Code adds it with claude mcp add --transport http, Claude and Claude Desktop take it as a custom connector in settings, Cursor reads it from .cursor/mcp.json, Codex from ~/.codex/config.toml, and VS Code from .vscode/mcp.json. Each of them signs in to the gateway itself, so there is no key to paste.

What does the Google Search Console connector not do?

The 8 actions above are the whole of it. A call to any other name is refused before it reaches Google Search Console rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time. Toolspoke holds no access to Google Search Console of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either. Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Google Search Console. An agent has to ask. Toolspoke does not retry, queue or back off around Google Search Console's own rate limits. A call that Google Search Console refuses comes back to the agent as a failed call.

Can I limit which actions an agent can call?

Yes, in two places. The project switches Google Search Console's actions on and off one at a time, for everyone in the project at once, and the screen groups them by read, write and destructive so turning off everything that deletes is one click. An individual agent key can then be narrowed further, to particular toolkits in a project and to particular actions in a toolkit. Whatever it was granted, a key never reaches a project its owner cannot.

What gets recorded when an agent calls Google Search Console?

Every attempt, with the agent that made it and the person that agent belongs to, the full request payload, the response payload, the status, the duration, and the credits spent. Values whose key names a secret are masked out before the record is shown to anyone. An operation the connector marks as not retained never has its response body written at all, so the gateway keeps no second copy of what was read.