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

With no annotations, the description carries the full burden of disclosing behavioral traits. It merely says 'manage,' which implies mutability but does not warn about the destructive 'remove' action, permission requirements, or any side effects. This is a significant gap for a tool that can modify account permissions.

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, concise and front-loaded with the domain. It wastes no words, though it could have included more actionable detail. Given the brevity, it earns a solid score for structure.

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 a multi-action schema with a destructive 'remove' operation, yet the description provides no context about actions, use cases, or consequences. There is no output schema, no annotation, and the description does not compensate for the missing behavioral context. This is inadequate for a tool of this complexity.

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

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

The schema descriptions cover 100% of the parameters with clear meanings (e.g., 'Optional email filter', 'Account action', 'Site URL to add to account', 'Account ID for add_site or remove'). The description adds no additional parameter-level information, so the baseline 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 the general purpose ('Manage Google Search Console service accounts and site permissions') but uses the vague verb 'manage' without specifying the exact operations (list, add, remove) that the tool performs. It does not distinguish itself from sibling tools like sites_manage, so purpose clarity is moderate.

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 guidance is provided. The description does not indicate when to use this tool versus alternatives such as sites_manage or sites_list, nor does it mention any prerequisites or exclusions. The agent is left to infer usage from the tool name alone.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It communicates read-only listing and auth context ('authorized user has access to'), and clarifies the difference between configured and discover modes. However, it does not mention potential scale of discover results, rate limits, or any permission requirements beyond the access statement.

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 leads with the verb and resource, then conveys both operation modes without extraneous detail. Every part 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 simple tool with two optional parameters and no output schema, the description covers its core behavior and scope adequately. Missing details like output format or the size of discover results are relatively minor given the low complexity.

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 mode enum and accountId default are already documented. The tool description only restates what the schema properties say and adds no meaningful parameter semantics beyond that.

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 ('AdSense publisher accounts'), and explicitly distinguishes two modes: configured vs discover. This clearly identifies what the tool does and separates it from sibling AdSense report/payment 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?

The description explains the mode parameter's semantics (configured saved accounts vs all accessible IDs) and notes the default, but it does not state when to prefer this tool over alternatives like adsense_report or adsense_payments_alerts. Usage guidance 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?

No annotations are provided, so the description must carry the behavioral burden. It does not explicitly state that this is a read-only retrieval operation, nor does it mention any side effects, data freshness, or authorization requirements. The description is a noun phrase rather than a behavioral statement.

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 very concise and front-loaded, with no redundant words. The parenthetical clarification adds useful detail. It could be improved by turning the noun phrase into an action-oriented sentence, but it is not bloated.

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 tool with one optional, well-documented parameter and no output schema, the description is minimally adequate. The main missing piece is explicit behavioral context (read-only, what states alerts can be in) and any guidance on when to prefer sibling reporting 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?

The only parameter, accountId, is already fully described in the schema with its default behavior. The tool description adds no additional parameter-level meaning, but because schema coverage is 100%, 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 clearly identifies the resource: outstanding AdSense payments and account alerts, with helpful parenthetical examples. It is distinguishable from sibling tools like adsense_report and adsense_accounts by its focus on payments and alerts, though it lacks a specific verb.

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 use case is implied: an agent would choose this tool when the user needs outstanding payments or account alerts. However, there is no explicit guidance about when not to use it or how it differs from adsense_report or adsense_accounts.

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, but it only summarizes what the tool reports. It does not disclose the response format, the default behavior when called with no arguments (LAST_7_DAYS range, auto-selected account), the startDate/endDate mutual dependency, or the rowLimit cap. The read-only nature is implied by 'report', but no explicit safety or side-effect context is given.

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?

A single tightly packed sentence that front-loads the resource (Google AdSense) and function (earnings & performance report), followed by the metric scope. Every element contributes, with no filler or repetition of schema 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?

