rankparse-mcp

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds the batch limit (50 domains) as a behavioral constraint but does not mention rate limits, pagination, or return details. It complements annotations 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 a single, front-loaded sentence with no redundant words. Perfectly concise and direct.

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 batch lookup tool with strong annotations and no output schema, the description provides the core purpose and batch limit. It does not explain return structure, but the simplicity and sibling context make it adequately complete for 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?

The schema only specifies 'domains' as an array of strings with 0% coverage. The description adds meaning by clarifying these are domains and limits the batch to 50. It does not detail format or validation rules, but for a single parameter this is reasonably compensative.

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 (get backlinks), the resource (domains), and the batch scope (up to 50 at once), distinguishing it from sibling get_backlinks. It is specific and immediately understandable.

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 batch usage through 'up to 50 domains at once' but does not explicitly compare to alternatives or state when not to use. It provides some usage context but lacks explicit when/when-not 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds minimal behavioral context beyond confirming it checks a balance, which is acceptable for such a simple read operation.

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

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

The description is a single, complete sentence with no wasted words. It is perfectly concise and front-loaded.

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

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

For a zero-parameter, read-only tool with strong annotations, the description 'Check remaining credit balance' is sufficient. It tells the agent exactly what resource is being queried and implies the return value (the balance). No output schema exists, but the description is clear enough for this trivial tool.

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

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

The tool has zero parameters, so the description need not explain parameter meaning. The baseline of 4 applies as there are no parameter semantics to clarify.

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 'Check remaining credit balance' uses a specific verb and resource, clearly distinguishing it from the sibling tools that focus on SEO data. It is immediately obvious 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 context is clear: this tool is for checking account credits, which is distinct from all sibling tools that retrieve SEO metrics. Though no explicit alternatives are named, the standalone nature of the tool makes its usage obvious.

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, covering safety and side-effect concerns. The description adds minimal behavioral context by saying 'distribution', implying aggregated counts, but does not disclose return format, pagination, or any nuance. Since annotations cover the safety profile, a 3 is appropriate.

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

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

A single sentence that is direct and free of filler. It efficiently states the tool's purpose without 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?

This is a simple read-only tool with only 2 parameters, and the description covers the core purpose. However, the lack of detail about the return format of the distribution and the 'limit' parameter means it does not fully equip an agent to understand what the output will look like. Given the tool's simplicity, this is a minimum viable description but with noticeable gaps.

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

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

Schema description coverage is 0%, so the description must explain both 'domain' and 'limit'. It only implies 'domain' ('for a domain') and gives no meaning to 'limit'. The parameter 'limit' is left completely unexplained, making the description insufficient to fully understand the 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 'get' and a resource 'anchor text distribution' for 'a domain', clearly distinguishing it from sibling tools like get_backlinks or get_referring_domains. No ambiguity about 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 provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or mention that other tools might be more suitable for related analyses. The only context is the name itself, which gives us no insight into specific use cases.

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 valuable behavioral detail about the default vs. recent sorting behavior and the optional filters, which goes beyond what annotations provide.

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 contains no superfluous information. Every clause 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 six-parameter tool with no output schema, the description covers the main functionality and sort modes, but it lacks details on the response structure, the limit parameter, and the exact format for filters like from_domain or link_type. This leaves gaps for an agent to correctly invoke the tool.

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

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

The schema provides no parameter descriptions (0% coverage). The description adds meaning for domain, sort, from_domain, link_type, and score, and explicitly explains the two sort enum values. However, it omits the limit parameter and does not explain the expected format/constraints for the filter parameters.

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

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

The description clearly states 'Get backlinks for a domain' with a specific verb and resource. It further distinguishes the tool by explaining the two sort modes and optional filters, setting it apart from sibling tools like get_referring_domains or get_link_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 contexts through the sort modes (importance for aggregated rows, recent for URL-level links), but it does not explicitly compare this tool to alternatives or state when to use it over other link analysis tools. There is no 'instead of' 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?

Even with annotations declaring readOnlyHint and idempotentHint, the description adds important context: under time budget the response may include partial=true and scored=false, yielding raw gap data without domain-authority ranking, and that retrying usually returns a fully scored result. This goes beyond the annotations and helps the agent manage expectations.

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: first states the purpose, second discloses the key behavioral caveat and retry guidance. Every word earns its place, and the most critical information is front-loaded.

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

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

For a simple 3-parameter read-only tool with no output schema, the description covers the main purpose, the competitive gap logic, and a critical partial-response edge case. It doesn't describe the return format or parameter syntax, but given the simplicity and strong annotations, this is a minor gap, not a major omission.

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

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

The input schema has no parameter descriptions (0% coverage), and the description does not explain domain, vs, or limit. While the names are intuitive, the description fails to explicitly map 'competitor' to vs or 'you' to domain, nor explain limit's meaning. The tool could compensate but 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 opens with a specific verb+resource: 'Find domains linking to a competitor but not to you', clearly identifying the tool's unique function. It further clarifies the output as 'ranked link-building prospects', distinguishing it from sibling tools like get_link_intersect or get_domain_overlap by focusing on the gap (competitor-only backlinks).

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 implies usage for link-building prospect discovery (competitive gap analysis). It doesn't explicitly name alternatives or exclusions, so it stops short of a 5, but the context is strong enough for an agent to select this tool for gap-based prospecting.

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 the Wayback Machine source and the specific data fields, but does not disclose potential behavioral nuances like rate limits, data availability caveats, or what happens when no crawl history exists. It provides some context beyond annotations but stops short of rich 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 a single, front-loaded sentence that immediately conveys the tool's purpose and key output fields. Every word is functional, with no redundancy or filler.

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

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

The description explains the return data (first/last seen dates, snapshot count) sufficiently, even without an output schema. Given the tool's low complexity (one parameter) and strong annotations, the description is nearly complete. It could be slightly more thorough by noting any response structure or edge-case behavior, but it's adequate for the intended use.

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 description coverage at 0%, the description compensates by explicitly using 'domain' in context, clarifying that the single parameter is the domain to query. However, it does not specify format requirements (e.g., bare domain vs. protocol, without www), which is a minor gap for a one-parameter tool.

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 retrieves first/last seen dates and total snapshot count for a domain, with the source explicitly identified as the Wayback Machine. This specific verb+resource combination distinguishes it from sibling tools like get_domain_authority or get_site_explorer.

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 use case (when crawl history is needed) but does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no direct comparison with related tools such as get_site_explorer or get_domain_rank, leaving usage context implicit.

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 no behavioral context beyond what the annotations already provide (readOnlyHint, idempotentHint, destructiveHint). It does not mention return format, potential errors, or any nuances like domain format expectations. While annotations cover safety, the description should still disclose behavioral traits such as whether the score is numeric or has a scale, which it does not.

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: 'Get authority score for a domain.' Every word contributes to the purpose, with no redundant or filler content. It is appropriately front-loaded 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?

