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 this is a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds genuinely useful context: the summary is user-visible in RankParse and is length-capped. It does not, however, disclose whether the task must be in a particular state, whether completion is reversible, or what happens on repeat calls (relevant given idempotentHint=false).

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

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

One efficient sentence with no padding, front-loading the action and payload. It is slightly dense in that the user-visibility note is tacked on, but every clause carries 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 simple two-parameter mutation with no output schema, the definition covers the essentials: what it does, what to put in the summary, and where the summary surfaces. It is incomplete on task-state prerequisites and the absence of a return description, though with no output schema that gap is minor.

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 carry the burden. It does explain the summary's content intent and mentions the 2000-character limit (duplicating the schema maxLength), but it adds nothing about task_id beyond the word 'queued task' — the '^tsk_' format and whether it must be an assigned task are left entirely to the schema.

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

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

Specific verb+resource: 'Mark a queued task done' with the payload described (a plain-text summary of findings and actions). It is clearly distinguishable from the read-oriented sibling get_agent_tasks.

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?

Usage is implied by 'queued task' and the summary content ('what you found and what you did'), but there is no explicit when-to-use guidance, no mention of preconditions (does the task need to be claimed/in-progress first?), and no routing against siblings like get_agent_tasks or log_activity.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds workflow context (work the task, then complete it with a summary) but says nothing about permissions, pagination, volume of tasks, or what an empty queue looks like. With annotations carrying the safety burden, 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?

Three short sentences, each earning its place: the first defines the resource, the second gives the session-start trigger, the third gives the completion workflow. Nothing is padded and the core purpose 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?

No output schema exists, so the description would ideally hint at what a task record contains (id, description, status) and how parameters affect the result set. It covers the caller workflow well but leaves both parameter usage and return shape unspecified, which is a notable gap for a session-initialization tool.

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

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

Schema description coverage is 0% and the description never mentions either parameter. The 'status' enum (open/claimed/all) and 'site_id' filter are left entirely unexplained, so an agent cannot tell from the definition whether it should pass a status to see claimed work or a site_id to scope results. For a tool with two parameters at zero coverage, the description should compensate and does not.

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

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

States a specific verb (get) and resource (tasks the user queued for you) with the product context (RankParse). It is immediately distinguishable from the many read siblings, and it names its natural sibling complete_agent_task, so the agent knows this is the queue-reading counterpart to task completion.

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?

Gives an explicit trigger ('At the start of any RankParse session, call get_agent_tasks') and an explicit follow-up ('Work on a task, then call complete_agent_task with a short plain-text summary'). This is a full when-to-use plus next-step workflow, not just implied 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 readOnly/idempotent/non-destructive, yet the description adds substantial context: it reads a cached daily background scan rather than fetching live, 'unknown' status means inconclusive rather than failed, optional/info checks are excluded from the score and must not be presented as failures, and the call costs 0 credits. That is exactly the kind of interpretation guidance annotations cannot convey.

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 purpose is front-loaded and nothing is outright wrong, but the body is one enormous run-on sentence with long parenthetical enumerations of crawlers and agent-protocol features that are hard to parse and partly redundant with each other. The content is useful but the structure costs readability.

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?

There is no output schema, so the description carries the full burden of describing return semantics, and it does: per-area scores, overall score being AI-visibility-only, site_health having its own area score, eligible:false with reason codes, and the meaning of status 'unknown'. An agent could call and interpret this correctly with no further information.

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 a single parameter at 100% schema description coverage, the schema already explains site_id and where to source it (list_rank_tracking_sites or list_websites). The description adds no additional parameter-level detail, so the baseline 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?

States a specific verb and resource ('Get the stored AI visibility (agent readiness / AEO) scan') and enumerates exactly what the scan covers, so the agent knows what it will receive. It explicitly distinguishes itself from recheck_ai_visibility and notes the site_health area overlap, which lets it be separated from siblings without opening any schema.

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 names the alternative ('use recheck_ai_visibility to queue one') with the condition that selects it, and gives explicit eligibility prerequisites (verified via GSC/Bing, paid plan Pro/Agency/Lifetime, otherwise eligible:false with reason not_verified or plan_required). It lacks explicit routing against get_site_health and get_schema_markup, which cover overlapping ground, 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 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?

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds crucial return-behavior context absent from annotations and schema: partial=true means timeout/incomplete, null score means unknown rather than zero, credit is refunded, and retry is advised.

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-loading the purpose and then delivering critical response-interpretation details without any wasted words. 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 simple single-parameter lookup tool, the description covers the most important subtle behavior (partial responses and null scores). It falls short on parameter format and does not address when to use this tool versus sibling authority/rank tools, but annotations and the simple schema reduce the overall burden.

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 one parameter with 0% description coverage. The description adds no meaning beyond the schema, such as whether 'domain' should be a root domain, full URL, subdomain, or whether it must exclude protocol or www. It merely repeats the parameter name in passing.

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: 'Get authority score for a domain.' It is clear what the tool does, but it does not distinguish this tool from similar siblings like get_domain_rank or get_domain_overlap, leaving disambiguation to the agent.

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 choose this tool over alternatives. The only conditional guidance is about interpreting a partial response (retry rather than treating as zero), which is response handling, not tool-selection 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, 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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered by structured data. The description earns credit for adding genuinely non-schema context: the required integration, where to route the user to connect it, and how the property is resolved when multiple Google accounts are linked.

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?

