google-search-console-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ELICITATION | No | false replaces the approval dialog with the two-call token. Not prefixed with GSC_ | |
| GSC_SITE_URL | No | Default property, e.g. sc-domain:example.com or https://example.com/. Makes site_url optional everywhere | |
| GSC_CLIENT_ID | No | OAuth2 client id | |
| GSC_READ_ONLY | No | true (or 1/yes) registers only the twelve read tools | |
| GSC_DENY_TOOLS | No | Same shape as GSC_ALLOW_TOOLS, subtracted from whatever the allow list left | |
| GSC_ALLOW_TOOLS | No | Comma-separated tool names, a list_* prefix, or essential | |
| GSC_ALLOWED_SITES | No | Comma-separated properties this server may touch at all; anything else is refused | |
| GSC_CLIENT_SECRET | No | OAuth2 client secret | |
| GSC_REFRESH_TOKEN | No | OAuth2 refresh token. All three OAuth2 variables are required together | |
| GSC_SERVICE_ACCOUNT_KEY | No | Service account key as raw JSON, or base64-encoded JSON | |
| GSC_SERVICE_ACCOUNT_KEY_FILE | No | Path to a service account key file. Alternative to GSC_SERVICE_ACCOUNT_KEY — setting both is an error | |
| GOOGLE_APPLICATION_CREDENTIALS | No | Application default credentials, used when no GSC_ credential is set |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_sitesA | Lists every Search Console property this credential can see, with the permission level it has on each. This is the first call to make when anything returns 403: an empty list means the identity was never added to any property, which is the usual state of a fresh service account. permissionLevel is what the credential may do: siteOwner (everything, including the Indexing API), siteFullUser (all data, no user management), siteRestrictedUser (most data), and siteUnverifiedUser — which means the property is listed but ownership was never proven, and every data call for it returns 403 until it is verified. |
| get_siteA | Returns one property and the permission level this credential has on it. Useful for settling which of the two spellings exists — "sc-domain:example.com" and "https://example.com/" are separate properties holding separate data. |
| add_siteA | Adds a property to Search Console. This does NOT verify ownership: unless the credential already owns the domain, the property lands as siteUnverifiedUser and every data call for it returns 403. To actually get a working property, use setup_site, which does this in the right order — get_verification_token, then the DNS record or HTML file, then verify_site, then this. |
| delete_siteA | Removes a property from Search Console. Two-step: the first call returns a confirmation token, the second performs the removal. |
| list_sitemapsA | Lists the sitemaps submitted for a property, each with when Google last downloaded it, how many URLs it holds per content type, and whether processing produced warnings or errors. To refresh a sitemap Google already knows, submit the same URL again — there is no separate update call, and submitting is idempotent. Google re-crawls on its own schedule; nothing can force it, and the ping endpoint that used to exist was removed in 2023. |
| get_sitemapA | Returns the full record for a single submitted sitemap: last submitted, last downloaded, warnings, errors, and the URL counts per content type. This is how to check whether a submission actually worked — errors appear here, never in the response to submit_sitemap. |
| submit_sitemapA | Submits a sitemap URL, or resubmits one Google already knows. To refresh a sitemap Google already knows, submit the same URL again — there is no separate update call, and submitting is idempotent. Google re-crawls on its own schedule; nothing can force it, and the ping endpoint that used to exist was removed in 2023. The call succeeding means Google accepted the address, not that the sitemap is valid — it is fetched later, and any parse error shows up in get_sitemap minutes to hours afterwards. |
| submit_sitemapsA | Submits up to 50 sitemaps for one property in a single call, reporting success or failure per entry. The API has no batch method — this makes the calls one after another — but it saves a round trip per sitemap, which is what makes a large site practical. One failure does not stop the rest. |
| delete_sitemapA | Removes a sitemap from the property. Two-step: the first call returns a confirmation token, the second performs the removal. |
| query_search_analyticsA | Clicks, impressions, CTR and average position from Google Search, grouped by any combination of dimensions. This is the whole of the Performance report, as an API. Give a date range as either period ("last28days") or start_date and end_date. Data is finalised 2–3 days behind, and only the last 16 months are retained. Two things about the numbers. Rows are capped at row_limit (default 100, maximum 25,000) and paged with start_row. And with the query dimension, Google withholds rare queries for anonymity, so the rows never sum to the property total — query without it when you need a true total. |
| inspect_urlA | Asks Google what it knows about one URL: whether it is indexed, when it was last crawled, which sitemaps reference it, the canonical Google chose versus the one declared, robots.txt and mobile-usability verdicts, and any rich-result problems. This is the API behind the URL Inspection tool in the Search Console interface. It reports the indexed state, not a live fetch — a page changed an hour ago still shows what Google last saw. The URL Inspection API allows 2 000 calls per property per day and 600 per minute. That is a daily budget, not a rate limit — spending it blocks inspection for the rest of the day. |
| inspect_urlsA | Inspects up to 20 URLs of one property in a single call, reporting a per-URL verdict. The API has no batch method — this makes the calls one after another — but it saves a round trip per URL. One failure does not stop the rest. The result is condensed to the verdict fields; use inspect_url for the full report on a single URL. The URL Inspection API allows 2 000 calls per property per day and 600 per minute. That is a daily budget, not a rate limit — spending it blocks inspection for the rest of the day. |
| list_verified_sitesA | Lists every site this credential has verified ownership of, with the full owner list for each. This is a different list from list_sites: that one is Search Console properties, this one is proven ownership, and a site can be in either without being in the other. setup_site compares the two. |
| get_verified_siteA | Returns one verified site and the email addresses of all its owners. |
| get_verification_tokenA | Returns the token that proves ownership of a site, and says exactly where to put it. Nothing is created and nothing is claimed by this call — it is safe to run against a domain you do not own, it just achieves nothing. A domain property can only be proven by DNS. A URL-prefix property can use FILE or META here; ANALYTICS and TAG_MANAGER prove ownership through an existing Google product rather than a token, so they have no token to fetch and are only usable with verify_site directly. Placing the token is a human step. Once it is in place, call verify_site. |
| verify_siteA | Tells Google to check for the verification token and, if it finds it, records this credential as an owner. Run get_verification_token first and place the token — this call only checks, it does not place anything. A failure here is almost always "not there yet" rather than "wrong": DNS records take minutes to an hour to propagate, and a freshly uploaded file may still be behind a CDN cache. Retrying later is the normal response. |
| unverify_siteA | Removes this credential from the owners of a site. Two-step: the first call returns a confirmation token, the second performs the removal. |
| update_site_ownersA | Replaces the list of verified owners of a site. This is how a second person or a service account is granted ownership without placing a token of their own. It REPLACES rather than adds: the list you pass becomes the complete owner list. Call get_verified_site first and send back the existing addresses plus the new one, or the others are removed. This server refuses a list that does not contain at least one address, because that is the shape of an accidental wipe. Two-step: the first call returns a confirmation token, the second performs the change. |
| get_indexing_statusA | Returns when this credential last notified Google about a URL through the Indexing API, and what kind of notification it was. This reports the notification history only — it says nothing about whether the page is indexed. inspect_url answers that. The credential must be a verified owner of the property — Search Console user access is not enough, and the API answers 403 without saying which of the two is missing. |
| request_indexingA | Tells Google through the Indexing API that a URL was updated or removed. Google only acts on this for pages with JobPosting or BroadcastEvent structured data. For any other page the call succeeds, returns a timestamp, and changes nothing — it is not a way to get a normal page crawled sooner. Submit a sitemap for that. The credential must be a verified owner of the property — Search Console user access is not enough, and the API answers 403 without saying which of the two is missing. The default quota is 200 URLs per day per project. |
| setup_siteA | Works out where a property stands and says exactly what to do next. Getting a working Search Console property takes four steps in one order — obtain a verification token, place it in DNS or on the page (a human step), verify ownership, add the property — and nothing in the API enforces that order. Calling add_site first succeeds and leaves a property that returns 403 for every piece of data, which looks like a permissions problem and is not. This reads the current state and reports the next step, including the DNS record or meta tag to copy when that is what is missing. It changes nothing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ni-c/google-search-console-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server