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?

Annotations already declare readOnly=true and idempotent=true. The description adds valuable runtime behavior: partial results with partial=true and scored=false under time budget, and that retrying yields a fully scored response. This goes beyond 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?

The description is two sentences, front-loaded with purpose, and follows with a concise behavioral note. Every word 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 description covers the tool's core purpose and key edge case (partial responses). Given the absence of an output schema and the relatively simple parameter set, it provides enough context for invocation, though it could include parameter clarification or return value details.

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 parameters 'domain', 'vs', or 'limit'. While the domain/vs relationship is implicit in 'competitor' vs 'you', the description does not map parameters to their meanings or provide any syntax guidance, failing to compensate for the 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: 'Find domains linking to a competitor but not to you: ranked link-building prospects.' It uses a specific verb ('Find') with a precise resource (competitive gap) and a clear output type (ranked prospects), distinguishing it from general backlink tools.

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

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

The description implies the primary use case (link-building prospect discovery) and provides specific retry guidance for partial responses ('retrying the same request usually returns a fully scored answer'). It doesn't explicitly name alternative tools, but the purpose is clear enough to guide selection among sibling tools.

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

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

Annotations already declare readOnlyHint, 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about prerequisites and the integration page, but the sentence 'Returns search volume and competition data' is a behavioral claim that seems inconsistent with listing accounts, reducing transparency about what the tool actually outputs.

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 composed of four sentences and is somewhat verbose. The first sentence is concise, but the later sentence about 'search volume and competition data' is confusing and appears to be irrelevant to the core purpose. The instruction to redirect the user to a URL could be folded more succinctly.

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 (no params, no output schema), the description covers the main context: purpose, prerequisites, usage, and alternatives. However, the misleading 'Returns search volume' statement undermines completeness because it suggests the tool returns something it likely does not, leaving the agent unsure about the actual response 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?

The tool has 0 parameters, and the schema coverage is 100% (empty properties). Per calibration, 0 params gives a baseline of 4. The description adds no input semantics, but none are needed; it does mention '10-digit customer IDs' which describes the output format, not input 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 begins with a clear verb+resource: 'List the Google Ads accounts the connected Google user can access, as 10-digit customer IDs.' This distinguishes it from sibling tools like get_google_ads_keyword_ideas. However, the later statement 'Returns search volume and competition data' directly contradicts the account-listing purpose, causing ambiguity about what the tool actually returns.

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 explicit usage context: 'Use this to help a user pick which account to select when they have more than one.' It also gives prerequisites ('Requires Google Ads to be connected and an Ads account selected'), directs the user to an integration page, and explicitly points to Google Search Console tools as alternatives for ranking data. This fully addresses when and when-not to use the 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 and destructiveHint false, so the safety profile is known. The description adds useful context about account prerequisites and clarifies the tool returns search volume/competition data, not rankings. 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 front-loaded with purpose and uses six sentences, each adding distinct value: purpose, use case, input, prerequisites, instructions, and clarification. No redundant or promotional language.

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 inputs, prerequisites, return data, and exclusions. With no output schema, it explains what data is returned (search volume, competition, bid ranges). It does not discuss pagination or rate limits, but the schema's limit parameter mitigates this gap.

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

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

The input schema covers all 7 parameters with detailed descriptions (100% coverage). The description adds minimal parameter-level info beyond saying to supply keywords and/or URL, which is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Discover NEW keyword ideas from seed terms and/or a URL' with specific data outputs. It distinguishes from siblings by noting it returns search volume/competition, not rankings, and directs users to GSC tools for ranking 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?

Explicitly says 'Use this for keyword research and content planning' and gives an example question. It also states prerequisites (Google Ads connected, Ads account selected) and provides a clear when-not-to-use: 'NOT keyword rankings; use Google Search Console 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, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond these: it specifies the output scope ('Returns search volume and competition data, NOT keyword rankings') and mentions the external requirement ('Requires Google Ads to be connected and an Ads account selected'), which is behavioral information not present in 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 four sentences, front-loaded with the core function, then usage guidance, alternative, prerequisite, and output clarification. Every sentence earns its place; no fluff. It is detailed but structured efficiently for an AI agent.

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 no output schema, the description covers the output type (search volume, competition, bid ranges) and explicitly what it does NOT return (keyword rankings). It also covers prerequisites and directs to integrations. Combined with high schema coverage and rich annotations, the description is complete for agent decision-making.

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

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