Four short sentences, front-loaded with what the tool does before the use case and setup requirement. Every sentence carries information, though the multi-account sentence is a slight detour relative to the core purpose.

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

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

With no output schema, the description tells the agent the metric basis (search traffic by country) and the setup and account-resolution conditions needed to call it successfully. Minor remaining gap: it doesn't hint at the row shape (country plus clicks/impressions) or that rowLimit governs result size, though the schema covers the latter.

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%, including format hints for site/dates, the rowLimit default of 25 with a 1000 cap, and the searchType enum with its discover/googleNews caveat. The description adds no parameter-level meaning beyond that, so the documented 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 first sentence names a specific verb ('Get') and a precise resource with its dimension ('search traffic broken down by country'), which immediately separates it from siblings such as get_gsc_device_breakdown or get_gsc_top_pages that slice the same data by another axis. No further reading of the schema is needed to know what it 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?

It gives concrete use cases ('understanding geographic audience and international SEO performance') plus a hard prerequisite: GSC must be connected, with a URL to send the user to. It doesn't explicitly name alternatives (e.g. the device breakdown sibling) when geo data isn't the goal, which keeps it 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 readOnly/idempotent/non-destructive, so the description is not burdened with safety. It adds genuinely non-schema context: the Google Search Console connection requirement, the dashboard URL to fix it, and the multi-account property-resolution behavior — details the agent could not infer otherwise.

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?

Four sentences, each carrying distinct information: capability, use cases, prerequisite with remediation, and account-resolution semantics. Front-loaded with the capability, though the account-resolution sentence is a lower-priority detail placed last.

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, four-parameter tool with a fully documented schema, the description covers what the schema cannot: authentication prerequisite, connection flow, and multi-account behavior. It omits any mention of data freshness/lag (a known GSC characteristic) or row limits, which would be the remaining 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 100%, including the searchType enum and its discover/googleNews caveat, so the schema does the heavy lifting. The description adds no parameter-level meaning (e.g., date-range limits or default window), so baseline 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?

States a specific verb+resource+scope: daily search performance trends (clicks, impressions, CTR, position) over a date range. This is clearly distinguishable from siblings like get_gsc_query_trend or get_gsc_page_trend, which are entity-specific, while this one is account/property-wide per day.

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 concrete use cases (spotting ranking changes, traffic drops, algorithm update impact) plus a hard prerequisite and remediation link. It stops short of naming alternatives such as get_gsc_page_trend or get_gsc_query_trend for drilling into a specific page or query, so routing is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful context beyond them: the connection requirement, the exact URL to resolve it, and the multi-account property-resolution behavior. It stops short of describing pagination or result shape, but for a read-only tool with annotations this is solid added value.

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

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

Three sentences, front-loaded with the core purpose, then the prerequisite and edge-case behavior. No wasted phrasing; each sentence carries distinct information, though the connection instructions could be trimmed slightly.

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 analytics tool with no output schema and full schema parameter coverage, the description covers the essential prerequisites and access nuances an agent needs. The device dimension is named and the connection dependency is handled, so nothing critical to correct invocation is missing.

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

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

Schema coverage is 100%, so site, startDate, endDate, and searchType are already fully documented in the input schema. The description adds no syntax or format detail beyond the schema, so baseline 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?

States a specific verb ('Get search traffic') and resource with the breakdown dimension (device type: desktop, mobile, tablet) made explicit. An agent can distinguish it from the many other get_gsc_* breakdowns because the dimension is named, though no sibling is called out by name.

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 a prerequisite (GSC must be connected) and how to fulfill it (direct user to rankparse.com/dashboard/integrations), which is real usage guidance. However, it gives no guidance on when to choose this device breakdown over the country/date-trend/page breakdown siblings, leaving that inference to the agent.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuinely non-obvious context: the GSC integration prerequisite, a concrete remediation URL, and how the property is resolved when multiple Google accounts are connected. It doesn't cover result size or what happens when no pages match, but the account-resolution and auth details are the harder-won information.

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

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