The tool has 8 flexible parameters, no output schema, and no annotations, but the schema itself is exceptionally well documented (100% coverage with defaults and enums), so the description need not re-explain parameters. However, it does not convey what a zero-argument call returns or how the report output is structured, which matters for such a flexible tool. Adequate orientation, with clear gaps around output and default behavior.

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 schema already documents every parameter with defaults and enums, meeting the baseline of 3. The description's mention of default metrics and dimension breakdowns restates schema information rather than adding new parameter-level meaning. No inter-parameter nuance is added beyond what the schema already says.

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 function: a Google AdSense earnings and performance report, and enumerates the covered metrics (estimated earnings, impressions, clicks, CTR, RPM) plus dimension breakdowns. This differentiates it from the AdSense-adjacent siblings (adsense_accounts, adsense_payments_alerts) by focusing on reporting rather than account or payment management. It stops short of a 5 because the verb 'report' is generic and sibling differentiation is implied rather than 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?

There is no guidance on when to use this tool versus alternatives. The description never mentions adsense_accounts or adsense_payments_alerts, nor any conditions that should route an agent to them, so the agent must infer the boundary from tool names alone. No prerequisites, exclusions, or use-this-instead hints are present.

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. It only lists metric categories and does not disclose whether this is a read-only operation, how date ranges interact with realtime metrics, or what the response format looks like. This is a significant gap for a data-querying 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 concise sentence with no wasted words. It efficiently communicates the tool's domain, though it could be more informative without sacrificing brevity. The structure is clean and front-loaded with the main subject.

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 and annotations, and the presence of sibling analytics tools, the description is severely incomplete. It does not explain return values, date handling, or how this 'advanced' tool differs from analytics_query/analytics_compare. The agent is left without context to use it effectively.

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 schema already documents all four parameters. The description adds limited value by listing metric types that partially map to the metricType enum, but it provides no extra detail on parameter combinations, constraints, or format beyond what the schema states.

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 lists metric categories (e-commerce, realtime, user behavior, conversion funnels) but lacks a verb like 'query' or 'retrieve'. It's not a tautology, but it's vague about the exact operation. It sets this tool apart from siblings by naming specific GA4 metric types, but the purpose remains unclear without an action.

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 over alternatives like analytics_query, analytics_compare, or analytics_anomalies. The description does not mention any exclusions, prerequisites, or trade-offs, leaving the agent without direction on selection.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Detect' which implies a read operation, but it does not explain what constitutes an anomaly, whether data is modified, if any authentication is needed, or what the response format looks like. This is minimal and lacks depth.

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 is concise and front-loaded with the primary action. It is not bloated, but it could be slightly more informative without losing conciseness. It earns its place but does not provide additional context, so it is not a 5.

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 5 parameters, no annotations, and no output schema. The description gives only a high-level purpose and fails to explain the return value, how the threshold affects detection, or what 'anomaly' means in this context. This leaves significant gaps for an agent to invoke the tool correctly.

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

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

The input schema covers all parameters with descriptions, meeting the high coverage criterion (>80%). The description itself does not add extra semantic meaning, but the schema provides adequate definitions for engine, dates, siteUrl, and threshold. Thus, a baseline 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 uses a specific verb 'Detect' and a specific resource 'search traffic anomalies' across Google and Bing. This clearly distinguishes it from sibling tools like analytics_query or analytics_compare, which focus on querying or comparing data rather than anomaly detection.

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 any prerequisites, exclusions, or situations where another tool would be more appropriate. Given siblings like analytics_advanced and compare_engines, explicit usage context is absent.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, requires special permissions, or has any side effects. It also does not describe the response format or how 'drop attributions' are computed. The description is a thin feature list with no additional behavioral context, which is inadequate for a tool with no annotation support.

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 front-loads the core concept ('Period-over-period') and lists three key capabilities without any filler. It is appropriately sized for a tool with moderate complexity and earns a high score for 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?