Schema description coverage is 100%, with each parameter having a clear description (e.g., keywords: 'The exact keywords to look up'). The main description reinforces the 'SPECIFIC list of keywords' idea but does not add meaningful semantic detail about language, geo, or network parameters beyond what the schema already provides. The baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Get average monthly search volume, competition level, and top-of-page bid ranges for a SPECIFIC list of keywords, with no expansion into related terms.' It uses a specific verb and resource, and explicitly distinguishes from the sibling tool get_google_ads_keyword_ideas by noting 'no expansion into related terms'.

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 explicit usage guidance: 'Use this when the user already has keywords in mind and wants them sized' and points to the alternative for discovery: 'For discovering new keywords instead, use get_google_ads_keyword_ideas.' It also states the prerequisite (Ads connected/account selected) and directs to the integration page, plus clarifies not to use for rankings.

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?

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the integration requirement and directs the user to connect via a specific URL, which is useful behavioral context 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 three focused sentences: purpose, use case, and 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?

Given the read-only nature, full parameter documentation, and clear annotation hints, the description is nearly complete. It lacks an explicit statement of return format, but for a list-finding tool with a self-explanatory name and no output schema, 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?

All parameters are fully described in the schema (100% coverage), so the description adds no additional parameter-level semantics. The tool description's mention of 'high impressions' and 'low CTR' maps to existing schema descriptions of minImpressions and maxCtr, providing no extra value.

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

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

The description clearly states the tool finds pages with high impressions but low CTR, which is a specific and actionable purpose. It distinguishes from sibling tools like get_gsc_low_ctr_queries by focusing on pages rather than queries.

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 ('Good starting point for title/description rewrites') and a prerequisite (Google Search Console must be connected). It does not explicitly compare to alternatives, but the context is clear enough for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, so the safety profile is covered. The description adds value by disclosing that GSC must be connected and providing a specific integration URL, plus explaining the strategic context behind the query results. 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 four sentences, front-loaded with the core purpose in the first sentence. Each subsequent sentence earns its place: the 'ranking but not clicked' explanation, the ROI rationale, and the prerequisite/instruction. There is no redundant content.

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

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

With six well-documented parameters and no output schema, the description adequately covers the tool's purpose, usage context, and prerequisite. It could mention what the return data looks like, but the self-explanatory name and rich schema make the description sufficiently complete 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?

The input schema has 100% coverage with detailed descriptions for all six parameters (site, startDate, endDate, maxCtr, rowLimit, minImpressions). The description does not add parameter-specific meaning beyond what the schema 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 clearly states 'Find search queries with high impressions but low CTR' with a specific verb and resource. It distinguishes from sibling tools like get_gsc_low_ctr_pages by focusing on queries rather than pages, and adds context by explaining these are 'ranking but not getting clicked'.

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

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

The description gives clear usage context: these queries are underperforming in clicks despite high impressions, and fixing them is 'typically higher ROI than chasing new rankings.' It also notes the prerequisite that Google Search Console must be connected, with a direct URL for setup. However, it doesn't explicitly mention when not to use this tool or name alternative tools, 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, covering the safety profile. The description adds valuable context by specifying the default sorting order (clicks descending) and the semantic meaning of the position range (page 1 bottom / page 2). This 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 three sentences, each earning its place: the core purpose, the sorting behavior, and the prerequisite. It's front-loaded with the key information and contains no redundant text.

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

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

Given the tool's moderate complexity and rich annotations/schema, the description covers the essential behavior: purpose, sorting, and prerequisite. It doesn't detail the return fields, but no output schema exists, and the description gives enough 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?

The schema has 100% parameter coverage, including defaults for minPosition and maxPosition. The description adds meaning by explaining why these positions matter ('quick win zone'), which helps the agent understand the tool's purpose beyond the raw parameter names.

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: finding queries ranking in positions 8–20, framing it as a 'quick win' opportunity. This specific position range distinguishes it from other GSC query tools like get_gsc_top_queries or get_gsc_low_ctr_queries, which target different metrics.

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

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

The description provides clear context on when to use the tool: to identify quick-win SEO opportunities where small improvements can increase clicks. It also states a prerequisite (GSC must be connected) and directs the user to the integration page. However, it doesn't explicitly mention alternative tools or when not to use it.

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

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

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by specifying the return data ('top pages... by clicks') and the external dependency on a connected GSC account, which is not in 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?

Three well-structured sentences: first states purpose with concrete examples, second describes the return value, third notes the prerequisite and action to resolve it. 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?

Given there is no output schema, the description adequately explains what the tool returns and the prerequisite. It doesn't explicitly mention date formats or rowLimit, but those are covered in the schema. For a read-only analytic tool, this is sufficiently complete.

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

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

The input schema has 100% coverage for all 5 parameters, so baseline is 3. The description reinforces the meaning of urlPattern with examples ('/blog/', '/products/'), but doesn't add substantial new meaning beyond the schema's existing property descriptions.

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

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

The description clearly states the tool's function with a specific verb ('Analyze search performance') and clarifies the scope ('URL segment') with concrete examples. It also specifies the output ('Returns the top pages within that segment by clicks'), distinguishing it from sibling tools like get_gsc_top_pages or get_gsc_page_queries.

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

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

