google-search-console-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Several tools cluster around the same underlying resources with fuzzy boundaries, such as gsc_get_sitemap, gsc_get_sitemap_health, and gsc_list_sitemaps, or gsc_monitor_indexation_freshness and gsc_get_data_freshness. Search Analytics is also fragmented across gsc_query_search_analytics, gsc_compare_search_types, gsc_find_losses_gains, gsc_cluster_queries, and gsc_detect_cannibalization, making tool selection ambiguous.
Naming Consistency4/5
All tools consistently use a gsc_ prefix with snake_case verb_noun names, which is a clear and predictable pattern. Minor deviations exist in verb choices—monitor, detect, track, plan, and cluster feel less uniform than simple list/get/query verbs—but the overall convention is consistent.
Tool Count3/5
20 tools is on the heavy side for a Google Search Console read-only server, especially since many are specialized wrappers around Search Analytics and URL Inspection that could be consolidated. The count is not unreasonable for the domain, but it feels somewhat over-fragmented.
Completeness4/5
The server covers the main read-only Google Search Console surfaces: properties, sitemaps, Search Analytics, and URL Inspection, with no obvious dead ends. It lacks write operations like submitting or removing sitemaps, but the tool set appears intentionally read-only, so this is a minor gap rather than a critical one.
Average 3.4/5 across 20 of 20 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 disclosing behavior. It only says 'compare performance' without stating that it is a read-only operation, what metrics are returned, how data is aggregated, or any limitations. The description adds minimal behavioral context beyond its primary action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the tool's core function and the relevant search types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a large sibling ecosystem, a one-line description is insufficient. It does not explain the expected return shape, which performance metrics are compared, how dateRange/datePreset interact, or when this tool is the appropriate choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only siteUrl documented. The description lists the search-types values, which partially helps clarify the searchTypes parameter, but it does not explain dateRange or datePreset semantics, and the schema lacks formats for nested date fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compare') and resource ('Search Console search types'), and enumerates the types involved. This distinguishes it from query-level or sitemap tools, though the meaning of 'performance' is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to prefer this tool over alternatives such as gsc_query_search_analytics or gsc_analyze_search_appearance_trends. The sibling list suggests many overlapping comparison/reporting tools, but the description provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the high-level outcome and does not explain detection logic, thresholds, whether it is read-only, or what the returned results look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence with no wasted words and the core purpose is front-loaded. It is concise, though it could be enriched with a brief example or note on output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is too thin for an agent to configure the tool confidently. It does not specify return format, result interpretation, or how the detection thresholds interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, and the description does not explain how parameters like topN, minPages, minImpressions, or maxTopPageClickShare affect detection. The phrase 'multiple pages compete' loosely maps to minPages and maxTopPageClickShare, but the mapping is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'detect queries where multiple pages compete for clicks/impressions.' It clearly distinguishes this from raw Search Analytics query tools and sitemap/indexation tools by focusing on cannibalization detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like gsc_query_search_analytics or gsc_cluster_queries. There are no exclusions, prerequisites, or contextual signals to help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only restates the validate action. It does not disclose what the tool returns on valid/invalid combinations, whether it executes a real Search Console request, or how errors are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the action. It is concise, though the brevity contributes to the lack of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A validation tool with no annotations, no output schema, and a nested dateRange parameter needs more context to be called correctly. The description omits validation criteria, expected outcome, and date format, so an agent cannot confidently predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% and the description does not compensate. It adds no detail about the dateRange structure/format, and it references 'metric' even though no metric property exists in the schema; only dimensions and searchType are minimally self-explanatory via the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate') and identifies the resource (Search Console metric/dimension/search type combination), which distinguishes it from the querying and sitemap sibling tools. However, 'metric' is mentioned even though the input schema contains no metric parameter, so the scope is slightly imprecise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Before executing it' implies the tool is a pre-flight check, giving some usage context. It does not name the specific sibling tool(s) it should precede, such as gsc_query_search_analytics, nor does it state when not to use validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses the operation as 'read-only', which is valuable given no annotations are provided. However, it does not mention other behavioral traits such as whether it queries live GSC data, whether it mutates any state, or what kind of output the plan contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It communicates the core action, resource, and input signals efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, low schema coverage, no annotations, and no output schema, the description is far from complete. An agent would struggle to know what objectives, date presets, or sampling limits to configure or what the resulting plan looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description carries the burden of explaining parameters, but it does not mention siteUrl, dateRange, pageLimit, objectives, or any other parameter. The reference to 'sitemap risk signals and Search Analytics page performance' provides only high-level conceptual context, not actionable parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Build'), a specific resource ('a read-only URL Inspection sampling plan'), and the target context ('for large sites'). It also names source signals ('sitemap risk signals and Search Analytics page performance'), which helps distinguish it from simple inspection tools, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the plan is 'for large sites', which implies a scale-based use case, but it provides no explicit guidance about when to choose this tool over siblings like gsc_bulk_inspect_urls. There are no stated exclusions or alternative routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. It reveals the clustering dimensions, but it does not state the output format, whether data is fetched live from Search Console, or any side effects / limits. For an unannotated tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single information-dense sentence with no filler. It front-loads the verb and resource, then adds the key distinguishing details about token-and-intent-based clustering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, nested objects, no output schema, and no annotations, this description is too sparse. It omits return structure, defaults behavior, and usage context, so an agent cannot fully predict the tool's output or decide when to invoke it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It indirectly relates to brandTerms and categoryRules via 'tokens' and 'intent signals', but it leaves limit, maxClusters, topQueriesPerCluster, datePreset, and searchType semantics to inference from names and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cluster') and resource ('Search Console queries') and adds the method ('simple tokens and intent signals: brand/non-brand, question, category, topic tokens'). This clearly distinguishes it from sibling tools that query raw analytics, validate queries, or detect losses/cannibalization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as gsc_query_search_analytics or gsc_validate_query. There is no mention of preferred contexts, exclusions, or sibling trade-offs, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the mechanism ('by querying recent daily rows'), which implies iterative scanning and ties directly to lookbackDays. But it doesn't disclose what happens when no data exists in the window, the number of API calls implied, or what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean 15-word sentence with zero redundancy; the core purpose is front-loaded. It is appropriately sized but slightly under-specified — there was room to add sibling differentiation or usage guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain return values and edge cases. It does neither: an agent doesn't know what result to expect (a single date? a structured object?), what happens when no data is found within lookbackDays, or which sibling covers the adjacent freshness concept (indexation vs. search analytics data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema already documents siteUrl and lookbackDays adequately, and searchType's enum is self-explanatory. The description's 'recent daily rows' phrasing adds modest context to lookbackDays as a scan window but doesn't add meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Detect the most recent date with Search Analytics data'. This distinguishes it from siblings like gsc_query_search_analytics (general data querying) and gsc_monitor_indexation_freshness (indexation freshness, not data availability). However, it doesn't explicitly name or contrast those alternatives the way the strongest definitions do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't say to use gsc_query_search_analytics for actual data retrieval, gsc_monitor_indexation_freshness for indexation monitoring, or how this freshness check fits into a workflow. Usage context must be inferred entirely from the name and purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full transparency burden. It only warns that the searchAppearance dimension may not be exposed; it does not disclose how trends are computed, what the return shape is, or behavior around limits, missing data, or the comparison periods.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the core purpose and a key caveat are presented immediately. The description earns its place despite being short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no annotations and no output schema, this description is under-specified. It omits default comparison behavior, output shape, sort semantics, page-level grouping effects, and how the current vs previous period comparison works, leaving important aspects of a correct call undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), so the description needs to add meaning. It adds useful context by naming the searchAppearance dimension and the trend-analysis focus, which helps explain delta-based sort and date-range parameters, but it leaves several parameters like topN, limit, minImpressions, and searchType effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (analyze) and a specific resource/dimension (Search Analytics searchAppearance) with a clear focus on structured data and rich-result trend signals. It distinguishes the tool from generic query analytics by naming the exact dimension, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when GSC exposes it' implies a precondition for use, and 'rich-result trend signals' implies the intended scenario. However, the description gives no explicit guidance on when to choose this tool over alternatives such as gsc_query_search_analytics or gsc_compare_search_types, so the agent must infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries most of the burden. It discloses that the tool returns analytics data, implying a read-only query operation, but it does not mention auth requirements, rate limits, pagination behavior, or potential large-response implications. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences, with the primary purpose and returned data front-loaded. The pointer to gsc:// resources is efficient and avoids repeating schema content. A bit more behavioral context could be added without making it bloated, but the current structure is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects, enums, no output schema), the description provides a reasonable high-level overview and links to compatibility references. However, it lacks usage guidance and does not convey how outputs are structured or paginated. The schema carries substantial detail, so this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50%, the description compensates partly by listing the core metrics and dimensions and directing users to gsc://metrics, gsc://dimensions, gsc://filters, and gsc://compatibility for field-level details. It does not deeply explain parameter interactions, but the schema covers several important parameters such as dataState, aggregationType, and autoPaginate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Query' and the resource 'Google Search Console Search Analytics', and enumerates the returned metrics and dimensions. It is obvious what the tool does, though it does not explicitly name sibling tools to differentiate itself, relying instead on the generic 'Search Analytics' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus sibling tools like gsc_compare_search_types or gsc_analyze_search_appearance_trends. The pointer to gsc://metrics, gsc://dimensions, and gsc://compatibility tells agents where to find field rules, but not which tool to choose for a given analysis scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. The verb 'Inspect' implies read-only behavior and the quota line adds rate-limit context, which is useful. However, it does not explicitly state that the tool makes no mutations, what response shape to expect, or any error/latency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The primary action and scope are front-loaded, and the quota constraint is isolated as a separate, easily digestible sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the inspection dimensions and quota, and the schema covers all parameters, which is adequate for a straightforward inspection tool. But with no output schema and no usage guidance, the description leaves an agent to infer the response format and when to prefer this over the bulk sibling. A more complete description would state that results return per-category status findings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the structured data. The description adds no parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not conflict or add detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') with a clear resource ('a URL') and enumerates the inspected facets: indexing status, crawl info, mobile usability, AMP, and rich results. It does not explicitly differentiate from gsc_bulk_inspect_urls, but the singular focus is evident from the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance explains when to choose this tool over alternatives. The presence of gsc_bulk_inspect_urls as a sibling implies a singular-vs-bulk distinction, but the description never states this. The quota mention is operational context, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly labels the operation as read-only, which is a meaningful safety trait, and lists the response's broad contents. However, it does not disclose potential caveats like quota/rate-limit behavior, what triggers a warning or error, or any fallback behavior beyond what the schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action ('Return an enriched read-only sitemap health summary') and then lists the distinguishing output elements. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description covers the key expectations: it is read-only and returns named summary categories. It could define 'health' or enumerate conditions for warnings/errors more explicitly, but the schema handles the one parameter and the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete documentation for the single siteUrl parameter, including format, examples, and the GSC_SITE_URL fallback. Schema description coverage is 100%, so the description adds no parameter-specific meaning; the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Return), a clear resource (sitemap health summary), and distinctive output categories (status totals, submitted/indexed content counts, warnings, errors). It does not explicitly contrast itself with siblings like gsc_get_sitemap or gsc_track_sitemap_deltas, but the health-summary framing is specific enough to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus nearby alternatives such as gsc_get_sitemap, gsc_list_sitemaps, or gsc_health_check. The description only states what the tool returns, leaving usage context and exclusions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is read-only, does not store state, and returns alert/review/ok assessments. It does not mention quota consumption, error handling, or how continueOnError affects behavior, but the core safety profile is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the key facts: read-only, URL Inspection watchlist, URL limit, and assessment output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a complex nested schema and no output schema, the description does not explain how expectedVerdict, expectedCanonical, and expectedCoverageState influence the returned alert/review/ok assessment. It also does not clarify the meaning of the output categories or the behavior of continueOnError, leaving an agent under-equipped to invoke the tool correctly for nuanced cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers urls, siteUrl, and languageCode with descriptions, but the tool description adds almost no parameter-level meaning. It does not explain the purpose of tags, label, priority, expectedVerdict, expectedCanonical, expectedCoverageState, or continueOnError, which are central to configuring watchlist entries correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only URL Inspection watchlist that inspects up to 10 URLs and returns alert/review/ok assessments. It names a specific resource and action, but does not explicitly differentiate it from siblings like gsc_inspect_url or gsc_bulk_inspect_urls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'watchlist for critical URLs' implies a monitoring use case, and the read-only plus no-state-storage behavior hints at safe repeated use. However, the description does not state when to prefer this tool over gsc_inspect_url, gsc_bulk_inspect_urls, or gsc_monitor_indexation_freshness, nor does it give exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full behavioral disclosure. It states that deltas are returned, but it does not disclose that results are likely limited/sorted via topN and sortBy, that minAbsClickDelta filters results, or how default comparison periods are derived. These are material behaviors for a comparison tool and are left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It efficiently captures the tool's core purpose and output without repeating schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 10 parameters, nested date-range objects, no output schema, and no annotations. A one-sentence description is insufficient to cover default-period behavior, result ordering/truncation, filtering, or output shape. An agent would need to infer too much to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate for the undocumented parameters. It maps conceptually to 'query or page' and to the delta metrics, but it adds little meaning for topN, limit, sortBy, datePreset, or searchType. The enum names help, but the description itself does not clarify how these parameters shape the comparison.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('compare') and names the resource ('query or page performance') and the exact output metrics ('click/impression/CTR/position deltas'). It clearly distinguishes this from siblings like gsc_compare_search_types, which compares search types rather than periods, and gsc_query_search_analytics, which is not period-delta focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever an agent needs to compare two periods of query or page performance. It does not explicitly mention exclusions or alternatives, so it stops short of a 5, but the contextual signal is strong enough for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the important 'read-only' safety trait and hints that the inspection portion is quota-limited via 'small sample'. It omits authorization requirements, composite-call failure modes (this likely aggregates multiple GSC endpoints), and rate-limit behavior beyond what the schema's quota note already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the critical 'read-only' qualifier and enumerates the three snapshot sections in a scannable list with zero filler. It loses a point for mild redundancy — 'monitoring' echoes the tool name and the packed three-item list could be structured more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter composite tool with no annotations and no output schema, the description names the three output domains but gives no hint of the return structure, does not mention Google Search Console authorization requirements, and does not explain that this aggregates multiple data sources. 'Snapshot' gives some sense of shape, but an agent still cannot predict the response format. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 83%, setting a baseline of 3. The description adds real value by mapping parameters into three functional buckets: freshness (lookbackDays, freshnessLagWarningDays, searchTypes), sitemap totals (siteUrl), and the optional URL Inspection sample (inspectUrls, languageCode). This grouping helps an agent reason about which parameters matter for a given goal beyond what the schema states individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names a composite resource scope — Search Analytics freshness, sitemap indexation totals, and a URL Inspection sample — and frames it as a read-only monitoring snapshot. This distinguishes it from dedicated siblings like gsc_get_data_freshness or gsc_inspect_url by signaling a combined overview tool. It stops short of a 5 because 'snapshot' is a weak verb and the exact return contents are not specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'monitoring snapshot' framing implies use for periodic overview checks rather than deep dives into a single metric, which is useful context. However, with 18 sibling tools it never states when to prefer this composite over gsc_get_data_freshness, gsc_inspect_url, or gsc_get_sitemap_health, nor does it give any when-not-to-use exclusions. Usage is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions 'read-only sites.get', which is a clear indication of a non-mutating operation. However, it does not disclose potential error conditions, authentication requirements, or behaviors for invalid site URLs. The read-only trait is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action ('Get one Search Console property') and immediately adds the distinguishing detail about permission level and the API method. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with a single parameter and no output schema. The description mentions the returned permission level, which partially addresses the return value. It does not detail error handling or edge cases, but for a straightforward read operation with one parameter, this is reasonably complete. The sibling gsc_list_sites is implicitly differentiated by 'one', though not explicitly named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter siteUrl is thoroughly documented with examples and a default. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'one Search Console property', and distinguishes it by adding 'and its exact permission level' and the API reference 'sites.get'. It unambiguously differentiates from gsc_list_sites (which lists multiple properties) by specifying 'one'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like gsc_list_sites. It implies a single-property use case via 'one', but does not state when to choose this over listing or mention any prerequisites, exclusions, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It usefully states that results include processing status and submitted/indexed counts. It does not mention read-only nature, pagination, or error behavior, but for a straightforward list operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that names the action, resource, and key output content with no filler. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-param list operation with fully documented schema and no output schema. The description gives an adequate overview of the return content (status, counts). A slightly richer note on output shape or sibling alternatives would make it fully complete, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have descriptive comments. The description adds no parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List sitemaps submitted for a Search Console property' plus what is included (processing status, submitted/indexed counts). It is clear, though it does not explicitly differentiate itself from siblings like gsc_get_sitemap or gsc_get_sitemap_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: enumerating submitted sitemaps for a property, with optional sitemapIndex for narrowing. But it gives no explicit guidance on when to prefer this over alternatives such as gsc_get_sitemap or gsc_get_sitemap_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly says 'Read-only' and 'no state is written', which clearly signals a safe, non-mutating operation. It doesn't cover rate limits or authentication, but the core side-effect profile is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the most important information front-loaded: the tool is read-only, it fetches a snapshot, it compares to a baseline, and it writes no state. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too thin: it doesn't describe the shape of the returned deltas or how the output is meant to be used as a future baseline. It also omits guidance on the behavior of includeUnchanged and minAbsIndexedDelta, leaving an agent to infer important filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema description coverage, the schema already documents siteUrl, baseline, and minAbsIndexedDelta. The description adds only minimal parameter-level context by labeling the baseline as 'agent-provided', and it does not clarify includeUnchanged, which lacks a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the operation: a read-only sitemap delta tracker that fetches the current sitemap snapshot and compares it to an agent-provided baseline. It specifies the resource (sitemap) and action (fetch/compare), but does not differentiate it from sibling sitemap tools such as gsc_list_sitemaps or gsc_get_sitemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—comparing a current snapshot to a baseline to detect deltas—and notes no state is written. However, it provides no explicit when-to-use/when-not-to-use guidance or alternatives among the many sitemap/indexation sibling tools, so an agent may need to infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does useful work: it reveals the 2000 requests/day/property quota, the sequential processing approach, and that results are normalized. It does not cover failure behavior or permissions, but the schema's continueOnError field handles error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the core action front-loaded and the quota immediately stated. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers quota and sequential processing, and the schema fully documents parameters. However, with no output schema and no annotations, 'normalized URL Inspection results' is vague, and the description never explicitly explains per-URL error output or the single-URL alternative. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented. The tool description adds no additional parameter-level meaning, so the appropriate baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Inspect multiple URLs') and signals bulk behavior, which distinguishes it from the single-URL sibling gsc_inspect_url. It does not explicitly name that alternative, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational context such as the conservative sequential limit and daily quota, but it never explicitly states when to prefer this tool over gsc_inspect_url or when not to use it. The batch use case is implied by the name and 'multiple URLs' rather than made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It signals read-only intent ('Get') and discloses that the response includes warnings/errors and fetch state, which tells the agent the tool surfaces problem states rather than only success data. It does not cover error/404 behavior, authentication needs, or rate limits, but for a read-oriented fetch this is an adequate baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 24-word sentence in which every element earns its place: scope ('one'), status ('submitted'), lookup key ('full feed path'), and the response content list. No filler, no repetition of schema details, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a low-complexity fetch tool with both parameters fully documented, and the missing output schema is partially compensated by enumerating the response fields. It does not clarify the relationship to gsc_get_itemap_health (which likely overlaps on fetch state and warnings/errors) or reference the list-then-fetch workflow with gsc_list_itemaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that feedpath is the primary lookup key and that the sitemap must have been submitted, though the schema already says 'exactly as submitted to Search Console,' so the description adds little meaning beyond the structured parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), a precise resource ('one submitted sitemap'), and the lookup mechanism ('by full feed path'). The word 'one' distinguishes it from sibling gsc_list_sitemaps, and the enumerated response contents (type, fetch state, warnings/errors, totals) make its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by full feed path' implies a necessary precondition — the agent must already know the exact submitted URL, otherwise enumeration via gsc_list_sitemaps would be required first. However, no sibling tools are named and no when-not-to-use conditions are stated; usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the operation is a read-oriented listing bounded by credentials, but it does not disclose pagination behavior, response shape, permission implications, or whether the results are complete or limited in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly written sentence that immediately states the action, the resource, and the credential scope. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description is largely sufficient: it tells the agent what the tool returns conceptually and what scope applies. The lack of an output schema and the absence of any note about usage context keep it from being fully complete, but the simplicity of the tool limits the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is nothing the description needs to add about parameter meaning. The baseline of 4 applies because no parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies a clear resource ('all Google Search Console properties accessible with the current credentials'). It clearly distinguishes itself from siblings like gsc_get_site (single property) and gsc_list_sitemaps (sitemaps, not sites).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: enumerating available GSC properties before working with a specific one. However, it does not explicitly state when to use this tool versus gsc_get_site or other site-level siblings, nor does it mention prerequisites or typical call patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful safety context by stating that the tool verifies read-only authentication and does not expose tokens. It could further clarify failure behavior or whether live network calls are made, but the key safety traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence delivers the action, scope, and a safety caveat without any filler. The key purpose is front-loaded and every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, and the description covers its main purpose and safety behavior. However, with no output schema and no annotations, the return shape or success/failure indicators are not described, leaving some inference required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, siteUrl, is already fully documented in the schema, including the GSC_SITE_URL fallback. The description's mention of 'configured default site' echoes that fallback but adds no new format or usage detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Verify' and names concrete resources: read-only authentication, visible properties, configured default site, and permission levels. This clearly differentiates it from sibling data-query or sitemap tools and makes the tool's diagnostic scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a health-check/diagnostic use case but does not explicitly state when to use this tool over siblings like gsc_list_sites or gsc_get_site. It gives clear context but no direct when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-search-console-mcp-server MCP server](https://glama.ai/mcp/servers/getmcpads-com/google-search-console-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/getmcpads-com/google-search-console-mcp-server)

Score Badge

Copy to your README.md:

[![google-search-console-mcp-server MCP server](https://glama.ai/mcp/servers/getmcpads-com/google-search-console-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/getmcpads-com/google-search-console-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/getmcpads-com/google-search-console-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server