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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context: the need for PERPLEXITY_API_KEY (auth) and cost (cents per call). It does not contradict annotations.

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

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

Three sentences: purpose, use case, and requirements. No fluff, information is front-loaded. Every sentence contributes.

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 explains the output content (sources cited, domain presence, answer text) and the API key requirement. For a read-only tool with no output schema, this is sufficient. Minor gaps like error handling or rate limits are not critical.

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 75% (domain and question have descriptions; model and country do not). The description implicitly clarifies the question and domain parameters but adds no detail about model or country. It provides marginal 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 states a specific verb ('Ask Perplexity's Sonar API') and a clear outcome (report citations, domain presence, answer text). It is distinct from all sibling tools, which focus on other aspects like robots, sitemaps, or Google data. No other tool addresses AI citation checking.

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

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

It provides a clear use case ('see if the site is being cited by AI search for target queries') and prerequisites (API key, paid). It does not explicitly name alternative tools for when not to use it, but the uniqueness of the function makes the context sufficient.

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

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

Annotations already declare readOnlyHint and idempotentHint, lowering the bar. The description adds that it performs live requests with each bot's User-Agent, which is a behavioral trait not fully covered by annotations, and notes detection of UA-based blocks. This adds valuable context beyond the structured fields.

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 dense two-sentence paragraph listing many crawlers and explaining consequences. While it is front-loaded with the main action, it is not concise and could be trimmed without losing key information. It is informative but not optimized for quick scanning.

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 there is no output schema, the description does not explain what the result looks like, but it clearly explains the method and the significance of blocked bots. Annotations cover safety, and the tool's purpose is well understood. It is fairly complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, and both parameters (url and liveFetch) are already documented in the schema. The description does not add significant meaning beyond the schema, except noting the URL should be representative. Baseline 3 is appropriate when the schema handles the 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 clearly states the tool checks whether AI and search crawlers can reach a page, and details the method (robots.txt rules and live UA requests). It is specific about the resource and lists many crawlers, but does not explicitly differentiate from the sibling robots_check tool, which likely performs a similar check.

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 the tool is for AI crawler access and mentions consequences of being blocked, but it does not explicitly state when to use this tool instead of alternatives like robots_check or ai_citation_check. There is no exclusion or comparison with siblings, leaving usage to inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing an external API key requirement and describing the output behavior (link detection and AI context). No contradictions found.

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

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

The description is three sentences with no filler. It leads with the core action, then explains the purpose and adds the key prerequisite, all in a tight structure. Every sentence contributes to understanding.

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 6 parameters, an external API dependency, and no output schema. The description gives a high-level output hint (list of mentions with link status and AI context) but omits details on response structure, pagination, error handling, rate limits, or behavior when the API key is invalid. For a tool with these complexities, more specifics would be needed for fully autonomous 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 only 17% (domain only). The description clarifies the roles of 'brand' and 'domain' implicitly ('brand name', 'your own domain') but provides no information about count, country, language, or checkLinks. With such low coverage, the description must compensate but does not, leaving several parameters ambiguous.

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 specific verbs and resources: 'Search the web for pages mentioning a brand name' and explicitly scopes to 'not on your own domain' while adding the link-checking purpose. It clearly distinguishes from siblings like keyword_suggest or ai_citation_check by focusing on unlinked mentions and outreach targets.

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 a use case ('outreach targets for links') and states a prerequisite (BRAVE_API_KEY), but it does not explicitly mention when to prefer this tool over alternatives or provide exclusions. The context is clear but not directive, so agents must infer applicability from the surrounding toolset.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by enumerating exactly what data is extracted (word count, heading counts, content terms, etc.) and the content-gap hint, giving the agent a clear picture of the operation's scope without contradicting annotations.

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

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

The description is compact, two sentences, with the core purpose front-loaded and details listed in a structured manner. No redundant filler, though the list of metrics is extensive, it is still 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?

For a tool with no output schema, the description lists the data points it returns but does not explain the output format or structure. It also omits clarification of the gapTerms parameter and does not mention that pages are fetched live, though openWorldHint implies external access. Given the complexity, 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?

Schema description coverage is 0%, so the description must compensate. It implicitly maps 'yourUrl' and 'competitorUrls' via the text, but the 'gapTerms' parameter is entirely undocumented in both the schema and the description. The agent cannot infer its purpose or constraints from the description alone.

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: auditing multiple URLs side by side, listing specific metrics (word count, headings, links, schema types, etc.) and explicitly mentions comparing 'yours plus pages ranking above you'. This differentiates it from single-page audit tools like page_audit and structured_data_audit.

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 competitive analysis but does not explicitly state when to use this over alternatives, nor does it mention any exclusions or conditions. It provides context (comparing with competitor pages) but lacks explicit routing guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds behavioral details: it compares two periods, uses sitemap lastmod for staleness, and returns top losing queries. It does not describe output format or pagination, but these are minor given the read-only nature.

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

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

Two tightly written sentences with zero filler. The primary purpose is front-loaded, and the actionable context follows naturally. Every word earns its place.

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

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

For an analysis tool with 9 parameters and no output schema, the description covers the selection logic well but omits details about the return format (e.g., whether it returns a list with metrics, sorting, or pagination). Still, given the read-only nature and clear purpose, an agent can reasonably infer expected output. The description is sufficient for most use cases.

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 only 33%, so the description should compensate for the undocumented parameters. It references 'two periods' and 'sitemap lastmod', which loosely maps to the date-range and sitemap parameters, but it does not explain top, minPreviousClicks, or the default periods. The description adds some meaning but not enough for a tool with 9 parameters.

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

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

The description uses a specific verb ('Find') and clearly specifies the resource ('pages') with precise criteria (clicks/impressions dropped, not updated recently). It distinguishes itself from sibling GSC analysis tools by focusing on content refresh candidates rather than generic opportunities or CTR reports.

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 ('best candidates for a content refresh') and even suggests follow-up actions, providing clear context. However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds behavioral context beyond these: it explains that the tool identifies overlapping queries, suggests links, and optionally fetches top candidate pages to check for existing cross-domain links. This clarifies the tool's analysis and network behavior, which is not covered by annotations.

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. The main purpose is front-loaded in the first sentence, and the optional behavior is added in the second. No filler or repetition, making it efficient and easy to parse.

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

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

Given the tool has 7 parameters, low schema coverage, and no output schema, the description provides the core purpose and an optional behavior, which is adequate for a high-level understanding. However, it does not explain how optional parameters like top, minImpressions, or date ranges affect results, nor what the output format is. The annotations cover safety, but the description leaves gaps for an agent to correctly configure the call.

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

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

Schema description coverage is only 29% (only siteA and checkExistingLinks have descriptions). The tool description does not elaborate on any parameters, such as top, startDate, endDate, minImpressions, or the semantics of siteB. With low schema coverage, the description should compensate but does not, leaving agents without guidance on how to set these parameters or their impact.

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 and specific purpose: for two owned Search Console properties on the same topic, it finds pages ranking for overlapping queries and suggests cross-links. The verb 'find' and 'suggest' with a concrete resource (two properties) makes the tool's function unambiguous, and it is distinct from any sibling tool like gsc_opportunities or content_refresh_candidates.

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

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

The description gives a clear usage context: 'for two Search Console properties you own on the same topic.' This tells the agent when the tool is applicable. It does not explicitly name alternatives or exclusions, but the condition 'you own' and 'same topic' is a sufficient usage guideline, especially given no sibling tool overlaps directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds behavioral detail: it returns a pass/fail checklist with recommendations, and it checks a sample of articles for bylines and dates. This goes beyond the annotations and gives the agent a concrete sense of what will happen.

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 a list of checks, which is efficient and front-loads the core purpose ('Site-level trust signals'). The list is dense but every item is relevant to E-E-A-T. No redundant 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 description explains the tool's scope, the checks performed, and the output (pass/fail checklist with what to add). It does not explicitly define the sampleArticles parameter's role, but given the simple schema and read-only nature, it is reasonably complete 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?

The description mentions 'a sample of articles' which implicitly relates to the sampleArticles parameter, but it does not explicitly state that sampleArticles controls the sample size or its constraints (default 5, max 20). Since schema coverage is 0%, the description could compensate more, but the intent is partially conveyed. siteUrl is self-evident.

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 audits site-level trust signals for search and AI engines, listing specific elements checked (About/Contact pages, schema, social profiles, etc.) and the return format (pass/fail checklist). This is a specific verb+resource with a distinct scope, easily differentiated from siblings like structured_data_audit which focus narrowly on schema validation.

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 scopes to 'site-level' trust signals, which implies it is for whole-site audits rather than page-level analysis. It does not name alternatives or provide when-not-to-use guidance, but the context is clear enough to infer appropriate 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect semantics. The description adds behavioral context beyond this: it states the output structure ('per-row current/previous/delta/percent change plus period totals') and the default breakdown by dimensions. This is valuable, though it does not mention edge cases like missing data or handling of zero denominators. Given the annotation coverage, this is a solid 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 two sentences, front-loaded with the core purpose and output characteristics, followed by a concrete usage example. There is no fluff, and every sentence contributes to the agent's understanding. It is efficiently structured and easy to parse.

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

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

With 9 parameters, low schema coverage (22%), and no output schema, the description is incomplete. It does not explain how the four date parameters (currentStart, currentEnd, previousStart, previousEnd) define the two periods, nor does it describe the dimensionFilters object structure or allowed match types. The description leaves significant gaps that an agent must infer or discover by trial, which is risky 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 only 22% (only propertyId and limit have descriptions). The description does not compensate for the other 7 parameters. It mentions the default dimensions but does not explain metrics, currentStart, previousStart, currentEnd, previousEnd, or dimensionFilters. Parameter names are somewhat self-explanatory (e.g., 'currentStart'), but the description adds minimal semantic value beyond the schema. For a low-coverage schema, the description should carry more explanatory weight; it does not.

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 purpose: 'Compare GA4 metrics between a current and a previous period, broken down by dimensions'. The verb 'compare' and resource 'GA4 metrics' are specific, and the default dimension (channel group) is mentioned. While it doesn't explicitly contrast with sibling tools like ga_run_report or gsc_compare_periods, the 'GA4' qualifier and comparison focus make its intent distinct 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?

The description provides a concrete use case: 'Use it for "how did organic traffic change vs last month"'. This gives the agent a clear scenario for invoking the tool. However, it does not mention when NOT to use it (e.g., for real-time data or complex custom reports), nor does it reference alternatives like ga_run_report for more flexible queries. It gives a useful but not exhaustive guideline.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side effects. The description adds the behavior that it includes custom dimensions/metrics and that the output can be large without a search filter, which are useful non-obvious details. No contradiction with annotations.

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

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

The description is two short sentences with no filler. It front-loads the core action and then provides a practical filtering tip. Every word earns its place.

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

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

For a metadata listing tool with a required propertyId and optional kind/search, the description covers the essential purpose and filtering behavior. It does not detail the return structure, but the absence of an output schema and the simplicity of the tool make that less critical. Annotations cover the safety profile, so nothing critical is missing.

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

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

Schema description coverage is 67% (propertyId and search have descriptions; kind does not). The description reinforces the search parameter's purpose and implies kind through 'dimensions and metrics', but it does not add substantial semantics beyond what the schema already provides. Baseline of 3 is appropriate given 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 the verb ('List') and the resource ('dimensions and metrics available for a GA4 property'), and adds specificity with 'including custom ones'. It is distinct from siblings like ga_list_properties (which lists properties) and ga_run_report (which runs reports), so an agent can immediately tell what this 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 gives clear context (listing available dimensions/metrics for a property) and even hints at usage by advising to filter with a search string to keep output small. However, it does not explicitly mention when to prefer this over alternatives, nor does it state exclusions. The context is sufficient for most agents to select it appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the requirement of both properties but does not disclose behavior for missing data, invalid dates, or how the merge handles pages present in only one source. Given strong annotations, the bar is lower, but the description adds only marginal 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, well-structured sentence that front-loads the core purpose and then lists the metrics and requirement. It has no redundancy or filler, making it efficient and easy to parse.

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

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

The tool merges two data sources and has 6 parameters, yet no output schema is provided. The description does not specify the output structure (beyond 'one table per landing page'), error handling, or parameter behaviors. Given the complexity and absence of an output schema, the description leaves critical details for correct invocation unexplained.

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 only 33% (siteUrl and propertyId have descriptions), so the description should compensate for the other four parameters (limit, sortBy, startDate, endDate). It does not explain their semantics or how they interact with the merged metrics. It only indirectly covers the two required parameters, leaving a significant gap for the rest.

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 purpose: to merge GA4 organic-search behavior with Search Console performance into one table per landing page. The verb 'combining' and specific resource ('landing page') make it distinct from sibling tools like gsc_search_analytics (Search Console only) and ga_run_report (GA4 only), which is a clear differentiation.

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 mentions a prerequisite ('Requires both the GA4 property and the Search Console property of the same site') but does not explicitly state when to use this tool versus alternatives (e.g., running separate queries). It implies usage but lacks explicit contrast with siblings, so the guidance is only partially provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat those. It adds valuable context by noting the prerequisite that the Analytics Admin API must be enabled and that the listing is scoped to the authorized account, which goes beyond the annotations.

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 concise sentences: the first states the core action and resource, the second adds a necessary prerequisite. No filler or redundancy; every word earns its place.

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

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

For a simple list tool with no parameters and safety annotations, the description is sufficiently complete. It specifies what is listed and the API requirement. It doesn't mention output format or pagination, but these are minor for a tool of this simplicity.

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

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

There are zero parameters, so the schema has full coverage and no parameter documentation is needed. The baseline for 0 params is 4, and the description doesn't need to add anything about parameters 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?

The description states a specific verb ('List'), a precise resource ('Google Analytics accounts and GA4 properties'), and the scope ('the authorized account can access'). It is unambiguous and clearly differentiates from sibling tools like ga_run_report, which run reports rather than list resources.

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 use for discovery of accessible accounts/properties, but it does not explicitly contrast it with alternatives or state when not to use it. The context is clear enough for an agent to infer the purpose, but no explicit routing guidance is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the time window (last 30 minutes) and lists available dimensions/metrics, which is useful behavioral context beyond annotations. It does not disclose potential limitations like data availability or latency, but given the annotation coverage, this is sufficient.

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

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

The description is a single, dense sentence that front-loads the core purpose (real-time GA4 data) and then lists supported dimensions and metrics. Every word adds value, with no fluff or repetition. It is optimally concise.

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 read-only tool, the description covers the essential aspects: data freshness (last 30 minutes) and valid dimensions/metrics. It does not mention pagination or limit behavior, but the schema provides defaults and bounds. There is no output schema, but the description implies the nature of the returned data. Overall, it is complete enough for an agent to call 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?

Schema description coverage is only 25% (propertyId has a description). The description compensates by listing valid dimension and metric names, which directly informs the 'dimensions' and 'metrics' array parameters. This adds meaning beyond the schema, though it does not explain the format of arrays or default behaviors (covered by defaults in schema). The propertyId hint in the schema is also helpful.

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 provides real-time GA4 data for the last 30 minutes, listing specific dimensions and metrics. This distinguishes it from sibling tools like ga_run_report (which likely handles historical data) and ga_compare_periods. The verb 'Real-time' and resource 'GA4 data' are explicit 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 implies usage for real-time data by stating 'last 30 minutes', but does not explicitly say when to use this tool versus alternatives such as ga_run_report. There is no direct statement of 'use this for immediate data' or 'use ga_run_report for historical data'. The real-time scope is a clear hint, but explicit guidance is missing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description need not repeat these. It adds context that a comparison date range introduces a 'dateRange' dimension and lists common dimensions/metrics, but it does not disclose return format, pagination behavior, or rate limits. This is acceptable given the annotations.

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

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

The description is concise, front-loaded with the core purpose, and uses a few sentences to convey key information. The list of common dimensions/metrics is useful but slightly lengthy; it earns its place by guiding parameter selection. No unnecessary 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?

For a report tool with no output schema, the description provides enough to call it correctly: property ID, dimensions, metrics, date range, and optional comparison. It points to ga_get_metadata for extended metadata. Missing details like return format are minor given the tool's nature and the provided 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 53%, and the description compensates by listing common dimensions and metrics, which helps agents populate the arrays. It also explains that compareStartDate adds a 'dateRange' dimension, adding meaning beyond the schema. The pointer to ga_get_metadata further supports parameter discovery.

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 runs a Google Analytics 4 Data API report, lists common dimensions and metrics, and points to ga_get_metadata for discovery. It implies a distinction from real-time and comparison tools but does not explicitly contrast with siblings like ga_run_realtime_report or ga_compare_periods.

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 only usage guidance is 'Use ga_get_metadata to discover more.' It does not state when to use this tool versus alternatives like ga_run_realtime_report or ga_compare_periods, nor does it mention prerequisites or exclusions. The optional comparison date range hints at overlap with ga_compare_periods but is not clarified.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, and the description reinforces this by mentioning 'adds/updates/deletes' and 'atomically'. It adds useful context about the branch update triggering CI/CD and the requirement to provide full file content. No contradiction with annotations.

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

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

The description is concise, front-loaded with the core action and purpose, then provides practical usage instructions in a few sentences. Every sentence adds value without redundancy.

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

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

The description is complete for a mutation tool: it covers the workflow (read, modify, commit), mentions atomicity, CI/CD implications, and branching options. It lacks explicit error handling or return format details, but since there is no output schema and annotations provide safety hints, this is 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 coverage is 80%, so most parameters are described in the schema. The description adds extra meaning by explaining the content parameter should hold full new file content and that createBranch creates from the default branch. However, it doesn't add much beyond what the schema already covers, 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 a specific action: creating one commit that adds/updates/deletes files atomically via the Git Data API, with the downstream effect on CI/CD deployment. It distinguishes itself from sibling tools like github_get_file (read) and github_list_commits (list) by naming the commit creation and file changes.

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 explicit workflow guidance: read files first with github_get_file, send full new content, and use createBranch for new branches. It implies when to use this tool (for commit changes) versus when to use the read tool, though it doesn't explicitly state 'do not use this for reading' – but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return field set (name, type, size, sha) and implies a non-recursive listing, but does not disclose potential edge cases (e.g., missing path, pagination, or whether subdirectories are included). Given the annotation coverage, this is adequate but not rich.

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

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

The description is a single, focused sentence that immediately states the core purpose and the returned information. It is concise, front-loaded, and contains no filler. Every word 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?

For a simple listing tool with three parameters and no output schema, the description covers the basic return fields and purpose. However, it omits clarification on the 'ref' parameter, recursion behavior, and error conditions. It also does not reference any sibling tools to guide selection, which is a gap given the large sibling set. The description is functional but not fully complete for an agent operating autonomously.

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 only 33% (only 'repo' has a description). The tool description mentions 'path' implicitly but does not explain the 'ref' parameter at all. It also does not clarify default behavior for 'path' (default is '') or the meaning of 'ref'. With low schema coverage, the description should compensate but does not add meaningful parameter semantics beyond what is already in 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 ('List files and folders') and the resource ('at a path in a repository'), and it enumerates the returned fields (name, type, size, sha). This distinguishes it from sibling tools like github_get_file (which retrieves file content) and github_list_commits (which lists commits). The purpose is unambiguous and specific.

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 conditions for selection, exclusions, or prerequisites. The intended usage must be inferred from the tool's name and context, which is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds that it checks token obtainability, which is a behavioral trait, but it doesn't disclose response format or error behavior. With annotations covering the safety profile, the description adds modest value.

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

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

Two sentences with no wasted words. The first sentence states the primary function, and the second gives usage guidance. Information is front-loaded and easy to scan.

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

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

For a simple tool with one optional parameter and annotations covering safety, the description is mostly adequate: it explains purpose and when to use. However, the lack of any explanation for the 'verbose' parameter leaves a gap, and the return value is not described. It's a minimum viable description 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 has a single optional boolean parameter 'verbose' with 0% description coverage. The description does not mention this parameter at all, so it fails to compensate for the schema gap. An agent has no guidance on what 'verbose' does or how to use it.

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: verifying which Google credentials are in use and whether an access token can be obtained. It uses a specific verb (verify) and resource (Google credentials) and distinguishes it from the many sibling audit and data tools by focusing on authentication status.

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

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

It provides explicit guidance on when to use this tool: 'Run this first if other tools fail.' This establishes a clear condition for invocation and implies it serves as a diagnostic prerequisite, which is sufficient to differentiate it from alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by explaining that results list competing pages with clicks, impressions, and position. It does not mention data lag or limits like top/minImpressionsPerPage, but it does not contradict the annotations and provides meaningful return-behavior 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 one well-structured sentence that front-loads the core behavior and then expands on result contents and intended use. Every clause contributes meaning, with no filler, repetition, or unnecessary detail. It is compact and easy to parse.

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

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

The description explains the core concept and result structure, but without an output schema it should provide more guidance on limits, default thresholds, and parameter behavior—especially since several parameters lack schema descriptions. The tool is relatively specialized, so basic usage is clear, but an agent would still need to infer details about minImpressionsPerPage and top. This is adequate but not 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 only 50%, and the description does not compensate by explaining key parameters such as top, minImpressionsPerPage, or searchType. It mentions queries, impressions, clicks, and position, but these are output concepts rather than parameter semantics. The description adds little beyond what the schema already provides for startDate, endDate, and siteUrl, leaving several parameters ambiguous.

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

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

The description opens with a specific verb and resource: 'Find queries for which two or more pages of the site receive impressions'. This clearly defines the tool's purpose and differentiates it from sibling tools like gsc_search_analytics or gsc_opportunities, which address different GSC reporting needs. It also explains the downstream action ('consolidate or differentiate'), giving the agent an unambiguous sense of what this tool is for.

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 a clear context for when to use this tool: when pages are competing for the same keyword and you want to consolidate or differentiate them. It does not explicitly name alternatives or exclusion conditions, but the use case is stated well enough that an agent can match it to the user's intent. A fully explicit when-to-use versus alternatives statement would push this to 5.

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

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

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds value by explaining the underlying logic (weighted by impressions) and providing concrete CTR benchmarks by position, which goes beyond the annotations and helps interpret results.

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

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

The description is two sentences with no filler. It leads with the core function and immediately provides actionable benchmarks, making it efficient and 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?

With 8 parameters and no output schema, the description should explain what the tool returns. It implies a list of queries/pages but does not detail output fields, sorting, or caveats like data lag (though the schema mentions lag). It is adequate for understanding the concept but incomplete for a fully self-sufficient call.

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

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

Schema coverage is only 38%, so the description should compensate. It references 'top positions' (relating to maxPosition) and 'impressions' (relating to minImpressions) but does not explicitly define top, dimension, searchType, or other parameters. It adds some context but not enough to fully bridge the schema gap.

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

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

The description clearly states the tool finds queries ranking in top positions with CTR far below the position benchmark, weighted by impressions, and explicitly names the use case (fastest wins from rewriting titles/meta descriptions). This distinguishes it from siblings like gsc_search_analytics or gsc_opportunities, which are broader.

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 (when seeking CTR improvements from titles/meta) but does not explicitly mention alternatives or conditions for choosing this over gsc_opportunities or gsc_search_analytics. The guidance is implicit 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable operational context beyond annotations: it notes the cost of one inspection call per URL against the ~2000/day quota and advises keeping batches small. No contradictions with annotations.

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: the first front-loads the purpose and output fields, the second adds a crucial cost warning. No redundant words or padding.

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 complexity (6 parameters, no output schema), the description covers purpose, input modes (list or sitemap), output fields summarized, and cost. It sufficiently prepares an agent to decide when to use it and what to expect, though it could elaborate on exact response formatting.

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 83% (5 of 6 parameters have descriptions). The description mentions the urls/sitemap usage patterns and the limit concept, but does not add new semantics beyond the schema. Since schema coverage is high, 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 runs the URL Inspection API over a batch of URLs or a sitemap and summarizes index status with specific fields (indexed, coverage state, robots state, last crawl, canonical mismatch). This is a specific verb+resource and distinguishes it from single-URL inspection tools like gsc_inspect_url.

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 batch usage (list of URLs or sitemap) and includes a cost warning to keep batches small. It does not explicitly name alternative tools or state when not to use it, but the batch nature and cost guidance make usage conditions clear.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral details: it groups results by page and optionally maps to WordPress post IDs when a WordPress site is configured. This goes beyond the annotations and clarifies the output organization without contradicting them.

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 redundancy. It front-loads the core purpose and adds the WordPress mapping detail efficiently. Every phrase earns its place.

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

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

For a tool with 9 parameters and no output schema, the description provides the essential context: the target range, the quick-win concept, and the WordPress integration. Parameters like siteUrl and date formats are covered in the schema, and the tool's read-only nature is handled by annotations. The only minor gap is the lack of explanation about the output structure, but since there is no output schema and the use case is clear, it is sufficient.

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 only 44%, so the description should compensate. It does explain the default position range (8-20) and the overall intent, but it does not elaborate on parameters like top, minImpressions, or minPosition/maxPosition beyond their names. The names are self-explanatory, but the description could have clarified relationships (e.g., how minImpressions affects results). It adds some value but does not fully compensate for the coverage gap.

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

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

The description states a specific verb ('Find'), resource ('queries with high impressions but average position in a range'), and the qualifying condition ('pages already ranking on page 1-2 that can be pushed into the top results'). This clearly distinguishes it from siblings like gsc_ctr_opportunities (focused on CTR) and keyword_suggest (keyword generation). The purpose is 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 clearly conveys when to use this tool: when seeking quick wins by improving pages in positions 8-20. It gives concrete context (title/content/internal-link work) but does not explicitly name alternative tools or exclusion criteria. Still, the usage scenario is obvious and distinct enough from the listed siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by explaining that it supports grouping, filtering (with an example), and pagination, which goes beyond the annotations. It does not cover rate limits or auth, but the annotations suffice for safety, and the description adds operational details.

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 action and metrics. It includes an example for filtering and mentions pagination, all in a compact format. Every sentence contributes useful information without redundancy.

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

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

Given the complexity (10 parameters, no output schema), the description covers the core use case well: it states the metrics returned, the grouping options, filtering, and pagination. It does not explicitly mention data lag (though that is in the parameter descriptions) or the need to use gsc_list_sites for siteUrl, but these are covered by the schema. Overall, it is fairly complete for an agent to understand the tool's purpose and basic usage.

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 70%, so the schema already documents most parameters. The description adds value by summarizing the grouping dimensions and providing a filtering example (page contains '/blog/'), which helps agents understand how to use the dimensions and filters parameters. It does not repeat schema details but enriches the conceptual model.

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 Google Search performance data with specific metrics (clicks, impressions, CTR, average position) and lists the grouping dimensions (query, page, country, device, date, searchAppearance). It also mentions filtering and pagination, which distinguishes it from sibling tools like gsc_compare_periods or gsc_opportunities by focusing on raw data retrieval.

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

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

The description gives clear context on what the tool does (query performance data) and its capabilities (filtering, pagination), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives such as gsc_opportunities or gsc_ctr_opportunities, so there is no explicit exclusion 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?

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavioral context beyond that by specifying the response contains period-over-period comparisons and multiple breakdowns. It doesn't discuss pagination or rate limits, but these are not critical for a snapshot tool with read-only annotations.

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, information-dense sentence that front-loads the core purpose and lists all major output categories. It then adds a concise usage directive. No filler or redundancy—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?

With no output schema, the description does a good job enumerating the returned data types (totals, deltas, top queries, etc.). However, it omits parameter explanations for non-required fields, which are part of a complete contextual picture for a complex tool. Still, the output description is thorough for a snapshot tool.

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

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

Schema description coverage is only 25% (only siteUrl is described). The description does not explain `top`, `days`, or `searchType`. While these are somewhat inferable from their names, the low coverage means the description should have compensated. It doesn't, leaving agents to guess at valid ranges or semantics for non-required parameters.

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

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

The description states a clear, specific verb (answers 'how is the site doing') and lists the exact data included: totals with deltas, top queries/pages, device/country splits, winners/losers. It also explicitly positions itself as the first tool for overviews/reports, distinguishing it from the many specialized GSC siblings.

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

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

It gives an explicit directive: 'Use this first when asked for an overview or a report.' This provides strong context for when to choose it over more granular tools like gsc_search_analytics or gsc_compare_periods. It doesn't name alternatives explicitly, but the phrase 'use this first' implies a starting point, which is sufficient.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the key behavioral profile. The description adds the 'or resubmit' nuance, which aligns with idempotence, but it does not go further into side effects, permission requirements, or confirmation behavior. No contradiction with annotations.

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?

Description is a single, front-loaded sentence with no filler: it names the action immediately and the scope. Every word earns its place, and the optional '(or resubmit)' adds meaningful nuance without bloat.

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

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

For a two-parameter tool with complete schema coverage, helpful annotations, and no output schema, the description is almost sufficient. The only notable omission is a hint about what happens when the sitemap already exists or how to interpret a result, but '(or resubmit)' and idempotentHint already cover repetition safety. Overall adequate for correct invocation.

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

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

Schema coverage is 100% and both parameters already carry full descriptions with examples and hints (e.g., 'Use gsc_list_sites to discover it'). The description adds essentially no parameter-level meaning beyond what the schema already provides, so it meets the baseline for high-coverage schemas.

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 states 'Submit (or resubmit) a sitemap URL for a property' — a specific action (submit/resubmit) on a clear resource (sitemap URL) with explicit scope (for a property). This differentiates it naturally from sibling tools like gsc_list_sitemaps (list) and sitemap_check (check), so an agent can choose it without opening schemas.

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

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

The description implies when to use it (to submit or resubmit a sitemap), which is useful context. However, it provides no explicit alternatives or exclusion guidance, such as 'use gsc_list_sitemaps to see existing sitemaps first' or 'don't use if you only need to verify a sitemap'. This is a gap but not confusing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds genuine value beyond annotations by disclosing that 'The tool verifies the key file before submitting', which is an important pre-condition behavior an agent needs to know. No contradiction with annotations; the description's write-implying language matches readOnlyHint=false.

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

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

Three dense sentences, each earning its place: core action with limit, prerequisite with location detail, and the Google exclusion. The main action is front-loaded before prerequisites. Slightly packed but not verbose; appropriate length for the information conveyed.

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?

Covers the essentials for an open-world submission tool: what it does, the 1000-URL cap, supported engines, the key-file prerequisite, verification behavior, and the Google exclusion. Missing return-value/response details (no output schema exists), so an agent doesn't know what success or failure looks like. Given moderate complexity (3 params, no nested objects), this is a minor but real 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?

Schema coverage is 67%, so the schema already documents key ('Overrides INDEXNOW_KEY') and keyLocation ('Overrides INDEXNOW_KEY_LOCATION') with descriptions. The description adds context about what INDEXNOW_KEY is and how the key file must be published, which enriches the key/keyLocation semantics. However, the urls parameter gets no extra explanation beyond the schema's uri format, and the description doesn't fully compensate for the 33% coverage gap.

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

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

States a specific verb+resource ('Submit up to 1000 changed URLs to IndexNow') with clear scope, and names the target search engines explicitly (Bing, Yandex, Naver, Seznam). The title 'IndexNow: notify Bing/Yandex of changed URLs' aligns with the description, and no sibling tool performs this exact function (gsc_submit_sitemap is Google-specific), so differentiation is not needed.

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 states the prerequisite: 'Requires INDEXNOW_KEY and the key file published at https://<host>/<key>.txt (or set INDEXNOW_KEY_LOCATION)'. Gives a clear when-not signal: 'Google does not support IndexNow', implying the agent should use Google's own tooling for Google URLs. Does not name an explicit alternative sibling tool, but the exclusion is informative enough.

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?

The description adds behavioral context beyond the annotations: it notes the tool is free and requires no key, deduplicates suggestions, and groups them by prefix. It also implies multiple requests via a-z expansion. Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. It could mention rate limits or external dependency, but the added value is solid.

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 core action and scope. It packs essential parameter guidance and output characteristics without fluff. Every clause earns its place, making it efficient for an agent to parse quickly.

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

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

For a 6-parameter tool with no output schema, the description covers the main purpose, key parameters, and high-level output format. It doesn't detail rate limits or the exact response structure, but the description's summary of deduplicated grouped suggestions is sufficient for an agent to understand expected results. The annotations cover safety and idempotency, so overall it is reasonably 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?

With schema coverage at 67%, the description compensates by explaining the seed expansion modes (question prefixes, a-z suffix) and providing concrete examples for hl and gl parameters. It does not elaborate on extraPrefixes, but the schema describes it. The description adds meaningful semantics beyond the schema's basic type descriptions.

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

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

The description clearly states the tool's function: expanding a seed keyword via Google Autocomplete, with specific modes (question prefixes, a-z suffix expansion) and output (deduplicated suggestions grouped by prefix). It is specific about the resource and action, and easily distinguished from sibling tools which are mostly audit, crawl, or analytics 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 provides clear context for using the tool, including language and country parameter guidance with examples, and mentions its utility for long-tail and FAQ ideas. However, it does not explicitly name alternatives or state when not to use this tool compared to other sibling tools, though its distinct purpose makes this less critical.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds that it crawls up to maxPages, reads titles and meta descriptions, and produces a draft in a specific format. It also notes the draft must be reviewed before publishing, indicating it does not write directly. This adds meaningful 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, well-structured sentence that front-loads the core action ('Crawl the sitemap') and efficiently packs in the output format and a safety instruction. No unnecessary words.

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

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

Given the complexity and lack of output schema, the description explains the process, output format, and that the result is a draft to be reviewed before publishing. It does not explicitly state the return type, but 'produce a draft' implies the tool returns the draft. Overall, it covers the essential information for an agent to use it correctly.

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

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

Schema descriptions cover 3 of 5 parameters (summary, siteName, excludePatterns). The description clarifies that maxPages limits the crawl ('up to maxPages') and implies siteUrl is the sitemap source, but it does not explicitly define siteUrl or maxPages beyond that. Since coverage is 60%, the description partially compensates but leaves siteUrl ambiguous.

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

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

The description states a clear verb (crawl, read, produce) and resource (draft llms.txt) with specific format details. It distinguishes itself from siblings like llms_txt_check (which likely checks existing files) by focusing on generation. The process is 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 the tool is for generating a draft from a sitemap but does not explicitly state when to use it versus alternatives like llms_txt_check or site_crawl. It provides context ('Crawl the sitemap') but lacks explicit exclusions or alternative routing.

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?

The annotations already signal read-only, non-destructive, and idempotent behavior. The description adds rich detail beyond that: it explains the source collection, URL rewriting, redirect following, and the exact classification categories (OK, REDIRECTED, REDIRECT_TO_HOME, CHAIN, NOT_FOUND, ERROR) plus sorting by old-site clicks. This substantially clarifies runtime behavior without contradicting the annotations.

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-organized paragraph that front-loads the purpose, then explains the process and classification in a logical order. Every sentence contributes to understanding, with no filler or redundancy.

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

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

Given there is no output schema, the description adequately explains the return format by enumerating the classification values and the sorting logic. It covers input sources, process, and output expectations. For a read-only, non-destructive tool with these annotations, nothing critical is missing.

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

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

Schema coverage is 50% (4 of 8 parameters have descriptions). The tool description indirectly references several parameters (period via 'pages with impressions in the period', old sitemap, new host) but does not explicitly explain the undocumented ones like concurrency or maxUrls. It adds some context beyond the schema but does not fully compensate for the missing parameter descriptions, warranting a middle score.

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 precise statement of what the tool does: verify that every URL on the old site still works on the new one before migration. It names the specific resources (Search Console, sitemap) and the classification outcomes, making its purpose unambiguous and clearly distinct from siblings like sitemap_check or robots_check.

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

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

It provides a clear usage context: 'Before pointing a domain at a new (static) site.' This tells an agent exactly when to invoke it. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable operational context: it requires GOOGLE_PLACES_API_KEY with 'Places API (New)' enabled, billing must be enabled, and mentions the free monthly allowance. This goes beyond the annotations and helps the agent understand prerequisites.

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

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

Three concise sentences with no wasted words. The action verb is front-loaded, and the operational requirements are stated clearly. Every sentence 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?

For a simple read-only tool with 3 parameters and no output schema, the description covers purpose, usage, prerequisites, and the data returned. It does not describe the exact response format, but given the annotations and the nature of the tool, this is 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 67% (query and placeId have descriptions; language does not). The description adds no parameter-specific meaning, leaving the language parameter undocumented. With moderate coverage and no compensation in the description, it falls short of the baseline 3.

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 verb ('Fetch') and resource ('Google Business Profile') with concrete data types (rating, review count, latest reviews). It does not explicitly distinguish from sibling tools, but the purpose is unique enough among the listed siblings (no other tool targets reviews).

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 use cases: 'source for AggregateRating schema and to monitor reputation.' It does not mention alternatives or when not to use it, but the stated uses give clear context for an agent deciding 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds valuable behavioral detail: the tool fetches robots.txt, shows groups and sitemap lines, and applies Google's longest-match rules for crawlability testing. This goes beyond the annotations and clarifies the operation's logic.

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 front-loads the primary action and includes all essential elements without fluff. Every phrase adds value: fetching, showing groups/sitemaps, testing with a user agent, and the rule engine. It is concise and informative.

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

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

For a read-only tool with two simple parameters and no output schema, the description is sufficiently complete. It explains the tool's core outputs (groups, sitemap lines, crawlability results) and the key behavioral rule. It does not detail edge cases or error handling, but those are not critical for a tool of this complexity given the 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 description coverage is 50%; the schema already explains that robots.txt is fetched from the first URL's origin and that userAgent has a default. The description reinforces the purpose of URLs (test crawlability) and mentions the default Googlebot, but adds little beyond what the schema states. The mention of 'Google's longest-match rules' adds context for the userAgent, but it is not directly tied to a specific parameter's semantics.

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

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

The description states a specific verb (fetch, show, test) and a clear resource (robots.txt) with a well-defined scope: fetching, displaying groups/sitemap lines, and testing crawlability. It clearly distinguishes from siblings like sitemap_check and ai_crawler_access by focusing on robots.txt rules and Googlebot behavior.

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: to inspect robots.txt and test URL crawlability for a specific user agent. It mentions the default Googlebot and Google's longest-match rules, which implies typical usage. However, it does not explicitly state when not to use it or mention alternatives, so it stops short of an explicit when/when-not.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it produces a draft (not a final publication), trims answers to ~600 characters, and suggests a follow-up publishing step. It does not contradict any annotation and enriches the behavioral picture with concrete constraints.

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

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

The description is three sentences with zero fluff. It front-loads the primary action, then breaks down each mode with a semicolon-separated list, and ends with the practical workflow note. Every sentence earns its place; the structure is scannable 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?

Given the tool has 4 parameters, one enum, and no output schema, the description covers the essential behaviors: the output kinds, the trimming behavior, and the follow-up publishing step. It does not explicitly describe the exact JSON-LD structure returned, but that is implied by the purpose and the annotations cover read-only/idempotent behavior. The only minor gap is the lack of explicit mention of 'maxQuestions' behavior, but that is a schema-level detail. Overall it is complete enough for an agent to call 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 only 25% (only organizationName has a schema description). The description compensates by explaining the 'kind' enum values in detail (faq, article, breadcrumb, all), but it does not clarify 'maxQuestions' beyond its schema metadata (default 10, max 30) nor the 'url' parameter, which is self-explanatory. It adds partial meaning for one parameter but leaves 'maxQuestions' under-documented, so it only partially compensates for the low 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 states a specific verb (generate), a specific resource (draft JSON-LD from an existing page), and enumerates the four output kinds (faq, article, breadcrumb, all). It clearly distinguishes itself from sibling tools like schema_validate (which validates) and structured_data_audit (which audits) by framing itself as a generation tool. No ambiguity remains about what the tool produces.

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 to use it: to produce draft structured data before publishing, and it names the follow-up action (publish with wp_set_schema). However, it does not explicitly state when not to use it or compare itself to alternatives like schema_validate, leaving some inference required. It implies usage through workflow rather than explicit exclusions.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds operational details beyond annotations: respects robots.txt for Googlebot, same-host constraint, breadth-first strategy, and a time estimate. It does not contradict annotations and provides useful context on how the crawl behaves.

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 moderately long but each sentence adds value. It front-loads the core purpose, then lists the detailed outputs and ends with a practical usage hint. It avoids fluff and is well-structured, though slightly verbose in the output enumeration.

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 crawl tool with no output schema, the description covers the key aspects: what it returns (list of metrics), how to bound it, performance expectations, and constraints (same host, robots.txt). It does not mention authentication requirements or exact response format, but these are minor given the comprehensive summary provided.

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 50%, so the description should compensate. It does explain maxPages (bounding) and startUrl (implicitly), but concurrency is left unexplained. The description adds a performance note tied to maxPages but does not fully elaborate on all parameters. This is adequate but not exhaustive.

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 verb ('crawl') and resource ('from a start URL'), and clarifies it audits each HTML page like page_audit. It lists the detailed site-level summary outputs, making its purpose unambiguous and distinguishing it from single-page tools like page_audit or specific checks like robots_check.

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 (site-wide audit vs. single page via 'like page_audit') and gives practical guidance on bounding with maxPages and performance expectations. However, it does not explicitly mention alternatives or when not to use it, such as when a sitemap check or robots check would be more appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavioral details such as sitemap index support, .gz handling, sampling vs. all URLs, a 500 cap for checkAll, and even sampling logic, which go beyond the annotations.

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

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

The description is three concise sentences with the primary action front-loaded. It covers the core functionality, format support, and auto-discovery without any redundant or vague phrasing.

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

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

Given the tool's moderate complexity and the lack of an output schema, the description explains the main actions and expected results (identifying 404s, redirects, errors) but does not detail the response structure or error handling. While sufficient for an agent to call correctly, a bit more detail on output would make it fully complete.

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

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

Schema description coverage is 80%, so the schema already documents most parameters (url, checkAll, listUrls, sampleSize). The description adds minimal parameter-specific meaning—it mentions auto-discovery for url and sampling for sampleSize, but these are already in the schema. Concurrency lacks a description in the schema and the description does not compensate for that gap.

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

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

The description explicitly states the tool fetches a sitemap, lists URLs, and checks HTTP status to identify 404s, redirects, and server errors. It also mentions auto-discovery from robots.txt or /sitemap.xml, making the purpose specific and distinct from sibling tools like site_crawl or robots_check.

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 on what the tool does and how to use it, including the option to pass a site root for auto-discovery. It does not explicitly name alternative tools or exclusion conditions, but the usage is straightforward and unlikely to be confused with siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explicitly checks remote image reachability, file size, content type, and fallback behavior, indicating the tool performs network fetches and assesses resource metadata. This goes beyond the bare annotation data without contradicting it.

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

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

The description is a single sentence that front-loads the core action ('Validate how a page previews when shared') and then efficiently lists the specific checks. It is dense but not bloated; every listed item adds concrete information. It could be broken into two sentences for readability, but it earns a high score for 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 the tool's moderate complexity and lack of an output schema, the description is almost complete: it covers what is validated and the main checks. However, it does not describe the result format (e.g., pass/fail, list of issues, or a structured report), which an agent would need to know for downstream handling. With no output schema to fill this gap, the description leaves a meaningful ambiguity.

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

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

The schema has a single 'url' parameter with no description (0% coverage), so the description must compensate. It effectively encodes the meaning of the parameter by stating the tool validates 'a page' that is to be shared, clearly implying the URL parameter is the target page. For a one-parameter tool, this is sufficient to make the parameter's role unambiguous.

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

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

The description states a specific verb ('Validate') and resource ('how a page previews when shared') and enumerates concrete checks (OG tags, Twitter card, image reachability, dimensions, etc.). It is clearly distinct from sibling tools like page_audit or structured_data_audit because it focuses exclusively on social/messaging/link-card preview behavior, so an agent can select it unambiguously.

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 makes the use case implicit: 'when shared' and the list of social contexts imply the tool is for preview validation. However, it does not explicitly state when to use this tool versus alternatives (e.g., page_audit, structured_data_audit), nor does it mention exclusions or prerequisites. The usage context is clear enough but not explicitly contrasted with 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavior beyond that: it validates required/recommended properties, flags invalid JSON and dates, and checks entity consistency across pages. It also clarifies the sampling approach. No contradictions found.

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 paragraph that front-loads the main action (extract JSON-LD and validate) and then details specific checks and input methods. It is information-dense without being redundant, though it lists many schema types which could be trimmed without losing core 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 description covers the main functionality, input methods, and validation scope. It does not describe the output format (no output schema exists) or mention limits like maxItems, but those are in the input schema. Given the tool's complexity and the annotations covering safety, the description is reasonably complete for an agent to understand what the tool does and how to call it.

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

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

Schema coverage is only 33% (only sitemapUrl has a description). The description explains that urls and sitemapUrl are alternative input methods ('Pass explicit urls or a sitemap'), which adds meaning to those parameters. However, sampleSize is not explicitly described, though 'sample' implies its purpose. The description partially compensates for the low coverage but could be more explicit about sampleSize and the relationship between urls and sitemapUrl.

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 extracts JSON-LD from pages, validates properties per schema type, flags invalid JSON/dates, and checks entity consistency. It lists specific schema types and mentions input methods. This distinguishes it from siblings like schema_validate (likely single-schema validation) and eeat_audit.

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 explains how to invoke the tool ('Pass explicit urls or a sitemap to sample') but does not explicitly state when to choose this over alternative tools like schema_validate or site_crawl. The intended context is implied by the description but not spelled out with exclusions or comparisons.

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