The description gives clear context for when to use the tool ('e.g. all blog posts...') and notes a key prerequisite ('Requires Google Search Console to be connected'). It doesn't explicitly name alternative tools or exclusions, but the segment focus and examples provide adequate 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 declare readOnly/idempotent/non-destructive, so the description doesn't need to restate that. It adds meaningful behavioral context: the tool requires Google Search Console to be connected and directs the user to a specific integration URL. It also clarifies the daily granularity of the trend data.

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 function, followed by use case and prerequisite. Every sentence earns its place; no fluff or redundancy.

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

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

For a tool with no output schema and four required parameters, the description adequately covers what data is returned (clicks/impressions/CTR/position) and the prerequisite (GSC connection). It's not exhaustive regarding pagination or aggregation details, but sufficient 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?

Input schema covers 100% of parameters with descriptions (page, site, startDate, endDate). The description adds no additional parameter-level semantics beyond what the schema already provides; the baseline of 3 applies since schema does the heavy lifting.

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

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

The description opens with a specific verb+resource: 'Get daily click/impression/CTR/position trend for a specific page.' This clearly distinguishes it from sibling tools like get_gsc_query_trend (query-focused) and get_gsc_date_trends (site-wide) by explicitly stating the scope is a single page.

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 states when to use: 'to see how a single page's search performance has changed over time, useful for measuring the impact of a content update or spotting a ranking drop.' This is clear usage context, though it does not explicitly name alternative tools for negative guidance. The integration prerequisite adds useful 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, 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, indicating a safe, read-only operation. The description adds the prerequisite that Google Search Console must be connected and directs users to an integration page, which is useful context. However, it does not disclose other behavioral details such as pagination, sorting, or response structure, so with annotations covering the safety profile, this is adequate but not exceptional.

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: the first states the function, the second explains the use cases, and the third provides a prerequisite/action. There is no fluff or repetition, making it 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?

The tool has no output schema, but the description gives enough context: it explains what the tool returns (query+page combinations) and why it's useful. It also notes the GSC connection requirement. While it doesn't detail the exact response format, the phrasing 'which exact queries are landing on which pages' implies the key fields. Given the tool's simplicity and existing annotations, this is reasonably complete.

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

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

The schema describes all four parameters (site, startDate, endDate, rowLimit) with clear descriptions and 100% coverage. The description adds no parameter-level detail, so the schema carries the full burden. According to the provided scheme, a baseline of 3 is appropriate when schema coverage is high and the description does not compensate further.

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 query+page combinations: which exact queries are landing on which pages.' This is a specific verb+resource+scope, and it distinguishes the tool from similar GSC tools like get_gsc_query_pages and get_gsc_page_queries by emphasizing the pairing concept. The mention of keyword cannibalization and search funnel further clarifies its unique value.

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 to use the tool: 'Essential for detecting keyword cannibalization... and understanding the search funnel.' It also mentions a prerequisite (GSC connection) and gives a directive to connect. However, it does not explicitly mention alternatives or when not to use this tool, 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, 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so no contradiction. The description adds behavioral details: it 'Shows which search features are driving impressions and clicks,' which clarifies the output's intent. It also discloses the integration dependency. With annotations covering safety, this additional context earns a 4.

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

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

The description is three concise sentences: the first states the core purpose with examples, the second describes the output behavior, and the third covers the dependency and next step. Every sentence earns its place, with no redundant or vague wording.

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

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

For a read-only reporting tool with full schema coverage and annotations, the description is mostly complete. It explains what the tool does, what it shows, and its prerequisite. However, it does not explicitly mention how results are aggregated (e.g., by feature over the date range) or provide any return format details, though no output schema exists. This is a minor gap.

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

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

Schema description coverage is 100%, with clear descriptions for site, startDate, and endDate. The description does not add further parameter-specific semantic details beyond what the schema already provides. Per the calibration, a baseline of 3 is appropriate when the schema handles the heavy lifting.

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

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

The description uses a specific verb and resource: 'Break down traffic by how the site appears in Google Search' and enumerates concrete examples ('organic web results, rich results, AMP, image search, video, news'). This clearly differentiates the tool from siblings like get_gsc_country_breakdown or get_gsc_device_breakdown, which focus on other dimensions.

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

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

The description gives clear usage context: 'Break down traffic by how the site appears in Google Search' and explicitly states a prerequisite: 'Requires Google Search Console to be connected.' It also directs the user to an integration page if not connected. It does not name alternative sibling tools, but the focus on search appearance inherently distinguishes it.

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

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

Annotations already 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 clear. The description adds significant behavioral context beyond annotations by disclosing that scores are derived from a sample of the 250 most recent backlinks, not the full profile. This is a critical limitation that affects interpretation of results. No contradiction with annotations.

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

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