The tool has 7 parameters, 2 enums, and no output schema, so the description should compensate by explaining the return values and edge cases. It only provides a brief feature list and does not clarify how modes differ, what 'trends' entails, or what the response looks like. This is insufficient for a tool with this complexity.

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 schema already documents all seven parameters, including enums for mode and engine. The description adds minimal extra meaning by framing the tool around 'period-over-period' comparisons, which hints at the date parameters, but it does not explain parameter interplay or the meaning of different modes. Baseline 3 is appropriate because the schema 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 clearly states the tool's scope: period-over-period search performance comparisons, trends, and traffic drop attributions. It identifies the resource (search performance) and implies analytical actions, though it lacks a direct verb like 'compare'. It distinguishes from siblings by focusing on period-over-period analysis and drop attribution, which are not mentioned in other tool names.

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 when period-over-period comparisons, trends, or drop attribution are needed, but it does not explicitly state when to use this tool versus alternatives like analytics_query or analytics_anomalies. No exclusions or alternative references are provided, so guidance is only 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 of behavioral transparency. It only lists supported dimensions but does not disclose return format, default date ranges, pagination, authorization requirements, or any side effects. For a read-like query tool, this is insufficient disclosure.

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, consisting of two short sentences with no wasted words. The first sentence establishes the tool's main purpose and differentiation, and the second lists key dimensions. All information is relevant and front-loaded.

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 has 7 parameters and no output schema, the description is quite thin. It doesn't explain what the query returns, how filters work, default date handling, or any orchestration details. The description is inadequate for an agent to fully understand the tool's behavior in complex 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?

The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides; it merely repeats the dimension values. No additional meaning or clarification is given.

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 this is a unified search performance query tool, and it differentiates itself by replacing single-dimension tools. It lists the supported dimensions (queries, pages, countries, devices, search appearances), providing a clear scope. However, it doesn't explicitly name the alternative tools it replaces, so it's not a perfect 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 implies that this tool should be used for search performance queries when multiple dimensions are needed, as it replaces single-dimension tools. However, it doesn't explicitly state when to use it versus the sibling analytics tools (e.g., analytics_compare, analytics_anomalies, analytics_advanced) or provide any exclusion criteria. The guidance is implied but not fully articulated.

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 for behavioral disclosure. It only states it compares GSC vs Bing, without explaining whether it performs read-only API calls, what data source it accesses, authentication needs, or how results are structured. For a multi-source comparison tool, 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 single-sentence description is concise and front-loaded with the core purpose. It lacks a bit of useful structure but contains no wasted words, earning a strong but not perfect score.

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

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

With 5 parameters, no output schema, no annotations, and only a one-line description, the tool's invocation context is under-specified. The description doesn't clarify optional parameter defaults, return format, or how the comparison matrix is built, making it insufficient for an agent to reliably use the tool.

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

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

Schema coverage is 100%, so the input schema already documents all five parameters. The description adds no parameter semantics beyond the schema, but the baseline of 3 is warranted since the schema fully covers parameter meaning.

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 a specific resource ('Cross-engine performance matrix comparing Google Search Console vs Bing Webmaster Tools'), making the tool's purpose clear. It doesn't explicitly differentiate from siblings like analytics_compare, so it stops short of a 5.

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

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

The phrase 'Cross-engine performance matrix' implies use when comparing GSC and Bing metrics, but the description provides no explicit when-to-use guidance or alternatives. A clear context is absent beyond the comparison intent, so usage is only implied.

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

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

Without annotations, the description carries full burden for behavioral disclosure. It clearly states the tool runs connectivity diagnostics, which is sufficient for a parameterless tool. However, it could elaborate on what diagnostics entail (e.g., pinging each account), but the simplicity mitigates the need.

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 concise sentences with no wasted words. It front-loads the action and purpose efficiently.

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 parameterless tool with no output schema, the description provides sufficient context: what it does and when to use it. No additional information is needed.

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 with 100% coverage. Per guidelines, a baseline of 4 applies when no parameters exist, and the description adds no unnecessary parameter info.

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 connectivity diagnostics') and resource ('all connected accounts'), clearly distinguishing it from sibling tools which focus on analytics, SEO, and indexing. It explicitly states the purpose: troubleshooting '0 results' or authentication issues.

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

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

The description explicitly states when to use the tool ('to troubleshoot '0 results' or authentication issues'), implying it should not be used for routine queries. This provides clear context for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by revealing that detection is heuristic, based on patterns like prompt verbs and conversational phrasing, operating on regular query-level performance data, and that results are an undercount rather than official. It does not describe return format or side effects, but the read-only nature is reasonably implied by 'Detect'.

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 first sentence front-loads the core purpose, and the second adds critical methodology and limitations. Every clause 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?

