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

With no annotations provided, the description carries the full burden, and it delivers meaningful behavior: the 100-item cap, per-target partial-failure semantics ('Each target reports success or its Google API error'), and the required 'webmasters OAuth scope'. It does not explicitly warn that deletion is irreversible, but the destructive verb plus detailed error-reporting behavior make this a strong disclosure overall.

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 sentences, each earning its place: scope/limit, error handling, and auth requirement. No filler, no repetition of schema content, and the most decision-relevant facts are front-loaded in the first sentence.

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 nested-array delete tool with zero annotations, no output schema, and 0% parameter coverage, the description covers the essentials: batch cap, per-target error reporting, and auth. But it leaves the siteUrl/feedpath value formats unexplained and says nothing about response shape or what happens on total failure. Adequate for invocation, incomplete for confident use on unfamiliar data.

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 partially does: 'submitted sitemap URLs' maps to feedpath and 'properties' maps to siteUrl, giving conceptual meaning to the nested object fields. However, it omits format requirements such as whether siteUrl expects a full URL or 'sc-domain:' prefix, and whether feedpath is a path or full URL. Meaningful but incomplete compensation for the schema gap.

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 verb ('Delete'), a precise resource ('submitted sitemap URLs'), and a clear batch scope ('up to 100... across multiple Search Console properties'). This cleanly separates it from the singular gsc_delete_sitemap and the inverse gsc_batch_submit_sitemaps without opening either 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 phrase 'across multiple Search Console properties' and the 'up to 100' limit imply the batching use case, but there is no explicit when-to-use/when-not-to-use guidance. It never names gsc_delete_sitemap as the alternative for a single deletion, nor does it state what to do when more than 100 targets need deleting. Usage context is inferable but not 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 carries the transparency burden and does a good job: it discloses the 100-item limit, the per-target success/error outcome, and the required OAuth scope. It does not detail other side effects or idempotency, but it states the key behavior for a batch submit 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?

Two tightly packed sentences with no filler: action and scope first, then per-item outcome and auth requirement. 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 low-complexity tool with no annotations and no output schema, the description covers the operation, limit, response style, and auth, but the missing definition of `targets` fields is a notable gap. An agent could still infer the object shape from the schema, but the description alone is not 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 explain the `targets` structure, but it never names or defines `siteUrl` and `feedpath`. 'Sitemap URLs' and 'properties' loosely hint at the fields, yet 'feedpath' is ambiguous and there are no format or example details.

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 ('Submit') and defines the resource and scope: up to 100 sitemap URLs across multiple Search Console properties. It clearly distinguishes itself from siblings like gsc_batch_delete_sitemaps and gsc_submit_sitemap by making the batch, cross-property behavior explicit.

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 gives a clear context for use: when you need to submit sitemap URLs in a batch across multiple properties, with a per-target result. The OAuth prerequisite provides an additional usage condition, though it does not explicitly say 'use gsc_submit_sitemap for a single property' or name 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 present, the description carries full responsibility for disclosing side effects; it states the delete action and OAuth requirement but does not say whether removal is permanent, what happens to the property, or whether the sitemap URL must still exist. This is a minimal disclosure 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.

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

The description is two short sentences with no filler; the action is front-loaded and the OAuth requirement is a meaningful addition. 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?

This is a simple two-parameter tool, but with no output schema, no annotations, and zero parameter documentation, the description leaves important call details unresolved, such as feedpath formatting and siteUrl representation. The minimum viable context for correct invocation is not fully met.

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, but it does not explain what siteUrl or feedpath mean or their expected formats. The wording 'property' and 'sitemap' loosely maps to the two parameters, but an agent cannot determine precise values from the text.

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 ('Remove') and resource ('a submitted sitemap from a Search Console property'), making the tool's purpose clear. It does not explicitly differentiate from sibling gsc_batch_delete_sitemaps, but the singular wording and title distinguish it enough for basic selection.

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 guidance is provided about when to use this single-delete tool versus its sibling gsc_batch_delete_sitemaps, or when deletion is appropriate. The only usage hint is the OAuth scope prerequisite, which is a permission constraint, not an alternative-selection rule.

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 alone must disclose behavior. It states the tool fetches status and metadata, but does not describe the return format, error behavior, required permissions, or how invalid inputs are handled. This leaves significant behavioral 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.

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