The description is two sentences: the first lists the tool's outputs, the second provides the crucial sampling caveat. Every word earns its place, no fluff or repetition. It is well-structured and immediately highlights the key limitation.

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 takes on the burden of explaining return content, which it does thoroughly by listing health score, risk flags, link quality breakdown, anchor text profile, top and risky backlinks, and outbound link summary. The sampling caveat adds essential context for interpreting results. For a read-only tool with one input, the description is complete enough 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 only one parameter 'domain' with a basic type of string and no description (0% coverage). The description compensates by starting with 'Audit a domain's backlink profile', making it clear the domain parameter is the target of the audit. It doesn't add format details (e.g., bare domain vs URL), but with a single parameter, the meaning is adequately conveyed.

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

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

The description uses the specific verb 'Audit' and clearly identifies the resource ('a domain's backlink profile'), then enumerates the exact components included: health score, risk flags, link quality breakdown, anchor text profile, top and risky backlinks, and outbound link summary. This level of specificity distinguishes it from sibling tools like get_backlinks or get_link_velocity.

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

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

The description implies when to use the tool—when a comprehensive backlink audit is needed rather than just a list of backlinks. It doesn't explicitly name alternatives or exclusion criteria, but the phrase 'Audit a domain's backlink profile' gives clear context. The sampling caveat also helps set expectations for use.

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?

The description discloses several behavioral traits beyond the annotations: per-user and service-wide daily caps (50/day), successful responses cached for 24h, and the default strategy. These details are not present in the annotations and provide critical operational context.

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

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

The description is two sentences long and every clause adds value: purpose, metrics, strategy guidance, and rate-limit/caching constraints. There is no repetition or filler, making it highly efficient.

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

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

Although there is no output schema, the description enumerates the exact return data (Lighthouse scores, Core Web Vitals, lab/field data), making the output expectations clear. Combined with parameter guidance and rate-limit information, this is fully complete for a read-only, 2-parameter 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 is minimal (url string, strategy enum) with 0% description coverage, but the description adds meaning to the strategy parameter by explaining its default and how to switch between mobile and desktop. The url parameter is self-explanatory and doesn't require further elaboration.

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 it produces a Google PageSpeed Insights report for a URL and enumerates the exact metrics returned (Lighthouse scores, Core Web Vitals). This distinguishes it from sibling tools like get_page_seo and get_site_health, making its 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 clear context for when to use the tool (for performance/accessibility/SEO metrics) and includes specific parameter guidance ('Defaults to mobile; pass strategy=desktop'). However, it does not explicitly name alternatives or state when not to use it, so it lacks the explicit 'when/when-not' distinction.

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 safety. The description adds 'real-time' as a behavioral trait, indicating live data fetching. No contradictions with annotations; the description enriches the safety profile with a timing characteristic.

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 with a clear front-loaded purpose and a comma-separated list of checks. It avoids fluff, though the list is long. The structure is effective for scanning.

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

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

For a read-only audit tool with no output schema, the description lists the audit components comprehensively. The sibling tool set provides context, and annotations confirm safety. However, it does not describe the output format or any rate limits or credit usage, which would improve completeness for a complex multi-check 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 has only one parameter 'url' with type string and no description. The description says 'for a URL' but does not specify expected format (e.g., protocol, encoding, or whether it accepts full URLs). With 0% schema description coverage, the description should compensate but fails to provide meaningful parameter guidance.

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

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

The description clearly states this tool performs a full real-time SEO audit for a URL, listing specific elements (title, meta, OG tags, etc.). It clearly distinguishes from sibling tools like get_schema_markup or get_page_performance by covering a comprehensive audit 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?

The description implies usage for comprehensive SEO audits but provides no explicit guidance on when to use this vs alternatives. It does not mention sibling tools or exclusions. The word 'Full' hints at its role as a one-stop audit tool, but explicit comparisons are absent.

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

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

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 the tool as read-only, idempotent, and open-world, so the safety profile is clear. The description adds value by revealing the output nature (ranked list with domain counts), which is not present in annotations. No contradictions or hidden behaviors are apparent.

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

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

The description is a single, well-structured sentence that front-loads the core function and includes a clarifying example. Every word contributes meaning; there is no fluff or redundancy.

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

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

Given the simplicity of the tool (0 parameters), the rich annotations, and the absence of an output schema, the description fully covers what the agent needs to know: it returns a global ranked list of technologies with counts. No additional context is necessary for correct invocation.

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

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

The tool has zero parameters, and the input schema is empty. The baseline for 0 parameters is 4, and since there are no parameters to explain, the description does not need to add parameter-level details. It correctly implies that the tool takes no input.

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: a ranked list of all detectable platforms and technologies with domain counts. It distinguishes itself from siblings like get_platform_domains (which likely returns domains for a specific platform) and get_tech_stack (which is probably per-domain) by emphasizing the global, aggregate nature of the 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 provides clear context by stating it is useful for comparing platform adoption, with a concrete example (WordPress vs Shopify). It does not explicitly mention when not to use it or name alternative tools, but the use case is clear enough for an agent to infer when to select this tool over others.

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

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

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds a valuable behavioral caveat: partial results may occur when query fan-out hits time budget. This beyond-annotation disclosure is transparent and useful.

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, purpose first, caveat second. Every word earns its place. Highly 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 single-parameter read-only tool with no output schema, the description covers purpose, use case, and a behavior caveat. It is complete for an agent to decide when to use and what to expect.

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 is only one parameter (domain) with no schema description coverage (0%). The description implies the domain is the seed for finding similar ones, but adds no format, examples, or constraints. It fails to compensate for the missing 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 uses a specific verb (Find) and resource (domains with similar link profiles) and adds a use case (competitor discovery). It does not explicitly contrast with sibling tools like get_competitor_gap or get_domain_overlap, but the purpose is clear enough.

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

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

Provides clear context by stating it is useful for competitor discovery. However, it does not explicitly state when not to use it or name alternatives, leaving some ambiguity relative to overlapping 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, 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 cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds concrete detail about what is checked (e.g., HSTS, CSP, robots.txt) and notes the 'real-time' nature, which helps the agent predict behavior beyond the 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?

A single, front-loaded sentence that immediately states the purpose, then lists specific checks. Every element adds value with no redundancy, making it both concise and structured for quick parsing.

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

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

With one simple parameter and rich annotations, the description covers the tool's scope well. It doesn't describe the output format, which would be useful, but the lack of an output schema reduces the expectation. The enumerated checks give enough context for an agent to invoke correctly.

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

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

Only one parameter, 'domain', with no schema description. The name is self-explanatory, and the description reinforces that the tool targets a website. While it doesn't specify formatting (e.g., with/without protocol), the simplicity of the parameter and tool context make this sufficient.

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

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

The description clearly states a specific action ('Real-time site health check') with enumerated checks (HTTPS, HSTS, redirect behavior, response times, security headers, robots.txt). This distinguishes it from sibling tools like get_page_seo or get_tech_stack, which focus on different aspects.

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 establishes clear context for use: when needing an overall site health assessment including security headers and redirects. It doesn't explicitly name alternatives or exclusions, but the sibling list shows this is the go-to for health checks, not backlinks or GSC metrics.

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 return field context but does not disclose potential rate limits, pagination, or behavior when no sitemap exists. With annotations, the bar is lower, but the description provides only modest added behavioral context.

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

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

The description is a single, focused sentence that front-loads the main action ('Discover and parse a domain's sitemap') and then concisely notes the returned fields. No words are wasted, and the structure is clear and scannable.

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

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

No output schema exists, so the description must convey what the tool returns; it does list the fields. However, the unexplained 'limit' parameter and lack of detail about response format or edge cases (e.g., no sitemap found) leave the description slightly incomplete for a simple tool. Annotations provide safety context, but overall the description is adequate yet not fully comprehensive.

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 parameter descriptions (0% coverage). The description only implies that 'domain' refers to the target domain, but it does not explain the 'limit' parameter at all. Since schema coverage is low, the description was expected to compensate, but it fails to clarify the optional limit parameter's meaning or effect on results.

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' and lists the returned fields (lastmod, changefreq, priority). This distinguishes it from sibling tools like get_gsc_sitemaps, which handles Google Search Console sitemaps. The verb and resource are specific and unambiguous.

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

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

The description provides clear context: use this tool to fetch a domain's sitemap URLs and metadata. However, it does not explicitly mention alternatives or exclusions (e.g., for GSC sitemaps, use get_gsc_sitemaps). Since the context is clear but no when-to-use guidance is given, it earns a 4.

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, so the safety profile is covered. The description adds the 'real-time' aspect, which implies a live network call and potential latency, and lists supported technology categories, but does not disclose response format, pagination, rate limits, or failure behavior. This adds some behavioral context beyond annotations but not rich.

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

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

The description is a single, focused sentence that front-loads the core action ('Real-time technology detection') and efficiently enumerates categories. No unnecessary words 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?

The tool has a single parameter and no output schema, so the description carries some responsibility to explain return expectations. It implies the result is a list of detected technologies with categories, but never explicitly states what the return looks like or whether it includes versions, confidence scores, etc. The simplicity of the tool and available annotations keep it from being wholly inadequate, but it is missing output clarity.

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' (string) with zero description coverage. The description mentions 'for a domain', confirming the input, but does not elaborate on format, constraints (e.g., protocol, subdomains, validity), or example values. Given the low schema coverage, the description should compensate more than it does.

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: real-time technology detection for a domain, listing specific categories (frameworks, CMS, analytics, etc.) and a scope of 50+ technologies. This distinguishes it from sibling tools like get_platform_domains and get_platform_trends by focusing on domain-level tech stack detection.

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

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

The description implies usage: if you need to identify a domain's technology stack, use this tool. However, it does not explicitly state when to use it over alternatives or provide any exclusion criteria. The 'real-time' mention suggests a live check, but minimal guidance is given.

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

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

Annotations already declare readOnlyHint=true, 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.

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

The description goes far beyond the sparse annotations (readOnlyHint=false, etc.) by disclosing critical behaviors: non-idempotent nature (returns added/skipped counts), limits, email validation rules, copy style requirements (no em-dashes, subject length, word count), punycode requirement for non-ASCII domains, skip reasons, and the fact that contacts added to a launched campaign remain inert until outreach_launch_campaign is called again. This is comprehensive and consistent 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?

Despite being a long paragraph, every sentence earns its place. It is front-loaded with the primary action, then systematically covers limits, usage on launched campaigns, content requirements, writing style, punycode, return values, and post-add behavior. No filler or redundancy; the density is appropriate for the tool's complexity.

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 description is exceptionally complete for a tool with no output schema. It explains not only what happens on success (count of added contacts) but also all skip reasons (invalid email, duplicate, copy too long, campaign full, already_contacted), the requirement to re-launch for live campaigns, and content constraints. The description fully covers the tool's behavior, limits, and edge cases, leaving few questions for the agent.

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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds meaningful semantics beyond the schema: per-contact copy requirements (subject and body length, style, word count), one-contact-per-domain limit, and the requirement for real, researched emails. It does not duplicate every schema field but enriches the meaning of the contacts array and its properties, justifying a 4.

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 'Add contacts with per-contact email copy to a campaign,' which is a specific verb and resource, clearly distinguishing this tool from the many read-only analytics siblings. It further clarifies its scope by detailing constraints (max 100 per call, 500 per campaign) and that it works on both draft and launched campaigns, leaving no ambiguity about its 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 provides clear usage context: it works on a draft campaign or an already-launched one, explicitly noting that adding to a launched campaign is 'how you top a live campaign up with fresh prospects.' It also implies exclusions by stating limits and the need for researched emails, but it does not explicitly name alternative tools or state when-not-to-use conditions. Thus it earns a 4 rather than 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavioral impact: that setting auto_send_enabled=false halts all sending, and that these settings 'control real email volume'. It also explicitly instructs to confirm with the user before making changes, adding a safety layer not present in structured data.

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

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

The description is two sentences, front-loaded with the primary action, and every clause serves a purpose. It efficiently packs scope, parameter details, and a safety warning without redundancy.

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

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

The tool is simple (two optional parameters), and the description covers its core behavior, scope, and user-confirmation requirement. It does not mention return values or what happens after a successful update, but given the lack of an output schema and the simplicity of the operation, this is a minor gap.

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

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

Input schema has 100% coverage, but the description adds practical meaning: it clarifies that max_sends_per_day has a range and applies globally, and that auto_send_enabled=false stops all sending while true resumes it. The 'and/or' phrasing also indicates both can be updated independently. This exceeds the schema's descriptions.

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

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

The description clearly states the tool's function with a specific verb ('Update') and resource ('the Gmail sending schedule'), and enumerates the two adjustable fields with their scope ('account-wide across all campaigns'). It distinguishes itself from sibling campaign-level tools by emphasizing account-wide settings.

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 ('account-wide', 'stops ALL sending', 'resumes it') that implies when to use this tool versus per-campaign controls like pause/resume. It adds an explicit usage directive: 'Confirm with the user before changing these'. However, it does not explicitly name alternatives or state when not to use it.

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

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

Annotations only state readOnlyHint=false and openWorldHint=true. The description adds substantial behavioral context beyond this: it creates a draft (not sent), sends via Gmail, requires user Gmail connection, and that campaigns are topped up not replaced. This is useful non-destructive and external-effect context not present in 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 front-loaded with the core purpose in the first sentence, then organized as a numbered flow that earns its place by clarifying the tool's role. Despite being longer than typical descriptions, every sentence contributes necessary context (steps, prerequisites, continuation behavior) without fluff.

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

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

The description provides a complete workflow, prerequisite, and continuation guidance, making it easy for an agent to sequence this tool correctly. It lacks an explicit statement of the return value (e.g., campaign ID), but the workflow implies the next steps (e.g., outreach_add_contacts) and the lack of an output schema makes this a minor gap.

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

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

The input schema descriptions already cover all three parameters (goal, name, your_domain) with examples, giving 100% schema coverage. The description does not add additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description opens with 'Create a draft link-building outreach campaign (sends via the user's connected Gmail)', providing a specific verb and resource. It clearly distinguishes this tool from siblings by noting it creates a draft (not launch) and is part of a larger outreach flow.

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 an explicit 8-step outreach flow, placing this tool at step 5. It directly tells when to use the alternative path: 'To CONTINUE an existing campaign rather than start a new one, begin at outreach_suggest_prospects instead of step 1 — campaigns are topped up, not replaced.' It also states the Gmail connection prerequisite.

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, idempotent, non-destructive behavior; the description adds concrete detail about the delivery count categories (awaiting launch, queued, sending, sent, skipped), which is useful beyond annotations. 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?

Two sentences, front-loaded with the primary action, and includes a practical usage phrase. No wasted words; every element 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?

Although there is no output schema, the description enumerates the delivery counts that will be returned and the scenario, making the return contents clear for a simple getter. The single-parameter schema is fully defined, and no additional context is needed.

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

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

Schema coverage is 100%, with the only parameter 'campaign_id' described as 'Campaign id'. The description does not add additional parameter-level details, but the tool's purpose (getting campaign status) implies the parameter identifies the target campaign. Baseline 3 applied.

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

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

The description clearly states the tool gets a campaign's status and delivery counts, with specific verb ('Get') and resource ('campaign'), and the parenthetical lists the exact statuses returned. It distinguishes itself from siblings like outreach_list_campaigns and outreach_launch_campaign.

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 direct usage context ('Use to answer "how is my campaign doing?"'), which is a clear cue for when to invoke this tool. It does not explicitly mention alternatives or exclusions, but the scenario is sufficient for a read-only status getter.

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?

Goes beyond annotations by detailing real email sending, pacing under daily send cap via hourly background sweep, automatic suppression of previously emailed contacts, and that it never re-sends on re-invocation. This adds significant behavioral context not captured by readOnly/idempotent hints.

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 dense and well-structured, front-loading the key action and consequence. Every sentence earns its place: prerequisites, suppression behavior, re-invocation safety, and return counts. No redundant or vague wording.

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

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

For a side-effectful tool with no output schema, the description covers all essential aspects: user approval prerequisite, pacing mechanism, suppression, re-invocation semantics, and expected return values. An agent has enough information to invoke it correctly and anticipate outcomes.

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 fully describes campaign_id with 'Campaign id to launch', and description does not add further parameter-specific semantics. Baseline of 3 is appropriate because schema coverage is 100% and the tool has only one simple parameter.

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 clearly states the tool 'launches a campaign' and that 'REAL EMAILS will be sent from the user's Gmail account', distinguishing it from sibling tools like pause/list/get. It also explains re-launch behavior for newly added contacts, making its 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?

Explicitly states when to use: 'Only call this after the user has seen the drafted emails and explicitly approved sending.' Also clarifies safe re-invocation to queue newly added contacts, providing clear context and preventing misuse.

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, so the agent understands this is a safe, read-only operation. The description adds that the result includes status and contact counts, which is useful but minimal; no further behavioral traits like pagination are disclosed.

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 conveys action, object, and output details with no redundant words. It is concise and easy to parse.

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

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

Given the tool's simplicity (zero parameters, safe read-only operation) and rich annotations, the description adequately covers the expected output ('status and contact counts'). No gaps that would hinder an agent's 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 tool accepts no parameters, so the schema trivially covers 100%. Per rubric, a tool with zero parameters receives a baseline of 4. The description doesn't need to explain parameter meaning since none exist.

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

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

The description starts with the action 'List' and clearly identifies the resource 'this account's outreach campaigns' with specific output details ('status and contact counts'). It distinguishes from sibling outreach_get_campaign, which likely handles individual campaigns.

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's clear scope ('this account's outreach campaigns') implies it is used to enumerate all campaigns, as opposed to outreach_get_campaign for a single one. It lacks explicit when-not-to-use language, but the context is clear enough for an agent.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful context: queued emails stay queued and resuming continues exactly where it left off, and other campaigns are unaffected. It does not cover edge cases like double-pausing, but the core behavior is well disclosed.

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 action, and contains zero filler. Every phrase earns its place: stopping sends, staying queued, resume continuity, and global scope of other campaigns.

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 mutation tool with one parameter, no output schema, and clear annotations, the description is complete. It explains the state change, the preserved queue, and the scoping to one campaign. No critical information is missing for an agent to understand the tool's effect.

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

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