Given that there is no output schema and no annotations, the description provides enough context to select and invoke the tool: purpose, scope, method, data source, and limitations. The main gap is that it does not describe the response shape or whether results are grouped or detailed, but the current description is still sufficiently complete for a heuristic insights tool.

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

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

The input schema has 100% parameter description coverage, so the schema already explains days, engine, siteUrl, includePages, and minImpressions. The description does not add meaningful parameter-level semantics beyond the schema; it mentions matching patterns but does not map those patterns to specific parameters. 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 opens with a specific verb ('Detect') and a precise resource ('likely generative-AI / AI-Mode / conversational fanout queries across Google and Bing'). This clearly distinguishes it from sibling tools like analytics_query or compare_engines, which target general query analytics or engine comparison rather than genAI-specific detection.

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 for when this tool is appropriate: when you need to detect genAI-style queries and are aware that public APIs lack citation data. It also provides an important exclusionary caveat ('it is an undercount, not an official report'). However, it does not explicitly name alternative tools or state when not to use it in favor of regular analytics 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, but description implies read-only, non-destructive behavior by returning a 'map.' Lacks details on caching or rate limits, but acceptable for a simple initialization 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 efficient sentences, front-loaded with imperative 'Start here.' No wasted words.

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

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

Given zero parameters, no output schema, and no annotations, the description covers all needed context: what it returns, when to call, and its role as a starting tool.

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

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

No parameters, so baseline 4. Description appropriately does not add parameter info since none exist.

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 tool returns a complete map of capabilities, platforms, and workflows. Distinct from all sibling tools which focus on specific SEO/analytics functions.

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

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

Explicitly says 'Start here' and 'Call this once at the beginning of any session,' providing clear when-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action 'check' but does not state side effects, authentication requirements, rate limits, or return format. The description only lists what is checked without deeper behavioral context.

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 redundant or extraneous words. It efficiently communicates the tool's core 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?

The tool has four parameters and no output schema, but the description does not explain return values or how the Google/Bing behaviors differ beyond the basics. The 100% schema coverage helps, but the description alone leaves gaps in expected output and parameter interaction.

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 a baseline of 3 is appropriate. The description adds some context by linking Google to notification status and Bing to quota, which hints at how engine and type parameters might be used, but it does not explicitly map parameters to actions.

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 checks notification status for Google Indexing API and remaining daily Bing submission quota, using a specific verb ('Check') and identifiable resources. This distinguishes it from sibling tools like indexing_submit, which handles submissions.

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 for checking status/quota but does not explicitly state when to use this tool versus alternatives like indexing_submit, nor does it provide any exclusions or conditions. 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Submit', which implies an external write action, but does not disclose authentication requirements, rate limits, side effects, or that different methods (standard/index_now/remove) may have different behaviors. This is a significant transparency 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, front-loaded sentence that immediately states the action and object. It is concise with no wasted words, and every element (the three mechanisms) adds value.

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?

Despite having 7 parameters and 2 enums, the description does not explain how they interrelate (e.g., which parameters are needed for IndexNow vs Google), any prerequisites, or what the tool returns. With no output schema, the description should provide more operational context but does not.

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 little beyond naming the protocols, but the schema already documents all seven parameters with meaningful descriptions. No additional parameter semantics are provided, which keeps the score at the baseline.

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 resource ('URL(s) for indexing'), and clearly distinguishes from sibling tools like sitemaps_submit by naming the indexing protocols (Google Indexing API, Bing, IndexNow). It is unambiguous about what the tool does.

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

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

The description provides the general use case (submitting URLs for indexing) but gives no guidance on when to choose this tool over siblings like sitemaps_submit or indexing_status, nor on how to choose among the three mentioned protocols. Usage is implied rather than explicitly explained.

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 full burden. 'Inspect' suggests a read operation, but it doesn't state that explicitly, nor does it mention response format, rate limits, or behavior for invalid URLs. Minimal behavioral context beyond the action verb.

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?

