gsc-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 overlap significantly: get_sitemaps, list_sitemaps_enhanced, and manage_sitemaps all list sitemaps; get_search_analytics, get_advanced_search_analytics, get_performance_overview, and get_search_by_page_query all return analytics data. This creates unclear boundaries and risks misselection.
Naming Consistency3/5
Most tools follow a verb_noun pattern (get_, list_, add_, delete_), but there are inconsistencies: get_sitemaps vs list_sitemaps_enhanced, inspect_url_enhanced vs batch_url_inspection (inconsistent word order), and the generic manage_sitemaps and reauthenticate break the pattern.
Tool Count3/5
21 tools is on the heavy side for a GSC server. Many tools duplicate functionality (e.g., multiple sitemap and analytics tools), making the count feel bloated, though it is not extremely excessive.
Completeness4/5
Core GSC operations are covered: property management (list/add/delete), sitemap submission and deletion, URL inspection, and search analytics. A minor gap is the lack of tools for managing permissions or performing bulk property changes, but the essential surface is complete.
Average 4.1/5 across 21 of 21 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under 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?
With no annotations provided, the description carries the full burden. It reveals some context about site_url formats and domain properties, but it does not disclose the nature of the operation (e.g., read-only), error handling, period overlap behavior, or what the comparison output represents. It focuses almost entirely on parameters rather than behavior.
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 structured as a docstring with a one-sentence summary followed by an Args list. Every line provides useful information without fluff. It is slightly long due to the number of parameters, but the structure is clean and 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 description thoroughly documents parameters, but it lacks usage guidance and behavioral transparency. An output schema exists, so return values may be covered there, but the missing when-to-use and operational context leave the description incomplete for a 7-parameter comparison 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?
The input schema has 0% descriptive coverage, but the description's Args section fully compensates. It explains each parameter, including the exact format for site_url (with examples), date format, defaults for dimensions and limit, and the subdomain filtering nuance. This is exemplary parameter documentation.
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's function: 'Compare search analytics data between two time periods.' This is a specific verb ('compare') with a clear resource (search analytics data) and scope (two periods). However, it does not explicitly differentiate from sibling tools like get_search_analytics or get_advanced_search_analytics, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of 'use this when comparing two periods' or 'for single-period data, use get_search_analytics.' The context is implied by the tool name and description but not articulated.
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 full responsibility. It implies a read-only inspection but doesn't disclose behavior such as what happens with invalid URLs, whether results are returned in a specific format, or any rate limits. It basically restates the purpose without adding behavioral detail.
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 and well-structured: a single purpose sentence followed by clear argument explanations. No unnecessary words or repetition, and the key details are 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 description covers the parameters and purpose adequately. An output schema exists, so return values don't need explanation. However, it lacks guidance on when to use this vs. sibling inspection tools, and prerequisites (like running list_properties first) are only implied via the site_url description.
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%, so the description must compensate. It does: site_url is explained with examples ('https://example.com/', 'sc-domain:example.com') and domain property nuance, and page_url is defined as 'the specific URL to inspect.' This adds significant 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?
The description states a specific purpose with a clear verb and resource: 'check indexing status and rich results in Google.' It is distinguishable from batch_url_inspection by the singular 'URL' focus, but it doesn't explicitly name alternatives, so it's not a full 5.
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 useful guidance on site_url (exact GSC property, domain vs subdomain usage), but it doesn't explicitly state when to use this tool over siblings like batch_url_inspection or check_indexing_issues. The context is clear but lacks exclusionary guidance.
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 carry the full burden of behavioral disclosure. It does not mention that this is a write/mutation operation, any authentication or verification requirements, or potential side effects (e.g., whether the site appears immediately, whether duplicate adds are rejected). The description simply states the action without revealing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a structured Args section. It avoids unnecessary fluff while providing essential parameter details. The only minor issue is the mixed format (docstring-style with prose), but it remains easy to parse and front-loaded with the core purpose.
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 tool with a single parameter and no complex return values, the description covers the main aspects: what it does and how to specify the parameter. However, it lacks usage guidelines and behavioral transparency, which would make it more complete. The existence of an output schema reduces the need to describe return values, but additional context about prerequisites or side effects is still missing.
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 only provides 'site_url' as a string with no additional meaning. The description significantly adds value by explaining the exact-match requirement and providing concrete examples for both standard URLs and domain properties (sc-domain:). This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a site') and the target resource ('your Search Console properties'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like delete_site and list_properties by using the specific verb 'add'.
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 context implicitly suggests when to use this tool (to add a new property), but it doesn't explicitly state when not to use it or mention alternatives. There are no exclusions or prerequisite conditions, leaving some ambiguity about scenarios where adding might not be appropriate.
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 burden of behavioral disclosure. It transparently explains that domain properties cover subdomains and describes how to filter by page, which adds useful behavioral nuance. However, it does not disclose safety traits (e.g., read-only), potential side effects, or rate limits, leaving some ambiguity for an agent.
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: a one-sentence purpose statement followed by a clearly formatted Args block. Every line adds value, and the examples are embedded without unnecessary prose. It is front-loaded and 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 that an output schema exists (so return values are handled elsewhere) and the two parameters are thoroughly explained, the description is largely complete. It references list_properties for valid site_url values and covers the key usage nuance of domain properties. Minor gaps remain, such as not stating any limits on the number of URLs or how to interpret errors, but overall it is sufficient for a straightforward 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%, so the description fully compensates. It provides detailed semantics for both parameters: site_url has exact format examples and explains domain vs. URL-property behavior, including how to scope to a subdomain; urls specifies 'List of URLs to check, one per line'. This is far 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?
The description clearly states the tool 'Check for specific indexing issues across multiple URLs' with a specific verb and resource, and the Args section further clarifies scope via site_url. However, it does not explicitly distinguish itself from sibling tools like batch_url_inspection or inspect_url_enhanced, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as batch_url_inspection or inspect_url_enhanced. The description provides detailed parameter usage (e.g., how to choose site_url for domain properties), but that is parameter-level guidance, not tool selection advice. No exclusions or alternative tool references are given.
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 provided, the description carries the full burden of behavioral disclosure. It adds context about how domain properties behave, but does not disclose whether the operation is read-only, permissions needed, rate limits, or what the response contains. This leaves significant gaps for a tool with no annotation safety hints.
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 a clear first sentence and a focused Args block that provides necessary parameter details without unnecessary fluff. 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 tool is simple with one parameter and has an output schema, so the description need not explain return values. It covers the main functional purpose and parameter semantics well, but lacks information about when to use this vs. the 'list_sitemaps_enhanced' sibling, which 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?
Schema coverage is 0%, and the description fully compensates by explaining site_url with concrete examples, the format (URL or sc-domain), and guidance on using domain properties for subdomain analysis. This adds substantial 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?
The description clearly states that the tool lists all sitemaps for a specific Search Console property, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like list_sitemaps_enhanced or get_sitemap_details, so it is slightly below top marks.
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 some usage context by explaining how to specify site_url, including the distinction between domain and URL properties, and recommends using the domain property and filtering by page for subdomain analysis. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusions.
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 add useful context about site_url semantics (domain property covers all subdomains and suggests filtering by page), which goes beyond raw parameter definitions. However, it does not disclose potential side effects of the delete action, permission requirements, or any irreversible consequences. This is a moderate disclosure, earning a 3.
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 front-loaded. The first sentence captures the tool's purpose and actions in one line, followed by a clear 'Args' section that explains each parameter without unnecessary verbosity. The structure is efficient and all sentences earn their 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?
Given that there are no annotations, 4 parameters, and an output schema, the description covers the essential parameter details and provides context about domain properties. It lacks clear usage guidance (when to choose this over siblings), which is a minor gap. Overall, it is complete enough for an experienced agent to use correctly, but not fully self-sufficient due to the missing sibling-differentiation context.
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 fully compensate. It does so excellently: explains site_url with exact examples and domain-property behavior, defines the action values (list, details, submit, delete), clarifies sitemap_url requirement for three actions, and specifies sitemap_index's optional use for 'list'. This is rich, precise parameter semantics that goes well 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?
The description clearly states the tool's purpose: 'All-in-one tool to manage sitemaps (list, get details, submit, delete).' It specifies the verb (manage), resource (sitemaps), and the supported actions. However, it does not explicitly distinguish itself from the dedicated sibling tools (get_sitemaps, submit_sitemap, delete_sitemap, etc.), so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the alternative sitemap-specific tools. It does not mention that this is a consolidated alternative, nor does it give any context about when a user might prefer one tool over another. The only contextual note is about domain properties for site_url, which is parameter guidance, not usage selection.
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 carry the transparency burden. It mentions the prerequisite of using an exact GSC property URL from list_properties and explains domain property behavior, but does not explicitly confirm read-only safety, potential errors, or rate limits. The read-only nature is only implied by 'Get detailed information.'
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 (~90 words), front-loaded with the purpose, and structured with an 'Args:' list. Every sentence contributes value, with no fluff or 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 an output schema exists, return details are not the description's responsibility. Both parameters are well-described, and the prerequisite for site_url adds context. However, usage alternatives and explicit safety disclosure are missing, preventing a perfect score.
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 descriptions are 0% covered, so the description compensates well. site_url is thoroughly explained with examples and domain property semantics; sitemap_url is given a basic definition. This adds substantial meaning 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 'Get detailed information about a specific sitemap,' which is a specific verb and resource. It distinguishes from siblings like get_sitemaps and list_sitemaps_enhanced by focusing on a single sitemap's details.
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?
Usage is implied by the tool name and description ('specific sitemap'), but there is no explicit statement of when to use this tool versus alternatives like get_sitemaps. It provides parameter-specific guidance (domain vs subdomain) but no exclusions 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 side effects and safety traits. It only labels the operation as 'Delete (unsubmit)' without detailing permanence, required permissions, or post-deletion effects. The domain property note is more about parameter usage than behavioral transparency.
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-sentence purpose followed by a clean Args list. Every sentence adds value, and the structure is front-loaded with the core action.
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 delete operation, the description covers the required inputs and their semantics. The existing output schema handles return values, so no additional return info is needed. It lacks explicit prerequisites like property ownership, but the site_url reference to list_properties indirectly covers that.
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 descriptions for the two parameters, so the description's Args section is essential. It explains the site_url format with examples and the domain property nuance, and defines sitemap_url clearly. This fully compensates for the empty 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 action: 'Delete (unsubmit) a sitemap from Google Search Console.' This specifies a verb and resource, distinguishing it from sibling tools 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the action ('Delete'), but it does not explicitly state when to use this tool versus alternatives such as submit_sitemap or manage_sitemaps. The domain property note provides context for site_url selection but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It implies a read-only operation through 'List', but does not explicitly state safety, permissions, rate limits, or side effects. It does add useful behavioral context about domain properties covering subdomains, which is a notable positive.
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, front-loaded with a clear purpose statement, followed by efficient parameter documentation. No filler or redundant information, 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 parameters well and the presence of an output schema means return values are already documented. The main gap is the lack of alternative tool references, but for the tool's simplicity, the information provided 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 schema has zero description coverage, but the description thoroughly explains both parameters: site_url with concrete examples and domain property behavior, and sitemap_index as the optional index to list child sitemaps. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sitemaps for a specific Search Console property with detailed information. The verb 'List' and resource 'sitemaps' are specific, but it does not explicitly distinguish itself from sibling tools like get_sitemaps or get_sitemap_details, so it misses the top score.
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 gives clear parameter usage guidance, such as site_url format and that domain properties cover all subdomains. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or when-not to use, leaving usage implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral consequences. It states the action ('Remove') but does not mention irreversibility, required permissions, or effects on associated data, which is a significant gap for a destructive 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?
The description consists of a single, clear sentence followed by a focused argument explanation. It is front-loaded, concise, and every part serves a purpose without wasting 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?
For a simple one-parameter delete tool, the description covers the core behavior and parameter format effectively. The presence of an output schema reduces the need to explain return values, but the lack of side-effect information (e.g., irreversibility) is a minor gap, keeping it from a perfect score.
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 only defines site_url with no description, so schema coverage is 0%. The description compensates fully by providing exact match requirements, concrete examples (https://example.com, sc-domain:example.com), and clarifying the format for domain properties, adding essential meaning 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 uses a specific verb ('Remove') and resource ('a site from your Search Console properties'), making the tool's purpose immediate and unambiguous. It distinguishes itself from sibling tools like add_site (adding) and list_properties (listing).
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 context that this tool is for removing a site, giving no exclusions. It does not explicitly mention alternatives, but the verb 'remove' and the URL format guidance make its usage context clear, which earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals an important nuance about domain properties covering all subdomains and suggests filtering by page for specific subdomains. However, it does not disclose other behavioral aspects such as data aggregation, freshness, or that the tool only returns an overview rather than raw analytics, which would be useful for setting expectations.
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. It opens with a clear one-sentence summary, followed by an Args block. Every sentence provides valuable information, with no filler or redundancy. The structure makes it easy to scan and understand.
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 nested objects) and the availability of an output schema, the description provides sufficient context. It covers parameter semantics and key usage nuances, and references list_properties for prerequisite understanding. It could be slightly more complete by mentioning when to prefer this over get_search_analytics, but overall it is adequate for effective usage.
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 descriptions are empty (0% coverage), so the description must fully compensate. It thoroughly explains site_url with examples and clarifies that domain properties cover all subdomains, which is critical for correct usage. It also clarifies that days is a look-back period with a default, adding meaning beyond the basic type and default provided in 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 clearly states the tool's function: 'Get a performance overview for a specific property.' This uses a specific verb and resource, making the purpose obvious. However, it does not explicitly distinguish from siblings like get_search_analytics, though the term 'overview' implies a summarized view.
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 context for using the tool, referencing list_properties and explaining the difference between domain and page properties. It gives actionable guidance on how to use site_url effectively. However, it does not explicitly state when not to use this tool or mention alternative tools, falling short of a full when/when-not comparison.
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 full burden. It notes that domain properties cover all subdomains and suggests filtering by page, which is useful behavioral context. However, it doesn't mention read-only nature, authentication, or potential errors, leaving gaps.
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 two well-structured sentences plus an args block, with no waste. It front-loads the purpose and gives concise, focused parameter guidance.
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 simple single-parameter tool with an output schema (not shown), the description adequately covers parameter semantics and usage. Missing details about errors or auth are minor for a getter, and return format is covered by 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?
The schema has a bare string parameter with no description, and the description fully compensates with examples, source from list_properties, and domain property semantics. This significantly exceeds schema information.
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 it retrieves detailed information about a specific Search Console property, clearly distinguishing from list_properties by focusing on one property. However, 'detailed information' is somewhat generic, so it's not a 5.
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 specifies that site_url must be the exact GSC property URL from list_properties, providing a clear workflow. It also explains how to handle domain properties to analyze subdomains. It does not explicitly mention alternative tools or when not to use this tool, but the guidance is clear.
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 full responsibility for disclosing behavioral traits. It only mentions submit/resubmit without addressing side effects, permissions, validation, or what happens on resubmission. The domain property note is helpful but does not cover mutation impact.
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, concise, and every sentence provides useful information. There is no fluff or 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?
The tool is relatively simple, and the description covers the core purpose and both parameters with practical guidance on domain properties. Since an output schema exists, return values are handled by that structure. It could be more complete by stating the outcome of resubmission, but it is adequate for the tool's simplicity.
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 coverage, the description compensates exceptionally well by explaining both parameters. site_url includes examples and domain property guidance, while sitemap_url is clearly defined as the full URL. This adds significant meaning 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 'Submit a new sitemap or resubmit an existing one to Google' with a specific verb and resource. This distinguishes it from sibling tools like get_sitemaps, list_sitemaps_enhanced, and delete_sitemap, which handle listing or deletion.
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?
It provides clear context by referencing list_properties for site_url and explaining the behavior of domain properties. However, it does not explicitly state when not to use this tool or mention alternatives such as manage_sitemaps for other sitemap operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It mentions 'within API limits' indicating rate limits and explains domain property coverage, but it does not explicitly state that this is a read-only operation, nor does it describe error handling or failure outcomes. Output schema covers return values, but other behavioral traits are sparse.
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: a one-line summary followed by two parameter entries. No redundant or extraneous text—every sentence adds value, making it easy to scan and understand.
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 simple batch tool with only two parameters and an output schema, the description covers essential usage and parameter semantics. It lacks explicit alternatives or exclusions, but given the small scope and presence of an output schema, it is reasonably 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 input schema has no descriptions (0% coverage), but the description fully compensates: it explains the exact format for site_url with examples, distinguishes domain vs URL properties, and specifies that urls should be one per line. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects multiple URLs in batch, with a specific verb+resource. It distinguishes from single-URL inspection tools like inspect_url_enhanced by emphasizing 'multiple' and 'batch', making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use site_url, including domain vs URL property handling and filtering by page for subdomains. However, it does not explicitly mention when to prefer this tool over alternatives like inspect_url_enhanced, relying mostly on the name and 'batch' wording.
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 full burden. It explicitly characterizes the tool as informational ('Provides information'), making clear it is a read-only operation with no side effects. It doesn't detail what specific information is returned, but the existence of an output schema mitigates this.
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 that conveys the essence without any fluff. It is the model of conciseness for a simple informational tool.
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, no side effects, simple purpose) and the presence of an output schema, the description is complete. It covers everything an agent needs to understand the tool's role.
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 is 4. The description adds no parameter details because none exist, and the schema is fully covered at 100%.
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 provides information about Amin Foroutan, the creator of MCP-GSC. It uses a specific verb ('Provides information about') and names the exact resource, distinguishing it from all sibling tools that focus on Search Console operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool — when one needs creator information. No alternatives exist among siblings, and the context is sufficiently clear, though it doesn't explicitly state an exclusion or alternative.
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, and it explicitly discloses the destructive action ('Deletes the current OAuth token file') and the interactive nature ('triggers the browser authentication flow'). It also notes the logout/login sequence, providing clear behavioral expectations. It could mention side effects or failure modes, but the disclosed information is substantial.
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 three concise sentences, each adding essential information: action, mechanism, and use case. It is front-loaded with the primary purpose and contains no filler or redundant content.
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 (0 parameters) and the presence of an output schema, the description is complete enough. It explains the purpose, the destructive side effect, and when to use it, which is sufficient for an agent to decide and invoke the tool correctly.
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 input schema has 0 parameters, so there is no parameter information to clarify. The description adds no parameter details, but none are needed. The baseline for 0 parameters is 4.
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: 'Perform a logout and new login sequence.' It specifies the mechanism ('Deletes the current OAuth token file and triggers the browser authentication flow') and the use case ('switch to a different Google account'). This distinguishes it from sibling tools, which are all search/analytics related.
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 explicitly says when to use the tool: 'Useful when you need to switch to a different Google account.' It does not provide explicit when-not-to-use guidance or name alternatives, but the use case is clear and the tool is unique among the listed 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?
No annotations are provided, so the description bears the burden. It discloses that results are grouped by category, delivered in a single call, and include auth status. It stops short of explicitly stating read-only safety, but the 'get' verb and nature of the tool make that obvious enough.
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: purpose, usage rule, and behavior/benefit. Front-loaded and free of 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?
For a zero-parameter tool with an output schema, the description covers all essential aspects: what it returns, when to use it, and why it's efficient. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has nothing to add beyond the empty schema. The baseline for 0 params is 4, and the description appropriately spends no effort on param explanations.
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 lists all available tools, shows current auth status, and explains how to get started. This is specific and distinguishes it from sibling tools that retrieve individual resource details.
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?
It explicitly instructs to 'ALWAYS call this first' when asked about tool availability or server capabilities, and contrasts with searching individually. This provides strong when-to-use guidance and implicitly says not to use other tools for this purpose.
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 that domain properties cover all subdomains and how to analyze a specific subdomain, plus row_limit boundaries. It stops short of explicitly stating read-only behavior or error handling, but the output schema covers return values.
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 'Args:' block is well-structured and informative, but slightly verbose with examples and recommendations. Every sentence contributes value, so it earns a high score, though it could be trimmed marginally.
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?
An output schema exists, so return values are covered. The description covers all four parameters, provides practical guidance, and points to an alternative tool for advanced needs. It is complete for a tool of this complexity.
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 thoroughly compensates by explaining each parameter: site_url format with examples, days default, dimensions accepted values and comma-separated usage, and row_limit recommendations including thresholds for different use cases.
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: 'Get search analytics data for a specific property.' It clearly distinguishes itself from the sibling tool get_advanced_search_analytics by mentioning row limits and directing bulk exports to that 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 states when to use get_advanced_search_analytics (for bulk exports beyond 500 rows) and provides detailed guidance on handling domain vs. site properties, including filtering by page. This clarifies appropriate usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly describes the scope (all accessed properties) and the usage pattern (call first), though it doesn't explicitly mention pagination or response format. The read-only nature is implied by 'list'.
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 a direct statement of function, followed by actionable usage guidance. No wasted 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?
For a no-parameter listing tool with an output schema, the description fully covers purpose, usage, and relationship to other tools. It's a complete minimal description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description adds value by explaining the purpose rather than parameter details, which are unnecessary. Baseline for 0 params is 4.
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 identifies the tool as listing GSC properties/sites with a specific verb and resource, and distinguishes itself by noting it's the entry point for obtaining site_url for other tools.
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 states when to use (to see all properties) and instructs to always call it first to get site_url for other tools, providing clear context relative to siblings.
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?
With no annotations provided, the description carries the full burden and excels. It discloses critical behavior: the filters parameter overrides the single-filter parameters, data_state semantics (final data has a 2-3 day lag), row_limit max of 25000, pagination via start_row, and defaults for dates. This goes well beyond what a schema alone would convey.
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 long but every sentence adds substantive value. The Args-style list is front-loaded with the primary resource (site_url) and proceeds logically. Given 14 parameters, the length is justified and there is no filler.
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 complex with 14 parameters and an output schema, so the description does not need to explain return values. It covers all parameters, defaults, overrides, and edge cases, making it fully self-contained. The provided output schema handles the return structure.
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 is the sole source of parameter meaning. It explains every parameter with format examples, valid values, defaults, and relationships (e.g., filter_* vs. filters). The filters example with JSON array is especially helpful.
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 opens with a specific verb+resource: 'Get advanced search analytics data with sorting, filtering, and pagination.' It clearly distinguishes this tool from the sibling get_search_analytics by emphasizing advanced capabilities. The name and description align.
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 context on when to use the tool (for advanced analytics with sorting/filtering/pagination) and includes a practical usage tip about domain properties vs. filtering by page. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., simple queries might use get_search_analytics).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It explains row_limit max of 500, the pagination limitation, and how domain properties work, but it does not explicitly state whether the operation is read-only or mention any rate limits or auth requirements. The provided context is useful but not exhaustive.
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, organized as an Args block, and every sentence adds practical value. It avoids redundancy and keeps the content tightly scoped to the tool's operation.
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 moderate complexity and the presence of an output schema, the description covers all necessary input semantics and the key limitation (500-row cap). It provides enough context for an agent to select and invoke the tool correctly, including when to use an alternative.
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 fully compensates by explaining each parameter: site_url format with sc-domain example, page_url purpose, days default, and row_limit semantics with recommended ranges. This goes well 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 gets search analytics data for a specific page, broken down by query, using a specific verb and resource. It distinguishes itself from siblings by noting that bulk exports beyond 500 rows should use 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including suggested row_limit ranges (5-20 quick overviews, 50-200 deeper analysis, 500 comprehensive) and points to get_advanced_search_analytics as the alternative for paginated bulk exports. It also clarifies domain property coverage and filtering by page.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Klartika/gsc-mcp-server'

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