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. It does not mention potential errors (e.g., duplicate site), verification requirements, or idempotency, leaving the agent without crucial context for a mutation 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 a single, well-formed sentence with zero unnecessary words. It is front-loaded with the verb and object, making it immediately scannable.

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 only one parameter, full schema coverage, and an output schema, so the description is minimally viable. However, it lacks behavioral context (e.g., error conditions, side effects) that would make it fully complete without 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?

Schema coverage is 100% with a clear description of the site_url parameter. The tool description adds no 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?

The description clearly states the specific action (add), the resource (site), and the context (Search Console). It distinctly differentiates from sibling tools like list_sites_tool or delete_site_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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or competing 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?

No annotations are provided, so the description must disclose behavioral traits. It only states the action without noting irreversibility, permission requirements, or side effects—critical information for a destructive delete operation. The description adds no value beyond what the tool name implies.

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 that communicates the core function efficiently. Every word serves a purpose, and there is no redundant or filler content.

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?

Although the input schema is complete and an output schema exists, the description omits essential context for a destructive operation, such as whether the deletion is permanent or requires confirmation. For a tool that removes data, this is a significant gap, leaving the description minimally adequate.

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% for both parameters, and the description adds no extra parameter context. Per the rules, this warrants a baseline score of 3; the description neither enhances nor detracts from the 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 clearly states the action (Remove) and the resource (a sitemap from Search Console), making it immediately distinguishable from sibling tools like submit_sitemap or list_sitemaps. The verb+resource combination precisely captures the tool's purpose.

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 action is self-evident, but the description provides no explicit guidance on when to use this tool versus alternatives such as delete_site_tool. There is no mention of prerequisites, exclusions, or when this tool would be appropriate over others.

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 'Remove a site' without noting irreversibility, permission requirements, or side effects on associated resources like sitemaps. For a deletion 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 a single sentence that directly states the tool's function with no unnecessary words. It is front-loaded and efficient.

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 is simple (one parameter, output schema exists), and the description conveys the basic purpose. However, the lack of any warning about the destructive nature or post-removal effects makes it incomplete for a delete operation, especially given 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?

The schema fully describes the sole parameter (site_url) with 'Site URL to remove', so schema coverage is 100%. The description adds no extra parameter information, matching the baseline of 3 for high schema coverage.

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 'Remove a site from Search Console' specifies a clear action ('Remove') and resource ('site'), distinguishing it from sibling tools like add_site_tool and list_sites_tool. The verb is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or conditions for removal mentioned. The description only states what the tool does, not when to invoke 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?

No annotations are provided, so the description carries the full burden. 'Get details' only conveys the read-only nature inherent in the verb, but it does not disclose any additional behavioral traits such as required authentication, error behavior, or response specifics. This is a minimal disclosure without meaningful transparency beyond the obvious.

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 one short sentence with no superfluous words. It is immediately readable and front-loaded with the essential action. This is exemplary conciseness.

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 need not be explained. However, the description does not mention any preconditions (e.g., the sitemap must exist) or provide usage context beyond the basic purpose. It is minimally sufficient for a simple getter but not fully complete in guiding the agent's 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 schema covers both parameters with descriptions (100% coverage), so the tool description adds no extra parameter insight. Both required parameters are clearly defined in the schema, allowing the agent to understand inputs without additional narrative. Baseline 3 is appropriate since the schema already does the heavy lifting.

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 'Get details for a specific sitemap' uses a specific verb ('Get') and resource ('specific sitemap'), clearly distinguishing it from sibling tools like list_sitemaps_tool (which lists all) and submit/delete variants. This is unambiguous and effectively differentiates from alternatives.

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 use when needing details on one sitemap, but it does not explicitly state when to use versus alternatives, nor does it provide exclusions or preconditions. Usage context is left to the agent to infer from the tool name and schema, making it adequate but not explicit.

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 conveying behavioral traits. 'Get' implies a read-only operation, which is transparent enough for a simple getter, but no details about edge cases (e.g., non-existent property) or permissions are provided.

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, clear sentence that is front-loaded and contains no extraneous words. It fully serves its purpose without wasted content.

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 simplicity (one parameter) and the presence of an output schema, the description is largely complete. However, it lacks explicit usage context relative to sibling tools, which is a minor 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 input schema provides 100% coverage with a detailed description of site_url, including examples of both site URL and domain property formats. The description adds no additional parameter information over the schema, 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?

The description clearly states the tool gets details for a specific Search Console property, using the verb 'Get' and referencing a specific resource. This distinguishes it from sibling tools like list_sites_tool, add_site_tool, and delete_site_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?

The phrase 'for a specific' implies a targeted lookup, but no explicit when-to-use or alternative tools are mentioned. There is no naming of list_sites_tool for listing all sites or get_sitemap_tool for sitemap details.

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. It discloses what information is returned (index coverage, crawl status, mobile usability, rich results), which is helpful, but it does not explicitly state that the operation is read-only, nor does it mention any permissions, rate limits, or error conditions.

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

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

Two sentences, each earning its place. First sentence states the tool's core purpose, second enumerates the key output categories. No redundancy or 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?