A single, well-structured sentence that immediately states the verb and resource. No redundant words or filler. The key constraints (single/batch, engines) are included efficiently.

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 no annotations, the description should explain what the tool returns or any important caveats. It doesn't mention the default engine behavior (all), batch size limits, or what the inspection output looks like, leaving a significant gap for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context by referencing 'single or batch URLs' (matching urls array) and 'Google or Bing' (matching engine enum), which reinforces the schema but doesn't add new syntax or format 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 the specific verb 'Inspect' and names the resource (indexing, canonical, crawl status) and scope (single/batch URLs on Google/Bing). This clearly distinguishes it from sibling tools like analytics_query or indexing_submit, though indexing_status overlaps somewhat.

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 when to use it (inspecting URL status across engines), but provides no explicit guidance on when not to use it or alternatives. It mentions batch and engine options, but lacks exclusions or comparisons to 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?

No annotations are provided, so the description must disclose behavioral traits, but it only says 'Run ... analysis' without mentioning any side effects, data returned, rate limits, authentication, or caveats. There is zero behavioral transparency beyond the bare action.

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 unnecessary words or repetition. It is perfectly concise and structured for quick parsing.

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 no annotations, the description should explain what the analysis returns and any relevant context, but it does not. It also lacks usage guidance, leaving important context incomplete for a tool with multiple parameters.

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 schema already documents all four parameters. The description adds no extra meaning beyond the schema, earning the baseline score 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 clearly states a specific action (Run) on a specific resource (PageSpeed Insights & Core Web Vitals performance analysis) for a page. It effectively distinguishes this tool from siblings like seo_audit or site_health_check by focusing on PageSpeed and Core Web Vitals.

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. There are no exclusions, prerequisites, or alternative tool suggestions, leaving the agent to infer usage solely from the tool's name and purpose.

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 itself must carry the burden of behavioral disclosure; it mentions supported formats but does not describe the output/return value, side effects, or any prerequisites. For example, it should state that validation is read-only and returns a validation report or errors.

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 is front-loaded with the action and lists the key input formats, containing no redundant information. It is 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?

While the tool is simple with one parameter and no output schema, the description clearly states the action and input formats, but it omits what the validation returns (e.g., a report, errors, pass/fail), which is a meaningful gap given the absence of an output schema. The description is adequate but 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?

The schema already documents the sole 'url' parameter with a clear description; the tool description adds context about supported formats but does not add parameter-specific semantics beyond the schema. With 100% schema coverage, the baseline is 3 as the description does not contradict or enhance parameter understanding.

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 'Validate' with a resource 'structured data' and lists supported formats (JSON-LD, Microdata, RDFa) for a given URL, clearly distinguishing it from siblings like inspection_inspect or pagespeed_analyze which address different concerns. It precisely states what the tool does.

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

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

No explicit guidance is provided regarding when to use this tool vs alternatives; the intended usage is implied by the name and description but not stated as a recommendation or exclusion. It does not mention when not to use it or point to sibling tools for related tasks.

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. It only states that the tool performs analysis, with no mention of whether it is read-only, what permissions are needed, rate limits, or output format. The word 'analysis' hints at a non-destructive operation, but this is insufficient for a complex tool with multiple analysis modes.

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 lists the core analysis types with no filler. Every word contributes to conveying the tool's purpose. It is exceptionally concise and well-structured.

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 complex tool with 8 analysis types, 5 parameters, and no output schema. The one-line description does not explain what each analysis type returns, how parameters like brandKeywords or minImpressions influence behavior, or what the output structure looks like. It is far too minimal for the tool's complexity, leaving significant gaps for an agent to invoke it correctly.

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

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