For a simple read-only tool with one parameter and rich annotations, the description is minimally sufficient. However, it lacks any information about the output format or what the authority score represents. Given no output schema, the description could have provided basic context on the return value, making this less complete than ideal.

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 zero description coverage for the 'domain' parameter, and the description does not compensate by explaining the expected format (e.g., 'example.com' vs 'www.example.com'). The parameter name is self-explanatory as the domain, but no additional meaning is provided. Given the low schema coverage, the description should have elaborated on parameter usage.

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 ('Get') and resource ('authority score for a domain'), clearly indicating the tool's function. It distinguishes from siblings like get_domain_rank by focusing on 'authority score' rather than rank, though it does not explicitly mention alternatives. Overall, 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?

No guidance is given on when to use this tool versus alternatives. There are no context cues, prerequisites, or exclusions. The description simply states what it does, leaving the agent to infer usage scenarios from the tool name and 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 minimal behavioral context (the 'all' intersection semantics) but does not disclose output format, pagination, or other runtime behavior. This is acceptable given the strong annotations, but no extra depth is provided.

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

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

The description is a single, direct sentence with no filler or redundancy. It front-loads the action and clearly states the tool's purpose.

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

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

The tool is simple and the annotations are rich, but the lack of an output schema and minimal parameter explanation leave the agent guessing about return shape and limit semantics. The description covers the core function but is not fully complete given the 0% parameter coverage and no output schema.

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

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

Schema description coverage is 0%, so the description must explain parameter meanings. It does not; 'domains' and 'limit' are only named with type constraints. The required array constraints (minItems 2, maxItems 5) are in the schema, but the semantic of 'limit' (e.g., maximum number of results) is not explained anywhere. The description fails to compensate for the lack of schema 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 uses a specific verb ('find') and resource ('domains linking to all queried domains'), clearly distinguishing this as an intersection/link overlap tool. It conveys the exact function without ambiguity.

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 clear use case (finding domains that link to every queried domain) but does not mention when to use this tool versus alternatives like get_link_intersect or get_competitor_gap. No exclusions or alternative tools are referenced, so guidance is only implicit.

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 return-type context (inbound edge count and linking domain stats) but does not disclose other behavioral aspects such as rate limits, response size, or whether results are aggregated or raw. This is acceptable for a simple read-only tool.

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

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

The description is a single, front-loaded sentence with no fluff. It states the action and the output in a concise manner, earning every word.

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 one parameter and no output schema, the description is minimally viable: it conveys the core purpose and return subjects. However, it leaves undefined key terms like 'inbound edge count' and 'linking domain stats' — are they counts, lists, or aggregates? The lack of an output schema increases the burden on the description to clarify the response, which it does not fully do.

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 one parameter 'domain' with no description, and schema coverage is 0%. The description does not compensate by explaining the expected format of the domain (e.g., 'example.com' vs 'www.example.com'), any constraints, or what constitutes a valid input. Since the parameter is simple, the gap is small, but the description adds no semantic value.

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

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

The description uses the verb 'Get' and specifies the resource (domain) and the returned data (inbound edge count and linking domain stats). It clearly indicates the tool's function, though it could be more explicit about what 'domain rank' is. It is not a tautology and provides enough specificity to differentiate it from listing-oriented siblings like get_backlinks or get_referring_domains.

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 offers no guidance on when to use this tool versus alternatives like get_domain_authority or get_referring_domains. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and description.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the dependency on Google Search Console connection and directs users to an integration page, which is valuable behavioral context 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 sentences, each serving a specific purpose: stating the function, indicating use case, and providing an integration directive. It is concise and front-loaded with the primary action.

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 presence of comprehensive schema annotations and no output schema, the description adequately conveys the tool's purpose and prerequisite. It could specify return metrics, but the country-breakdown concept is clear from the name and description.

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

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

The input schema descriptions cover 100% of parameters (site, startDate, endDate, rowLimit), so the description does not need to add parameter-level details. The tool description does not provide additional semantics beyond what's 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 tool's function: 'Get search traffic broken down by country,' which specifies both the action and the resource. This distinguishes it from sibling tools like get_gsc_device_breakdown and get_gsc_date_trends by focusing on country segmentation.

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 use-case context ('useful for understanding geographic audience and international SEO performance') and identifies a prerequisite ('Requires Google Search Console to be connected') with a direct action for the user. It does not explicitly mention alternatives but the context is 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?

The annotations already establish this as a safe read-only, idempotent operation. The description adds the prerequisite that Google Search Console must be connected and provides actionable setup instructions, which is useful behavioral context. It does not detail response structure or rate limits, but that's not necessary 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 three sentences, each serving a distinct purpose: defining the data returned, suggesting use cases, and providing a setup prerequisite with an action. No wordiness or redundancy; front-loaded with the primary function.

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 straightforward 3-parameter read tool with strong annotations, the description is quite complete. It explains what data is returned, provides use cases, and addresses setup requirements. It doesn't describe the output format, but no output schema exists and the metric list already sets expectations.

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

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

The input schema already documents each parameter ('site', 'startDate', 'endDate') with clear descriptions, so the schema coverage is 100%. The description adds no additional parameter-level details beyond mentioning 'date range' and 'daily', which doesn't enhance schema semantics. Thus 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 retrieves daily search performance trends with specific metrics (clicks, impressions, CTR, position) over a date range. While it doesn't explicitly name sibling tools, the combination of metrics and daily granularity effectively distinguishes it from other GSC tools like country or device breakdowns.

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 ('spotting ranking changes, traffic drops, or algorithm update impact') and prerequisite guidance (GSC must be connected, with a link to the integration page). However, it does not explicitly state when not to use it or mention alternatives, such as using a query-specific trend tool for keyword-level analysis.

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. The description adds the crucial integration requirement (GSC must be connected) and user action, which is valuable auth/integration context beyond the structured data. 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?

Two concise sentences front-load the primary function and device types, followed by a necessary prerequisite and actionable instruction. Every sentence earns its place with zero 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?

For a simple read-only tool with 3 fully documented parameters and no output schema, the description is complete enough. It covers the essential purpose, device breakdown, and the connection prerequisite. Slight deduction for not explicitly describing the return format, but the name and description make it predictable.

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?

Input schema covers all three parameters with descriptions (site, startDate, endDate), so the baseline is 3. The tool description does not add any additional parameter-specific meaning 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 uses a specific verb ('Get') and resource ('search traffic broken down by device type'), clearly distinguishing it from sibling GSC breakdown tools like country breakdown or date trends. It names the exact dimensions (desktop, mobile, tablet), making the purpose unambiguous.

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

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

