Your agent needs Google Search Console data. It has to pull clicks and impressions before a content review, inspect whether a freshly shipped page is indexed, or submit a sitemap after a deploy. You searched for a Search Console MCP server and found several. Here is the fact that reframes the decision: none of them are Google's. So the real choice is between a community MCP server that wraps the Search Console API and the official API itself. They differ on three axes that matter in production: who the agent authenticates as, who you trust to run the code, and who maintains the tool surface.
Before comparing them, it helps to be precise about what each object is, because one of them is not what most people assume.
There is no Google-maintained Search Console MCP server. The servers you find on package registries and GitHub are built by individual developers or third-party vendors, each wrapping some subset of the Search Console API and exposing it over the Model Context Protocol (MCP). They typically run locally over stdio, or as a self-hosted remote server, and they usually authenticate through a Google Cloud service account JSON referenced by GOOGLE_APPLICATION_CREDENTIALS, or a local OAuth token.json created once for a single Google account.
That distinction is the whole story. A community server works, but you are the one running it, updating it, and deciding whether a stranger's repository should hold a credential that reaches your Google Cloud project.
The Search Console API, formerly the Webmaster Tools API, exposes four services: Search Analytics (clicks, impressions, CTR, position, grouped by dimensions), URL Inspection (per-URL index status), Sitemaps (list, get, submit, delete), and Sites (list, get, add, delete). It authenticates with OAuth 2.0 through a user-consent flow or a service account, scoped by webmasters for writes and webmasters or webmasters.readonly for reads. There is no API key option for these calls. You can read the full surface in the official Search Console API reference.
One boundary worth stating up front: the separate Indexing API is a different product with its own service-account requirement and is limited to JobPosting and BroadcastEvent structured data. It is not part of the Search Console API and does not index general pages.
Scalekit exposes a single Google Search Console connector, and it wraps the official Search Console API, not a community MCP server. It ships ten agent-ready tools with LLM-optimized schemas, OAuth 2.0 per user, and per-user connected accounts. You can browse the tool list and quickstart on the Scalekit Google Search Console connector docs, or find it in the full AgentKit connector catalog.
The comparison below is between a typical community GSC MCP server and the official Search Console API. Community servers vary, so treat the MCP column as representative rather than universal.
Read the last two rows first. A community server can only expose what its author chose to wrap, and it acts as one identity: the service account or the account behind the local token. The API exposes the complete surface, and Google versions and supports it. The other rows drift toward "Partial" for the MCP column for the same reason: nobody is contractually responsible for keeping a hobby server current with the API. Capability parity is achievable on either path. Identity, trust, and maintenance ownership are not, and those are the axes an agent decision actually turns on.
Auth is where the two paths diverge hardest, and where the multi-tenant reality shows up.
Most community GSC MCP servers expect a service account JSON or a single OAuth token.json. A service account is one identity: to reach a property, that account must be granted access to it inside Search Console, and every call runs as that account rather than as the user who triggered the agent. A local token.json is worse for multi-user products, because it represents exactly one Google account. Neither shape expresses per-user permissions.
The Search Console API supports OAuth 2.0 Authorization Code for per-user consent and service accounts for server-to-server access to properties you control. The scopes are webmasters and webmasters.readonly. There is no static API key, so an agent acting for many users needs a real consent flow per user, which is the architecturally correct model and also the one that creates credential-management work.
For a B2B agent serving forty marketers across eight customer organizations, the correct model is one OAuth grant per user, scoped to the properties that user can see. That is forty tokens to store, refresh, and revoke. A shared service account collapses all forty into one identity and one permission set, which is both a security failure and an accuracy failure: what one user cannot see, the agent should not be able to reach. The principle is simple. What the user cannot do, the agent cannot do. See access control for multi-tenant AI agents for the full argument.
Both paths leave you holding operational surface area. They just hand you different pieces.
With a community MCP server you own the runtime and the supply chain. You host it, patch it, and decide whether an unaffiliated repository should hold a credential to your Google Cloud project. There is no versioning contract, so a server update can change tool names or schemas under you, and there is no support channel when it does.
With the raw API you own request construction, error handling, retries, pagination, and the OAuth lifecycle across four services. You also write and maintain the tool schemas that turn searchanalytics.query, urlInspection.index.inspect, sitemaps, and sites into definitions an LLM can call. Every API change is now your maintenance task.
Quotas are a production constraint on both paths. Search Analytics accepts a rowLimit from 1 to 25,000 per request, and URL Inspection is capped at roughly 2,000 queries per property per day at the time of writing, so a batch inspection agent hits the ceiling fast. There is also a sharp edge: the API requires siteUrl as a single percent-encoded path segment. On the raw API you write that encoding into every request; with a maintained connector the schema documents it and the model fills it in, though it remains a place to watch.
The paths are not interchangeable, and the right answer depends on who the agent serves.
If your agent serves other people, each connecting their own Search Console, neither raw path is complete. That is the case a managed connector is built for: per-user OAuth, a maintained tool surface over the official API, and no server for you to host or trust. For the broader framing of this tradeoff, see MCP vs APIs and how they differ.
There is a problem that sits underneath the MCP vs API choice, and it does not go away no matter which you pick.
Both paths produce a credential per user. The API's Authorization Code flow gives you an OAuth token per user; a community server that uses per-user OAuth gives you the same. That token is the beginning of the work, not the end of it.
A token has to live somewhere outside the agent runtime, encrypted at rest and isolated per tenant. Access tokens expire and must be refreshed proactively rather than on a 401, or concurrent agent threads race each other into retry storms. When a marketer leaves or a customer churns, you need to surface and revoke every credential tied to that identity. Neither the Search Console API nor a community MCP server does any of this for you. In a multi-tenant agent that is N credentials, each with its own lifecycle. For the mechanics, see token vault for AI agent workflows and how to handle token refresh.
The Scalekit Google Search Console connector handles the OAuth flow, per-user token storage, and automatic refresh, so the MCP vs API decision stops touching your auth infrastructure. Credentials never enter the agent runtime; your code executes against a scoped identifier, not a raw token.
The pattern below is per-user by default. It authorizes one user, loads only the tools that user's connected account is allowed to call, and runs a standard Claude tool-use loop. The example uses Python and the Anthropic SDK; the same connected-account pattern works in TypeScript via the Node SDK and in LangChain, Google ADK, and CrewAI.
Create a connection named googlesearchconsole once in the Scalekit dashboard, then resolve the current user from your own authenticated session. The identifier is your system's user ID; never accept it from the client.
The next call is the one that separates a per-user agent from a shared-credential agent. Your code is not loading a flat connector catalog; it is loading only the tools this user's connected account is authorized to call, in Anthropic's native format, so there are no schemas to hand-write.
For a read-only reporting agent, Claude will reach for tools like googlesearchconsole_list_sites and googlesearchconsole_query_search_analytics; a technical-SEO agent adds googlesearchconsole_inspect_url and the sitemap tools. The exact ten tool names and their parameters live in the connector docs.
This is the standard Anthropic tool-use loop. Claude decides what to call, your code executes the tool through Scalekit against the user's connected account, and the result goes back until Claude produces a final answer. The token never touches your loop.
Scalekit maintains the connector, so when the Search Console API changes, the tool definitions refresh on their side and your agent code stays the same. Start from the AgentKit quickstart if this is your first connector.
An SEO agent that quietly reads the wrong property, or writes a sitemap deletion nobody asked for, is a problem you only catch if the actions are recorded.
Because every execute_tool call runs through Scalekit against a specific connected account, each one is a logged event: which identifier acted, which connected account was used, which tool ran, when, and whether it succeeded or failed. That record is queryable rather than scattered across your own print statements. See agent tool observability and the deeper write-up on audit trails for agent auth.
Search Console data is delayed, so an agent's read is often the thing a decision rests on, and a mutation like a sitemap submit or a property removal has real downstream effect. On a self-run community server or the raw API you build this audit trail yourself. On the connector it is a property of every tool call, which is exactly what a security reviewer asks for when your agent starts touching customer properties.
Search Console rarely travels alone. A useful agent pairs a ranking drop with GA4 numbers, a content calendar, and a note in Slack, and it does that for many customers at once.
A Virtual MCP Server gives every agent a scoped, user-specific MCP endpoint with no server to deploy, host, or maintain. One server definition serves all users; before each run, a short-lived session token is minted scoped to that specific user's connected accounts. The endpoint is static; the identity is per-user. That is the piece the community MCP path cannot give you, because a self-hosted server acts as one identity for everyone.
A Virtual MCP server exposes only the tools you explicitly allow, not everything the connector defines. A read-only SEO reporter can be limited to googlesearchconsole_query_search_analytics, googlesearchconsole_inspect_url, and the list tools, with add_site, delete_site, and delete_sitemap left out entirely, which shrinks the blast radius and reduces tool bloat in context. For when this pattern pays off, see how tool calling auth changes when you move from single-tenant to multi-tenant.
If your agent is a personal SEO assistant working your own properties from an interactive client, a community GSC MCP server is a legitimate, fast start, as long as you accept that you run and trust it. If your agent is a deterministic pipeline that needs the full surface and Google's versioning, build against the Search Console API directly. If your agent serves other people, each with their own Search Console, use a maintained connector so per-user OAuth and the credential lifecycle are handled at the infrastructure layer. The one question that decides it: does the agent act for many users, each with their own properties? If yes, the credential problem is the real work, and that is what needs production-grade infrastructure regardless of the path.
Start from the Scalekit Google Search Console connector docs, browse the full connector catalog, and check AgentKit pricing when you are ready to scale. Building now and want a hand? Join the Scalekit Slack community, or talk to us for immediate help.