The schema already fully documents the only parameter (campaign_id: 'Campaign id to pause'), achieving 100% schema coverage. The description adds no additional meaning about the parameter beyond the fact it identifies 'one campaign', which is already implied. Baseline 3 is appropriate.

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

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

The description clearly states a specific action ('Pause one campaign') and explains the exact behavior (queued emails stop sending but stay queued). It distinguishes itself from sibling tools like outreach_resume_campaign and outreach_launch_campaign by emphasizing the pause semantics and continuity upon resume.

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 to use: when you need to pause a single campaign while preserving its queue. It implies the use case for resuming later, but does not explicitly compare with alternatives (e.g., launch or delete). The sibling names help, but the description could be more explicit about when not to use it.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral context: queued emails become eligible for the next hourly send sweep. This gives the agent a clearer picture of side effects. It doesn't mention auth or rate limits, but those are not critical for this simple action.

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

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

The description is a single sentence that front-loads the action and purpose, with no redundant information. Every word earns its place.

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

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

For a single-parameter mutation tool with no output schema, the description explains what happens (resume and effect on queued emails) sufficiently. 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 schema already describes campaign_id as 'Campaign id to resume' with 100% coverage. The description adds no additional parameter details, 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 clearly states the action (resume) and the resource (a paused campaign), and adds the consequence that queued emails become eligible for the next hourly sweep. This distinguishes it from sibling tools like pause or launch.

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 intended use case: resuming a campaign that was previously paused. It provides clear context ('a paused campaign') but does not explicitly mention alternatives or when not to use it, 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, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context by listing the specific data points returned (connected account, auto-send toggle, daily cap, sent today, remaining budget, queued count, drain estimate), giving the agent a clear picture of what to expect without side effects.

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 and then uses a colon to list the returned status items. It is concise, every element adds value, and no words are wasted.

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 status tool with no output schema, the description fully specifies what data will be returned: connected account, auto-send state, daily cap, sent today, remaining, queue total, and drain estimate. This is complete enough for an agent to invoke the tool and interpret the result.

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

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