Provides clear context by stating the prerequisite that Google Search Console must be connected, and gives a specific action for the user to connect it. While it does not explicitly mention alternatives or exclusions, the prerequisite and directive serve as useful usage guidance, earning a 4 rather than a 3.

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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond this by noting the requirement that Google Search Console be connected and directing the user to the integration dashboard. This is valuable behavioral/dependency information.

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

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

Three sentences, each serving a distinct purpose: defining the tool, stating a use case, and noting a prerequisite with an action. No fluff or repetition. Information is front-loaded with the core functionality in the first sentence.

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

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

For a moderate-complexity tool with six parameters and no output schema, the description covers the what, why, and prerequisite clearly. It omits details about return format, but that is not critical for tool selection, and the parameters' defaults are already in the schema. The integration instruction adds practical completeness.

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

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

Schema coverage is 100%, with all six parameters described in the input schema. The description's 'high impressions but low CTR' aligns with the minImpressions and maxCtr parameters but doesn't add specific parameter-level details beyond what the schema already provides. 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 finds pages with high impressions but low CTR, using a specific verb ('Find') and resource ('pages'). It distinguishes itself from sibling tools like get_gsc_low_ctr_queries by focusing on pages rather than queries, and adds a concrete use case ('starting point for title/description rewrites').

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 ('Good starting point for title/description rewrites'), which helps an agent decide relevance. It doesn't explicitly name alternatives or exclusions, but the context is strong enough to guide selection among the many sibling GSC 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 and destructiveHint=false, so the read-only safety is covered. The description adds meaningful behavioral context: GSC must be connected, and it instructs the agent to direct the user to a specific URL for integration. This goes beyond the annotations by exposing a dependency and remediation step.

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 three sentences, front-loaded with the core purpose. The ROI rationale and connection instruction each serve a distinct purpose and are not redundant. Zero filler.

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

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

With no output schema, the description implicitly indicates the return is a list of queries. It covers purpose, prerequisite, and user guidance. However, it does not mention result limits or sorting, but those are defined in the schema parameters. Overall it's adequate for a read-only filtered list tool with good annotations.

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

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

Schema coverage is 100% with descriptions for all 6 parameters, so baseline is 3. The description adds conceptual context ('high impressions' and 'low CTR') but does not add syntax or format details beyond what schemas already provide. The default values and formats are already in 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?

Description opens with a specific verb+resource: 'Find search queries with high impressions but low CTR', clearly distinguishing from sibling get_gsc_low_ctr_pages (pages vs queries). The definition also explains the underlying issue ('ranking but not getting clicked') which adds purpose clarity.

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

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

Provides clear context for when it's valuable ('Fixing these is typically higher ROI than chasing new rankings') and a hard prerequisite ('Requires Google Search Console to be connected') with an action to connect. However, it does not explicitly name alternative tools or state when not to use, only implies via the ROI statement.

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 valuable behavioral details: results are sorted by clicks descending (GSC API default) and the tool requires GSC to be connected, with a direct integration link. This 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 sentences, front-loaded with the primary purpose, then sorting behavior, then a required prerequisite. Every sentence earns its place with no redundancy or filler.

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

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

The tool is a read-only query tool with solid annotations and full schema coverage. The description adds the strategic context (quick wins), sorting behavior, and integration prerequisite. For this complexity, it is fully complete and actionable.

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

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

Schema coverage is 100%, so every parameter already has a clear description. The description reinforces the meaning of minPosition/maxPosition by describing the 8–20 range, but it does not add substantial new semantic information beyond what the schema provides. 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 states a specific verb and resource: 'Find queries where the site ranks on positions 8–20'. It clearly distinguishes this tool from GSC siblings by focusing on the opportunity/quick-win position range, making the purpose unmistakable.

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

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

The description provides clear context for when to use the tool ('quick win zone where small improvements can meaningfully increase clicks') and a prerequisite (Google Search Console connected, with integration instructions). However, it does not explicitly name alternative tools or state 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 a behavioral prerequisite (GSC must be connected) and directs the user to an integration page, which is valuable context beyond annotations. No contradictions detected.

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 four short, purposeful sentences. It front-loads the core purpose, then adds a use-case clarification and a setup requirement. No fluff or redundancy; every sentence earns its place.

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

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

For a read-only tool with rich annotations and 100% schema coverage, the description covers purpose, use case, and a key prerequisite (GSC connection). It does not explain return format or pagination, but the schema and annotations provide enough context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema documents all 5 parameters fully. The description adds no additional parameter-level meaning beyond what is already in the schema, so baseline 3 is appropriate.

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

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

The description states a specific action and resource: 'Get search queries driving traffic to a specific page.' This clearly distinguishes it from sibling tools like get_gsc_top_queries (which returns top queries across a site) and get_gsc_query_pages (which returns pages for a query). The phrase 'what a page ranks for' adds clarity.

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: it is useful for understanding a page's ranking queries. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it lacks exclusion guidance. The prerequisite about requiring GSC connection is helpful for 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the output ('top pages within that segment by clicks') and the integration requirement ('Requires Google Search Console to be connected'), going beyond what annotations provide.

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

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

Three sentences, each earning its place: purpose with examples, return value, and integration prerequisite/directive. No fluff or redundancy; information is front-loaded in the first sentence.

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

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

Despite lacking an output schema, the description gives a clear summary of the return value ('top pages within that segment by clicks') and the required integration. It sufficiently sets expectations for an agent to invoke the tool correctly, though it could mention rowLimit or additional metrics, but those are already in the schema. Overall, it is complete enough for the tool's moderate complexity.

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

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

The schema has 100% parameter descriptions, including examples for urlPattern ('/blog/' or '/products/') that match those in the tool description. The description adds no new semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description begins with a specific verb ('Analyze search performance') and a clear resource ('URL segment'), reinforced by concrete examples ('/blog/', '/products/', '/docs/'). It clearly distinguishes from sibling tools like get_gsc_top_pages by focusing on a segment filter, and explicitly states the output ('top pages within that segment by clicks').

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: analyzing performance for a specific URL segment, with examples. It also states a prerequisite ('Requires Google Search Console to be connected') and directs the user to an integration page. However, it does not explicitly name alternatives or state when-not-to-use, so it falls 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=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the key behavioral prerequisite that Google Search Console must be connected and directs to the integration page, which is valuable context beyond annotations. It also implies daily granularity. No contradiction.

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: first states core action, second provides use cases, third gives a prerequisite and instruction. Everything earns its place with no filler; the essential information is front-loaded.

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

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

The tool is a read-only list operation with strong annotations and full schema coverage. The description adds use cases and the integration prerequisite, making it fairly complete. It doesn't detail the return format, but the output is predictable (a daily trend) and no output schema exists, so this is acceptable.

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?