The tool has three fully documented parameters and an output schema, so return values are already specified. The description covers the essential purpose and informational content; lacking only explicit usage caveats, which are minor given the straightforward read-like nature.

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 each parameter already explained (site_url as property, inspection_url as fully-qualified URL, language_code as localization). The description adds no additional meaning beyond the schema, 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?

Description uses specific verb 'Inspect' with clear resource 'URL's index status in Google Search' and lists return categories (index coverage, crawl status, mobile usability, rich results), distinguishing it from sibling tools focused on sites, sitemaps, and 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?

Provides clear context that this tool inspects a specific URL's status within Google Search, making it obvious when to use. However, it does not explicitly mention when not to use it or compare to alternatives like query_search_analytics for performance data.

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 must carry the burden of behavioral disclosure. It does not state that this is a read-only operation, mention any output format, or note potential side effects. The word 'list' implies a query, but the description lacks explicit transparency about 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, front-loaded sentence with zero wasted words. It fully conveys the action and object in one concise statement.

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 list tool with one parameter, the description is complete in conveying what it does and that it requires site_url. An output schema exists, reducing the need to explain return values. However, the absence of usage guidelines and behavioral notes prevents a perfect score.

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% with site_url described as 'Site URL or domain property.' The description adds only 'for a site,' which loosely links to the parameter but does not provide additional meaning, format, or usage details beyond the schema. 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?

The description uses a specific verb ('list') and resource ('all sitemaps') with an explicit scope ('for a site'), clearly distinguishing it from sibling tools like get_sitemap (single sitemap), submit_sitemap, and delete_sitemap. It names the exact action and object.

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 on when to use this tool versus alternatives, such as get_sitemap to retrieve a specific sitemap or submit_sitemap to add one. The description simply states the action without context or 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 provided, the description carries the burden of behavioral disclosure. It mentions that the list is accessible by the authenticated user and that it returns entries with permission levels and site URLs, providing useful context. However, it does not explicitly state that the operation is read-only, whether pagination is used, or any rate limits, leaving some 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 concise and front-loaded: one sentence states the action and scope, and the second defines the return value. There is no unnecessary detail, making it appropriately sized for the tool's simplicity.

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 zero parameters and the presence of an output schema, the description provides sufficient context for a listing operation. It clearly states what is returned and the scope. It could have mentioned error behavior or auth prerequisites, but these are not critical for a simple list tool and are largely covered by 'accessible by the authenticated user.'

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, and the description correctly adds no parameter information. Per the rule, 0 params yields a baseline of 4. The description's note about the return content (permission levels and site URLs) enriches understanding but is not parameter-related.

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 tool's function with a specific verb 'List' and resource 'Search Console properties', and explicitly scopes it to those accessible by the authenticated user. This distinguishes it from sibling tools like get_site_tool (single property), add_site_tool, and delete_site_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?

The description implies usage for listing all properties, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. For example, it doesn't say 'use this to get the site URLs needed for other tools' or 'use get_site_tool for a specific property.' Usage is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses the return metrics and grouping behavior, which implies a read-only operation. However, it does not mention potential limitations, rate limits, data freshness, or side effects, which would be valuable 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 two sentences, front-loaded with the primary purpose, then return value, then suggested use cases. Every sentence adds value with no fluff.

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 (10 parameters, output schema exists), the description covers the essential purpose, output metrics, and use cases. It does not need to explain return values because an output schema is present. Missing details like pagination and data state are handled by the schema, so the description is sufficiently 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 baseline is 3. The description adds narrative about dimensions (pages, queries, countries, devices, date ranges) and filters, but these are already covered in the schema parameters. It does not introduce additional meaning beyond the 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 clearly states the tool queries search traffic data, names the returned metrics (clicks, impressions, CTR, average position), and distinguishes it from sibling site management tools. The verb 'Query' and resource 'search traffic data' are specific and unambiguous.

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

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

It explicitly states when to use the tool: 'Use this to analyze search performance for specific pages, queries, countries, devices, or date ranges.' This provides clear context, though it does not mention alternatives 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 provided, the description carries the full burden of behavioral disclosure. The phrase 'Submit a sitemap for crawling' gives no detail about side effects (e.g., whether it overwrites existing sitemaps), required permissions, or error conditions. This is a significant gap 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?

The description is a single sentence with no redundant wording, making it very concise. However, it is so brief that it lacks structure or elaboration; there is no wasted text, but the overall content is minimal.

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 an output schema and only 2 parameters, so complexity is low. Yet, the description is too sparse: it omits when to use the tool, behavioral implications, and any context about how it fits with site management. Given there are no annotations, this description is not complete enough for an agent to use it confidently.

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 feedpath and site_url are described in the schema. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies. It does not harm, but it does not compensate for any vagueness in the site_url description.

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 the specific verb 'submit' with the resource 'sitemap' and the purpose 'for crawling', which clearly distinguishes it from sibling tools like list_sitemaps_tool or delete_sitemap_tool. However, it doesn't explicitly mention the scope or target, making it slightly less precise than a 5.

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

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 add_site_tool or get_sitemap_tool. It does not state prerequisites (e.g., site must exist) or mention any specific scenarios where this tool is appropriate.

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