Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says the tool 'adds' a site, with no details about side effects, permissions, duplicate-add behavior, whether the site is immediately usable, or what the API returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with no filler. The brief 'Args' section provides exactly the parameter detail needed without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, the URL semantics are well covered and an output schema exists. However, key operational context is missing: what happens when the site is added, whether verification is required, and how this relates to other Search Console management steps. The agent can invoke the tool correctly but lacks deeper context for robust decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage, but the description fully compensates by specifying that site_url must be an exact match, giving concrete URL patterns, and explaining the sc-domain: format for domain properties. This is strong, actionable parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Add a site') and a clear target ('Search Console properties'). This is unambiguous and naturally distinguishes the tool from siblings like delete_site, list_properties, and get_site_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites, ownership, or verification requirements. The description only explains what the tool does, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden of behavioral disclosure. 'Within API limits' is vague and gives no concrete limit, error behavior, or side-effect information. The read-only nature is only implied, not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. The Args section adds essential parameter guidance without fluff, and every line contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Input semantics are well-covered and an output schema exists, so return values do not need explanation. However, the description lacks concrete batch-limit numbers and does not guide the agent toward or away from the single-URL sibling tool. These gaps matter for a tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fully compensates. It explains that site_url must be an exact GSC property URL from list_properties, gives example formats, and clarifies domain-property subdomain coverage. It also specifies that urls must be provided one per line.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Inspect multiple URLs in batch'. The batch qualifier distinguishes this from sibling tools like inspect_url_enhanced, though it does not explicitly name the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The batch scope implies it is intended for inspecting multiple URLs at once, and the site_url guidance references list_properties as a prerequisite. However, there is no explicit statement about when to choose this over inspect_url_enhanced or any batch-limit threshold.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. 'Check' implies a read-only operation and the parameter guidance is useful, but the description does not disclose what kinds of indexing issues are reported, any request limits for the URL list, or error behavior. It is not contradictory or misleading, just minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: a one-sentence summary followed by an Args block with no redundant text. Every sentence earns its place, and the formatting makes parameter semantics easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with an output schema, the description covers the essential invocation details well. The main omissions are the exact nature of 'specific indexing issues' and guidance on choosing this tool over sibling inspection tools, but the output schema likely fills in return-value expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains that site_url must be an exact GSC property from list_properties, gives examples, and explains domain vs. site property semantics. It also clarifies that urls is a list with one URL per line, which is critical for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Check for specific indexing issues across multiple URLs' names a clear verb, resource, and scope. However, the term 'specific indexing issues' is undefined and the description does not differentiate this from sibling tools like batch_url_inspection or inspect_url_enhanced, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use versus alternative tools, but the Args section provides meaningful usage guidance on how to select site_url (exact GSC property from list_properties and domain-property handling for subdomains). This is implied usage context rather than a clear routing rule, so it is slightly above no guidance but below explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden for behavioral context. It adds a useful GSC-related behavior ('Domain properties cover all subdomains') and explains how to adapt site_url plus page filtering for subdomains. Still, it does not disclose permissions, read-only/side-effect status, rate limits, or how 'top results' are ranked, leaving behavioral transparency only partially covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The one-line purpose is front-loaded, followed by a tight Args list. Every line earns its place: formats, defaults, and the domain-property guidance are all necessary for correct invocation. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all seven parameters, includes the key domain-vs-site property nuance, and the presence of an output schema covers return-value details. It is slightly incomplete because dimensions has no allowed-value list ('query', 'page', etc.) and 'top results' does not specify the ranking metric, but these are minor gaps for an otherwise well-specified tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully: site_url includes exact expected formats and examples, all four date parameters specify YYYY-MM-DD, and dimensions/limit explain their defaults and purpose. This adds substantial meaning beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: 'Compare search analytics data between two time periods.' This unambiguously names the tool's operation and distinguishes it from single-period siblings like get_search_analytics, so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case (comparing two periods) is clear, and the site_url note correctly ties the parameter to list_properties. However, the description never explicitly says when to prefer this tool over get_search_analytics or get_advanced_search_analytics, nor states exclusions such as 'use for single-period trends instead.' The usage guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of behavioral disclosure. It states the core action but does not mention that deletion is likely irreversible, what cascade effects occur (e.g., sitemaps removed), whether ownership is required, or what happens on failure. For a destructive operation, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two efficient sentences: the action is front-loaded, and parameter details are compactly structured with clear examples. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter destructive tool, the operational calling information is nearly complete, and the output schema covers return values. However, the missing behavioral context around permanence, side effects, and prerequisites means the definition is only minimally adequate rather than thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero description for the single parameter, but the tool description thoroughly compensates: it gives exact-match requirements, concrete URL examples, and the special sc-domain: format for domain properties. This is exactly the level of detail an agent needs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Remove') and resource ('site from your Search Console properties'), making the tool's purpose unambiguous. It clearly distinguishes itself from siblings like add_site and list_properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