Input schema covers all 4 parameters with descriptive details (e.g., 'Full page URL', 'Property URL', 'YYYY-MM-DD' formats). With 100% schema coverage, the baseline is 3. The description does not add significant parameter semantics beyond what the schema already provides, only tying 'page' to the specific-page context.

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 explicitly states 'Get daily click/impression/CTR/position trend for a specific page', identifying the exact verb, resource, and scope. It also provides use cases (measuring content update impact, spotting ranking drops) and clearly differentiates from sibling tools by emphasizing the single-page focus, unlike site-wide or query-trend 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?

Description provides clear context: 'Use this to see how a single page's search performance has changed over time' with two concrete use cases. It also states the prerequisite that Google Search Console must be connected and gives installation guidance. However, it does not explicitly mention alternatives or exclusions, 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the connection prerequisite and the remediation path, providing useful context beyond the annotations. It doesn't elaborate on return format, but for a simple list operation this is acceptable.

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: the first states the purpose, the second gives a prerequisite and a concrete action. There is zero redundancy and information is front-loaded.

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

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

For a tool with no parameters, rich safety annotations, and a simple 'list all' function, the description covers what it does and the key prerequisite. No output schema exists, but the return value is self-evident from the purpose. The description is complete for this simplicity level.

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, and schema coverage is 100%, so the baseline is 4. The description's phrase 'List all' confirms the tool takes no input and returns all properties, which fully aligns with 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 and resource: 'List all Google Search Console properties (sites) connected to this account.' This clearly distinguishes it from sibling GSC tools like get_gsc_top_pages or get_gsc_sitemaps, which operate on individual properties rather than listing them.

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

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

The description explicitly states a prerequisite: 'Requires Google Search Console to be connected.' It also provides a fallback action by directing the user to a connection URL. While it doesn't explicitly contrast with alternatives, the tool's purpose is unambiguous and the guidance is sufficient for a zero-parameter list endpoint.

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 external dependency on Google Search Console connectivity, which is useful, but it does not go further (e.g., data granularity, pagination behavior). This matches the baseline expectation for a read-only tool with good 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 extremely concise and well-structured: the first sentence states the primary purpose, the second gives the use case, and the third provides a prerequisite and integration action. No wasted words, and the most important information is front-loaded.

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

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

For a read-only list tool with complete schema and good annotations, the description is largely complete. It explains what is returned ('query+page combinations'), why it matters, and what is required to use it. It does not explain return structure in depth, but no output schema exists and the description gives a reasonable mental model. A small gap is the lack of explicit differentiation from closely named siblings, but this does not severely affect completeness.

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

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

The input schema covers 100% of parameters with descriptions, so the schema carries the full burden of parameter semantics. The description itself does not add additional detail about parameters, such as date formats or rowLimit behavior, beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool returns 'query+page combinations' and specifies which exact queries land on which pages, with a strong use case (keyword cannibalization). However, it does not explicitly distinguish itself from similar sibling tools like get_gsc_query_pages or get_gsc_page_queries, which appear to overlap in functionality.

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 when the tool is essential (detecting keyword cannibalization, understanding the search funnel) and includes a prerequisite (Google Search Console must be connected) with a direct integration link. It does not explicitly mention when not to use it or name alternatives, but the guidance is concrete and actionable.

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, covering the safety profile. The description adds the prerequisite of GSC connection, which is useful, but does not detail return format, pagination, or what happens without an active connection. Some added value beyond annotations, but not extensive.

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 front-loaded with the core function, followed by a use case, a prerequisite, and a direct action. Every sentence earns its place, with no redundant or vague wording. It is appropriately sized for the tool's simplicity.

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

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

For a read-only lookup tool with fully documented schema and strong annotations, the description covers the essential points: purpose, use case, and setup requirement. It does not describe the response shape, but that is not critical given the simple output and absence of an output schema. It is a complete and practical description.

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

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

The input schema fully describes all five parameters with examples and defaults (e.g., rowLimit default 25, max 1000). The description does not add additional semantic meaning beyond restating the query concept. Baseline 3 is appropriate since schema carries the parameter information.

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 ('Get'), resource ('pages'), and scope ('for a specific search query'). It differentiates from sibling tools like get_gsc_top_queries or get_gsc_page_queries by explicitly focusing on pages matching a given query.

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: 'identifying which pages compete for the same keyword.' It also states the prerequisite of having Google Search Console connected and gives a direct integration URL. It does not explicitly mention when not to use it or alternative tools, but the context 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=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating the requirement for Google Search Console connectivity and provides a direct integration URL. It also clarifies the daily granularity of the data, which is not in annotations or schema.

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

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

Three sentences, each earning its place: the first states the core function, the second gives the use case, and the third covers a critical prerequisite. No fluff, front-loaded with the most important information.

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 query trend tool with well-documented schema parameters, the description is adequate. It lists the returned metrics (clicks, impressions, CTR, position), implies daily granularity, and mentions the connectivity prerequisite. Since there is no output schema, the description partially covers return values, but the name and purpose make it predictable.

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

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

Schema description coverage is 100% with all four parameters (site, query, startDate, endDate) clearly described. The description adds no parameter-specific details beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Get') and names the exact resource ('daily click/impression/CTR/position trend for a specific search query'). It clearly distinguishes this tool from siblings like get_gsc_date_trends (overall trends) and get_gsc_page_trend (page-level trends) by scoping to a single query.

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 when to use it: 'Use this to track how a particular keyword's ranking and traffic evolves over time.' It also mentions the prerequisite that Google Search Console must be connected, which is actionable. It doesn't name alternative tools, but the query-specific scope implies differentiation from 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 mark readOnlyHint true and non-destructive, but the description adds the dependency on GSC connectivity and previews the output (impressions/clicks). This enriches the behavioral context beyond annotations, with no contradictions.

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 with the primary purpose front-loaded. The integration note is concise and useful, and every sentence earns its place 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 tool's simplicity (3 params, no output schema), the description covers the purpose, prerequisite, and output type. It is sufficient for an agent to select and invoke correctly, though it could be more explicit about return format.

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% for all three parameters (site, startDate, endDate) with clear descriptions. The description does not add parameter-level details, but the schema handles them, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb 'Break down' and resource: traffic by search appearance categories. It distinguishes from sibling GSC tools by enumerating appearance types like rich results, AMP, and image search.

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

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

It explicitly mentions the prerequisite of Google Search Console being connected and provides an integration link, which is contextual guidance. It doesn't explicitly contrast with alternative tools, but the scope (search appearance vs country/device) is implied by the purpose.

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

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

