Google Search Console MCP Server

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation2/5
Multiple tools have overlapping purposes, such as list_sitemaps vs list_sitemaps_enhanced, and get_search_analytics vs get_advanced_search_analytics. The descriptions help but the boundaries are unclear, especially for batch_url_inspection vs check_indexing_issues.
Naming Consistency4/5
Tool names generally follow the verb_noun pattern (list_properties, get_search_analytics, compare_search_periods). Minor deviations like batch_url_inspection and the 'enhanced' suffix in inspect_url_enhanced/list_sitemaps_enhanced cause slight inconsistency but overall naming remains predictable.
Tool Count4/5
15 tools is at the upper boundary of the ideal range but appropriate for the scope of GSC. However, several tools could be merged (e.g., analytics variants, sitemap listers), making the count slightly inflated.
Completeness4/5
The server covers the main GSC features: properties, analytics, sitemaps, and URL inspection. Minor gaps exist (e.g., no write actions like submitting sitemaps), but for a read-only server, the coverage is solid. The redundant tools actually add some completeness to specific use cases.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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 are present, so the description carries the full burden of disclosing behavior. It only explains the site_url argument and says 'list all sitemaps', but does not mention return format, possible errors, rate limits, or whether it includes submitted vs. detected sitemaps. This is a significant gap for a tool that presumably queries a service.
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: a one-sentence purpose plus an Args section. The formatting is clean and easy to scan. The guidance about domain properties is useful and not redundant. It earns its keep without bloat.
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 there is an output schema (not shown) and only one parameter, the description covers the key usage point. However, the lack of distinction from sibling tools such as list_sitemaps_enhanced leaves a completeness gap. A brief 'use this instead of X when...' would make it more 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?
The schema has no parameter descriptions (0% coverage), but the description includes a detailed Args section that explains site_url with examples and clarifies the semantics of domain properties. This fully compensates for the schema gap, going beyond what the JSON schema provides.
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 action: 'List all sitemaps for a specific Search Console property.' It uses a specific verb and resource, and mentions the property scope. However, it does not differentiate from the sibling tool 'list_sitemaps_enhanced', so it misses the sibling differentiation part.
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?
There is some implied usage context: it tells users to supply an exact property URL and explains the difference between domain and URL-prefix properties. But it does not explicitly state when to use this tool versus alternatives like list_sitemaps_enhanced or get_sitemap_details, and provides no exclusion criteria.
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 adds useful detail that site_url must match an exact property from list_properties, clarifies how domain properties work, and notes the default days value. However, it omits broader behavioral traits such as read-only status, potential rate limits, or any error conditions.
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 compact and front-loaded with the primary purpose, followed by a concise Args list. Every sentence adds meaningful context without redundancy, making it easy to parse quickly.
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, two parameters, and existence of an output schema, the description is adequate. It covers the key domain-specific nuances (property formats, domain coverage) that structured fields cannot. It loses a point for not addressing edge cases like invalid properties or parameter interactions, but overall it is complete enough for effective use.
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%, so the description must compensate. It thoroughly explains both parameters: site_url is described as an exact GSC property URL with concrete examples and domain-property caveats, while days is explained as a look-back period with a default. This significantly enriches the minimal 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 clearly states the tool retrieves a performance overview for a specific property, using a specific verb and resource. However, it does not differentiate this from sibling tools like get_search_analytics or get_advanced_search_analytics, which could also be considered performance-related.
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 usage context regarding site_url format and domain property behavior, but gives no explicit guidance on when to use this tool versus alternatives. There are no when-to-use or when-not-to-use statements, leaving the agent without criteria for 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 transparency burden. It adds meaningful context about site_url semantics (domain vs subdomain filtering) but does not disclose return format, errors, rate limits, or confirm that it is a read-only operation beyond the 'get' verb. Useful 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 compact and well-structured: a one-sentence purpose followed by parameter details. Every line adds value, with no fluff. The formatting improves scannability.
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-parameter get tool with an output schema available, so the description need not explain return values. It covers both parameters and adds site_url nuance. Missing comparison to sibling tools is a minor gap given the tool's standalone clarity.
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 schema provides only parameter names and types (both strings) with 0% description coverage. The description compensates by explaining site_url meaning, providing an example, and adding guidance on domain-property filtering. sitemap_url is only described as 'the full URL', which is adequate but less detailed.
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 opens with a clear verb and resource: 'Get detailed information about a specific sitemap.' This distinguishes it from listing-oriented siblings like get_sitemaps and list_sitemaps_enhanced, though it does not explicitly name contrasting tools.
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 useful context on how to supply site_url (exact GSC property from list_properties, domain property coverage) but does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is contextual, not comparative.
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 full responsibility. It does not state whether the operation is read-only, what permissions are needed, or how non-indexed URLs are handled. 'Inspection' implies non-mutating, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose in the first sentence. The arg details are necessary and directly useful, with no redundant 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?
Given the tool's simplicity (two parameters) and the presence of an output schema, the description covers the essential invocation details. The main gap is the lack of behavioral disclosure (e.g., read-only nature, rate limits), but overall it is sufficient for correct invocation.
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 input schema has zero descriptions for parameters, so the description must compensate. It does so thoroughly: site_url is explained with exact property formats ('https://example.com/' or 'sc-domain:example.com') and domain property behavior, while page_url is defined as the specific URL to inspect. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Enhanced URL inspection to check indexing status and rich results in Google.' It specifies the resource (URL) and the function (inspection for indexing/rich results), but does not explicitly distinguish when to use this over sibling batch_url_inspection or check_indexing_issues.
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 guidance on how to use the parameters (e.g., getting site_url from list_properties and handling domain properties), but it does not explicitly state when to use this tool versus alternatives. Usage is implied for inspecting a single URL, but no exclusions are mentioned.
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 convey behavior. It only says 'Get detailed information' and provides parameter guidance. It does not mention potential errors, authentication, read-only nature explicitly, or any side effects, which 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 concise and well-structured, with a one-sentence purpose followed by a focused Args section. Both parts are necessary and add value without redundancy.
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 (1 required param) and has an output schema, but the description lacks behavioral details and explicit usage alternatives. While the parameter guidance is thorough, the overall context is somewhat minimal given no annotations.
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 schema provides no description for site_url (0% coverage). The description compensates excellently with exact format, two examples, and an explanation of domain vs URL-prefix properties, making it clear what to pass.
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 it retrieves detailed information about a specific Search Console property, with a specific verb and resource. It distinguishes from siblings like list_properties by emphasizing 'specific' property, though it doesn't enumerate the details.
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 instructs that site_url should come from list_properties, establishing a prerequisite. It also explains domain property behavior and filtering for subdomains. However, it doesn't explicitly name alternative tools or state when not to use this one.
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 the description carries the burden. It adds useful behavioral context: site_url must be an exact GSC property from list_properties, domain properties cover all subdomains, and URLs are one per line. But it doesn't disclose response format, side effects, permissions, or rate limits. It implies read-only via 'check' but doesn't state it.
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 clear purpose sentence plus two concise parameter explanations. No wasted words.
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?
With an output schema present, the description needn't detail return values. It covers the two parameters thoroughly and provides prerequisite context via list_properties. It lacks explicit alternative tool guidance and a definition of 'specific indexing issues', but is otherwise complete for a two-param 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?
Schema coverage is 0%, and the description fully compensates by explaining both parameters: site_url includes exact format, examples, and subdomain handling via domain properties; urls specifies the one-per-line format. This adds essential meaning beyond the bare 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?
Describes the tool as checking for specific indexing issues across multiple URLs, with a clear verb+resource. However, it doesn't explicitly distinguish itself from sibling tools like batch_url_inspection or inspect_url_enhanced, so it's clear but lacks sibling 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?
Provides a prerequisite that site_url should come from list_properties and explains domain property behavior, but doesn't explicitly state when to use this tool instead of alternatives like batch_url_inspection. Usage is implied by 'across multiple URLs' but not contrasted with siblings.
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 adds useful context about the exact GSC property URL requirement and domain property coverage, and explains the sitemap_index behavior. However, it does not disclose what 'detailed information' entails, potential errors, or any limitations, leaving some behavioral aspects ambiguous.
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: the main action is front-loaded, followed by a clean Args section with no redundant text. Every sentence adds value, making it easy for an agent to parse quickly.
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 moderate complexity (2 parameters, output schema present, no annotations), the description covers parameter semantics and usage guidance effectively. It misses explicit sibling differentiation and edge-case details, but it is complete enough for an agent to invoke the tool correctly in most scenarios.
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 input schema has zero description coverage (0%), so the description must compensate. It thoroughly explains both parameters: site_url with format examples and domain behavior, and sitemap_index with its purpose. This fully compensates for the schema gap and adds significant meaning beyond the raw 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 clearly states the action ('List all sitemaps') and the resource ('a specific Search Console property') with 'detailed information.' It also mentions the optional sitemap_index for child sitemaps, which adds capability context. However, it does not explicitly differentiate from sibling tools like get_sitemaps or get_sitemap_details, so it lacks sharp sibling distinction.
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 clear usage context: it advises using the domain property as site_url and filtering by page to analyze a subdomain, and explains when to use sitemap_index to list child sitemaps. It does not state when to choose this tool over siblings or provide exclusions, but the guidance is sufficient for typical usage.
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 of behavioral disclosure. It does disclose that domain properties cover all subdomains and that API limits apply. However, it does not mention what happens on invalid URLs, how many URLs are allowed, or any error behavior. The disclosed behavior is useful 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 compact: one sentence for purpose and two concise argument explanations. No filler or redundant content. The structure front-loads the core action and logically follows with parameter details, making it easy to scan.
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 (two params) and the presence of an output schema, the description covers the essential context: batch operation, parameter sourcing, and domain property behavior. It could add specifics like maximum batch size or error handling, but 'within API limits' plus the output schema substantially fills the need. A small gap remains regarding practical limits.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters in depth: site_url specifies it must be an exact GSC property from list_properties, provides examples, and explains domain vs. site property semantics. urls is defined as a list of URLs, one per line. This adds significant meaning beyond the bare 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 starts with 'Inspect multiple URLs in batch', which clearly states the verb (inspect), resource (URLs), and scope (batch vs single). This distinguishes it from sibling tools like inspect_url_enhanced, which likely handles single URLs. The phrase 'within API limits' adds practical context.
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 gives explicit usage guidance for the site_url parameter, referencing list_properties and explaining domain vs. site property behavior. It implicitly indicates this is the batch alternative to single-URL inspection, but it does not explicitly name alternatives or state when not to use this tool. The guidance is clear enough for correct 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 are provided, so the description must carry the behavioral disclosure burden. It adds useful context about site_url domain property coverage and how to filter by page, but does not disclose whether the operation is read-only, how the comparison is computed, or any side effects. The lack of annotations makes this a moderate score.
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 opens with a clear one-sentence summary followed by a structured Args list. Each parameter has a concise, informative explanation. There is no redundant or misleading content; every sentence earns its place.
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 description covers the parameters thoroughly and an output schema exists, so return values are presumably documented. However, it doesn't provide valid values for dimensions, and it lacks explicit guidance on selecting this tool over alternatives. Overall, it's complete enough for basic invocation but has minor gaps.
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 fully compensates by explaining every parameter: site_url format and examples, date formats, dimensions default, and limit default. This adds significant meaning beyond the bare schema titles.
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 states a specific action ('Compare search analytics data') on a clear resource ('between two time periods'). This distinguishes it from sibling tools like 'get_search_analytics' which typically fetch a single period. The verb+resource is specific and unambiguous.
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 implies usage context (for comparing two time periods) but does not explicitly state when to use this tool over sibling analytics tools such as 'get_search_analytics' or 'get_advanced_search_analytics'. No alternatives or exclusions are mentioned, but the title and summary give clear context.
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. 'Provides information' implies a read-only operation, but it does not explicitly state side-effect freedom or return format details. Given the simple nature, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently.
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?
The tool is extremely simple with no parameters and an output schema present. The description fully explains what the tool does, and no additional context is necessary.
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, so no parameter explanation is required. The baseline of 4 applies as the description adds no param semantics but none are needed.
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 function with a specific verb ('Provides information') and identifies the resource (Amin Foroutan, creator of MCP-GSC). This distinguishes it from sibling tools that focus on search analytics or site data.
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?
No explicit when-to-use vs alternatives, but the tool's narrow scope makes its use obvious whenever creator information is needed. The absence of similar sibling tools makes exclusions unnecessary.
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 provided, so the description carries the full burden. It discloses meaningful behavioral details: domain property coverage, filter override semantics, data freshness lag, and pagination. However, it doesn't explicitly state that the operation is read-only or mention access requirements, which would be even stronger.
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 leads with a concise summary sentence, then uses a well-organized Args list. Every line adds essential parameter information; no redundancy or filler. The length is justified by 14 parameters.
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?
All parameters are thoroughly explained with defaults, examples, and edge-case behavior (domain properties, filter override, data_state). With an output schema present, return value explanation isn't needed. The description fully equips an agent to select and invoke this 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?
Schema description coverage is 0%, and the description compensates fully by defining every parameter with formats, defaults, valid values, and an example for 'filters'. Includes constraints like max row_limit and data_state options, going well 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?
Clearly states it retrieves advanced search analytics data with sorting, filtering, and pagination. The verb 'Get' and resource 'advanced search analytics data' are specific. Though it doesn't explicitly name a sibling tool, the 'advanced' qualifier and enumeration of capabilities distinguish it from simpler analytics tools.
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 context on parameter usage (site_url from list_properties, filters override individual filter params, data_state options) but doesn't explicitly state when to use this tool vs. siblings like get_search_analytics. The usage guidance is implied rather than direct.
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 burden. It discloses important behavior: site_url must come from list_properties, domain properties cover all subdomains, and row_limit has max. It also explicitly mentions pagination limitations. This adds meaningful context beyond what the schema provides, though it doesn't cover error handling or rate limits.
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 a concise summary line followed by an Args block. Every sentence is informative, no filler, and the layout makes it easy to scan. It's appropriately sized for the tool's 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 4 parameters, output schema exists, and no annotations, the description is thorough: it covers purpose, param semantics, scope definitions, and alternative tools. It provides enough context for an agent to invoke this tool correctly without needing extra clarification.
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%, so the description fully compensates by explaining each parameter with examples, defaults, and usage tips (e.g., site_url formatting, row_limit ranges). This goes well beyond the bare schema and makes the parameters self-explanatory.
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 function: 'Get search analytics data for a specific page, broken down by query.' This is a specific verb+resource+scope, distinguishing it from the general search analytics tools and other siblings.
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 on when to use this tool (for a specific page, broken down by query) and explicitly points to get_advanced_search_analytics for bulk exports beyond 500 rows. It doesn't explicitly contrast with get_search_analytics, but the alternative guidance and row_limit suggestions offer clear usage 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 provided, the description carries the transparency burden. It discloses key behaviors: returns all tool names grouped by category, shows auth status, and is faster than searching individually. It doesn't detail the output structure or any limitations, but the existence of an output schema likely covers return format. The auth-related context adds useful insight beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core function, the second gives explicit usage guidance, the third adds behavioral detail (grouping, speed, auth). No wasted words, and the most important information is 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 meta-tool with an output schema, the description is complete. It explains what the tool returns (tools, auth status, getting started), when to use it, and why it's beneficial (faster than searching). The output schema likely details the structure, so the description doesn't need to repeat return values. The context signals (output schema present) support this.
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 0 parameters, so baseline 4 applies. The description mentions "single call" and "all tool names" which reinforces that no filtering or additional inputs are needed. Since there are no parameters, there is nothing more to explain about them, and the schema coverage is irrelevant here.
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 returns a full list of available tools, current auth status, and how to get started. It uses a specific verb ("Get") and resource, and clearly distinguishes itself from the domain-specific sibling tools (e.g., get_search_analytics, list_properties) by being a meta-capabilities tool.
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 provides when-to-use guidance: "ALWAYS call this first when asked what tools are available, what this server can do, or how to get started." It also contrasts with searching individually, noting this is faster. This offers clear direction and implies the alternative, making it highly actionable.
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 burden. It discloses the scope (verified, domain, URL-prefix) and the tool's role as a discovery mechanism. It lacks details on error cases or return format, but for a read-only listing tool this is sufficient.
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, front-loaded with the primary purpose and immediately followed by actionable usage guidance. Every word earns its place with no redundancy.
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 listing tool with an output schema (context signal), the description provides complete context: what is listed, in which account, and why to invoke it first. No additional behavioral details are needed.
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, so the baseline of 4 applies. The description accurately conveys that no input is needed, and adds value by explaining the output's purpose (site_url for other tools).
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 'List' and the resource 'Google Search Console (GSC) properties and sites', with explicit scope ('all ... the user has access to'). It distinguishes from siblings by focusing on property listing, not analytics or sitemaps.
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 'when to use' guidance: 'Always call this first to get the exact site_url needed for other tools.' This is a clear directive that differentiates it from alternatives and establishes a prerequisite workflow.
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 full burden. It discloses key behaviors: domain property coverage, default values, dimension options, and row_limit semantics. It doesn't mention auth/rate limits, but for a data retrieval tool with output schema present, this is adequate. Slight deduction for not stating the return format explicitly.
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, front-loaded main purpose, and every sentence adds value. It is longer than minimal but efficiently packed with essential guidance without fluff.
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 has an output schema, the description needn't explain return values. It covers all parameters with practical advice and alternative tool mention, making it complete for a moderately complex tool. No gaps in coverage.
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%, so the description fully compensates. It explains site_url with examples and scale (domain vs. page), days default, dimensions allowed values and multiple dimensions, and row_limit with recommended ranges. This adds significant meaning beyond the raw 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 function: 'Get search analytics data for a specific property.' It uses a specific verb (Get), identifies the resource (search analytics data), and distinguishes it from the sibling get_advanced_search_analytics by noting pagination support 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?
Explicit guidance is provided: dimensions and row_limit usage recommendations, plus a direct alternative: 'For bulk exports beyond 500 rows, use get_advanced_search_analytics which supports pagination.' This clearly indicates when to use this tool vs. the alternative.
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:

[![mcp-gsc-readonly MCP server](https://glama.ai/mcp/servers/appscaptain/mcp-gsc-readonly/badges/card.svg)](https://glama.ai/mcp/servers/appscaptain/mcp-gsc-readonly)

Score Badge

Copy to your README.md:

[![mcp-gsc-readonly MCP server](https://glama.ai/mcp/servers/appscaptain/mcp-gsc-readonly/badges/score.svg)](https://glama.ai/mcp/servers/appscaptain/mcp-gsc-readonly)

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/appscaptain/mcp-gsc-readonly'

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