The description is a single concise sentence with no redundant or filler language. It is front-loaded and easy to parse, though it is arguably too sparse to fully serve the agent.

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 no annotations, no output schema, and 0% parameter coverage, the description alone is insufficient. It does not explain what 'status and metadata' includes, what makes a sitemap 'submitted', or how the two required parameters relate. For a simple two-parameter tool, a richer description would be feasible and necessary.

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% description coverage, and the description does not explain siteUrl or feedpath. The parameter names are somewhat self-explanatory, and 'submitted sitemap' hints at feedpath, but no format, relationship, or required values are clarified. The description fails to compensate for the schema gap.

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 'Fetch' with a clear resource: status and metadata for a submitted sitemap. The singular 'a submitted sitemap' implies a targeted operation, distinguishing it from listing or submitting sitemaps, though it does not explicitly name the sibling tools.

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 usage conditions, when-to-use guidance, or alternatives are mentioned. The singular phrasing implies this tool is for one specific sitemap rather than all sitemaps, but no explicit guidance differentiates it from gsc_list_sitemaps or other 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, but it only says 'Inspect.' It does not explain whether this is a read-only operation, whether it performs a live inspection, what auth or property access is required, or what kind of response the agent should expect.

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, focused sentence with no filler or redundancy. It front-loads the action and object, which makes it easy for an agent to parse quickly.

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

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

The tool has no annotations, no output schema, and no parameter descriptions. The description does not explain return values, status semantics, possible error conditions, or how the inspection result should be interpreted. It is minimally adequate for selecting the tool but insufficient for reliable invocation.

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 needed to explain siteUrl, inspectionUrl, and languageCode. It only loosely maps to 'URL' and 'Search Console property,' leaving languageCode entirely unexplained and providing no format or constraint details for the required 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 uses a specific verb ('Inspect') with a specific resource ('indexed status of a URL') and scopes it to a Search Console property. This clearly distinguishes the tool from siblings like gsc_search_analytics, gsc_list_sitemaps, and gsc_top_queries.

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 usage context is implied: use when you need to check whether a URL is indexed under a Search Console property. However, it does not explicitly state when not to use it, nor does it mention alternatives such as search analytics or sitemap tools.

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 does disclose the output fields and sort order, and it notes the one-or-many-properties scope. However, it does not mention default filtering thresholds like minImpressions or maxCtr, the dataState behavior, or how pagination/limits affect results.

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: it immediately establishes the tool's core filter and then states the return shape. Every word contributes meaningful 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?

Given 16 parameters, no output schema, and no annotations, this description is too sparse to be fully actionable. It captures the central use case and return shape, but an agent cannot infer the semantics of most filtering parameters or the site-selection modes without additional context.

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 for 16 parameters. It only hints at site selection ('across one or many properties') and the impression/CTR thresholds ('high-impression, low-CTR'), leaving device, country, type, dataState, pageContains, queryContains, maxPosition, and other parameters unexplained.

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 ('Find') with a clear resource ('high-impression, low-CTR queries') and explicitly states what it returns ('clicks, impressions, CTR, and position sorted by impressions'). This clearly separates it from generic analytics siblings like gsc_search_analytics or gsc_top_queries.

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 no explicit guidance on when to use this tool versus gsc_top_queries, gsc_search_analytics, or other siblings. There are no exclusions, alternatives, or prerequisites mentioned; the intended use case is only implied by the title and the 'high-impression, low-CTR' phrasing.

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 does communicate that this is a read-only listing of 'submitted' sitemaps rather than all discovered sitemaps, which is useful. However, it does not disclose output format, pagination, property URL requirements, or any side effects.

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

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

The description is a single focused sentence with no filler or repetition. It is concise and front-loaded, though the brevity comes at the cost of missing important behavioral and parameter context.

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 four undocumented parameters, zero schema description coverage, no annotations, and no output schema, this description is too sparse to fully support correct invocation. An agent would be left guessing about property selection and behavior across multiple sites.

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 adds no parameter-level meaning. siteUrl, allSites, siteUrls, and sitemapIndex are not explained at all, leaving an agent unable to know how to request a single property versus multiple sites or how sitemapIndex is used.

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 ('List'), a specific resource ('submitted sitemaps'), and a scope ('for a Search Console property'). It is understandable and distinct from sibling list_sites, though it does not explicitly contrast with gsc_get_sitemap.

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

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

The description gives no guidance on when to use this tool versus alternatives like gsc_get_sitemap or gsc_submit_sitemap. There are no exclusions, prerequisites, or context clues to help an agent choose between closely related sitemap operations.

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 burden. 'List' implies a read-only operation, and 'available to the authenticated Google account' discloses the auth boundary. However, it does not mention return format, pagination, or any other behavioral caveats, which is acceptable for a simple list but not fully transparent.

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. It efficiently conveys the action, the resource, and the auth context 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?