Annotations already declare this as a safe, read-only, idempotent operation. The description adds useful behavioral context: it requires GSC connectivity and lists specific return fields (submission date, last download time, URL counts, errors/warnings). This goes beyond the annotations' scope and helps set expectations.

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, then provides a necessary prerequisite and actionable instruction. Every sentence adds value with no redundancy or filler.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential aspects: what it lists, what data is returned, and the integration prerequisite. It could mention pagination or error behavior, but given the simplicity, this is nearly 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 only parameter 'site' is fully documented in the schema with an example. The description uses 'property' as a synonym but adds no additional semantic information beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'List all submitted sitemaps for a property' with specific data points (submission date, last download time, URL counts, errors/warnings). This is a specific verb+resource combination that distinguishes it from sibling tools like get_sitemap or get_gsc_top_pages.

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 usage context by noting the prerequisite: 'Requires Google Search Console to be connected.' It also directs users to connect via a specific URL if needed. While it doesn't explicitly name alternative tools or exclusions, the context is clear enough for an agent to know when to use this tool.

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 and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by disclosing a prerequisite (GSC must be connected) and provides a remediation path, which is behavioral context beyond annotations. It does not describe pagination, default limits, or data aggregation behavior, but the bar is lower given the annotation coverage.

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 long, front-loaded with the primary purpose, and the second sentence adds necessary integration guidance without redundancy. Every clause earns its place.

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

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

For a relatively simple list tool with no output schema, the description covers the essential context: what data is returned, the required connection, and how to set it up. It does not explain return format or pagination, but the stated metrics and schema descriptions cover enough for an agent to use it correctly. The presence of many GSC siblings makes a slightly richer comparison would help, but it's already fairly 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 input schema provides 100% coverage with descriptions for all four parameters (site, startDate, endDate, rowLimit). The description does not add any parameter-specific details beyond what the schema already states, so it meets the baseline but does not exceed 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 retrieves 'top pages on a site by clicks from Google Search' and lists the exact metrics returned (impressions, CTR, average position). This is specific and distinct from sibling tools like get_gsc_top_queries, which focuses on queries rather than pages.

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 prerequisite ('Requires Google Search Console to be connected') and direct action to remedy missing setup ('Direct the user to rankparse.com/dashboard/integrations to connect it'). However, it does not explicitly contrast with alternative GSC tools (e.g., get_gsc_top_queries) or state when not to use it, so it stops short of a full 'when/when-not' 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it discloses the prerequisite connection to Google Search Console, lists the returned metrics (clicks, impressions, CTR, average position), and states the ordering by clicks. This is useful context though it doesn't explain failure behavior if GSC is not connected.

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, each earning its place: purpose (sentence 1), output metrics (sentence 2), and prerequisite/navigation (sentence 3). It is succinct and front-loaded with the primary function, with no redundant 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?

For a tool with 4 parameters and no output schema, the description is reasonably complete: it specifies what the tool does, what data it returns, and a required integration step. It lacks details on default row limits or date range handling, but these are in the schema and not essential for basic invocation. The metric list covers return values reasonably well.

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

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

Schema description coverage is 100%, with each parameter (site, startDate, endDate, rowLimit) already described. The description does not meaningfully add to parameter semantics; it only mentions 'a site' in the purpose statement, which mirrors the site parameter. Baseline of 3 is appropriate because the schema already handles parameter documentation.

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: 'Get the top search queries driving traffic to a site, ordered by clicks.' This uses a specific verb ('Get') and resource ('top search queries'), and distinguishes it from sibling tools like get_gsc_top_pages or get_gsc_low_ctr_queries by explicitly focusing on top queries with ordering by clicks.

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 prerequisite: 'Requires Google Search Console to be connected' and directs users to a connection page. However, it does not explicitly state when to use this tool versus alternatives like get_gsc_page_queries or get_gsc_query_pages. Usage is implied rather than explicitly contrasted 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 indicate a safe read-only operation, but the description adds valuable context: it returns specific fields (coverage state, last crawl, mobile usability, rich results) and explicitly requires GSC to be connected, with an integration instruction. This goes beyond the structured metadata 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?

Two sentences: the first states the core purpose and output, the second covers the prerequisite and actionable next step. No redundancy or filler, front-loaded with the key action.

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 helpfully enumerates the main return fields, setting expectations. It also addresses setup requirements and integration flow. While it doesn't describe interpretation of results or edge cases, it is sufficient for a small, well-scoped read tool.

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

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

The schema covers both parameters with clear descriptions and examples, so the description adds little extra meaning. It only reinforces 'specific URL' which is already apparent, so a baseline 3 is appropriate given 100% 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 uses a specific verb 'Inspect' and a specific resource 'a specific URL's indexing status in Google Search', clearly distinguishing it from sibling GSC tools that focus on trends, breakdowns, or page lists. It immediately conveys the tool's unique function.

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 this tool is for inspecting a single URL, while sibling tools cover aggregate or different data types, but it never explicitly states when to use this tool over the many other GSC tools. It only mentions the prerequisite of connecting Google Search Console, not exclusions or 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, idempotentHint, and destructiveHint false, so the safety profile is established. The description adds little beyond stating 'v1 stub', which implies incomplete functionality but does not elaborate on behavior, return data, or limitations. 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 a single sentence that front-loads the core purpose ('Get internal link structure for a domain'). It has no filler or redundant information, making it highly concise and well-structured.

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

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