The tool has zero parameters and the schema coverage is 100%, so there are no parameters to document. The description adds no parameter information, but with no params, the baseline is 4. There is nothing missing.

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

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

The description clearly states the verb 'Get' and the resource 'Gmail sending pipeline status', then enumerates specific data fields returned. This distinguishes it from siblings like outreach_configure_sending or outreach_launch_campaign, which involve actions rather than status retrieval.

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

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

The description makes it clear this is for checking sending pipeline status (account, auto-send, daily cap, queue). It implies a pre-flight or monitoring use case, but does not explicitly name alternative tools or state when not to use it. Given the sibling list, this is a distinct read-only status tool, so 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructive action. The description adds the important exclusion list behavior and the truncation caveat, plus the cached/unpaginated sibling behavior, giving practical operational transparency beyond the annotation flags.

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 longer than typical but every sentence earns its place: it front-loads the starting instruction, lists return fields, gives a mandatory action, names alternatives, and closes with a workflow. It is dense but well-structured and skips 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 fully describes the meaningful return entities (campaign context, capacity, send queue, exclude_domains, truncation flag) and provides actionable next steps. For a single-parameter tool with no output schema, this is complete enough to guide correct invocation and follow-through.

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

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

Schema coverage is 100% and the only parameter, campaign_id, is self-explanatory. The description reinforces its meaning ('top up') but does not add significant new syntax or format details, 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 opens with 'START HERE when adding more websites to an existing campaign', a specific verb and resource. It clearly states what the tool returns and distinguishes itself from sibling discovery tools by framing it as the campaign-context entry point.

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 says when to use the tool ('START HERE'), provides a required filtering step against exclude_domains, names alternatives (get_similar_domains, get_link_intersect, get_platform_domains) when the gap is exhausted, and ends with the full workflow through outreach_add_contacts and outreach_launch_campaign.

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 non-read-only, non-idempotent, non-destructive. Description adds critical context: it sends real LinkedIn invites, requires user confirmation, and requires user's own connected account. This goes beyond annotations by warning about real-world impact and prerequisites.

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

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