Four sentences, front-loaded with the purpose before prerequisites, and each sentence carries distinct information (concept, use case, auth prerequisite, multi-account behavior). The second clause is mildly redundant with the first, but it aids comprehension rather than padding.

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

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

For a 7-parameter read-only analytics query with a fully documented schema, the description covers what an agent needs to decide and call: what it returns conceptually, the integration prerequisite, and account-resolution behavior. No output schema exists, so some detail on the returned page rows is missing, but nothing blocking remains.

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 every parameter (site, date range, maxCtr, minImpressions, rowLimit, searchType) is already documented with defaults and formats. The description reinforces the semantics of the impression/CTR pair conceptually but adds no threshold values, syntax, or edge-case guidance beyond the schema. Baseline 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?

States a specific verb and resource ("Find pages") plus the exact filter concept: high impressions, low CTR. The plain-language gloss ("Google is showing frequently but users aren't clicking") makes the heuristic unambiguous. It does not name the closely related sibling get_gsc_low_ctr_queries, so the page-vs-query distinction rests on the tool name alone.

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?

"Good starting point for title/description rewrites" gives a concrete when-to-use scenario tied to a real workflow. It stops short of exclusions or naming alternatives such as get_gsc_low_ctr_queries or get_gsc_opportunity_queries, so an agent must infer which granularity to pick.

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 read-only, idempotent, non-destructive, open-world behavior. The description adds genuinely non-structured operational context: GSC must be connected, where to send the user to connect it, and how multi-account property resolution works.

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?

Four short sentences, front-loaded with what the tool finds and why it matters; each sentence contributes either interpretation or setup guidance. No repetition of schema or annotation 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?

Covers the key non-schema prerequisites (connection, integration URL, account selection) for a read-only tool with a fully described schema. Since there is no output schema, a brief note on what a row contains would have completed it.

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

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

Schema description coverage is 100%, including defaults for maxCtr, minImpressions, and rowLimit, so the schema carries parameter semantics. The description adds no threshold detail or format hints beyond the schema, so baseline 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?

States a specific verb and resource ('Find search queries with high impressions but low CTR') and explains the interpretation (ranking but not clicked). It implicitly separates itself from get_gsc_low_ctr_pages by targeting queries rather than pages, but never names that sibling explicitly.

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?

Gives clear diagnostic context ('title or meta description is weak') and a strategic rationale for using it, which implies when it is useful. However, with ~40 GSC siblings including get_gsc_opportunity_queries and get_gsc_low_ctr_pages, it offers no explicit alternative or exclusion guidance.

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

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

Annotations already establish readOnly/idempotent/no-destructive, and the description adds genuinely new context: result ordering (clicks descending per GSC default), the connection prerequisite with a remediation link, and how the property resolves when multiple Google accounts are linked. It stops short of describing the returned fields or the effect of rowLimit beyond what the schema says.

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?

Front-loads the definition and the position window before the operational caveats. Four sentences, each carrying distinct information; the multi-account sentence is edge-case but legitimate operational context.

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, no-output-schema tool, the description should say what columns come back (clicks, impressions, CTR, position). It only mentions sort order. Prerequisites and scope are otherwise well covered, so it is adequate but leaves a notable gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description gives the position bounds (8–20) semantic meaning as a ranking tier, but adds nothing about searchType, rowLimit, or date format beyond the schema's own text.

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

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

States a specific verb and resource ("Find queries") and pins down a distinctive filter — average position 8–20 — which functionally separates it from get_gsc_top_queries and get_gsc_low_ctr_queries. It doesn't name those siblings explicitly, so the differentiation is inferred from the position window rather than stated.

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?

Gives clear preconditions (GSC must be connected, with a URL to fix that) and frames the use case as the "quick win" zone. It never says when NOT to use it or points to an alternative among the many other GSC tools, so the agent must infer the routing.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds meaningful context beyond that: GSC must be connected, the user should be directed to the integrations page, and multi-account property resolution is handled automatically.

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 and then adds prerequisite and account-routing details. It is efficient, though the sentence about understanding what a page ranks for is slightly generic.

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 GSC query tool with fully documented parameters, the description covers the key selection and invocation context: what it returns conceptually, the integration requirement, and multi-account behavior. It does not describe return fields or pagination behavior, but those gaps are relatively minor given the schema coverage and annotations.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including rowLimit defaults and searchType limits. The description adds no parameter-level 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 gives a specific verb and resource: 'Get search queries driving traffic to a specific page.' The page-level scope is clear, but it does not explicitly distinguish this tool from nearby siblings such as get_gsc_query_pages or get_gsc_top_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: 'Useful for understanding what a page ranks for.' It also states the Google Search Console prerequisite, but it does not name alternatives or when-not-to-use conditions.

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 readOnly/idempotent annotations, it discloses two non-obvious behaviors: GSC must be connected (with a URL to send the user to) and multi-account properties resolve through whichever account can see them. That auth/setup context is genuinely additive. It stops short of noting pagination or result-size behavior for the rowLimit parameter.

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?