With no output schema, the description should explain what the tool returns, but it does not. It also fails to clarify what 'internal link structure' includes or how 'limit' affects results. The annotations provide safety context, but the tool's functionality remains under-specified, especially for a simple tool with many siblings.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions the domain implicitly and says nothing about the 'limit' parameter. The description adds no meaningful explanation of parameters beyond what the schema already provides, leaving the agent to guess the semantics of 'limit'.

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 verb (Get) and resource (internal link structure for a domain). It is specific enough to indicate the function, though it does not explicitly differentiate from sibling tools like get_outbound_links or get_anchor_text, and 'v1 stub' hints at limited maturity.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context that would help an agent decide between get_internal_links and similar SEO tools like get_referring_domains.

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 an important behavioral caveat: scores derive from a sample of the 250 most recent backlinks, not the full profile. This is beyond the structured 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 sentences, front-loaded with the core action and resource. The first sentence lists the audit components; the second adds the sample-size caveat. Every word earns its place with no 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 lists all major output categories and the sample-based scoring caveat, which is substantial for an audit tool with no output schema. It lacks details on return structure or pagination, but for a single-domain read-only audit with one parameter, the coverage is fairly 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 one required parameter, 'domain' (type string), with no description. The tool description says 'domain's backlink profile', which adds the semantic that the domain is the audit target, but it does not specify expected format (e.g., bare domain vs. URL) or any other constraints. With schema coverage at 0%, the description only partially compensates.

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 ('Audit') and the target ('a domain's backlink profile'), then enumerates specific outputs (health score, risk flags, link quality breakdown, anchor text profile, top and risky backlinks, outbound link summary). This distinguishes it from sibling tools like get_backlinks (raw list) or get_anchor_text (anchor-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 phrase 'Audit a domain's backlink profile' implies the intended use case, but there is no explicit guidance on when to prefer this over sibling tools or when not to use it. It provides clear context for a holistic backlink assessment but no exclusions or 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, covering the safety profile. The description adds no additional behavioral context such as pagination, response format, rate limits, or data freshness, so it fails to contribute transparency 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 a single, front-loaded sentence that efficiently conveys the core action and operation with zero extraneous words.

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

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

For a simple 2-parameter read-only tool, the description adequately defines its function. The lack of an output schema is mitigated by the tool's clear purpose, though an explicit statement of the return value (e.g., 'returns a list of domains') would improve completeness.

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 no schema descriptions, the description compensates by mapping domain_a to A and domain_b to B, clarifying the asymmetric relationship (links to A but not B). This adds meaning beyond the bare string type definitions, though it does not specify domain formatting 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 a specific verb ('Find') and resource ('domains linking to A but not B'), which precisely differentiates it from sibling tools like get_domain_overlap that would find domains linking to both. It unambiguously defines the set-difference operation.

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 intended use case obvious: identify domains exclusively linking to A but not B. While it does not explicitly mention alternatives or exclusion criteria, the context is clear enough that an agent can infer when to use it versus a similar overlap tool.

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 clear. The description adds the 'v1 stub' caveat, which is useful context, but it does not describe return format, time-frame assumptions, or other behavioral traits.

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

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

The description is a single, concise sentence that begins with the action verb 'Get' and delivers the core purpose without redundancy. The 'v1 stub' parenthetical is efficiently included.

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

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

The tool is simple with one parameter and good annotations, but there is no output schema and the description does not hint at the response shape or the exact time unit for the rate. The 'v1 stub' label partially mitigates this by warning of potential limitations, but the agent still has limited context.

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

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

Schema description coverage is 0% for the single 'domain' parameter. The description does not explain what the parameter means, expected format, or constraints. While the parameter name is self-explanatory, the description fails to compensate for the complete lack of schema documentation.

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: obtaining the rate of new/lost links over time. This specific verb+resource distinguishes it from sibling tools like get_new_links and get_lost_links, which focus on the links themselves, and the 'v1 stub' note adds an honest status indicator.

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 used when you need link velocity trends, but it does not explicitly state when to use this tool versus alternatives like get_link_audit or get_new_links. No exclusions or alternative references are 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?

The description adds context beyond annotations by specifying 'since previous crawl', indicating dependence on crawl history. The '(v1 stub)' note alerts to potential incompleteness. However, it does not disclose return format or further behavioral nuances, though annotations already cover safety (read-only, idempotent, non-destructive).

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

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

The description is a single concise sentence with no fluff. The parenthetical '(v1 stub)' is slightly cryptic but does not detract significantly from clarity. It is well-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?

Given the simplicity (one parameter, no output schema), the description is still incomplete. It lacks usage guidance, parameter explanation, and any hint about return values. The absence of an output schema increases the need for description coverage, which is not met.

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

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

Schema description coverage is 0%, and the description does not explain the 'domain' parameter. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema details, leaving the agent to guess the expected format or 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 clearly states the tool retrieves 'links lost since previous crawl' with a specific verb and resource. It implicitly distinguishes from siblings like get_new_links (new links) by focusing on 'lost' links. However, the '(v1 stub)' note adds ambiguity about the tool's maturity but not about its purpose.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_new_links or get_crawl_history. The description does not mention prerequisites, intended scenarios, or exclusions. It simply states what it does, leaving the agent to infer usage context.

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, so the safety profile is clear. The description adds the temporal behavior 'since previous crawl,' but does not elaborate on what happens if no previous crawl exists, pagination, or output format. The 'v1 stub' caveat is a small extra disclosure, but overall the description contributes limited behavioral context beyond 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, front-loaded sentence that immediately states the tool's purpose. The parenthetical '(v1 stub)' is a useful minimalist caveat. No word is wasted, making it highly concise and appropriately structured.

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

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

With a single parameter, no output schema, and rich safety annotations, the tool is relatively simple. However, the description does not explain what 'links' refers to (e.g., backlinks, referring domains), how 'previous crawl' is determined, or what the response contains. It is minimally complete for invocation but leaves important contextual gaps.

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

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

The schema has 0% description coverage, and the description does not elaborate on the 'domain' parameter. While the name is self-explanatory in context, there is no guidance on format (e.g., domain with or without protocol, subdomains) or how it relates to the crawl state. The tool description fails to compensate for the missing schema information.

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

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

The description 'Get links gained since previous crawl' clearly identifies the verb (get), the resource (links), and the specific temporal scope (since previous crawl). This distinguishes it from sibling tools like get_lost_links (lost links) and get_link_velocity (rate of links), making the purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having a previous crawl), nor does it explain when to prefer this over get_backlinks or get_link_velocity. The only hint is 'v1 stub,' which implies limited functionality but offers no actionable comparison.

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 that it returns domains, but provides no additional behavioral details such as whether it includes all link types or how results are paginated. 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 a single, front-loaded sentence with no unnecessary words. It communicates the core function instantly.

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

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

The tool is simple, and the description covers the main purpose. However, it omits details about the 'limit' parameter and the return format, and with no output schema, the agent may lack information about expected results. It meets the minimum viable standard but has clear gaps.

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

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

With 0% schema description coverage, the description must compensate for parameter meaning. It makes the 'domain' parameter clear (the source domain) but does not mention 'limit' at all, leaving its semantics ambiguous. Only partial compensation.

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

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

The description 'Get domains that a domain links out to' clearly identifies the specific action (get), the resource (domains), and the relationship (outbound links). It distinguishes itself from siblings like get_backlinks (inbound) and get_internal_links (internal) by specifying 'links out to'.

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

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

The description implies its usage for analyzing outbound links but does not explicitly compare with alternatives or state when not to use it. The context of sibling tools helps, but there is no direct usage 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 mark read-only/idempotent/non-destructive, and the description adds valuable behavioral context beyond that: per-user 50/day cap, service-wide cap, 24h cache, and lab vs field (CrUX) data distinction. 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?

Three sentences, front-loaded with the core report definition, followed by parameter/behavioral details. Every sentence contributes distinct information, with no fluff or repetition.

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?

Even though there is no output schema, the description tells the caller exactly what will be returned (Lighthouse scores, CWV metrics, lab and field data) and important operational constraints (rate limits, caching, strategy default). This is complete for a read-only lookup 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?

