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 mentions that the property stays unverified until ownership is confirmed, which is useful. However, it does not cover potential side effects (e.g., replacement, duplicate behavior), permissions, or reversibility—important for a mutation 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?

Two sentences, no filler. The action is front-loaded, and the format guidance and verification note are directly relevant. Every word 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 tool with a single parameter and no output schema, the description covers the essential usage and a key behavioral trait (unverified state). It omits potential edge cases like duplicate properties or error handling, but these are likely covered by the API itself. Overall, it is sufficiently complete 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?

Schema coverage is 100% (siteUrl is described), so baseline is 3. The description adds real value by explaining the two accepted formats and their distinctions (sc-domain: vs https://), which goes beyond the schema's single example. This clarifies acceptable input and reduces ambiguity.

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 ('Add a property to Search Console') with a specific resource and verb, and distinguishes itself from siblings like list, remove, or analyze tools. It also provides concrete URL format examples, making the tool's scope unmistakable.

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 clear context on how to form the siteUrl (domain vs. URL-prefix) and notes the verification status, implying when the tool is appropriate (adding a property). It does not explicitly state when not to use it or name alternative tools, but the purpose is distinct enough that an agent can infer usage.

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 the key consequence that indexed pages are not deindexed, which is valuable, but it does not mention whether the action is reversible, what permission or property requirements exist, or what happens if the sitemap does not exist.

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 sentences with no filler. The primary action is front-loaded, and the crucial non-deindexing caveat is packed into the second sentence without excessive wording.

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 deletion tool, the description plus fully documented schema is largely sufficient. The lack of annotations and output schema is partially mitigated by the explicit consequence statement, though a bit more context about preconditions or return behavior 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 100%, so the parameters are already documented. The tool description adds no additional insight about feedpath or siteUrl beyond what the schema already states, so it earns the baseline score without extra credit.

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 names the specific verb 'Remove' and the exact resource ('a sitemap') scoped to 'a property', making the action unambiguous. The second sentence additionally distinguishes this from deindexing content, which prevents confusion with broader content-removal operations.

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 establishes the context for use: removing a sitemap from a property. It also implicitly excludes the deindexing use case, though it does not explicitly name an alternative sibling tool like gsc_submit_sitemap or gsc_list_sitemaps for contrast.

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 full burden. 'Get details' clearly indicates a read operation, and the parenthetical lists what the response will contain, but it does not mention error behavior for unsubmitted or invalid URLs, authentication requirements, or the fact that siteUrl has a default fallback. The description is not misleading, but it is minimal on behavioral nuance.

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 that front-loads the core action ('Get details') and immediately lists the relevant response aspects. Every word adds value, and there is no redundant restatement of the tool name or title.

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 only two parameters, no output schema, and no nested objects, the description is nearly complete: it identifies the target resource, the required input, and the expected response contents. It could mention behavior for missing or invalid sitemaps, but the existing description covers the main calling context adequately.

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 100%, with siteUrl documented as 'Falls back to GSC_DEFAULT_SITE' and feedpath documented as 'Sitemap URL, e.g. https://www.example.com/sitemap.xml'. The tool description reinforces that the target must be a single submitted sitemap but does not add meaning beyond the schema, so the baseline score of 3 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 states a specific verb ('Get'), a specific resource ('one submitted sitemap'), and the exact kind of details returned ('status, contents, errors/warnings'). This clearly distinguishes it from sibling tools like gsc_list_sitemaps, which would handle multiple sitemaps, and gsc_submit_sitemap/gsc_delete_sitemap, which perform different actions.

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 'one submitted sitemap' implies the tool is for retrieving details about a single existing sitemap, but it never explicitly says when to prefer this over gsc_list_sitemaps or what to do if the sitemap has not been submitted. Usage context is present but only implied, not stated as a positive or negative 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?

With no annotations, the description covers the operational constraints: permission level and property ownership. It also implies read-only behavior via 'check' and lists the type of information returned, making side effects and access requirements 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 succinct, two sentences, with the primary purpose stated first. It avoids unnecessary elaboration while delivering all essential information in a well-ordered manner.

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 absence of an output schema, the description adequately covers the tool's capabilities and constraints. It does not require explanation of return values and is complete for an inspection tool in the context of sibling tools.

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?

All parameters have schema descriptions, and the tool description reinforces the key parameter (inspectionUrl). Since schema coverage is 100%, the description does not need to repeat parameter details; the existing info 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 clearly states the action ('check') and the resource (URL), listing specific aspects (coverage, canonical, crawl, mobile usability, rich results) and the ownership constraint. It is distinct from sibling tools which handle site management or 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 explicitly outlines prerequisites (OWNER permission, owned properties) and implicitly indicates when to use (to inspect URL details). The description provides clear conditions for successful use, leaving no ambiguity about applicability.

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 cover behavioral traits. It is a read-only operation implied by 'list', but the description does not explicitly mention side effects, permissions, or rate limits. It does convey the primary action and return data, but lacks explicit transparency about non-obvious 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?

Single, succinct sentence with clear structure: verb first, then object, then additional detail. No unnecessary 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?

The description is adequate for a simple list operation with two parameters and no output schema. It mentions the type of data returned (submission dates, indexed counts), giving a good expectation. Could be slightly more explicit about output format but overall 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 descriptions cover both parameters comprehensively (100% coverage). The tool description does not add extra meaning beyond what the schema already provides, so baseline 3 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?

Clearly states the action (list), the resource (submitted sitemaps), and the property context. It also specifies the returned data (submission dates, indexed counts), distinguishing it from sibling tools like list_sites or 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?

Implies usage for listing all sitemaps for a property, but does not explicitly contrast with alternatives such as gsc_get_sitemap (for a single sitemap) or gsc_list_sites (for properties). No when-not to use guidance is provided.

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 full responsibility for behavioral disclosure. It adequately states the operation's outcome: listing all accessible properties and exposing permission levels. It does not mention potential side effects (none expected) or limitations like pagination, but for a simple list operation, this is sufficient transparency and does not hide any surprising 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 a single, efficient sentence that front-loads the action and resource, then adds the key detail of permission levels. There is no fluff or redundant phrasing, making it easy for an agent to parse quickly.

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

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

For a zero-parameter, no-output-schema tool, the description is complete. It tells the agent exactly what will be returned: all properties the service account can access, including permission levels. Nothing else is needed for correct invocation or interpretation of results.

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 the schema is complete (100% coverage) and there is nothing for the description to add. The baseline for 0-parameter tools is 4 because the schema already defines everything. The description's mention of 'permission levels' does not pertain to parameters but to the output, so it doesn't add parameter semantics but is not 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 states a specific action ('List'), a clear resource ('all Google Search Console properties'), and the scope ('the service account has access to, including permission levels'). This precisely differentiates it from siblings like gsc_add_site or gsc_search_analytics, which operate on specific properties or metrics.

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 context about what the tool does and implies its use as an inventory/overview tool, distinct from the mutation-oriented siblings. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions like 'use this instead of gsc_list_sitemaps when you want sites only'. It stops short of explicit routing guidance.

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 communicates that the operation is destructive, but does not mention irreversibility, permission requirements, side effects on associated data, or whether the property can be re-added later.

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 wasted words. The core action and object are front-loaded, making it easy to scan.

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 destructive tool with no annotations and no output schema, the description is too sparse. It omits important operational context such as whether removal is permanent, what happens to existing data, and any confirmation or authorization 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 100%, and the single parameter siteUrl is already described as 'Property to remove'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.

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 ('Remove') on a specific resource ('a property from Search Console'). This clearly distinguishes it from sibling tools like gsc_add_site and gsc_list_sites.

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 tool versus alternatives, nor any mention of prerequisites or conditions. The description only states what the tool does, not when it should be selected.

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 full burden; it does not mention side effects, permissions, rate limits, or the structure of the response, leaving behavioral aspects undisclosed.

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 sentence but packs essential information about the operation, metrics, and defaults without unnecessary verbosity.

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 complexity with 10 parameters and nested filter groups, the description is too brief; it omits explanations of output format, available search types, aggregation options, and filter semantics, making it insufficient for full understanding.

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 description adds minimal insight beyond the schema; it notes the default date range and valid dimensions, but many parameters like searchType, aggregationType, and filters are not explained in the description, and the schema already covers most descriptions.

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 (run a query) and the resource (Search Console search-analytics), and lists the returned metrics and grouping dimensions, making it distinct from sibling tools about sites and 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?

The description does not provide any guidance on when to use this tool versus other tools, or any conditions that would trigger its use; it only states what it does.

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 behavioral disclosure. It indicates a mutation ('Submit') but does not state side effects, idempotency, potential errors, or whether repeated submissions are allowed. The 'same as clicking Submit in the UI' hint is thin and fails to cover key operational aspects like state changes or auth requirements.

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 that front-loads the primary action. The parenthetical UI analogy adds minor context without bloat. It is efficient, though the brevity leaves room for missing behavioral detail that could be seen as excessive compression.

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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It omits crucial context such as the need for an existing property (siteUrl) or the relationship with sibling actions like gsc_add_site. The lack of guidance on prerequisites or expected outcomes leaves the agent under-informed for a non-trivial write operation.

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 100%—both parameters have descriptions (siteUrl fallback and feedpath example). The tool description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema fully documents 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 clearly states the action ('Submit') and the resource ('a sitemap URL for a property'). It distinguishes from sibling tools like gsc_list_sitemaps and gsc_get_sitemap by describing a submission operation. The 'same as clicking Submit in the UI' reinforces the action but doesn't add specificity about the property context.

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. It does not mention that it is for adding a new sitemap, nor does it reference any prerequisites (e.g., site verification) or conditions that would make it the right choice over gsc_delete_sitemap or gsc_list_sitemaps. The UI comparison is vaguely contextual but not directive.

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