Google Search Console (GSC) MCP

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation2/5
Multiple tools serve overlapping purposes: sitemap management has three tools (get_sitemaps, list_sitemaps_enhanced, manage_sitemaps) and URL inspection has three (batch_url_inspection, inspect_url_enhanced, check_indexing_issues). Search analytics tools also overlap, causing potential ambiguity.
Naming Consistency2/5
Naming pattern is inconsistent: some tools use verb_noun (add_site, delete_site, submit_sitemap) while others use get_X or other patterns (get_sitemaps, inspect_url_enhanced, batch_url_inspection). This mix reduces predictability.
Tool Count3/5
20 tools for a GSC server is near the upper bound of reasonableness. While the scope is broad, there is redundancy (e.g., manage_sitemaps duplicates individual sitemap tools) suggesting a leaner set would be more appropriate.
Completeness3/5
Covers core GSC areas (sites, sitemaps, search analytics, URL inspection) but lacks coverage reports (like index coverage or mobile usability). Some CRUD operations for sitemaps are duplicated rather than streamlined.
Average 4.2/5 across 20 of 20 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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 provided, so description must carry full burden. Discloses read nature implicitly but no explicit safety, auth, rate limits, or destructive behavior. Minimal beyond purpose.
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?
Description is brief, front-loaded with purpose, and includes a structured 'Args:' section. Every sentence adds value without unnecessary verbosity.
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 basic use with two parameters and output schema present. However, lacks differentiation from sibling tools and does not clarify scope of 'performance overview' compared to other analytics endpoints.
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?
Adds significant meaning to site_url (exact from list_properties, domain vs subdomain) and explains days default. Schema coverage is 0%, so description compensates well.
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 states 'Get a performance overview for a specific property' and explains the site_url parameter. However, it does not explicitly differentiate from similar tools like 'get_search_analytics' or 'get_advanced_search_analytics'.
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?
Provides guidance on site_url format and days default, including advice on domain vs subdomain usage. Lacks explicit when-to-use vs siblings or when-not-to-use.
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 must disclose behavior. It only covers URL format requirements but omits behavior on duplicate adds, error handling, rate limits, or authentication needs.
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 relatively concise and upfront with the purpose, though the list of URL examples takes some space. Every sentence adds value, but it could be trimmed slightly.
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 one-parameter tool with an output schema, the description covers the parameter well but lacks information on behavior such as idempotency, errors, or prerequisites. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter site_url is thoroughly explained with exact match requirements, multiple URL format examples, and the special sc-domain: prefix for domain properties, adding significant value beyond the schema.
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 'Add' and the resource 'site' in the context of Search Console properties, distinguishing it from sibling tools like delete_site or list_properties.
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 when to use the tool (when adding a site) but does not provide explicit guidance on when not to use it or mention alternatives. No prerequisites or permissions are discussed.
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 full burden. It explains parameter details (e.g., site_url format, date format) but does not discuss side effects, return behavior, or safety (e.g., read-only). The basic purpose is clear but lacks depth.
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 efficient: one sentence stating purpose, followed by a focused Args block with line-by-line parameter explanations. No wasted words, and the key action 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?
The tool has 7 parameters and an output schema; the description covers all parameters adequately for invocation. However, it does not describe what metrics are compared or what the output contains, relying on the output schema. Missing details like comparison logic limit completeness.
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 0%, and the description adds significant meaning: site_url is explained with examples and domain property hints, periods specify YYYY-MM-DD format, and dimensions/limit have defaults clarified. This compensates well for the bare schema.
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 'Compare search analytics data between two time periods', specifying the action (compare) and resource (search analytics data). This distinguishes it from sibling tools like get_search_analytics which are single-period, though no explicit sibling mention is needed.
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. There is no mention of prerequisites, when not to use, or comparison with related tools like get_search_analytics.
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, and the description does not disclose behavioral traits such as irreversibility, required permissions, or side effects of deletion. The only behavioral context is the parameter format.
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 concise with a clear purpose statement and focused parameter details. A slight improvement could be structuring the Args section more formally.
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 the essential parameter semantics but lacks behavioral transparency and does not reference the output schema. For a simple deletion tool, it is adequate but could mention return values or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description extensively explains the 'site_url' parameter with exact match requirements and format examples, adding significant value beyond the schema.
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 'Remove a site from your Search Console properties,' using a specific verb and resource, which distinguishes it from sibling tools like 'add_site' or 'delete_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 does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or when not to use it. The usage is implied but not guided.
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 must disclose behavioral traits. It states the tool lists sitemaps with detailed info, but does not mention that this is a read-only operation, any side effects, error conditions, or rate limits. The behavioral traits are insufficiently 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?
The description is very concise: one sentence for purpose, followed by bullet-like parameter explanations. Every sentence adds value and is front-loaded. No redundant or verbose content.
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 simple two-parameter tool and existence of an output schema, the description is fairly complete. However, it lacks explanation of what 'detailed information' means, and does not address pagination or limits. Surfficient for a basic list operation but could be more informative.
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 0%, but the description provides meaningful explanations for both parameters: site_url is explained with examples and domain property usage, sitemap_index is explained as optional for child sitemaps. This adds significant value beyond the schema, though could include more validation details.
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 it lists all sitemaps for a specific property with detailed information. This distinguishes it from siblings like 'get_sitemaps' (basic listing) and 'get_sitemap_details' (single sitemap). The verb 'list' and resource 'sitemaps' are specific.
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 explains how to use the site_url parameter (e.g., domain property covering subdomains) and mentions filtering by page. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'get_sitemaps' or 'submit_sitemap'.
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, and the description does not disclose behavioral traits such as rate limits, read-only vs mutation, error handling, or response format. The description carries full burden but gives minimal behavioral context.
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 relatively concise and structured with clear bullet points for parameters. However, the 'Args:' section could be integrated more seamlessly for brevity.
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?
Having an output schema reduces the need to describe return values, but the description lacks details on error behavior, maximum URLs, and prerequisites. It is adequate but not comprehensive.
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 coverage is 0%, but the description adds meaning: explains site_url format with examples and specifies that urls should be 'one per line'. This adds value beyond the plain schema types.
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 'check' and the resource 'indexing issues' across multiple URLs. It distinguishes from sibling tools like inspect_url_enhanced (single URL inspection) by specifying multiple URLs.
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?
Provides explicit guidance on site_url format (e.g., domain vs site-level property) and how to filter by page. However, lacks explicit instructions on when not to use this tool compared to alternatives like batch_url_inspection.
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 does not declare whether the tool is read-only, has side effects, or any rate limits. The description focuses on parameter format rather than behavioral traits.
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 concise with no redundant information. It uses a clear 'Args:' structure and front-loads the purpose. Every sentence adds value.
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?
Given the tool's simplicity (2 parameters, no annotations, output schema exists), the description is mostly complete. It explains parameters thoroughly but lacks behavioral details that would be expected to fully inform an agent. The output schema likely covers return values, so that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds comprehensive meaning: for site_url, it provides exact format, examples, and domain property usage; for page_url, a clear description. This compensates fully for the lack of schema descriptions.
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 tool's purpose: 'check indexing status and rich results in Google.' It uses a specific verb ('check') and resource ('URL indexing status'), and distinguishes from siblings like 'batch_url_inspection' which handles multiple 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 description provides parameter usage guidance (site_url format, domain vs subdomain) but does not explicitly state when to use this tool versus alternatives like 'batch_url_inspection' or 'check_indexing_issues'. Usage is implied but lacks 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 present, so description carries full burden. Only mentions API limits; does not disclose error behavior, idempotency, or output format beyond what schema provides.
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 plus clear parameter descriptions. No redundant information; front-loaded with main purpose.
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?
Covers parameters well and mentions API limits. Does not specify batch size or error handling, but output schema likely covers return format. Minor gap for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds detailed semantics: site_url includes examples and domain property usage, urls specifies 'one per line'. Compensates fully for missing schema descriptions.
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 explicitly states 'Inspect multiple URLs in batch (within API limits)', clearly identifying the verb, resource, and scope. It distinguishes from sibling tools like 'inspect_url_enhanced' which is likely single-URL.
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?
Provides guidance on using site_url (domain vs subdomain) and mentions API limits, but lacks explicit comparison to siblings or when not to use 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?
No annotations are provided, so the description must cover behavioral traits. It discloses the action (listing) but does not state whether this is a read-only operation, what permissions are needed, or any side effects. For a listing tool, the description should at least imply it is non-destructive.
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 highly concise: two sentences plus a brief argument block. Every part is necessary and adds value. There is no superfluous text.
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 simple (one parameter), and an output schema exists, so the description need not detail return values. The description covers the parameter well and provides context about domain properties. A perfect score would require mentioning that the tool lists all sitemaps (including state), which it does, so the slight deduction is for not explicitly stating that it is read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the lack of schema description coverage by thoroughly explaining the site_url parameter, including examples, format requirements, and important domain property behavior. This adds significant value beyond the schema.
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: 'List all sitemaps for a specific Search Console property.' This clearly communicates the action and scope, and distinguishes it from siblings like 'list_sitemaps_enhanced' or 'get_sitemap_details' by focusing on the basic listing for a given property.
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 provides detailed usage guidance, including the exact format of site_url and notes on domain property behavior (covers all subdomains, use domain property and filter by page for specific subdomain analysis). However, it does not explicitly state when to use this tool versus alternatives such as 'list_sitemaps_enhanced'.
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 bears the full burden. It identifies the action as deletion (mutation) and explains parameter details, but does not disclose side effects (e.g., reversibility, impact on indexing) or required permissions.
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 concise, using a structured 'Args' block with clear parameter descriptions. Every sentence serves a purpose, and there is no redundant information.
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 two-parameter tool with an output schema (though not shown), the description covers both parameters adequately and provides necessary context for usage. It does not explain the response, but the output schema can fill that 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?
Schema description coverage is 0%, but the description significantly adds meaning by explaining site_url with examples (including domain vs subdomain) and specifying sitemap_url as the full URL. This goes beyond what the schema provides.
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 explicitly states 'Delete (unsubmit) a sitemap from Google Search Console.' The verb 'delete' and resource 'sitemap' are clearly defined, distinguishing it from siblings like submit_sitemap or list_sitemaps.
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?
Provides clear guidance on the format of site_url (exact GSC property URL with examples) and explains domain property usage. It does not explicitly state when to avoid using this tool, but the purpose is distinct enough that alternatives are obvious.
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 burden. It describes the tool as a read operation (getting details) and indicates the expected input format, but it does not disclose behavioral traits such as required permissions, rate limits, or error responses. The description adds some context but is not comprehensive.
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 extremely concise—just two sentences for the main purpose, plus a multi-line parameter explanation. Every part is necessary: the main purpose, the parameter definition with examples, and the subdomain note. No fluff.
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 has one parameter and an output schema (not shown). The description explains the input thoroughly and references where to find valid values (list_properties). It does not describe the output, but the output schema covers that. Missing explicit error scenarios or prerequisites, but given the simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to add all meaning. The description thoroughly explains the site_url parameter: its source (list_properties), exact format with examples (including the sc-domain: prefix), and a key behavioral note about domain properties covering all subdomains. This provides complete semantic understanding beyond the schema's type and title.
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 starts with 'Get detailed information about a specific Search Console property.' which clearly states the verb (Get) and resource (detailed information about a Search Console property). It differentiates from siblings like list_properties by specifying it's for a specific property.
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 provides guidance on the site_url parameter, including example formats and an important note about domain properties covering subdomains. This helps the agent decide when to use this tool and how to construct the input, but it does not explicitly list alternatives or when not to use it.
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 provided, so description carries full burden. It states 'get detailed information' but does not disclose specifics of return format, side effects, or authorization needs. The presence of an output schema partially compensates.
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 concise and well-structured, with a clear header and organized args section. Every sentence provides valuable information without redundancy.
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?
Given the output schema exists, the description adequately covers the input requirements and usage context. It could mention potential errors or limitations, but overall is sufficient for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains both parameters: site_url includes examples and domain property guidance, sitemap_url is clearly defined. This adds significant meaning beyond the schema.
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 'Get detailed information about a specific sitemap', using a specific verb and resource. It distinguishes from sibling tools like get_sitemaps (list) and manage_sitemaps (actions).
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?
Provides clear guidance on when to use the tool (to get details on a specific sitemap) and explains parameters in detail, including domain property handling. However, it lacks explicit when-not-to-use or alternative tool mentions.
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 partially carries the burden. It discloses that actions include submit and delete (mutations) and list/details (reads), but does not elaborate on idempotency, error handling, or side effects like overwriting on submit.
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 concise, using a short paragraph and a clear list of arguments. Every sentence provides value, and the structure is easy to parse.
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?
Given the tool's complexity with 4 parameters and multiple actions, the description covers parameter usage and references list_properties for site_url format. It does not mention return values, but an output schema exists. Minor gap: no mention of prerequisites like property being added first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description fully compensates. It explains site_url format with examples, action as the operation, sitemap_url as required for specific actions, and sitemap_index as optional for listing children. This adds crucial meaning beyond the schema names.
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 tool is for managing sitemaps with actions list, get details, submit, delete. It distinguishes from sibling tools by being the all-in-one version, and the purpose is immediately clear.
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 provides context for each parameter, especially site_url with format examples and action usage. However, it does not explicitly warn when to use this tool versus individual sitemap tools, missing some guidance on when not to use.
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 exist, so description must carry the burden. It indicates a write operation but does not disclose side effects, error conditions, or authentication needs. Adequate for a simple action but lacks depth.
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?
Concise two-sentence description with front-loaded purpose, followed by well-structured parameter documentation. No extraneous information.
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?
Covers the essential action and parameter details. An output schema exists to handle return values. Could mention prerequisites like having a valid GSC property, but overall complete for a submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides detailed semantics for both required parameters, including examples, format clarification, and usage notes for domain properties, adding significant meaning.
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 action 'Submit a new sitemap or resubmit an existing one to Google' with specific verb and resource. It distinguishes from sibling tools like delete_sitemap and list_sitemaps_enhanced by focusing on submission.
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?
Provides clear usage context by explaining site_url format and domain property handling. Does not explicitly state when not to use or alternatives, but the purpose is self-evident for submission.
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 burden. It discloses default values and row_limit limitations but does not explicitly state read-only nature, authentication needs, or data freshness. It is somewhat transparent but could be more explicit about safety.
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 well-structured with an 'Args:' section, uses clear language, and every sentence adds value without redundancy. It is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input parameters comprehensively, explains limitations and alternatives, and with an output schema present, does not need to describe return values. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter: site_url with format examples, days default, dimensions options with examples, and row_limit with usage ranges. Fully compensates for missing schema descriptions.
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+resource ('Get search analytics data for a specific property') and clearly distinguishes from siblings like 'get_advanced_search_analytics' by noting its limitation (max 500 rows) and the alternative for bulk exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs the advanced version, explains how to handle domain properties with filtering, and gives row_limit recommendations for different analysis depths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses pagination behavior (row_limit max 25000, start_row), filter logic (AND across multiple dimensions), data_state options (all vs. final with lag), and overrides between filter parameters.
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 well-structured with parameter explanations in a bullet-like format, but it is lengthy. Every sentence adds value, so it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, output schema exists), the description covers input usage thoroughly, including pagination, filtering, sorting, and data state. Output details are delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds comprehensive meaning to all 14 parameters, including examples for filters and explanations of defaults and constraints.
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 tool retrieves 'advanced search analytics data with sorting, filtering, and pagination.' This distinguishes it from simpler tools like get_search_analytics and compare_search_periods.
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 provides specific usage advice, such as how to use site_url for domain vs. subdomain analysis and guidance on when to use filters vs. filter_dimension. However, it does not explicitly mention when NOT to use this tool or compare it directly to siblings.
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 full burden. It discloses behavioral traits: domain properties cover subdomains (filter by page for subdomain analysis), row_limit max 500 with pagination alternative. It does not explicitly state read-only nature but it is implied. No contradictions.
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 front-loaded with a clear purpose statement. Every sentence serves a purpose – parameter explanations, usage tips, alternative tool reference. No wasted words despite being detailed.
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?
Given 4 parameters, output schema existence, and sibling tools, the description covers parameters well and mentions an alternative tool. It does not describe the output structure (though output schema handles that) or authentication requirements, which are standard and can be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides thorough inline parameter guidance: site_url (example, domain property behavior), page_url (specific page), days (default 28), row_limit (ranges, max, alternative). Each parameter gains meaningful context beyond the bare schema.
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 tool's purpose: 'Get search analytics data for a specific page, broken down by query.' This verb+resource+scope formulation distinguishes it from siblings like get_search_analytics (likely overall data) and get_advanced_search_analytics (bulk pagination).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: site_url format (with domain property subdomain coverage), page_url requirement, row_limit ranges (5-20 overview, 50-200 analysis, up to 500 comprehensive), and clearly names get_advanced_search_analytics as the alternative for bulk exports beyond 500 rows.
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 burden. It discloses that the tool retrieves 'all verified sites, domain properties, and URL-prefix properties', indicating a read-only listing of accessible resources. However, it doesn't explicitly state behavior for empty accounts or permission issues, leaving a minor 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?
Three concise sentences front-loaded with the main action. Every sentence adds value: first states function, second adds detail on what is listed, third provides usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete. It explains what the tool returns (list of properties/sites) and when to use it (first step to get site_url). No further details are needed for a simple listing tool.
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?
There are zero parameters, so schema_description_coverage is 100%. The baseline for no parameters is 4, and the description does not need to add extra details since there is nothing to parameterize. It correctly omits any parameter references.
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?
Description clearly states it lists all GSC properties and sites the user has access to, with specific verb 'List' and resource 'properties and sites'. It distinguishes from sibling tools like add_site or get_site_details by focusing on enumeration rather than individual operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Always call this first to get the exact site_url needed for other tools', providing clear when-to-use guidance and establishing it as a prerequisite. The context signals show no required parameters, reinforcing its role as an initial discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses destructive behavior (deletes token file) and interactive nature (triggers browser flow). The agent is well-informed of side effects.
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?
Three sentences, each adding value: action, mechanism, use case. No fluff, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully explains purpose, behavior, and context. No gaps remain.
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?
No parameters exist (baseline 4). Description does not need to add parameter info; the schema is already exhaustive.
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 tool performs a logout and login sequence, with specific actions: deleting the OAuth token and triggering browser auth. It distinguishes from siblings as no other tool handles authentication.
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?
Explicitly says 'useful when you need to switch to a different Google account,' providing clear context. No exclusions or alternatives listed, but given no sibling auth tools, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the behavioral disclosure burden. It accurately describes the tool as returning a list of tools grouped by category and indicates auth status, with no side effects or destructive actions mentioned. This is complete for a read-only discovery tool.
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 concise (4 sentences) and front-loaded with the primary action. Every sentence adds necessary information: purpose, usage guidance, return format, and value proposition. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear output schema), the description provides all essential context: what it does, when to use it, what it returns, and how it benefits the agent. It is complete for effective invocation.
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 no parameters, and the input schema is fully covered (100%). The description does not need to add parameter details, so a baseline of 4 is appropriate. The description adds no param-specific info, which is fine.
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 it returns a full list of tools, auth status, and getting-started info. It distinguishes itself from sibling tools (e.g., add_site, inspect_url_enhanced) by being the meta-tool that lists all available tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to call it ('when asked what tools are available, what this server can do, or how to get started') and emphasizes calling it first. It also provides a rationale ('faster than searching individually'), effectively guiding the agent's decision-making.
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-GSC-MCP MCP server](https://glama.ai/mcp/servers/amirjahfar1/Google-Search-Console-GSC-MCP/badges/card.svg)](https://glama.ai/mcp/servers/amirjahfar1/Google-Search-Console-GSC-MCP)

Score Badge

Copy to your README.md:

[![Google-Search-Console-GSC-MCP MCP server](https://glama.ai/mcp/servers/amirjahfar1/Google-Search-Console-GSC-MCP/badges/score.svg)](https://glama.ai/mcp/servers/amirjahfar1/Google-Search-Console-GSC-MCP)

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/amirjahfar1/Google-Search-Console-GSC-MCP'

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