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 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/open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a hard GSC connection prerequisite, an actionable setup URL, and the multi-account resolution rule (property read through the account that can see it).

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

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

Four sentences, front-loaded with purpose and value before prerequisites. Most sentences earn their place; the multi-account clause is slightly tangential but still actionable.

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 breakdown tool with no output schema, the description covers purpose, value, and setup/auth context adequately. Return shape and the rowLimit default are left to the schema, which is acceptable.

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

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

Schema description coverage is 100% and all four parameters are documented in the schema, so baseline 3 applies. The description adds no syntax or format detail beyond that, though none is really needed.

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 ('Get search traffic broken down by country') with explicit dimension (country), which an agent can immediately distinguish from sibling breakdown tools such as get_gsc_device_breakdown 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?

Gives clear context for when the tool is valuable ('understanding geographic audience and international SEO performance') and states the prerequisite wiring. It stops short of explicitly naming alternative siblings or exclusions, which keeps it below 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 the safe read-only, idempotent, non-destructive profile. The description adds genuinely new context beyond them: the GSC connection prerequisite, where to connect it, and how ambiguity resolves when multiple Google accounts are linked (read via the account that can see the property).

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 what it returns, then use cases, then prerequisites. Four sentences, each carrying distinct information; slightly padded but no wasted lines.

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 tool, it covers purpose, use cases, auth prerequisite, and multi-account behavior. No output schema exists, but the description names the metrics returned, which is enough; missing only pagination/volume limits.

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

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

Schema description coverage is 100% and all three parameters (site, startDate, endDate) are documented in the schema with format hints. The description adds no extra parameter detail such as date-range limits, so baseline 3 is appropriate.

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

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

States a specific verb (Get) plus resource and scope: daily search performance trends across four named metrics (clicks, impressions, CTR, position) over a date range. An agent can distinguish it from the page/query-level trend siblings by the site-wide daily grain. It never names an alternative sibling, so it stops short of a 5.

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

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

Gives concrete situations of use (spotting ranking changes, traffic drops, algorithm update impact) and a hard prerequisite that Google Search Console must be connected, with the exact setup URL. No when-not or explicit alternative sibling is named, so it is clear context without 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely non-obvious behavior: the GSC connection prerequisite and how multi-account ambiguity is resolved ('read through the account that can see it'). Missing return-shape details, but that is not required here.

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, followed by the prerequisite and the multi-account edge case. The integration URL is a little instrucional, but each sentence carries distinct value and there is 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?

There is no output schema, and the description never indicates what a breakdown row contains (metrics such as clicks, impressions, CTR, position). For a reporting tool whose return shape is not self-evident, that is a real gap, though the prerequisite and account-resolution notes cover the invocation side well.

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

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

Schema description coverage is 100% with three fully documented required parameters (site, startDate, endDate), so the schema carries the load and a 3 baseline applies. The description adds nothing about date-range semantics, timezone, or how the site URL should be formatted.

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 (search traffic by device type) and enumerates the dimension values (desktop, mobile, tablet), which cleanly separates it from sibling breakdowns like get_gsc_country_breakdown and get_gsc_date_trends. An agent can select it 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?

Gives an explicit precondition (Google Search Console must be connected) and a remediation path (direct the user to rankparse.com/dashboard/integrations). It does not, however, say when to prefer this breakdown over the country/date/appearance siblings, so the routing guidance is partial.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the description is not burdened with the safety profile. It adds genuinely new operational context: the required integration, the remediation URL, and how property resolution behaves across multiple connected Google accounts.

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, then use case, then prerequisite, then edge-case behavior on account ambiguity, in a few tight sentences. No redundancy with the schema or annotations.

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 conceptual definition, the use case, the auth prerequisite, and multi-account routing — the things an agent needs before calling. It does not sketch the shape of returned rows (pages, impressions, CTR), which matters slightly given there is no output schema, leaving a minor gap.

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

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