The input schema already describes all five parameters with full coverage (100%), so the baseline is 3. The description essentially repeats the enum values of the 'type' parameter without adding deeper meaning, such as parameter dependencies (e.g., brandKeywords for brand_vs_nonbrand) or interpretation of thresholds. It adds no semantic value 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 identifies the tool as 'Specialized SEO intelligence analysis' and enumerates eight distinct analysis types (recommendations, quick wins, cannibalization, etc.), which clearly conveys its function and differentiates it from siblings like analytics_query or site_health_check. However, it lacks an explicit verb (e.g., 'runs', 'performs'), which keeps it from a perfect score.

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 list of analysis types implies when to use the tool (e.g., for quick wins or cannibalization), but there is no explicit guidance about when to choose this tool over alternatives, nor any exclusions. The usage context is only implied, not clearly stated.

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

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

With no annotations, the description must disclose behavioral traits, but it only lists capability names. It does not state whether the operation is read-only, requires authentication, has rate limits, or returns specific data shapes. The lack of any behavioral context leaves the agent guessing about side effects and output format.

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 concise fragment that lists the tool's capabilities in a scannable way. No redundant words. However, it is a noun phrase rather than a full sentence, which slightly reduces clarity, but it earns a high score for efficiency.

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?

Despite having six parameters and no output schema, the description provides no information about return values, how to interpret the three types, or what the output structure looks like. It does not compensate for the missing output schema and leaves the agent without enough context to fully understand the tool's behavior.

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 already provides 100% description coverage for all six parameters, so the baseline is 3. The description adds slight meaning by aligning 'keyword performance stats', 'related query expansion', and 'search volume estimates' with the 'type' enum values, but it does not explain parameter syntax, dependencies, or country/language format beyond what the schema already provides.

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

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

The description lists concrete outputs ('Keyword performance stats, related query expansion, and search volume estimates') that map directly to the tool's function and distinguish it from sibling analytics/site tools. It lacks a verb but communicates the resource (keywords) and the types of analysis. Could be clearer by explicitly stating 'perform keyword research' but is specific enough.

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 like analytics_query or compare_engines. There is no mention of suitable scenarios, exclusions, or relationship to sibling tools. The existence of the 'type' enum (stats/related/traffic) implies different use cases but is not explained in the description.

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 transparency burden. It states 'health audit' but does not say whether it is read-only, what data is checked, what output the user can expect, or any side effects. 'Audit' implies a non-mutating action, but that is not explicit, and no details on return values or limitations are given.

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 phrasing. The word 'Comprehensive' is somewhat vague but not wasteful. It is well-front-loaded and easily scannable, though the brevity comes at the cost of omitted contextual detail.

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 and annotations, the description is too terse to be complete. It does not explain what 'health audit' entails, what each level (summary, full, crawl_issues) returns, or how it relates to sibling tools like diagnostics or seo_audit. The tool has three optional parameters, but the description gives no sense of when to adjust them.

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 little beyond the schema: it mentions the two search engines, but the engine parameter already enumerates google, bing, and all. No additional meaning is provided for 'level' or 'siteUrl'. Thus it meets the baseline without enhancement.

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 is specific in scope: a health audit across Google Search Console and Bing Webmaster Tools. It clearly indicates the resource (site health) and the action (audit). However, it doesn't contrast with sibling tools like seo_audit or diagnostics, so it only partially distinguishes itself.

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 over alternatives. There is no mention of 'use this for...' or 'instead of...', and the sibling tools (seo_audit, diagnostics, compare_engines) suggest plausible overlap, but the description gives no criteria for choosing this 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it deletes a sitemap, but does not mention consequences (e.g., irreversibility), permission requirements, error behavior, or how the operation affects both engines depending on the 'engine' parameter. This is a significant gap for a destructive 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, focused sentence with no extraneous words. It is well-structured and immediately conveys 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?

The tool is relatively simple with three parameters, all documented in the schema. However, without an output schema or annotations, the description leaves gaps about return values, side effects, and behavior when 'engine' is 'all'. It is adequate but not fully complete for a destructive 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%, so the baseline is 3. The description adds only marginal value by naming the two engines (Google Search Console, Bing Webmaster Tools) which aligns with the 'engine' parameter enum, but does not elaborate on feedUrl or siteUrl beyond what the schema already provides.

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

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

The description clearly states the action ('Delete a sitemap') and the resource ('from Google Search Console or Bing Webmaster Tools'), distinguishing it from sibling tools like sitemaps_list and sitemaps_submit. 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?