When to use this tool is implied by its name and action ('remove a site'), but there is no explicit guidance on when not to use it, no mention of alternatives, and no prerequisites or conditions. The context is clear enough, but the description leaves routing entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. 'Delete (unsubmit)' communicates the mutating action and clarifies that it removes the sitemap submission rather than the hosted file, but it does not mention permissions, side effects on indexed pages, or error/response behavior. It is adequate but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the purpose, followed by a focused Args section. Every sentence adds necessary information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter delete operation with an output schema, the description provides all needed input context: where site_url comes from, how to format it, and exactly what sitemap_url should be. Nothing required for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must fully explain the parameters. It does: site_url is defined as an exact GSC property with examples and domain-property guidance, and sitemap_url is defined as the full sitemap URL to delete. This adds substantial meaning beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Delete (unsubmit) a sitemap from Google Search Console,' which names the exact operation and resource. This clearly distinguishes it from sibling tools like submit_sitemap or delete_site.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does not explicitly name alternatives, but it gives concrete usage context: site_url must be an exact GSC property from list_properties, and it explains when to use a domain property versus a URL property. This is clear contextual guidance, though exclusions such as preferring manage_sitemaps for bulk operations are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses default date ranges, filter override behavior, row_limit maximum, pagination via start_row, and the difference between 'all' and 'final' data states. It does not explicitly state read-only behavior, but 'Get' and the analytics context make that reasonably clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact Args-style block with each parameter on its own line and the core purpose front-loaded. It is long due to 14 parameters, but each line provides necessary detail without fluff. The JSON filter example is the only slightly verbose part, yet it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no annotations and no enum constraints, this description provides all necessary invocation details: exact formats, defaults, constraints, pagination semantics, and data freshness behavior. An output schema exists, so the description does not need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by documenting every parameter with formats, defaults, valid values, and relationships. The filters parameter even includes a JSON example and explains that it overrides the single-filter parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get advanced search analytics data with sorting, filtering, and pagination.' This clearly distinguishes it from the simpler sibling get_search_analytics and states exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers concrete usage context, such as requiring site_url to be an exact property from list_properties, explaining domain-property/subdomain analysis, and describing data_state freshness trade-offs. It does not explicitly contrast with get_search_analytics, but the advanced capabilities and parameter guidance make the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses return behavior (tool names grouped by category), efficiency (single call is faster), and that it indicates authentication needs. This is solid though not exhaustive; it does not explicitly state that the call is read-only or describe failure modes, but for a capability-discovery tool the provided detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and usage instruction, then supplies behavioral detail. It is compact, but 'current auth status' in the first sentence and 'Also shows if authentication is needed' later are mildly redundant, preventing a perfect conciseness score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter discovery tool with an output schema, the description covers invocation triggers, return grouping, auth-status behavior, and where to start. Nothing essential is missing for an agent to select and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema coverage is 100%, so the schema already fully documents the input surface. The baseline for zero-parameter tools is 4; the description adds no parameter detail because none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Get a full list of all available tools') and adds auth status and getting-started guidance. It clearly differentiates from domain-specific siblings like get_site_details or submit_sitemap by defining its scope as server-wide discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit trigger condition: 'ALWAYS call this first when asked what tools are available, what this server can do, or how to get started.' It also gives a rationale (single call vs individual searching), which helps the agent decide when to invoke it instead of alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full transparency burden. 'Provides information' implies a safe, read-only operation with no side effects, which is the key behavioral trait an agent needs. It does not elaborate on response shape or potential errors, but for a zero-parameter informational tool the stated behavior is largely sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or repetition. It communicates exactly what the tool does and who it is about without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool takes no parameters and an output schema exists, the description provides all the context needed for safe invocation. An agent can confidently call this tool when creator information is requested, and the output schema covers return-value specifics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so description-level parameter guidance is not needed. The empty schema already makes this clear, and the description adds no unnecessary parameter-related content.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a concrete verb and resource: it provides information about Amin Foroutan, the creator of the MCP-GSC tool. This clearly differentiates the tool from all siblings, which focus on sites, analytics, sitemaps, and other operational concerns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is provided. However, the intended usage is reasonably implied: an agent should call this tool when asked about the creator of MCP-GSC. It does not mislead, but it also does not formally contrast with other informational tools like get_capabilities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. 'Get a performance overview' implies a read-only operation, and the description adds detail about domain property coverage. However, it does not mention what the overview contains, whether it requires special permissions, or what the response shape is; the output schema helps but is not described here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by a concise parameter explanation. Every sentence contributes useful information and there is no filler or repetition of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only overview tool with a simple two-parameter schema and an output schema available, the description is largely sufficient. It covers parameter semantics and usage context well. The only notable gap is that 'performance overview' is not defined, so the agent must rely on the output schema or tool name to infer metrics like clicks, impressions, CTR, or position.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It explains that site_url should be an exact GSC property URL from list_properties, gives concrete examples, clarifies that domain properties cover all subdomains, and explains how to analyze a specific subdomain. It also gives the meaning and default of days. This fully covers both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Get a performance overview for a specific property.' It is not as specific as sibling names like get_search_analytics or get_advanced_search_analytics, but it is not a tautology and gives the agent a reasonable idea of the operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides useful context on how to supply site_url, including the distinction between URL-prefix and domain properties and how to handle subdomains. However, it does not explicitly say when to use this tool versus alternatives like get_search_analytics, get_advanced_search_analytics, or compare_search_periods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It covers defaults, the 500-row cap, allowed dimensions, comma-separated multi-dimensions, and the subdomain behavior of domain properties. It stops short of mentioning authorization or rate limits, but since this is a read-only analytics query, the most important behavioral constraints are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with a one-sentence summary followed by a compact, scannable Args list. Each line adds meaningful guidance: defaults, options, max limits, and a pointer to the paginated sibling. No filler or redundancy is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for an agent to call this tool correctly: all parameters are explained, defaults are given, the 500-row boundary is explicit, and the paginated alternative is identified. An output schema exists, so documenting return values is unnecessary here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document the parameters—and it does. It explains site_url with exact GSC formats and subdomain filtering, days with a default, dimensions with allowed options and comma-separated examples, and row_limit with defaults, maximum, and suggested ranges. This exceeds what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly states the action and resource: 'Get search analytics data for a specific property.' It also distinguishes itself from get_advanced_search_analytics by noting that the advanced tool supports pagination for bulk exports, which prevents an agent from selecting the wrong sibling by mistake.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives practical guidance for every parameter and explicitly states when to use an alternative: 'For bulk exports beyond 500 rows, use get_advanced_search_analytics which supports pagination.' It also explains how to choose site_url and row_limit ranges, giving an agent clear conditions for using this tool correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 clearly implies a read-only analytics operation and transparently discloses the 500-row limit with a pagination alternative. However, it does not mention potential rate limits, exact-match requirements, or behavior when no data exists for a page, which would be useful completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured as a one-line purpose followed by an Args list. Every sentence adds value: parameter explanations, defaults, usage intervals, and a sibling reference. There is no filler or repetition of schema data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and the existence of an output schema, the description covers all necessary invocation context: required parameters, optional parameters with defaults, max limit, usage guidance, and a pointer to an alternative for larger exports. It is fully sufficient for an agent to call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by explaining every parameter in depth: site_url with property URL formats and domain-property nuance, page_url as a specific page, days with default, and row_limit with practical ranges and a hard max. This goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Get search analytics data for a specific page, broken down by query,' which names a specific verb, resource, and scope. This clearly distinguishes it from sibling tools like get_search_analytics and get_advanced_search_analytics without needing to inspect their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool vs alternatives: it advises using the domain property as site_url and filtering by page for subdomain analysis, and it directs users to get_advanced_search_analytics for bulk exports beyond 500 rows. The row_limit usage ranges also give situational recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation, and the domain-property guidance adds useful behavior context, but it does not disclose authentication requirements, potential errors, or side-effect guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: a clear lead sentence immediately followed by focused parameter guidance. There is no filler or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter, an output schema, and no nested objects, the description covers the essential invocation details. It could be slightly more complete with explicit when-to-use guidance, but the provided context is sufficient for a straightforward getter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully compensates for the single parameter by explaining the exact URL format, giving examples, and clarifying how domain properties behave. This is exactly the kind of guidance an agent needs to supply a correct site_url.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: 'Get detailed information about a specific Search Console property.' It identifies the resource and uses a specific verb, though it does not explicitly differentiate itself from sibling tools like get_capabilities or get_sitemaps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context by instructing that site_url must come from list_properties and explains how to handle domain properties ('use the domain property as site_url and filter by page'). However, it does not explicitly state when to prefer this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'detailed information' and gives parameter guidance, but does not disclose response behavior, permissions, error cases, or any side effects. For a read-only inspection tool this is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by concise, useful parameter explanations. Every sentence adds meaningful guidance, and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values do not need explanation. The description covers both required parameters well and gives practical context about domain properties. The only missing piece is explicit guidance on when to use this tool versus sibling sitemap tools, which would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains that site_url must be an exact GSC property URL from list_properties, gives concrete examples for URL-prefix and domain properties, and clarifies subdomain coverage. sitemap_url is defined as the full URL of the sitemap, which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Get detailed information about a specific sitemap.' It is differentiated from sibling list tools by emphasizing a specific sitemap, though it does not explicitly name alternatives like get_sitemaps or list_sitemaps_enhanced.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear contextual guidance on choosing site_url, including that domain properties cover all subdomains and how to analyze a specific subdomain by filtering by page. It does not explicitly say when to prefer this tool over sibling sitemap tools, so it stops short of a full when/when-not explanation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral disclosure burden. It adds the useful nuance that domain properties cover all subdomains, but it does not mention pagination, limits, response format, or explicitly confirm read-only behavior. 'List' implies a read operation, but that is not enough for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear one-sentence purpose followed by a tight parameter note. The domain-property caveat is valuable and there is no filler or redundant restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-required-parameter tool with an output schema, the description thoroughly explains the only parameter and how to obtain it. It does not explicitly route the agent to list_sitemaps_enhanced when richer sitemap data is needed, but that is a differentiation gap rather than a correctness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates well. It explains that site_url must be an exact GSC property URL, gives concrete examples including sc-domain:example.com, and explains how domain properties cover subdomains. This adds substantial meaning beyond the bare schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and object: 'List all sitemaps for a specific Search Console property.' It clearly identifies what the tool does and its scope, but it does not explicitly distinguish itself from sibling tools like list_sitemaps_enhanced or get_sitemap_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete prerequisite (use site_url from list_properties) and explains property URL formats, but it never states when to prefer this tool over list_sitemaps_enhanced or get_sitemap_details. Usage context is implied by the simple listing action rather than explicitly contrasted with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosing behavior. It mentions checking indexing status and rich results but does not describe side effects, permission requirements, rate limits, or what happens when a URL is not indexed or the property is invalid. The domain-property note is useful but is parameter behavior, not overall tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the tool's purpose, and keeps parameter documentation in a clean list. The domain-property explanation is useful and not redundant, though 'Enhanced' adds little meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with an output schema, the description is largely adequate and covers the key inputs well. It lacks guidance on choosing this tool over sibling alternatives and does not mention potential errors or edge cases related to URL inspection, making it only moderately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so well for site_url by providing exact property format, examples, and domain-property behavior. page_url receives only a minimal definition ('The specific URL to inspect'), which is clear but less rich than site_url.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action (inspect a URL) and resource (Google Search Console URL), with the purpose of checking indexing status and rich results. It is clear, though it does not explicitly differentiate itself from sibling tools like 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides helpful usage context, such as getting the exact site_url from list_properties and guidance for using domain properties with subdomain filtering. However, it does not state when to prefer this tool over alternatives like batch_url_inspection or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It reveals the operation is a read-only list of everything the user can access, enumerates property types ('verified sites, domain properties, and URL-prefix properties'), and references the 'connected Google Search Console account,' implying the read scope. It could mention pagination or rate limits, but for a list tool the transparency is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. The purpose verb is front-loaded, the scope is specified next, and the usage directive closes it. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema defined, the description is complete: it names what the tool lists, when to call it, and what to extract from it (site_url). No additional detail is needed for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning since none exist, but it does clarify the output context (site_url needed for other tools), which is relevant even though not a parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List all Google Search Console (GSC) properties and sites the user has access to.' It clearly distinguishes itself from siblings like get_site_details by emphasizing 'all' and 'Always call this first,' positioning it as the discovery entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Always call this first to get the exact site_url needed for other tools.' It does not mention when not to use it or name alternatives, but for a top-level list operation this is clear and sufficiently directive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the burden of behavioral disclosure. It does add meaningful behavioral context: domain properties cover all subdomains, and sitemap_index lists child sitemaps. It does not mention auth requirements, rate limits, or explicitly confirm that the operation is read-only, though 'List' suggests it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and reasonably concise, front-loading the purpose and then providing an Args section. Every sentence adds signal, though 'with detailed information' is somewhat vague and could be omitted without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, the output schema is available, and both parameters are clearly documented, the description is largely complete. The main gap is the lack of explicit guidance on when to use this tool instead of the overlapping get_sitemaps or get_sitemap_details siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate for parameter meaning. It does: site_url is explained with exact formatting examples and linkage to list_properties, including domain-property nuance, and sitemap_index is described as an optional sitemap index URL for listing child sitemaps. This is strong, complete parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'List all sitemaps for a specific Search Console property with detailed information.' This clearly conveys what the tool does. However, it does not explicitly distinguish itself from the sibling get_sitemaps or get_sitemap_details tools beyond the word 'enhanced' and 'detailed information.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful usage context for the site_url parameter, instructing users to use an exact GSC property URL from list_properties and explaining how domain properties behave. It does not, however, say when to choose this tool over siblings like get_sitemaps or get_sitemap_details, so tool-selection guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for disclosing side effects and requirements. It mentions actions like delete and submit, which imply mutations, but does not state whether delete is irreversible, whether submit requires existing verification, or any rate-limit/auth context. This is a significant gap for a management tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: a one-line purpose followed by a clear, line-per-parameter Args section. Every sentence adds value, and the most important scoping information (site_url source) is placed early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return shape, and the Args section covers parameters well. However, the description lacks guidance on how this umbrella tool relates to the specialized sitemap siblings and does not mention failure/error behavior, so an agent is left to infer when to prefer it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The Args section compensates for 0% schema coverage by detailing each parameter: site_url must be an exact GSC property URL from list_properties, action has four allowed values, sitemap_url is required for details/submit/delete, and sitemap_index is optional and only used with the list action. It even gives an example for site_url. This fully explains the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it is an 'All-in-one tool to manage sitemaps' and explicitly lists the covered actions: list, get details, submit, delete. This is a clear verb+resource statement, though it does not mention the sibling specialized tools (e.g., get_sitemaps, delete_sitemap) or how it differs from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies broad use for all sitemap operations but offers no explicit guidance on when to choose this tool over the many sibling tools like list_sitemaps_enhanced or submit_sitemap. It does provide some parameter-level guidance (e.g., using the domain property from list_properties and filtering by page for subdomains), but that pertains to arguments, not tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses a destructive side effect: 'Deletes the current OAuth token file.' It also explains the resulting auth flow, so an agent understands this is a state-changing, interactive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler. The core action comes first, the mechanism second, and the use case last. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description fully covers what the tool does, the important destructive behavior, and the scenario where it is needed. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty with 0 parameters, so parameter semantics are not applicable. Per the 0-parameter baseline, the description does not need to add parameter-level detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Perform a logout and new login sequence') and the resource affected (OAuth token file, browser authentication flow). It directly distinguishes itself from sibling tools, which are all Search Console data/site operations, by making clear this is an authentication restart tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly identifies when to use it: 'when you need to switch to a different Google account.' It doesn't discuss when not to use it or list alternatives, but the intended context is clear and the tool is unique among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the action but does not mention side effects, whether resubmission replaces existing sitemaps, permissions required, rate limits, or async validation behavior. This is a mutation tool, so those gaps are meaningful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, then uses an Args section to add parameter guidance without redundancy. Every sentence provides actionable information, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with an output schema, the description covers the main action and both parameters thoroughly. It lacks explicit behavioral context like side effects or permissions, but the presence of an output schema reduces the need to explain return values, so the overall package is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates. It details that site_url must be an exact GSC property URL from list_properties, provides concrete examples including sc-domain format, and explains domain-property behavior. sitemap_url is also clarified as the full URL.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Submit') and resource ('sitemap') with a clear target ('to Google'), and the distinction between new and existing submissions is explicit. This clearly differentiates the tool from the get/list/delete sitemap siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the tool for both initial submission and resubmission, and it gives domain-vs-subdomain usage guidance for site_url. It does not explicitly mention when not to use it or compare with siblings like manage_sitemaps or delete_sitemap, but the context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.