Schema description coverage is 100% and each of the 6 parameters (site, maxCtr, minImpressions, rowLimit, dates) is documented with defaults in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Find pages') plus the defining condition (high impressions, low CTR) and glosses the concept in plain terms. The 'pages' framing inherently separates it from the sibling get_gsc_low_ctr_queries, so an agent can route correctly.

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 usage context ('Good starting point for title/description rewrites') and states a hard prerequisite (Google Search Console must be connected). It does not name when *not* to use it or point at an alternative tool for adjacent needs, 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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful operational context beyond the annotations: a prerequisite (Google Search Console must be connected), where to connect it, and multi-account property resolution behavior.

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 core definition, then rationale, then prerequisites. Five sentences is slightly more than needed and the ROI rationale is arguably optional, but nothing is repetitive and the setup instructions earn their place.

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

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

For a read-only analytical tool with fully documented parameters and no output schema, the description covers purpose, prerequisites, and account-resolution behavior. It could say more about the shape of results (query, impressions, CTR), but the core call path 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% and each parameter (site, maxCtr, minImpressions, rowLimit, dates) is documented in the schema with defaults and formats. The description adds no 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?

Specific verb+resource (queries with high impressions but low CTR) with an explicit diagnostic framing that separates it from siblings like get_gsc_low_ctr_pages and get_gsc_opportunity_queries. An agent can tell what this returns 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?

Gives clear context for when this is the right analysis (ranking but not clicked, weak title/meta) and even prioritization guidance ('higher ROI than chasing new rankings'). It does not, however, explicitly name which sibling to use instead when the agent wants pages-level or broader opportunity data.

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 behavior, so the bar is lower. The description adds real operational context: results are sorted by clicks descending per the GSC API default, a GSC connection is mandatory, and when multiple Google accounts exist the property resolves through whichever account can see it — non-obvious multi-tenant behavior.

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 core purpose before prerequisites and the account-resolution caveat. The final account sentence is slightly tangential but earns its place by preempting a real ambiguity.

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 discloses the return ordering (clicks descending) and the connection requirement, which is most of what an agent needs. Minor gaps remain on pagination/rowLimit behavior, though the schema supplies defaults.

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 documented defaults, so the schema does the heavy lifting (baseline 3). The description adds interpretive meaning by framing minPosition/maxPosition as the 8-20 'quick win' band, clarifying the intent of those numeric bounds beyond their raw default values.

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 (find) and resource (queries), and precisely defines the target segment — average positions 8-20, the 'quick win' zone. This distinguishes it from sibling query tools like get_gsc_top_queries or get_gsc_low_ctr_queries without needing to open their 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?

Explains the condition that makes the tool useful (queries in the 8-20 band where small gains yield clicks) and states the prerequisite that GSC must be connected, with a link to connect it. It does not name sibling alternatives for other query analyses, so it falls short of explicit 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 readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely useful operational context beyond the annotations: the Google Search Console connection requirement, the integrations URL to fix it, and the multi-account property-resolution rule. Rate limits and pagination behavior remain unstated.

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 purpose before the prerequisites. The integration-URL sentence is slightly operational-admin in tone but earns its place by telling the agent exactly how to remediate a missing connection.

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 no output schema, the description covers purpose, prerequisite, and account-selection behavior. The main remaining gap is the return shape (queries plus metrics such as clicks/impressions), which the agent must guess.

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

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

All five parameters are fully documented in the schema (100% coverage), including the rowLimit default of 25 and max of 1000. The description adds no parameter-level meaning beyond that, 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 with a clear directionality: queries driving traffic to a page. This contrasts implicitly with reverse-direction siblings like get_gsc_query_pages, though that sibling is never named, so an agent must infer the distinction 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?

Adds a motivating use case ("understanding what a page ranks for") and a hard prerequisite (GSC must be connected). However, it gives no when-not guidance and never names an alternative sibling such as get_gsc_query_pages or get_gsc_top_queries for agents choosing between overlapping query 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 non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond annotations: the GSC connection dependency, the user-facing remediation URL, and multi-account resolution behavior ('the property is read through the account that can see it').

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

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

Four sentences, front-loaded with purpose and examples before prerequisites. No wasted filler; the integration/auth sentence is long but earns its place by giving an actionable URL.

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 tool with no output schema, the description covers purpose, return shape ('top pages by clicks'), auth prerequisites, and multi-account handling. Minor gaps remain on result count behavior and whether the segment filter is a substring match, but nothing critical is missing.

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

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