Four short sentences, front-loaded with what the tool does and what it returns, then prerequisites. No filler, though the multi-account sentence could arguably be deferred to a prerequisites block.

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, yet the description states what comes back (top pages within the segment by clicks), plus the connection requirement, which is the main failure mode. With 100% schema coverage on the six parameters, the remaining gap is only the sibling routing guidance.

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's urlPattern examples largely repeat the schema's own example ('/blog/' or '/products/'), and it adds nothing about rowLimit defaults, date range semantics, or searchType restrictions.

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

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

States a specific verb+resource (analyze search performance for a URL segment) with concrete examples of segment patterns and even the return shape (top pages by clicks). However, it never distinguishes itself from close siblings like get_gsc_top_pages or get_page_performance, which an agent would also consider for page-level 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?

Usage is implied by the segment-filter framing, and connection prerequisites are spelled out, but there is no explicit when-to-use vs when-to-prefer get_gsc_top_pages or get_gsc_page_queries. The agent must infer the routing decision from the sibling names alone.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds real context beyond them: Google Search Console must be connected, the user must be directed to an integration URL, and multi-account property resolution is handled automatically.

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 returned metrics and followed by use cases and the auth prerequisite. No sentence is 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 read-only, non-destructive trend query with full schema coverage and annotations, the description covers what is returned, why to use it, and the critical connection prerequisite. The lack of an output schema is offset by the metric list, though the granularity of the daily series is only implied.

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

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

Schema description coverage is 100%, so the schema already documents site, page, startDate, endDate, and searchType. The description does not add syntax, formatting, or selection guidance beyond what the schema provides.

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

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

States a specific verb and resource: daily click/impression/CTR/position trend for a specific page. The 'single page' framing distinguishes it from site-wide trend siblings like get_gsc_date_trends, but it does not explicitly name competing tools such as get_gsc_query_trend 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?

Gives clear when-to-use context: measuring the impact of a content update or spotting a ranking drop for one page. It stops short of explicit exclusions or naming the alternative tools to use for query-level or site-level trends.

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 openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are de-duplicated so properties visible to multiple connected Google accounts appear once each, plus the connection prerequisite — details absent from 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 short sentences, each load-bearing: what it returns, the prerequisite plus fix, and the multi-account dedup rule. The core capability is front-loaded and nothing is redundant.

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 list tool with no output schema, the description covers the prerequisite, the dedup semantics, and the integration setup path. The one modest gap is that it never hints at the shape of a returned property (name vs. URL), though that is a minor omission for such a simple read.

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 takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument call and adds that the account context is implicit rather than supplied, which is the only thing an agent might wonder about.

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

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

States a specific verb and resource ('List all Google Search Console properties (sites) connected to this account') and adds the scoping qualifier 'connected to this account'. Among the many get_gsc_* siblings, this is clearly the enumeration/prerequisite tool rather than an analytics query, so sibling differentiation is implicit 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?

Explicitly states the prerequisite ('Requires Google Search Console to be connected') and gives the remediation path ('Direct the user to rankparse.com/dashboard/integrations'). It stops short of saying when to prefer this over the get_gsc_sitemaps or get_gsc_top_pages family, but the prerequisite framing makes the intended entry-point role 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the connection prerequisite, the URL to send users to, and that the property is resolved through whichever connected account can see it. It does not cover result ordering or truncation, which a caller might care about.

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?

Four short sentences, front-loaded with the core purpose and the cannibalization use case before the prerequisites. Each sentence carries information; only the dashboard URL sentence is arguably boilerplate, but it is operationally useful.

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 covers what the tool returns conceptually (query+page pairs) and the auth/multi-account setup that would otherwise block a call. Gaps are minor: no hint about pivoting the pairs to detect cannibalization, and no row-limit/pagination expectations beyond the 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 100%, so site, dates, rowLimit and searchType are all documented upstream, including the discover/googleNews query caveat. The description adds nothing about parameters beyond the multi-account property resolution, so baseline 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?

States a specific verb+resource and clarifies scope with 'which exact queries are landing on which pages', which is more precise than the tool name alone. However, it never distinguishes itself from the near-identical siblings get_gsc_query_pages and get_gsc_page_queries, so an agent cannot tell from the description which of the three to pick.

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

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