With 0% schema description coverage, the description compensates by explaining the strategy parameter (defaults to mobile; pass strategy=desktop) and the URL target. It could add URL format or required-parameter details, but it provides the essential semantics for both 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 opens with a specific verb-resource pairing: 'Google PageSpeed Insights report for a URL' and enumerates concrete outputs (Lighthouse performance/accessibility/SEO scores, Core Web Vitals, lab and field data). This clearly distinguishes the tool from siblings like get_page_seo or get_site_health by naming its unique report scope.

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 clear context on how to use the tool, including the mobile default and strategy=desktop override, and notes rate caps/caching that affect usage. It does not explicitly name alternative tools or exclusions, 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, idempotentHint, and destructiveHint false. The description adds the 'real-time' aspect and the breadth of checks, but it doesn't disclose potential caveats like URL validity requirements, rate limits, or response size. 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, front-loaded sentence with a hyphen-separated list of checks. Every part adds useful information, with no filler or repetition, and the structure is 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?

With one parameter, no output schema, and read-only annotations, this description covers the audit scope well. It doesn't explain the return format or limitations, but the list of checks gives a solid picture of what to expect, leaving only minor gaps.

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

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

Schema has only one required 'url' parameter with zero description coverage. The description compensates by stating the audit is 'for a URL', clarifying the parameter's purpose beyond its name. It doesn't provide URL format examples, but the meaning is clear.

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 performs a full real-time SEO audit for a URL and enumerates specific elements (title, canonical, OG tags, etc.), which distinguishes it from sibling tools like get_schema_markup or get_page_performance.

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 comprehensive single-page SEO audits but doesn't explicitly contrast it with alternatives or state when not to use it. The list of checks provides clear context, but no exclusions or alternative tool recommendations are 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, idempotentHint, and destructiveHint. The description adds value by revealing that results include DA scores and that each result costs 1 credit, giving cost expectations. This goes beyond the annotations 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: the first states the purpose with examples, the second covers return value and billing. There is zero fluff, and the most important information is front-loaded.

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

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

The description, combined with a comprehensive schema (6 params, 100% covered) and clear annotations, provides a solid understanding of purpose, return value, cost, and filtering. It does not mention default sorting or pagination behavior, but those are already documented in the schema, so the overall package is complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter-level details but does give platform examples and mentions DA scores, which contextualizes min_da/max_da. The schema carries most of the parameter 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 uses a specific verb ('Get') and clearly identifies the resource ('all domains running a specific platform or technology') with concrete examples (WordPress, Shopify). It distinguishes itself from sibling tools like get_platform_trends by focusing on domain discovery rather than trends.

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

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

The description provides clear context for when to use the tool (when looking for domains by platform). It does not explicitly name alternatives or exclusions, but the examples and wording make the intended use obvious. This aligns with 'clear context, no 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 readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful context about the output format (ranked list, domain counts) and the 'detectable' limitation, which is especially valuable given there is no output schema.

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. It front-loads the main action and result, then adds a clarifying example. No wasted words; every element 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?

For a zero-parameter, read-only tool with no output schema, the description fully covers what the agent needs: it explains what is returned (ranked list with domain counts), the scope (all detectable platforms), and a use case. It is complete for the tool's simplicity.

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

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