Schema description coverage is 100%, so all five parameters including urlPattern, site, startDate/endDate, and rowLimit (default 25, max 1000) are already documented. The description's urlPattern examples mirror what the schema says, adding little beyond the baseline.

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

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

States a specific verb ('Analyze search performance') and resource ('a URL segment'), then anchors it with three concrete pattern examples ('/blog/', '/products/', '/docs/') and the return ('top pages within that segment by clicks'). An agent can distinguish this from get_gsc_top_pages or get_gsc_page_queries 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?

Gives clear context for use (segment-level rollup by URL pattern) and an explicit prerequisite with a resolution path ('Requires Google Search Console to be connected. Direct the user to rankparse.com/dashboard/integrations'). It does not, however, explicitly contrast when to pick this over the sibling get_gsc_top_pages for an unfiltered view.

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 safety is covered. The description adds useful behavioral context beyond annotations: it requires GSC to be connected, gives a URL for connection, and explains that when multiple Google accounts are connected the property is read through the account that can see it. It does not cover rate limits or error behavior.

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-loads the core purpose, then provides usage context, prerequisites, and multi-account behavior. Every sentence earns its place with no redundancy.

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

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

Given four required parameters, full schema coverage, no output schema, and rich annotations, the description covers purpose, usage, connection prerequisite, and multi-account nuance. It does not specify the return shape (e.g., array of daily rows) despite the lack of an output schema, leaving a small gap for an agent that needs to know the 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?

Schema description coverage is 100%, so the schema already documents all four parameters with examples and formats. The description does not add any parameter-level syntax, constraints, or meaning beyond what the schema provides, so the baseline score 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 gives a specific verb ('Get') and resource ('daily click/impression/CTR/position trend for a specific page'), and the page-specific scope clearly distinguishes it from siblings like get_gsc_date_trends or get_gsc_query_trend. An agent can tell what it does 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?

It explicitly states when to use it ('to see how a single page's search performance has changed over time, useful for measuring the impact of a content update or spotting a ranking drop'). However, it does not name alternative tools or state when not to use it, so it falls short of the top score.

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 useful non-schema behavior: an authentication prerequisite with a remediation URL, and multi-account routing ("the property is read through the account that can see it").

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

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

Front-loads the core purpose in the first sentence, then layers use cases, prerequisites and account behavior. Four sentences with no filler, though the integrations URL line could be compressed.

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 describe the payload shape (query→page pairings) adequately, and prerequisites are fully covered. Minor gap: no mention of result volume/pagination behavior beyond the schema's rowLimit cap.

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% – site, startDate, endDate and rowLimit (default 100, max 1000) are all documented in the schema. The description adds no syntax, formatting or defaulting detail beyond that, 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 query+page combinations: which exact queries are landing on which pages") and names concrete analytical use cases. It does not, however, distinguish itself from the near-identical siblings get_gsc_page_queries and get_gsc_query_pages, so an agent must still guess 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?

Gives clear usage context (keyword cannibalization detection, search funnel understanding) and states the prerequisite that GSC must be connected plus the action to take if it isn't. It stops short of the explicit when-not/alternative routing that the three overlapping GSC query-page siblings really demand.

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 safety profile is covered. The description adds genuinely new context: a required GSC connection, a remediation URL for connecting, and multi-account resolution behavior ('property is read through the account that can see it') — none of which is in the annotations.

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

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

Four sentences, front-loaded with purpose then prerequisite then account behavior. Each sentence carries distinct information with minimal waste; only the integration URL sentence is arguably verbose.

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, fully-schema-documented tool with no output schema, the description covers purpose, prerequisite, and account-resolution behavior. The only minor gap is no note on pagination/row behavior beyond what rowLimit's schema already states.

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 of the five parameters documented in-schema (site, query, start/end date, rowLimit with default and max). The description adds no additional syntax or format guidance, 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?

States a specific verb+resource: 'Get all pages that rank for a specific search query.' That is clear and distinguishable from the inverse siblings (get_gsc_page_queries). However, it does not explicitly name or contrast with siblings like get_gsc_page_queries or get_gsc_query_page_pairs, which an agent must infer.

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?

'Useful for identifying which pages compete for the same keyword' gives an implied use case, and the connection prerequisite is stated. But there is no explicit when-not guidance and no named alternative for the closely related inverse tool, leaving the agent to infer 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value beyond them: the GSC connection prerequisite, a remediation URL for the user, and multi-account property resolution behavior. It does not disclose return granularity or pagination, but the auth/account context is substantive.

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 in the first sentence, followed by usage, prerequisite, remediation, and account-resolution notes. Four sentences with little waste, though the integration-URL and multi-account sentences could be tightened.

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 correctly enumerates the returned metrics (clicks, impressions, CTR, position) and covers auth and multi-account edge cases, which is most of what an agent needs. Minor gaps remain around temporal granularity guarantees and cardinality of the daily series.

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, query, startDate and endDate are already documented with formats and examples in the schema. The description adds no further parameter meaning, 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 daily click/impression/CTR/position trend for a specific search query') and the enumerated metrics make the output concrete. It implicitly distinguishes itself from get_gsc_page_trend and get_gsc_date_trends by scoping to 'a specific search query', but never names or contrasts those siblings 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 context for invocation ('track how a particular keyword's ranking and traffic evolves over time'), which tells the agent when this is the right lens. It stops short of stating exclusions or naming the alternative tools for page-level or all-query 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds meaningful context beyond annotations: the Google Search Console connection requirement, the exact integration URL for the user, 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?