It gives a concrete use case ('detecting keyword cannibalization') and a prerequisite (GSC must be connected), which implies when to reach for it. But there is no explicit when-not guidance and no mention of the sibling query/page tools that largely overlap, leaving the selection decision ambiguous.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds meaningful context beyond that: Google Search Console must be connected, the integration URL is provided, and multi-account property resolution is explained.

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 action and use case, then adds only relevant prerequisites and account behavior. Every sentence provides useful information without unnecessary 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?

There is no output schema, and the description does not specify what fields are returned for each page. It does, however, cover the essential call context: purpose, connection requirement, and multi-account resolution.

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 all parameters are already documented in the schema. The description does not add parameter-specific format or behavior details beyond what the schema provides, establishing the baseline score.

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

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

The description states a specific verb and resource: 'Get all pages that rank for a specific search query.' It also clarifies the analytical use case, but it does not explicitly distinguish itself from close siblings such as get_gsc_page_queries or get_gsc_query_page_pairs.

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 clear context for when the tool is useful: 'identifying which pages compete for the same keyword.' It also states the connection prerequisite, but gives no explicit exclusions or direct alternative-tool routing.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is lower; the description adds genuinely useful context beyond them: GSC must be connected, where to send the user to connect it, and how the property is resolved when multiple Google accounts exist. It does not cover rate limits or how much history is available, which is the remaining gap.

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

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

Front-loaded with the core purpose, then prerequisites, then the multi-account edge case in order of likely need. Four sentences, all substantive; the multi-account sentence is slightly tangential but prevents a real failure mode.

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 usefully names the returned metrics (clicks, impressions, CTR, position) at daily granularity, and it covers the auth/connection prerequisite. What's missing is any indication of date-range limits or data freshness, which matters for a time-series tool.

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

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

Schema description coverage is 100%, including the searchType enum and its caveat about discover/googleNews not supporting query — the description repeats none of this and adds no parameter-level detail. Baseline 3 applies since the schema carries all parameter meaning.

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

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

States a specific verb and resource with scope: 'daily click/impression/CTR/position trend for a specific search query.' The 'specific search query' framing implicitly separates it from get_gsc_date_trends (site-wide) and get_gsc_page_trend (page-level), but no sibling is named explicitly, so an agent must infer the boundary from names alone.

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?

'Use this to track how a particular keyword's ranking and traffic evolves over time' gives a clear use context, and the connection prerequisite plus the dashboard link tells the agent what must be true before calling. It stops short of stating when to prefer get_gsc_query_pages or get_gsc_query_page_pairs instead.

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 openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context: the auth/connection requirement, the dashboard URL for remediation, and how the property is resolved when multiple Google accounts are connected. It doesn't describe response shape, but that is a minor gap 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?

Front-loads what the tool does, then follows with prerequisite and account-resolution notes; each sentence is functional. Slightly more prose than strictly necessary, but no waste.

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

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

With no output schema, the description does state what comes back (which search features drive impressions and clicks) and covers the setup dependency. It is complete enough for a 4-param read tool, though a hint about row grouping or dimensions would round it out.

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

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

Schema coverage is 100%, so site, startDate, endDate, and the searchType enum are fully documented in the schema, including the caveat about googleNews/discover not supporting query. The description names the appearance dimensions but adds no format or usage detail beyond the schema, so the baseline 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?

States a specific verb and resource: breaking down traffic by how the site appears in Google Search (rich results, AMP, image, video, news). This clearly distinguishes it from sibling breakdowns like get_gsc_device_breakdown and get_gsc_country_breakdown without needing to inspect schemas.

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

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

Provides a concrete prerequisite (Google Search Console must be connected) and tells the agent to direct the user to rankparse.com/dashboard/integrations, plus explains multi-account property resolution. It does not, however, explicitly contrast with alternatives like get_gsc_top_queries or get_gsc_date_trends, so an agent must infer when this breakdown is the right choice.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuine behavioral context beyond that: the auth precondition, the integration URL for remediation, and the multi-account resolution rule ('the property is read through the account that can see it'). It does not cover pagination or return shape, but that is a modest gap.

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

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