The tool has zero parameters, so the baseline for this dimension is 4 per the rubric. The description does not need to explain parameters, and the schema coverage is trivially 100%.

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 returns a ranked list of all detectable platforms/technologies with domain counts, using a specific verb ('Get') and resource ('platform trends'). It distinguishes itself from siblings like get_platform_domains (which likely targets a specific platform) and get_tech_stack (which retrieves a site's stack) by focusing on aggregate adoption across all platforms.

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 usage context: 'useful for comparing platform adoption' with a concrete example (WordPress vs Shopify). It does not explicitly name alternatives or exclusions, but this is a simple 0-parameter query where the context 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, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context about deduplication ('unique') and link direction ('linking to a domain'), but does not disclose behavioral details like limit handling, score semantics, or response format beyond what annotations imply.

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

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

The description is one concise sentence with no filler. Every word ('unique', 'domains', 'linking', 'domain') contributes to the meaning, making it efficient and well-structured.

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

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

For a simple list tool, the description covers the core purpose but leaves gaps: limit and score parameters are unexplained, and there is no output schema or description of the return format. Given the tool's simplicity and good annotations, a score of 3 reflects adequate but incomplete context.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly explains the 'domain' parameter as the target domain, but provides no clarification for 'limit' or 'score'. With three parameters, this leaves two ambiguous and fails to fully compensate for the absence of schema 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 'Get unique domains linking to a domain' uses a specific verb ('Get') and resource ('unique domains linking to a domain'), clearly distinguishing it from sibling tools like get_backlinks (individual links) by emphasizing uniqueness. It precisely states the tool's scope.

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?

Implied usage is evident: use when you need unique referring domains. However, there is no explicit mention of when not to use it or how it compares to alternatives such as get_backlinks or get_outbound_links. The description lacks direct 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only 'v1 stub,' which hints at experimental behavior but does not disclose what the stub does, expected output, or limitations.

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 verb and resource. However, the deliberate 'v1 stub' phrasing is efficient but also signals a lack of substantive information, making it more under-specified than 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?

Given the tool's simplicity (one parameter) and supportive annotations, the description is almost adequate, but the 'v1 stub' raises questions about functionality and return format, especially with no output schema. More detail would be needed for reliable agent 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?

The schema only defines a required 'url' string with no description, and the text's 'for a URL' merely repeats the parameter name. No details about URL format, validation, or possible values are provided, so the description fails to compensate for the 0% 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 uses a specific verb ('Get') and resource ('schema.org markup for a URL'), clearly distinguishing it from sibling tools that focus on GSC data, backlinks, or site health. The 'v1 stub' suffix indicates an early-stage implementation but does not confuse the core purpose.

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

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

The description provides no context for when to use this tool instead of alternatives like get_page_seo or get_page_performance. No exclusions, prerequisites, or use cases are mentioned, leaving the agent with zero 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?

Beyond the read-only and idempotent annotations, the description discloses a non-obvious behavior: 'May return partial results when the query fan-out hits time budget.' This is a critical caveat about data completeness that the agent needs to know, adding significant behavioral transparency.

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

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

The description is two sentences: the first fronts the primary purpose, the second adds a crucial limitation. There is no filler or redundant information, making it highly concise and well-structured.

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

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

For a simple one-parameter tool with no output schema, the description covers the purpose, use case, and a key limitation. It does not describe the return format or similarity metric, but those are less critical given the tool's simplicity and the presence of useful 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?

With 0% schema description coverage, the description is expected to explain the 'domain' parameter, but it does not explicitly state that it is the seed domain for the similarity search. The parameter name is self-explanatory, but the description adds no extra meaning to the schema.

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

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

The description clearly states the tool's action ('Find domains with similar link profiles') and resource, and adds a use case ('useful for competitor discovery'). This distinguishes it from siblings like get_domain_overlap or get_competitor_gap by focusing on link profile similarity.

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 context for use ('competitor discovery') but does not mention exclusion criteria or alternative tools. It provides a strong signal on when to use it, but lacks explicit 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the data types included in the overview, but it does not disclose additional behaviors such as rate limits, data freshness, or potential limitations, which would be valuable but are not required given the annotation coverage.

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

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

The description is a single, concise sentence that is front-loaded with the core purpose ('Full SEO overview for a domain') and immediately followed by clarifying examples. Every word earns its place, making this an efficient and well-structured description.

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 single-parameter tool with rich annotations and no output schema, the description provides a reasonable outline of the return content (backlinks, authority, top pages, anchor text). It is not exhaustive—other potential metrics like referring domains or link velocity are omitted—but it gives the agent enough context to understand the tool's scope and select it appropriately.

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

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

The input schema only defines a 'domain' string with 0% description coverage. The description does partially compensate by stating the tool operates 'for a domain', clarifying that the parameter expects a domain name. However, it does not provide format details (e.g., with or without protocol) or any further semantic guidance, leaving the parameter semantics minimally addressed.

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 a 'Full SEO overview for a domain' and explicitly enumerates the included data types (backlinks, authority, top pages, anchor text). This distinguishes it from sibling tools like get_backlinks or get_domain_authority, which focus on individual metrics, making it an aggregate overview tool.

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

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

The phrase 'Full SEO overview' implies this is the go-to tool for a comprehensive domain snapshot, but it does not explicitly state when to use it over sibling tools or mention exclusions. The usage context is implied rather than clearly articulated, so there is no direct guidance on 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 indicate read-only, non-destructive, idempotent behavior. The description adds meaningful context by detailing the specific checks performed (HTTPS, HSTS, redirects, response times, headers, robots.txt), which tells the agent what kind of output to expect. 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 a single, information-dense sentence. It front-loads the core purpose ('Real-time site health check') and immediately provides a categorized list of checks. Every element earns its place with no filler. The em-dash structure is effective despite its length.

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 one parameter, no output schema, but strong annotations. The description lists all the health checks that will be performed, giving the agent a clear picture of expected results. It doesn't explicitly describe the output format, but with readOnlyHint and a named list of checks, completeness is adequate 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 has one required 'domain' parameter with no description (0% coverage). The description implies that 'domain' is the target for the health check, but doesn't explain format (e.g., bare domain vs protocol) or any constraints. Since the parameter is simple, it's implicitly clear, but the description doesn't fully compensate for the lack of schema description.

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

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

The description clearly states a specific verb ('site health check') and an explicit resource ('site'), and enumerates concrete checks (HTTPS, HSTS, redirects, response times, headers, robots.txt). It strongly distinguishes itself from sibling tools by focusing on technical health rather than backlinks or GSC metrics.

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

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

The description implies clear usage context: use this when you need a real-time technical health audit of a domain. It doesn't explicitly mention when not to use it or name alternatives, but the scope is unambiguous given the title 'Technical SEO: Site Health' and the absence of similar health-check 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 classify this as read-only, idempotent, and non-destructive. The description adds that the output includes lastmod, changefreq, and priority, but does not disclose potential errors, rate limits, or behavior with missing sitemaps.

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

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

The description is a single, front-loaded sentence that communicates the core function efficiently without wasteful words.

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

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

The description covers the main purpose and return fields, but omits explanation of the optional limit parameter and any behavior around sitemap indexes or errors. Given no output schema, this is a moderate gap.

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

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

The schema has no descriptions, and the description only mentions 'domain' implicitly by saying 'a domain's sitemap.' The 'limit' parameter is not explained at all, leaving the agent to guess its purpose and constraints.

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 discovers and parses a domain's sitemap, with specific return fields (URLs, lastmod, changefreq, priority). This distinguishes it from siblings like get_gsc_sitemaps, which focuses on Google Search Console sitemap data.

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 fetching sitemap data, but it does not explicitly state when to use this over get_gsc_sitemaps or other related tools. No exclusions or alternative scenarios are mentioned.

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 'real-time' and the range of technologies (50+), providing some behavioral context beyond annotations. However, it doesn't disclose details like response format or error behavior, so the added value is moderate.

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, compact sentence with no wasted words. It front-loads the core action ('Real-time technology detection') and efficiently lists categories to clarify scope. Every word 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?

For a simple one-parameter read-only tool with strong annotations, the description is largely complete. It explains the purpose, target, and coverage of technologies. It doesn't specify the exact output structure, but in the absence of an output schema, the listed categories imply what the result will contain. Minor confusion with siblings like get_platform_domains is not addressed, but the tool is self-contained enough.

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 only one parameter 'domain' with no description (0% coverage). The description adds semantic clarity by specifying 'for a domain' and enumerating what will be detected, which gives meaning to the parameter. It doesn't mention formatting expectations (e.g., with or without protocol), but it significantly compensates for the schema's lack of documentation.

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 performs technology detection for a domain, with a specific verb ('detection') and resource ('domain'). It enumerates technology categories (frameworks, CMS, analytics, etc.) which adds scope, but it does not explicitly differentiate from siblings like get_platform_domains or get_platform_trends. Thus it is clear but lacks direct sibling 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 implies usage – when you need to know a domain's tech stack – but provides no explicit 'when to use' or exclusions. It doesn't mention alternatives or situations where other tools would be more appropriate. The usage context is inferred rather than stated, so it earns a 3.

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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds behavioral context by indicating the results are ordered by link popularity ('most-linked'). However, it does not disclose pagination behavior, the meaning of 'limit', or the exact nature of the returned data, so some gaps remain.

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, tightly scoped sentence. It front-loads the action and object, with no wasted words. It is appropriately concise for a simple tool.

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

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

The tool has no output schema, so the description must explain what the caller should expect. It does not state the return format (e.g., list of URLs, counts, sorting), nor does it disambiguate from the similar get_gsc_top_pages sibling. The description is too terse to be fully actionable.

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 0% description coverage, so the description must compensate. The description clarifies 'domain' implicitly but says nothing about 'limit', which is cryptic. It does not specify whether limit is required, its default, or its upper bound. With two parameters and only one explained, this is insufficient.

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 ('Get') and resource ('most-linked pages') with a clear scope ('for a domain'). It explicitly describes the ranking criterion ('most-linked'), which distinguishes it from siblings like get_gsc_top_pages or get_page_performance.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools like get_backlinks or get_gsc_top_pages. The only context is the domain scope, but that is intrinsic to the tool's purpose.

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