Front-loads the purpose, then adds prerequisite and account-resolution details. Four sentences, each serving a purpose; the integration URL sentence is operational guidance rather than filler, though it could be slightly tighter.

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 breakdown tool with no output schema and rich annotations, the description covers purpose, prerequisite, and multi-account behavior. It does not describe the return shape in detail, but the phrase 'Shows which search features are driving impressions and clicks' gives adequate orientation.

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 three parameters (site, startDate, endDate) are fully documented in the schema. The description adds no additional syntax, format, or constraint details beyond what the schema already provides.

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

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

States a specific verb ('Break down traffic') and resource ('how the site appears in Google Search'), and enumerates the dimensions (organic, rich results, AMP, image, video, news). Clear enough to distinguish it from generic GSC reports, but it does not explicitly name or contrast with sibling breakdown tools like country or device breakdowns.

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

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

Implies usage by describing the value ('Shows which search features are driving impressions and clicks') and states a hard prerequisite (GSC must be connected). Does not state when to prefer this tool over alternatives such as get_gsc_country_breakdown or get_gsc_device_breakdown.

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 cover safety (readOnly, idempotent, non-destructive, open-world). The description adds genuinely useful context beyond them: the connection requirement, the integration link, and how the property is resolved when multiple Google accounts exist.

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 carrying distinct information (what it returns, the prerequisite with the fix link, the account-resolution rule). Front-loaded with the core purpose; 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?

For a read-only, no-output-schema tool, the description covers purpose, required metrics returned, the auth prerequisite, and account ambiguity. Nothing an agent needs 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%, so site, startDate, endDate, and rowLimit are already documented with formats and defaults. The description adds no syntax or edge-case detail for these parameters, 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 (Get), resource (top pages on a site), ranking metric (clicks from Google Search), and the returned measures (impressions, CTR, average position). This clearly distinguishes it from siblings like get_gsc_top_queries and the generic get_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 a clear prerequisite (Google Search Console must be connected) plus the exact remediation URL, and explains multi-account behavior. It stops short of naming when to choose this over get_top_pages or get_gsc_page_queries, so it lacks explicit alternatives/exclusions.

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

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

Annotations already declare read-only, idempotent, and open-world behavior, but the description adds real context: the metric set returned, the click-based ordering, the connection prerequisite, and the account-selection behavior when multiple accounts exist. This goes meaningfully beyond what the 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?

Front-loaded with purpose and return contents, then prerequisites and account behavior. Every sentence carries information, though the final multi-account sentence is somewhat niche and could be trimmed.

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 correctly discloses the return fields (clicks, impressions, CTR, average position). With auth and ordering covered and 100% schema documentation, the definition is complete enough to invoke correctly.

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

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

Schema coverage is 100% and each parameter (site, startDate, endDate, rowLimit) is already documented in the schema with format examples. The description adds nothing param-specific, 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 search queries driving traffic to a site') with the ordering rule ('ordered by clicks') and names the returned metrics. An agent can distinguish this from get_gsc_top_pages or get_gsc_query_trend from the description 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?