Four sentences are efficiently used: the field list is front-loaded, followed by the auth prerequisite, the remediation URL, and the account-resolution edge case. Slightly dense but every sentence carries distinct 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 list tool whose annotations already establish the safety profile, the description covers purpose, returned fields, prerequisites, and a tricky multi-account case. No output schema exists, but the description enumerates the key returned fields, leaving little an agent needs unresolved.

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 a single parameter with 100% schema description coverage ('Property URL e.g. https://example.com'), so the schema already documents it fully. The description only implies the 'property' concept and adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb (List) and resource (submitted sitemaps for a property) and enumerates the returned fields: submission date, last download time, URL counts, errors/warnings. It is clear on its own but never distinguishes itself from the sibling get_sitemap, which could plausibly cover similar ground.

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 communicates a prerequisite (Google Search Console must be connected) and where to connect it, which is real usage context. However, it offers no explicit when-to-use guidance relative to siblings like get_sitemap or the other GSC tools, so selection is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: the integration prerequisite, the setup path, and account-resolution logic when multiple Google accounts exist. It omits result format and whether rowLimit is enforced before or after aggregation.

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 doing distinct work: what it returns, the prerequisite with an actionable URL, and the multi-account edge case. Purpose is front-loaded with no 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 compensates by enumerating the returned metrics (impressions, CTR, average position) and the sort dimension. Combined with the auth prerequisite and account handling, an agent has everything needed to call this correctly and to explain failures.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including defaults and the rowLimit max. The description adds only that results are ordered by clicks, which is ordering rather than a parameter, so baseline 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?

States a specific verb and resource ('Get the top pages on a site') plus the exact metric basis ('by clicks from Google Search') and the returned metrics. This distinguishes it from generic sibling get_top_pages and from get_gsc_top_queries, though no sibling is explicitly named.

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?

Gives clear context for use: Google Search Console must be connected, and it names the exact URL to send users to for setup. It also resolves the multi-account ambiguity (the property is read through whichever account can see it). It does not, however, say when to prefer this over siblings like get_top_pages or get_gsc_page_queries.

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, openWorld, non-destructive), so the bar is lower, and the description adds real value: an auth dependency, a recovery URL for the unconnected case, and multi-account resolution behavior. It stops short of disclosing pagination/rowLimit behavior or rate limits, which keeps it from a 5.

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?

Front-loaded with the core purpose and return metrics, then the prerequisite, then the fallback instruction. Four sentences with little waste, though the final multi-account sentence is a mild tangent that only helps in a narrow edge case.

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 usefully enumerates the returned fields (clicks, impressions, CTR, average position) and covers the auth/setup gap that would otherwise block a call. What's missing is guidance on rowLimit/default sizing and how results are ordered beyond 'by clicks'.

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

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

Schema coverage is 100%, so every parameter is documented in the schema including the searchType enum caveat about discover/googleNews. The description's mention of 'ordered by clicks' and the returned metrics adds a little framing but no parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

The description gives a specific verb and resource ('Get the top search queries driving traffic to a site, ordered by clicks') and names the four metrics returned, so an agent can tell it apart from page-oriented siblings like get_gsc_top_pages. It stops short of explicitly naming the sibling tools that offer overlapping query data (get_gsc_query_trend, get_gsc_page_queries), so it's differentiation-by-implication rather than explicit.

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

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

The description states a prerequisite (Search Console must be connected) and a remediation URL, which is useful operational guidance. But it never says when to prefer this over get_gsc_query_trend, get_gsc_opportunity_queries, or get_gsc_low_ctr_queries, so the agent must infer the choice from the tool names alone.

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

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

Annotations already declare the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantive context beyond that: the connection prerequisite, the onboarding URL to fix a missing connection, and how the property is resolved when multiple Google accounts are linked. That auth/precondition behavior is exactly what annotations cannot convey.

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?

Four tight sentences, front-loaded with the action and then the return payload, prerequisites, and account resolution. Every sentence carries information; the return-field enumeration is justified because no output schema exists, though it is the one part that runs slightly long.

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 compensates by enumerating the returned facets, and it covers the connection precondition and multi-account behavior for a read-only, open-world inspection tool. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema description coverage is 100% with only two parameters, so the schema already documents both 'url' and 'site' with examples. The description adds only an implicit note that the property is read through the account that can see it, which does not clarify parameter syntax or format beyond the schema. Baseline 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?

