This MCP server provides full Google Search Console and Google Indexing API access through 13 tools.
Manage Search Console sites: list, get, add, and delete properties.
Manage sitemaps: list, get, submit, and delete sitemaps.
Query Search Analytics for clicks, impressions, CTR, and position with filtering, grouping, pagination, and hourly data support.
Inspect URLs for index status, crawl info, rich results, AMP, and mobile usability.
Use the Indexing API to notify Google about URL updates/removals, get notification metadata, and batch up to 100 notifications.
Supports inspecting a URL's AMP status, mobile usability, and rich results via the URL inspection tools.
Provides integration with the Google Indexing API to notify Google about URL updates or removals, supporting both single and batch notifications.
Offers full API coverage for Google Search Console, including managing sites, submitting sitemaps, and querying comprehensive search performance data like clicks, impressions, CTR, and ranking positions.
MCP server for Google Search Console API and Google Indexing API — full API coverage.
Requires Node.js 20 or newer, matching the MCP SDK's installed runtime dependencies.
Task | Tool |
"Check which queries my site ranks for" |
|
"Notify Google about an eligible job posting or livestream URL" |
|
"Find pages with indexing errors" |
|
"Get search performance data for the last 30 days" |
|
"Compare click-through rates between mobile and desktop" |
|
"Submit my sitemap to Google" |
|
"Batch notify eligible job posting/livestream URLs" |
|
For AI agents: See
llms.txtfor a machine-readable summary. Copytemplates/CLAUDE.mdortemplates/AGENTS.mdinto your project to teach your agent about this MCP.
Unlike other GSC MCP servers that only wrap searchAnalytics.query, this server exposes every endpoint available in the Google Search Console and Indexing APIs.
Related MCP server: gsc-mcp
Tool | Description |
| List all sites (properties) in your Search Console |
| Get details of a specific site |
| Add a new site (property) |
| Remove a site |
Tool | Description |
| List all submitted sitemaps for a site |
| Get details of a specific sitemap |
| Submit a sitemap |
| Delete a sitemap |
Tool | Description |
| Query search performance data (clicks, impressions, CTR, position) with filtering and grouping. Supports hourly data with the |
Tool | Description |
| Inspect a URL's index status, crawl info, rich results, and AMP (the deprecated mobile-usability field may be absent) |
Tool | Description |
| Notify Google about an eligible |
| Get latest notification metadata for an eligible URL (requires |
| Batch notify up to 100 eligible URLs and report every embedded request status |
Indexing API eligibility: Google supports this API only for pages with
JobPostingstructured data or livestream pages withBroadcastEventembedded in aVideoObject. The tools requirecontentTypeso callers must identify which supported type applies. A successful API response confirms receipt of the notification; it does not guarantee that Google indexed the URL. Useurl_inspection_inspectto check index status. See Google's Indexing API usage guide.
Google's default per-project limits are 200 publish requests per day, 180 metadata requests per minute, and 380 requests per minute across endpoints. The daily limit resets at midnight Pacific Time. A batch of 100 URLs still consumes 100 requests; batching reduces connections, not quota usage. Check your project's actual quota before sending notifications. See the official quota reference.
Two authentication methods are supported:
{
"mcpServers": {
"gsc-mcp": {
"command": "npx",
"args": ["-y", "@mikusnuz/gsc-mcp"],
"env": {
"GSC_CLIENT_ID": "your-client-id",
"GSC_CLIENT_SECRET": "your-client-secret",
"GSC_REFRESH_TOKEN": "your-refresh-token"
}
}
}
}Required OAuth2 scopes:
https://www.googleapis.com/auth/webmasters
https://www.googleapis.com/auth/indexing
{
"mcpServers": {
"gsc-mcp": {
"command": "npx",
"args": ["-y", "@mikusnuz/gsc-mcp"],
"env": {
"GSC_SERVICE_ACCOUNT_KEY_PATH": "/path/to/service-account-key.json"
}
}
}
}For Search Console read/write tools, add the service account as an owner or user with sufficient permission. For Indexing API tools, Google requires the service account to be added as a delegated owner of the property; user-level access is not sufficient.
Go to Google Cloud Console
Create a project (or select existing)
Enable Search Console API and Indexing API
Create OAuth 2.0 credentials (Desktop app type)
Use the OAuth Playground to generate a refresh token with scopes:
https://www.googleapis.com/auth/webmasters
https://www.googleapis.com/auth/indexing
Go to Google Cloud Console
Create a service account
Download the JSON key file
Enable Search Console API and Indexing API
In Search Console, add the service account email as an owner for your sites
MIT
Batch notify Google about up to 100 eligible JobPosting or BroadcastEvent URL updates/removals. Each embedded response is checked independently; a successful notification does not guarantee indexing.
| Name | Required | Description | Default |
|---|---|---|---|
| notifications | Yes | Array of eligible URL notifications (1-100 items). Each item has url, contentType, and type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and usefully discloses the batch limit, independent per-item response checking, and the important caveat that successful notification does not guarantee indexing. It does not cover auth requirements or quota behavior beyond the item limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with scope and limits, then the important caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter batch notification tool with no output schema, the description covers eligibility, batch size, per-item independence, and the key indexing caveat. It stops short of describing response shape or authentication/quota context, but is otherwise complete enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the notification object fields, enums, and 1-100 item range. The description reinforces eligibility and batch size but adds little parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Batch notify Google about ... JobPosting or BroadcastEvent URL updates/removals." It distinguishes itself from the likely single-URL sibling indexing_publish through the word "Batch" and the explicit 100-item limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful usage context: up to 100 eligible URL updates/removals for JobPosting or BroadcastEvent content. It does not explicitly state when to use indexing_publish instead, but the batch-vs-single distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest Indexing API notification metadata for an eligible JobPosting or BroadcastEvent URL. This reports notification history, not whether Google indexed the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The fully-qualified URL to check notification status for | |
| contentType | Yes | Eligible structured-data type on the page: JobPosting, or BroadcastEvent embedded in VideoObject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does useful work by clarifying that this reports notification history, not whether Google indexed the URL. 'Get' implies a read operation, but auth requirements, rate limits, and exact response behavior are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and immediately followed by the key caveat. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description provides enough context to select and invoke it correctly, including the important limitation about notification history versus indexing status. The absence of an output schema means return fields are not detailed, but the description still gives a useful high-level account of what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description reinforces the eligible content types but adds no format or usage detail beyond what the structured parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: getting the latest Indexing API notification metadata for eligible JobPosting or BroadcastEvent URLs. It also explicitly distinguishes the result from indexing status, which prevents confusion with sibling inspection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The eligibility constraint (JobPosting or BroadcastEvent URL) and the caveat that it reports notification history rather than indexed status give clear usage context. It does not explicitly name the alternative tool for checking indexing status, so it falls short of full when-to-use routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Notify Google about an eligible URL update or removal via the Indexing API. Google supports only JobPosting pages and livestream pages with BroadcastEvent embedded in VideoObject; this notification does not guarantee indexing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The fully-qualified URL to notify about | |
| type | Yes | Notification type: URL_UPDATED or URL_DELETED | |
| contentType | Yes | Eligible structured-data type on the page: JobPosting, or BroadcastEvent embedded in VideoObject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it discloses the significant behavioral trait that this is a hint, not a guarantee, and that only two page types qualify. It omits operational constraints such as quota/rate limits and auth requirements, which matter for an Indexing API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero waste; the action is front-loaded and the eligibility constraint plus non-guarantee caveat follow immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-param notifier with no output schema, the description covers what the agent must know to call it correctly. Missing quota/auth context keeps it from being fully complete, but the core eligibility and expectation-setting content is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with enums for type and contentType, so the schema already defines the parameters. The description adds eligibility meaning around contentType, but no further format or sequencing guidance beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Notify Google about an eligible URL update or removal via the Indexing API.' It clearly frames a single-URL notification but never names siblings like indexing_batch_publish or url_inspection_inspect, so the agent must infer this is the single-URL variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage condition (eligible URL update or removal) plus hard eligibility limits (JobPosting pages, livestream pages with BroadcastEvent in VideoObject) and the caveat that notification does not guarantee indexing. It stops short of explicitly excluding or routing to alternatives such as batch publish or inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query search traffic data from Google Search Console. Returns clicks, impressions, CTR, and position data with flexible filtering and grouping.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Search type filter: web, image, video, news, discover, googleNews (default: web) | |
| endDate | Yes | End date in YYYY-MM-DD format | |
| siteUrl | Yes | The site URL | |
| rowLimit | No | Maximum number of rows to return (1-25000, default: 1000) | |
| startRow | No | Zero-based row offset for pagination | |
| dataState | No | 'all' includes fresh (possibly incomplete) data, 'final' only finalized data, 'hourly_all' required when using 'hour' dimension | |
| startDate | Yes | Start date in YYYY-MM-DD format | |
| dimensions | No | Dimensions to group by: country, device, page, query, searchAppearance, date, hour (hour requires dataState='hourly_all') | |
| aggregationType | No | How data is aggregated (default: auto) | |
| dimensionFilterGroups | No | Filter groups to apply to the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose important behavioral traits such as required permissions (must have site access in Search Console), data freshness considerations, potential sampling, or rate limits. The mention of 'flexible filtering' is generic and not actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence covering purpose and output. It could be better structured with more detail, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description is too brief. It omits crucial context such as pagination behavior, output structure, data staleness implications, and prerequisites for using dimensions like 'hour'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds only generic phrasing ('flexible filtering and grouping') that does not enhance understanding beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries search traffic data from Google Search Console and returns clicks, impressions, CTR, and position. It effectively distinguishes from sibling tools which deal with indexing, sitemaps, and site management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for the tool's purpose in analytics, and sibling tools are distinctly different (indexing, sitemaps, sites), making it easy to choose. However, it does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a sitemap from Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL | |
| feedpath | Yes | The URL of the sitemap to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the deletion action but does not disclose side effects, ownership requirements, or any behavioral details beyond the basic operation. Since no annotations are present, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence that is efficient and front-loaded, but it could benefit from slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema or annotations, the description is too minimal. It lacks details on return values, error handling, or prerequisites, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing basic definitions for both parameters ('The site URL' and 'The URL of the sitemap to delete'). The tool description adds no additional semantics, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'a sitemap from Google Search Console', distinguishing it from sibling tools like sitemaps_get or sitemaps_submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about a specific sitemap.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL | |
| feedpath | Yes | The URL of the sitemap (e.g. 'https://example.com/sitemap.xml') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Retrieve information', implying a read operation, but omits details on permissions, rate limits, error handling, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 7-word sentence, very concise. However, it is nearly too minimal; slightly more detail could improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about return values, error scenarios, and relationship to other sitemap tools. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (siteUrl, feedpath) with clear descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Retrieve' and specifies the resource 'information about a specific sitemap'. It distinguishes itself from sibling tools like sitemaps_delete and sitemaps_list by implying a read operation, but could be more precise about what 'information' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sitemaps_list or sitemaps_submit. The description does not mention prerequisites or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sitemaps submitted for a site in Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL | |
| sitemapIndex | No | Optional: URL of a sitemap index to list only sitemaps in that index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it lists sitemaps, but does not disclose behavioral details like whether it returns all at once, pagination, or any side effects. As a read operation, it assumes safety but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Action and resource are front-loaded, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description should hint at what is returned (e.g., list of URLs, statuses). It does not. Also lacks mention of scope (only submitted sitemaps) or behavior when siteUrl is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters have clear descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'all sitemaps submitted for a site in Google Search Console', which is specific and differentiates from sibling tools like sitemaps_delete or sitemaps_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., sitemaps_get for single sitemap). No mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a sitemap for a site to Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL | |
| feedpath | Yes | The URL of the sitemap to submit (e.g. 'https://example.com/sitemap.xml') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing whether submission is idempotent, what happens on duplicate submission, or any auth/validation requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description omits return value information (e.g., success/failure indication) and important context like idempotency or prerequisites, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters (siteUrl and feedpath) with clear descriptions, so the description adds no additional semantic value. Baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Submit a sitemap for a site to Google Search Console,' which specifies the verb 'submit' and the resource 'sitemap for a site.' This distinguishes it from sibling tools like sitemaps_delete, sitemaps_get, and sitemaps_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., sitemaps_get, sitemaps_delete) and does not mention prerequisites such as site verification in Google Search Console.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a site (property) to Google Search Console. Verification may still be required.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL to add (e.g. 'https://example.com/' or 'sc-domain:example.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that verification may still be required, which is a key behavioral trait. However, with no annotations, it lacks details on idempotency, error handling, or asynchronous behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is adequate, covering the purpose and a key behavioral note. Could mention success/failure or duplicate handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no further meaning beyond the schema's parameter description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Add' and the resource 'site (property) to Google Search Console', and distinguishes from sibling tools like sites_delete, sites_list, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the simplicity of the tool and sibling context imply it's for adding new sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a site (property) from Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only states 'Remove', implying a destructive action, but does not explain irreversibility, required permissions, or consequences for other Search Console features.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the removal process, reversibility, and potential side effects. It is insufficient for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the only parameter ('The site URL to remove'). The tool description adds the overall context of removal but does not provide additional formatting or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('a site (property)'), and the domain ('from Google Search Console'). It effectively distinguishes from sibling tools like sites_add, sites_get, and sitemaps_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or restrictions mentioned (e.g., site verification status, impact on indexing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about a specific site (property) in Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL (e.g. 'https://example.com/' or 'sc-domain:example.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states 'retrieve information' without disclosing side effects, permissions, rate limits, or return format. This is insufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema, the description is nearly complete. However, it lacks detail on what 'information' is returned and any edge cases (e.g., invalid URLs). Slightly below ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the siteUrl parameter. The description adds no extra meaning beyond the schema, but the schema already provides adequate detail. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about a specific site, using the verb 'retrieve' and resource 'information about a specific site'. It distinguishes from siblings like 'sites_list' and 'sites_add'/'sites_delete', which are list and mutation operations respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing site info, but lacks explicit when-to-use or when-not-to-use guidance. It does not reference sibling tools or provide context for choosing this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sites (properties) you have access to in Google Search Console.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention potential behavioral traits like pagination, rate limits, or whether 'access' implies any permissions beyond listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information. No extraneous words, perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is adequate but lacks details on return format, pagination, or required permissions. It is minimally complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The description adds no additional parameter information, which is appropriate given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (sites/properties), and scope (you have access to). While it doesn't explicitly differentiate from sibling tools like sites_get or sites_add, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to list all accessible sites) but does not provide explicit guidance on when not to use it or mention alternatives such as sites_get for a specific site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a URL in Google's index. Returns the current URL Inspection API result, including indexing status, crawl info, rich results, and AMP status. The deprecated mobileUsabilityResult field may be absent.
| Name | Required | Description | Default |
|---|---|---|---|
| siteUrl | Yes | The site URL (property) the inspected URL belongs to | |
| languageCode | No | Optional BCP-47 language code for localized results (e.g. 'en-US', 'ko') | |
| inspectionUrl | Yes | The fully-qualified URL to inspect (must be under the site) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It usefully states that the tool returns current API results and notes that the deprecated mobileUsabilityResult field may be absent, but it omits permission requirements, rate limits, and whether the operation is strictly read-only. Some behavioral context is provided, but key operational constraints are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise: it states the core action, summarizes return contents, and adds a useful deprecation note in three short sentences. Every sentence adds value without repetition or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read tool with complete parameter schema coverage and no output schema, the description is nearly complete. It lists the main return categories and warns about a deprecated field, though it could additionally mention authentication or property verification requirements. The missing pieces are minor for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the three parameters fully. The description does not add any parameter-specific meaning, syntax, or constraints beyond what the schema provides, such as the relationship between siteUrl and inspectionUrl. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Inspect a URL in Google's index.' It clearly distinguishes this tool from sibling tools like indexing_publish, sitemaps_submit, and search_analytics_query, which perform different actions. An agent can identify the tool's purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no guidance on when to use it vs alternatives, prerequisites, or exclusions. It does not mention that the URL must belong to a verified site property or when inspection is preferable to other indexing tools. Usage is only implicitly suggested by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.6indexing_batch_publish4 fields changedInput schema / properties / notifications / descriptionPrevious value: -"Array of URL notifications (1-100 items). Each item has a url and type."New value: +"Array of eligible URL notifications (1-100 items). Each item has url, contentType, and type."Input schema / properties / notifications / items / properties / contentTypeAdded value: +{
+ "description": "Eligible page type: JobPosting, or BroadcastEvent embedded in VideoObject",
+ "enum": [
+ "JobPosting",
+ "BroadcastEvent"
+ ],
+ "type": "string"
+}Input schema / properties / notifications / items / properties / url / formatAdded value: +"uri"Input schema / properties / notifications / items / requiredPrevious value: -[
- "url",
- "type"
-]New value: +[
+ "url",
+ "contentType",
+ "type"
+]indexing_get_metadata3 fields changedInput schema / properties / contentTypeAdded value: +{
+ "description": "Eligible structured-data type on the page: JobPosting, or BroadcastEvent embedded in VideoObject",
+ "enum": [
+ "JobPosting",
+ "BroadcastEvent"
+ ],
+ "type": "string"
+}Input schema / properties / url / formatAdded value: +"uri"Input schema / requiredPrevious value: -[
- "url"
-]New value: +[
+ "url",
+ "contentType"
+]indexing_publish3 fields changedInput schema / properties / contentTypeAdded value: +{
+ "description": "Eligible structured-data type on the page: JobPosting, or BroadcastEvent embedded in VideoObject",
+ "enum": [
+ "JobPosting",
+ "BroadcastEvent"
+ ],
+ "type": "string"
+}Input schema / properties / url / formatAdded value: +"uri"Input schema / requiredPrevious value: -[
- "url",
- "type"
-]New value: +[
+ "url",
+ "contentType",
+ "type"
+]v1.3.1indexing_batch_publishindexing_get_metadataindexing_publishsearch_analytics_querysitemaps_deletesitemaps_getsitemaps_listsitemaps_submitsites_addsites_deletesites_getsites_listurl_inspection_inspectScored across 13 tools
Tools are mostly clearly separated by resource and action: sites, sitemaps, indexing, URL inspection, and search analytics each have distinct operations. The only mild overlap is between indexing_get_metadata and url_inspection_inspect, but their descriptions clarify that one reports notification history while the other reports index status.
Names consistently use snake_case with a resource_action pattern such as sites_add, sitemaps_submit, and search_analytics_query. Minor deviations like indexing_get_metadata and the redundant-sounding url_inspection_inspect keep it from being fully uniform.
The 13 tools are well-scoped for Google Search Console: four for sites, four for sitemaps, three for Indexing API operations, one for URL inspection, and one for search analytics. Each tool covers a meaningful operation without unnecessary sprawl.
The surface covers the core GSC lifecycle: sites and sitemaps each have list/get/add-or-submit/delete operations, search analytics has flexible querying, URL inspection is included, and Indexing API publish/metadata/batch operations are present. No obvious core workflow is missing.
Read-only Google Search Console MCP server for AI assistants.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Hosted Google Search Console MCP server, with each action switched on or off per account.
SEO MCP: Search Console, GA4, SERP and domain data, rank tracking, AI citations and site fixes.