The description provides clear context for when to use the tool (when deleting a sitemap) and mentions both target engines. However, it does not explicitly discuss alternatives or when not to use it, though the destructive nature of the operation makes the use case fairly evident.

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 indicates the tool lists submitted sitemaps, implying a read operation, but does not mention authentication requirements, rate limits, or what 'status' values are possible. The word 'submitted' adds some scoping, but other behavioral traits are 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 clear sentence with no redundant words. It front-loads the verb and resource, making it immediately understandable. It earns its place without any 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?

The tool has no output schema and no annotations, and the description is minimal. It does not explain the return format, the meaning of 'status', or how the engine and feedUrl parameters affect results. Given the list operation's moderate complexity, the description is too sparse to fully prepare an agent for 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 100%, so the baseline is 3. The description mentions 'for a site' which loosely maps to siteUrl, but it does not elaborate on the engine or feedUrl parameters. Since the schema already describes these parameters, the description adds minimal extra 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 clearly states the verb 'List' and the resource 'submitted XML sitemaps and status' for a site. This distinguishes it from sibling tools like sitemaps_submit and sitemaps_delete, making the purpose unambiguous.

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

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

The description implies usage when you need to view submitted sitemaps and their statuses, but it does not explicitly state when to use this tool versus alternatives like sitemaps_submit or sitemaps_delete. No exclusions or alternative guidance is provided, so it falls to implied 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 full burden of behavioral disclosure. It only states that a sitemap is submitted, but does not explain side effects (e.g., whether existing sitemaps are replaced), idempotency, or any asynchronous behavior. This is a significant gap for a mutating 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-structured sentence that directly conveys the purpose without any filler or repetition. 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 description covers the core action and targets, but given no output schema or annotations, it omits details about return values and behavioral nuances. For a tool with moderate complexity, this is adequate but 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 coverage is 100%, with each parameter having a description in the schema. The tool description itself adds no further parameter semantics, so the baseline score of 3 applies based on the schema's sufficiency.

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

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

The description clearly states the verb 'Submit' and the resource 'XML sitemap', with explicit targets (Google Search Console and/or Bing Webmaster Tools). This distinguishes it from sibling tools like sitemaps_list and sitemaps_delete, which handle listing and deletion.

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 related workflows, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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 burden. It does reveal the operation is a read-only listing and mentions 'verified' properties, but it doesn't explain what 'verified' means or how GA4 properties fit into the engine parameter. Doesn't cover pagination or return format.

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 sentence, front-loaded with the verb, no filler. Every word contributes to the meaning.

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

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

The tool is simple (one param, no output schema), but the description lacks important context: what 'verified' means, how GA4 relates to the engine parameter, and what the return data looks like. Adequate for a basic listing tool but with gaps.

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% (engine has a description). The description adds platform names but creates ambiguity by introducing GA4, which is not a search engine and doesn't map cleanly to the enum values (google, bing, all). Thus it adds some value but also confusion.

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 names the resource ('verified web properties') plus the target platforms (GSC, Bing, GA4). This clearly distinguishes it from siblings like sites_manage and sitemaps_list.

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 its usage context—listing verified sites across specific platforms. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for a list operation. A small deduction for not explicitly saying 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?

No annotations are provided, so the description carries the full burden. It states the action ('add or delete') but does not disclose side effects, permissions, reversibility of delete, or any limitations. For a mutation tool, 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?

A single sentence, front-loaded with the action and resource, no unnecessary words. 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?

Given it's a mutation tool with no annotations, no output schema, and no behavioral disclosures, the description is too minimal. It doesn't mention outcomes, error handling, or prerequisites, making it incomplete for the 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 coverage is 100% with descriptions for all parameters, so the baseline is 3. The description adds no specific meaning beyond the existing schema descriptions; it merely aligns with the action enum.

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

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

The description clearly states the verb (add/delete) and resource (web property), and explicitly names the two target platforms (Google Search Console or Bing Webmaster Tools). This distinguishes it from sibling tools like sites_list or accounts_manage.

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 (it's for adding/deleting sites) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. It is adequate but leaves the agent to infer context.

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