States a specific verb (Inspect) and resource (a specific URL's indexing status in Google Search), and enumerates the returned facets (indexed status, coverage state, last crawl, mobile usability, rich results). It is clearly distinguishable from the neighboring GSC analytics tools (top pages, queries, sitemaps) which do not perform per-URL inspection.

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?

Gives the operative context: it requires Google Search Console to be connected and points the user to rankparse.com/dashboard/integrations to connect it, plus the multi-account resolution rule. It does not explicitly contrast itself with siblings like get_gsc_properties (which one might need first to know valid site values) or state when not to use it, so it stops short of 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the background job cadence, the meaning of google_inspection_available=false (no verified Google property, so no inspection ever occurs), the result ordering (not-indexed first), and cost. These are exactly the operational traits an agent needs.

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?

Purpose is front-loaded, then return contents, then freshness caveat, then the sibling alternative and cost. Dense and mostly waste-free, though the long parenthetical field list makes it heavier than strictly necessary.

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 carries the burden: it describes per-page fields, verdict values, coverage/robots/indexing states, summary counts, and sort order. Nothing an agent needs to call or interpret the tool is missing.

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

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

Schema description coverage is 100%, so limit, offset, status and site_id are already fully documented with enum values. The description adds only an indirect hint about ordering ('not-indexed pages come first') and no extra syntax or format detail, which is the baseline case.

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

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

States a specific verb and resource (get Google index status of pages tracked on a website's Indexing page) and enumerates the exact fields returned per page plus summary counts. It is clearly distinguishable from sibling inspection tools without opening any schema.

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 routes single-URL live lookups to get_gsc_url_inspection and notes the 0-credit cost and the roughly daily background re-inspection cadence, which tells the agent when data is fresh enough. No explicit 'when not to use this' for other cases (e.g. site-wide crawl data), so not quite 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, 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description adds crucial behavioral context beyond these: it reads stored snapshots (not live), missing days are absent rather than zero, and provider_limited indicates insufficient provider data. This prevents misinterpretation and exceeds what annotations alone convey.

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 thorough but every sentence earns its place. It front-loads the primary purpose, then logically addresses caveats: non-live nature, single-engine requirement, missing data semantics, and provider_limited status. No redundancy or fluff.

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

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

For a read-only tool with 6 parameters (5 required), the description covers all critical nuances: date handling, missing data interpretation, engine-specific behavior, and output row structure (mentions rows and device field). Although no output schema exists, the description gives enough to understand what will be returned.

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 detailed descriptions, so the baseline is 3. However, the description adds meaningful semantics: for 'engine' it reiterates the requirement and single-engine nature; for 'dimension' it explains the difference between 'total' and 'device' rows and clarifies that missing device rows mean 'not synced per-device' rather than no traffic. This goes well 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 verb 'get' and the specific resource: 'stored day-by-day ranking history for one keyword on one search engine over a date range.' It distinguishes itself from siblings by explicitly noting it is not a live SERP check and that engine is required because history is single-engine, referencing get_keyword_rankings for cross-engine comparisons.

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 explicit when-to-use guidance: 'History is inherently single-engine, so engine is required (use get_keyword_rankings first to compare across engines).' It also warns about Bing/Yandex being opt-in and lower-frequency, and explains the meaning of provider_limited, which helps the agent decide when this tool is appropriate.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered; the description then adds substantial behavioral value beyond them: positions are provider-reported averages that must not be blended across engines, a missing engine means 'not connected' rather than zero/bottom rank, Bing/Yandex absence is normal because they are opt-in, and a null position with availability other than 'available' signals a sync/data-quality issue. These caveats prevent a whole class of misinterpretations.

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: purpose first, then the 'not live' constraint, then progressively deeper interpretation caveats. It is long (roughly 170 words), but nearly every sentence carries a distinct trap-prevention fact, so the length is earned. The only structural weakness is uninterrupted dense prose with no scannable breaks or bulleted caveats.

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 ably pre-explains the response's most dangerous fields — enabled_engines for connectivity and availability for sync/data-quality state — plus the current-vs-previous period semantics. Pagination and defaults are left to the schema, which fully covers them. The absence of any sketch of the overall response shape keeps it just short of a 5.

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 of 3 applies; the schema already documents all six parameters, including the engine parameter's default behavior and its 'leave unset unless you need one engine only' guidance. The description's caveats concern response interpretation (enabled_engines, availability) rather than parameter meaning, so it adds no parameter-level detail — acceptable at baseline but no higher.

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 opening clause names a specific verb and resource — "Get stored ranking summaries (current vs previous period) for a website's tracked keywords across Google, Bing, and Yandex" — and adds concrete scope via the engine list. It further distinguishes itself from live-check tools with an explicit "it is not a live SERP check" disclaimer and from history-style tools by framing the data as snapshot summaries over a comparison window.

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: this reads schedule-synced RankParse snapshots rather than live SERP data, which tells an agent when the tool is and is not appropriate. It stops short of a 5 because it never names the natural sibling alternative (get_keyword_rank_history) for historical trend needs; the only exclusion expressed is 'not a live SERP check' without pointing to the alternative 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 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: digests are opt-in and default off, delivery is Sunday at 18:00 UTC when meaningful changes exist. This enriches the agent's understanding beyond the annotations without 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 with no filler. The main purpose is front-loaded, followed by specific details of the returned configuration and delivery schedule. Every sentence adds value.

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

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

For a single-parameter getter with no output schema, the description fully explains what the response contains (enabled state, threshold, email override) and adds delivery timing context. Nothing an agent needs to correctly call and interpret the result is missing.

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

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

The schema description coverage is 100% and the site_id parameter is already well-documented (source from list_rank_tracking_sites). The description does not add extra semantics for the parameter, but the schema fully covers it, 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 tool retrieves rank-change alert configuration for a RankParse website, specifying the exact fields returned (digest enablement, threshold, email override). This distinguishes it from sibling tools like update_rank_alert_settings and list_rank_change_alerts, 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 implies its usage as a read operation for current settings, and the sibling list includes an update counterpart, but it does not explicitly say when to use it vs alternatives. It provides clear context of what it returns, so an agent can infer when it's appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, 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 cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuine behavioral context beyond those annotations: it explains that the tool returns every entity, handles @graph nesting, and reports malformed blocks. No contradiction exists between the description and annotations.

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

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

The description is a single, information-dense sentence that front-loads the primary action and resource, then adds valuable output details after a colon. Every phrase contributes meaning, with no repetition of structured fields or unnecessary 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 one-parameter, read-only tool with no output schema, the description explains the input source and the expected output contents well: entities, types, nested @graph structures, and malformed blocks. Minor gaps such as URL formatting or error handling are present, but they are not critical given the tool's simplicity and the supporting annotations.

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

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

Schema description coverage is 0%, so the description must compensate for explaining the url parameter. It only says 'from a URL', which adds little beyond what the parameter name already implies. It does not mention URL format, whether the URL should be absolute/encoded, or any other constraints, so the semantic contribution is minimal.

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, 'Extract', and names the exact resource: schema.org JSON-LD structured data from a URL. It goes further by specifying what is included—every entity, entities nested in @graph, types, and malformed blocks—making its purpose clear and distinguishable from sibling SEO analysis 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 use case is implied: use this tool when you need JSON-LD schema markup from a given URL. The title 'Technical SEO: Schema Markup' reinforces the context. However, the description does not explicitly state when to prefer this tool over siblings or provide any exclusion criteria, so routing relies mostly on inference.

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

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description goes beyond them by explaining that failed/partly failed proposals carry an error_code and spelling out three concrete codes with their operational meaning (nothing_to_send, payload_changed_since_approval, approver_lost_permission), which materially shapes how an agent reacts.

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?

Front-loaded with the purpose and status list, then the usage cue, then error semantics. Every sentence carries information, though the error_code enumeration is on the long side relative to a simple list 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?

With no output schema, the description usefully discloses one important return field (error_code on failures), which an agent would otherwise not know to look for. The remaining gap is pagination/limit behavior and site_id scoping, which are relevant for a list endpoint.

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 carry the parameter burden, but it only touches the status dimension and does so incompletely (listing 6 of the 10 enum values actually available, omitting executing, partially_succeeded, superseded and cancelled). Neither limit nor site_id is mentioned at all, leaving two of three parameters undocumented anywhere.

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

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

States a specific verb (List) and resource (proposed actions) plus the status dimension, which cleanly distinguishes it from the sibling propose_* write tools. An agent can identify this as the read-side counterpart of the proposal workflow without opening the schema.

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?

"Use it to see what the user approved or skipped" gives a clear when-to-use context, and the error_code guidance implies a follow-up workflow (re-propose, or tell the user). However, no explicit alternatives or when-not-to-use conditions are named, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context beyond that: it never runs a live check, absence of events means no significant moves, and provider-limited or pending engines generate nothing rather than false alerts. This prevents common misinterpretations and fully complements the annotations. No contradiction exists.

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 and then adds dense, relevant caveats. The parenthetical event examples justify their length, and there is no filler or tautology. 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?

With no output schema present, the description compensates by specifying result semantics: no events = no significant moves, provider-limited engines produce nothing, and events exist only when alerts are enabled. It also names the related settings tool, giving the agent enough context to invoke correctly and interpret results.

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

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

Schema description coverage is 100%, so the schema already documents site_id, limit, and offset. The description adds only the conceptual 'one RankParse website' scope and doesn't repeat parameter syntax. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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: 'List recent rank-change alert events for one RankParse website,' and enumerates what counts as an alert (top 3/top 10 entries/exits, threshold moves, new/lost rankings). This clearly separates it from sibling tools like get_rank_alert_settings or get_keyword_rank_history by focusing on recorded alert events rather than settings or raw ranking history.

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

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

It explicitly says the tool 'Reads recorded events, never runs a live check,' and that 'a keyword with no events simply had no significant moves,' giving the caller a concrete interpretation of an empty result. It also routes to related setup via 'see get_rank_alert_settings' and explains when events exist. It doesn't enumerate all alternative tools explicitly, but the context is strong.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: it reads RankParse snapshots rather than performing live SERP queries, which is important for an agent setting expectations about data freshness.

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