Three sentences, each earning its place: what it does, when to use, and critical warnings. Front-loaded with the core action and immediately follows with the most important caveat (real automation, confirm with user).

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 no output schema, the description covers the action, prerequisites, user confirmation requirement, and integration setup. It's complete for the agent to decide and execute safely.

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

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

Schema coverage is 100% and the single parameter campaign_id is well-described in the schema. The description adds context by mentioning where to get the ID (from list or create), but this is minor added value beyond the schema.

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

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

The description clearly states the tool activates a paused Zeekeo campaign to start sending real LinkedIn connection invites, with specific verb and resource. It distinguishes from siblings by noting campaigns are created paused by default and this is the follow-up to zeekeo_create_campaign.

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: after zeekeo_create_campaign, and when not: requires user confirmation and connected Zeekeo account. Provides alternative action (direct user to connect account) and context for real automation.

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 annotations (readOnlyHint false, openWorldHint true), the description warns that this starts REAL LinkedIn automation, explains the conditional follow-up after acceptance, and discloses the prerequisite of a connected user account. 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?

Five sentences, each earning its place: core action and flow, template prerequisite, target selection constraint, real-automation warning, and account-connection dependency. Front-loaded and free of 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?

High-complexity tool (10 params, side-effecting real automation) is well covered with prerequisites, safety warnings, and flow explanation. Minor gaps remain around return values and precise launch timing, but no output schema exists and the description carries the core context effectively.

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

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