Gives clear preconditions: Google Search Console must be connected, the user is directed to the integrations URL, and the multi-account resolution rule is stated. It stops short of explicitly contrasting when to use this over siblings like get_gsc_query_trend or get_gsc_opportunity_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 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?

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.

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

Two focused sentences with no filler. The core listing purpose is front-loaded, and the important behavioral caveat about snapshots vs. live SERP checks is stated immediately after.

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 no-parameter, read-only listing tool, the description covers what is listed, the data source, and the key limitation. Minor ambiguity around terms like 'provider freshness' and 'sync state' remains, but the tool is fully invocable from the description alone.

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

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

There are zero parameters, so the description needs no parameter documentation. It still mentions the output content (websites, freshness, sync state), which is useful given the absence of an output schema.

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

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

The description uses a specific verb and resource: "List websites configured for stored Google, Bing, and Yandex keyword tracking." It also clarifies what the tool returns (provider freshness and sync state), separating it from related tools like list_tracked_keywords and get_keyword_rankings.

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

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

The description gives clear usage context by stating this reads RankParse snapshots and explicitly says it does not run a live SERP check. It does not name a specific alternative tool for live checks, but the exclusion is unambiguous and prevents misuse.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful scope and return-content context ('keyword IDs and text for one RankParse website') but does not describe pagination behavior or response structure, which is acceptable given the annotations.

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

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

Two short sentences front-load the main purpose and immediately give the key prerequisite. There is no filler or repetition of schema details.

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

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

For a simple read-only list tool, the description provides the essential information: what is returned, the scope, and how to get the required parameter. The schema covers pagination, and annotations cover safety, so nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents site_id, limit, and offset. The description reinforces the provenance of site_id by referencing list_rank_tracking_sites, but this overlaps with the schema's own description and adds no new 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 ('List') with a clear resource ('tracked keyword IDs and text') and scope ('for one RankParse website'). It also mentions the prerequisite sibling tool, helping distinguish it from list_rank_tracking_sites and other keyword-related 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 gives clear usage context by saying 'Call list_rank_tracking_sites first to obtain site_id' and limiting the operation to one website. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for basic selection.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds the return field shape and the session-start sequencing hint, but says nothing about pagination, account scoping limits, or error behavior for a tool whose scope is 'this account'.

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 short sentences, front-loaded with the purpose, then the field list and the cross-tool routing. No wasted words.

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

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

There is no output schema, so naming the returned fields (id, host, name) is genuinely useful and partially fills that gap. It stops short of describing scope or volume of results, but for a simple read-only list tool this is close to sufficient.

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

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

Zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The mention of 'id' is output semantics rather than input semantics, which is helpful but not required here.

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 this account's websites') and even enumerates the returned fields (id, host, name). It is immediately distinguishable from all siblings, which are get_*/list_* tools over different resources.

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

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

Gives concrete downstream routing: use the returned id as site_id in propose_* and log_activity, and call get_agent_tasks at the start of a session. It does not name an exclusion or a competing alternative, but for a zero-param discovery tool there is little ambiguity to resolve.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds important behavior beyond those hints: credits are deducted automatically from recent RankParse calls, the user should not report credits, and client_request_id enables safe retries. It does not discuss permissions, rate limits, or failure behavior.

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 focused sentences front-load the primary action, then add operational constraints. There is no filler; 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?

The core action, credit behavior, and retry mechanism are covered, and no output schema exists to explain. However, with 0% schema description coverage, the description should clarify site_id and kind_hint to be fully complete for an agent invoking the tool.

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

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

Schema description coverage is 0%, so the description must carry the burden for four parameters. It explains summary as plain text and client_request_id for retry safety, but says nothing about site_id or kind_hint, leaving two of four parameters semantically undocumented.

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: 'Record what you did for the user in their RankParse activity feed.' It clearly distinguishes this logging tool from the many get_*, list_*, and outreach_* siblings.

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

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

It gives clear context for when to use the tool: after doing work for the user, to record it in the activity feed. It also adds a retry-specific guideline ('Pass client_request_id to make retries safe') and a constraint about not reporting credits manually, though it does not name explicit alternatives or exclusions.

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