For a zero-parameter list endpoint, the description tells the agent what it returns and under what authentication context. It does not describe the output schema or pagination, and no output schema exists, but this is a minor gap given the tool's simplicity.

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, and schema description coverage is effectively complete by virtue of being empty. No parameter documentation is needed, and the description correctly adds nothing redundant. The zero-parameter baseline of 4 is appropriate.

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 and resource: 'List all Search Console properties'. It also clarifies the scope with 'available to the authenticated Google account', making the tool's purpose unambiguous and distinct from sibling tools like gsc_list_sitemaps or gsc_search_analytics.

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 clearly states the context: it lists all properties for the authenticated account. It does not explicitly name alternatives or exclusions, but given the zero-parameter signature and distinct resource type, the lack of explicit when-not guidance is a minor gap rather than a serious one.

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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. It conveys a read-only query behavior and enumerates returned metrics, which is useful. But it omits pagination behavior, row limits, aggregation semantics, or any mention that results may be filtered or grouped by dimensions, which are significant query behaviors.

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 two sentences are clear and free of filler, front-loading the action and scope. However, for a 12-parameter tool, this brevity leaves out critical guidance; it is efficient but not appropriately sized.

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 no output schema and low schema coverage, the description should compensate by explaining the query flow, required date parameters, output shape, and constraints. It only states scope and metrics, leaving most parameter semantics and behavioral context undefined, which is inadequate for correct invocation.

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 does not mention any parameters. Key inputs like startDate, endDate, dimensions, filters, siteUrl/allSites, rowLimit, and aggregationType are left undocumented, so the description adds no semantic value 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 uses a specific verb ('Run') and resource ('Search Analytics query'), and explicitly names the scope (one, selected, or all properties) and output metrics (clicks, impressions, CTR, average position). However, it does not differentiate from gsc_top_queries or gsc_keyword_opportunities, which likely overlap in search analytics data, so it lacks explicit sibling distinction.

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 no guidance on when to use this tool versus alternatives like gsc_top_queries. There are no exclusions, prerequisites, or context about which workload it fits. An agent must infer usage solely from the tool name.

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 must carry the full disclosure burden. It implies a read-only discovery operation but says nothing about response format, how the date parameters affect results, permissions, or rate limits. The behavioral transparency is 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?

Two short sentences with the main point front-loaded. There is no filler or redundant restatement of the title, and every word contributes to the tool's purpose.

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 no output schema and no annotations, the description gives a viable workflow but leaves gaps: it does not say why startDate and endDate are required or what the returned list looks like. The description is minimally adequate for selecting and invoking the tool, but an agent would still need to rely on schema defaults and enums to fully understand the call.

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 needed to compensate for the five parameters. It only hints at 'property' (siteUrl) and the output values, but it does not explain startDate, endDate, type, or dataState, or how they scope the results. The schema's enums and defaults provide some guidance, but the description adds little semantic value.

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 action ('Discover') and resource ('searchAppearance values available for a property'), directly matching the tool's purpose. It also differentiates the tool from siblings like gsc_search_analytics by explaining that the values are meant for filtering later Search Analytics calls.

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 explicitly states the intended workflow: call this tool to obtain searchAppearance values before making Search Analytics calls. It gives clear context for when to use it, but it does not mention exclusions or alternative sibling tools.

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 burden. It discloses an auth requirement (webmasters OAuth scope), which is useful, but it does not mention side effects, duplicate handling, verification requirements, or error behavior. This is adequate but incomplete.

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

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

Two sentences with no redundant phrasing. The core action is front-loaded and the auth note is a valuable single addition.

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 no output schema, no parameter descriptions, and no annotation coverage, the description is too sparse. It leaves an agent unsure about exact parameter semantics, response behavior, and when to choose this over the batch submission sibling.

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 only hints at parameter meaning via 'sitemap URL' and 'Search Console property.' It gives a rough mapping to feedpath and siteUrl but does not explain URL formats, accepted values, or how the two parameters relate.

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 action: submit a sitemap URL to a Search Console property. It identifies both the resource and the operation, though it does not explicitly differentiate itself from the sibling gsc_batch_submit_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?

There is no guidance on when to use this tool versus the batch submission or deletion siblings. The OAuth scope requirement is a prerequisite, not usage direction, so an agent must infer when this single-submit tool is appropriate.

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 burden of behavioral disclosure. 'Fetch' implies a read operation, but the description does not disclose dataState behavior, pagination, return format, authentication needs, or effects of options like allSites.

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. It is appropriately concise, though the extreme brevity leaves out important operational detail for a tool with 13 parameters.

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 13 parameters, absence of annotations, and lack of an output schema, the description is too sparse. It provides a useful high-level summary but omits significant behavioral and parameter details needed for correct invocation in varied scenarios.

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 add meaning. It maps the query, page, country, and device filters to the relevant parameters and hints at site selection via one/selected/all properties. However, many parameters such as type, limit, dataState, and includePages remain unexplained.

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: 'Fetch top query rows', and clarifies the scope as one, selected, or all properties. It is clear about the core action, though it does not explicitly distinguish itself from similar siblings like gsc_search_analytics or gsc_keyword_opportunities.

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 no guidance on when to use this tool versus alternatives such as gsc_search_analytics or gsc_keyword_opportunities. It implies usage for top queries but lacks explicit context, conditions, or exclusions.

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