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

With no annotations provided, the description carries the transparency burden. It does say 'Fetch', which correctly signals a read-only operation, and 'single target' clarifies the input scope. However, it does not disclose the shape of returned backlink records, pagination behavior, or the 'per_domain' caveat that results may exceed 100 records.

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

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

The description is a single, well-organized sentence that front-loads the action and resource, then enumerates the filter dimensions in a skimmable list, and ends with the exact endpoint. Every element earns its place and there is no redundant 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 tool with 17 parameters and no output schema, the one-line overview is useful but not fully complete. The schema documents all parameters, but the description does not describe the expected result structure, pagination semantics, or behavior when optional filters are omitted. It is adequate for invocation but relies heavily on the schema and agent inference.

Complex tools with many parameters or behaviors need more documentation. 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 parameters are already well documented with enums, defaults, ranges, and meanings. The description adds only a high-level grouping of filters (rank, URL/anchor, nofollow) without providing syntax or interaction details. Baseline 3 is appropriate because the schema carries the semantic weight.

Input schemas describe structure but not intent. Descriptions should explain 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 names the exact operation and resource: 'Fetch backlinks pointing to a single target'. It also lists the distinguishing capabilities (sorting, limits, rank filters, URL/anchor filters, nofollow filter), which clearly separates it from sibling aggregation tools like backlinksSummary or backlinksRefdomains. The endpoint reference 'v1/backlinks/all' removes ambiguity about which API function is being invoked.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 feature list implies this is the raw backlinks endpoint, and 'single target' gives some scope context. However, the description never names sibling alternatives or states when not to use it, so an agent must infer the distinction from the tool name and sibling list rather than from explicit 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?

No annotations are provided, so the description must carry the full burden of disclosing behavior. It does indicate a read-only 'Fetch' operation and scopes the request to a single target, but it does not mention authentication expectations, how results are aggregated or grouped, whether pagination exists beyond the limit parameter, or what response shape to expect. These are material gaps for an API 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 that names the action, resource, and key controls without unnecessary fluff. The parenthetical endpoint reference is mildly redundant with the tool name but still useful for direct API mapping, so the length and structure are appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 five parameters, no annotations, no output schema, and several similar sibling tools. The description explains the core purpose but does not clarify return values, grouping behavior, or how it differs from other backlinks* tools, leaving the definition incomplete for reliable selection and 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%, with all parameters and defaults documented, so the baseline is 3. The description adds little beyond what the schema already provides, though it does reinforce the 'single target' concept and the presence of sorting and limit controls.

Input schemas describe structure but not intent. Descriptions should explain 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 identifies the operation ('Fetch') and the resource ('anchor texts of backlinks pointing to a single target'), making its purpose immediately understandable. However, it does not explicitly distinguish itself from sibling tools like backlinksAll or backlinksRefdomains, 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?

The description implies the tool is used when anchor-text data for a backlink target is needed, and it notes sorting and limit controls. It does not mention alternatives, exclusions, or comparative conditions, leaving the when-to-use decision somewhat 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Fetch authority metrics' which conveys a read operation, but does not disclose what metrics are included, whether the data is live or cached, or any response structure. The endpoint path in parentheses adds no 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, efficient sentence with the core action front-loaded. It includes useful endpoint information in parentheses without any 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?

The description is insufficient for an agent to fully contextualize the tool: it lacks return value details, usage guidance relative to siblings, and clarity on what 'authority metrics' encompasses. Given the lack of output schema and annotations, this one-liner leaves too much unsaid.

Complex tools with many parameters or behaviors need more documentation. 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 both target and output parameters already described in the schema. The description adds no additional parameter semantics beyond what the schema provides, 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?

The description clearly states the tool fetches authority metrics for a target, with the target types explicitly listed (domain, host, or URL). This is a specific verb-resource pair, though it does not explicitly distinguish itself from siblings like domainOverview or backlinksSummary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the many sibling tools. The description only states what the tool does, not when it should be preferred over alternatives like domainOverview or backlinksSummary.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the basic operation and mentions sorting/limit controls. It does not say that results are sorted descending, what fields are returned, whether pagination exists, or what the response looks like, leaving the agent to infer behavior from 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?

The description is a single front-loaded sentence that states the action, resource, key controls, and endpoint without filler. It earns its place and stays compact despite the number of parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 schema is rich enough to make the tool minimally invocable, but with no output schema and no annotations, the description should have provided more operational context such as result shape or how this differs from sibling backlink tools. It is adequate for a simple list operation but has clear gaps for an agent deciding among 23 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 100%: target, mode, limit, output, and order_by all have their own descriptions with enums and defaults. The description's 'sorting and limit controls' merely echoes what the schema already documents, adding no new parameter-level 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?

The description names a specific verb ('Fetch') and resource ('site pages that have backlinks'), which clearly identifies the operation as a list of indexed pages rather than raw backlink records. The endpoint path adds confirmation. It does not explicitly distinguish itself from siblings like backlinksAll or backlinksSummary, but the word 'pages' gives enough semantic separation for a 4.

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

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

No guidance is given about when to use this tool instead of backlinksAll, backlinksRefdomains, backlinksAnchors, or other siblings. The phrase 'with sorting and limit controls' describes features but does not state intended use cases or 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?

With no annotations present, the description carries the full burden of behavioral disclosure. 'Fetch' implies a read operation and 'limit controls' hints at pagination, but the description does not state return format, rate limits, authentication needs, or how sorting behavior manifests in the response.

Agents need to know what a tool does to the 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 naming the action, resource, target requirement, and available controls. There is no filler or redundant elaboration, and the endpoint suffix is compact useful context.

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

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

For a straightforward read-only tool with a fully described input schema, the description covers the essentials. However, there is no output schema and no annotations, so the response shape, error behavior, and when-to-use boundaries remain unstated, making the description adequate but not complete.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, their defaults, enums, and constraints. The description only adds the generic phrase 'sorting and limit controls,' which does not meaningfully supplement the schema but does not need to given full coverage.

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

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

The description uses the specific verb 'Fetch' and clearly identifies the resource ('referring domains') and the target scope, making the core function understandable. It does not explicitly distinguish this from sibling tools like backlinksAll or backlinksAuthority, so it falls just 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?

No guidance is provided about when to use this tool versus alternatives such as backlinksAll, backlinksSummary, or backlinksAuthority. The only implied use case is needing referring-domain data, but there are no exclusions, prerequisites, or contextual cues.

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?

With no annotations provided, the description carries the full burden. It discloses a read-only fetch action and the notable behavior of optionally building an analysis prompt, which adds value. However, it does not describe output shape, pagination, rate limits, or any other operational constraints, so the disclosure remains incomplete.

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

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

The description is compact and front-loaded with the primary action. The second sentence adds the optional analysis-prompt behavior and endpoint context. The parenthetical endpoint is mildly redundant with the tool name, but it does not waste words overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no annotations and no output schema, the description should explain what 'extended backlink statistics' actually include and how the response is returned. It also fails to differentiate the tool from the many sibling backlink tools, making tool selection unnecessarily difficult for an agent.

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

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

Schema description coverage is 100%, so the schema already documents mode, output, and target thoroughly. The description adds some context by noting multiple targets and domain-vs-competitor comparison, but it does not materially deepen parameter understanding beyond the schema, 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 uses a clear verb and resource: 'Fetch extended backlink statistics for one or multiple targets.' It also adds the distinguishing capability of optionally building an analysis prompt comparing a domain against a competitor. It stops short of a 5 because 'extended backlink statistics' is vague relative to sibling tools like backlinksAuthority or backlinksRefdomains.

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

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

There is no explicit guidance on when to use this tool versus the many sibling backlink tools. The mention of comparing 'your domain vs a competitor for a given keyword' implies a use case, but no alternatives are named and no exclusion criteria are given, leaving an agent to guess.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It implies read-only behavior via 'Fetch' but does not mention pagination, date-range handling, dependence on the source country code, or what the response contains. Not misleading, but very thin.

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

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

The description is extremely short and has no filler words; every token contributes. However, the brevity sacrifices valuable context, making it effectively minimal rather than 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?

Given no annotations, no output schema, and a moderate six-parameter schema, the description is too sparse to be contextually complete. It fails to explain what 'domain ads' are, the role of source and date range, or how this tool differs from domainAdsByKeyword, all of which matter for correct selection and 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 input schema has 100% parameter description coverage, so the schema already documents all parameter meanings. The description's 'by domain' merely maps to the domain parameter and adds no additional semantic detail beyond the schema.

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

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

The description states a specific action ('Fetch') and resource ('domain ads') scoped by domain, with the endpoint reference adding a small amount of clarity. It is not a tautology because it adds the verb 'Fetch', but it largely mirrors the tool name and does not elaborate on what 'domain ads' means.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the closely related domainAdsByKeyword or other siblings. There are no exclusions, prerequisites, or specific use cases mentioned, so an agent has to infer suitability entirely from the name and schema.

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?

There are no annotations, so the description must carry behavioral disclosure. It does not mention pagination (page/limit), date-range constraints (from/to), the required country source, or the shape of the returned data; it only says 'fetch'.

Agents need to know what a tool does to the 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 filler. The endpoint parenthetical adds a small amount of useful context without bloating the text.

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

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

For a tool with six parameters, no annotations, and no output schema, this description is too minimal to fully orient an agent. It lacks usage context, behavioral details, and any indication of what a result contains, though the schema does document parameters.

Complex tools with many parameters or behaviors need more documentation. 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 adds no parameter-level meaning beyond the schema, but it does not need to, as each property already has a descriptive text.

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

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

The description states a clear action ('Fetch'), resource ('domain ads'), and selection criterion ('by keyword'), plus the endpoint. It does not explicitly contrast with sibling domainAdsByDomain, though the keyword qualifier makes the purpose 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?

No guidance is provided about when to use this tool versus alternatives such as domainAdsByDomain or domainKeywords. The description only states the operation, leaving the agent to infer appropriate 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states what data is fetched and does not explain return structure, limitations, regional behavior, or any side effects. This is minimal but not misleading.

Agents need to know what a tool does to the 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 filler. It wastes no words and immediately identifies the operation and resource.

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

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

Without an output schema or annotations, the description leaves important context missing: what the returned brand names look like, whether results are paginated, and how this differs from the related AIO sibling tools. The high schema coverage helps with parameters but not with overall call semantics.

Complex tools with many parameters or behaviors need more documentation. 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 three parameters and their meanings. The description adds little beyond naming the endpoint, so the baseline score of 3 is appropriate.

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

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

The description states a clear verb ('Fetch') and resource ('AI Overviews brand names'), and the endpoint string reinforces the purpose. It does not explicitly differentiate from sibling tools like domainAioKeywordsByBrand, but the verb and resource are specific enough for basic identification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 its siblings. There is no mention of scenarios, prerequisites, or alternative tools, leaving the agent to infer usage from the name and schema alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Fetch,' which implies a read-only operation, but provides no detail on pagination behavior, how brand matching works, what data is returned, or how filters interact with the results.

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

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

The description is a single concise sentence and front-loads the core resource. It is not bloated, though it largely restates the title and adds only the endpoint, so it earns a slightly above-average score rather than a perfect one.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 complex 24-parameter tool with no output schema and no annotations, yet the description only gives a one-line summary. Essential context—such as what 'by brand' means for querying, the shape of the response, and how pagination and filters behave—is absent, making the tool under-specified for reliable 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%, and the schema already documents all 24 parameters, including enums and defaults. The description adds no additional parameter context, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Fetch') and the resource ('AI Overviews domain keywords by brand'), plus the endpoint. It is not a tautology and conveys a specific purpose. However, it does not explicitly contrast itself with similar siblings like domainAioKeywordsByTarget or domainAioDiscoverBrand, relying on the phrase 'by brand' to imply the distinction.

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

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

There is no guidance about when to use this tool versus its many siblings, no exclusions, and no mention of prerequisites or context. The description only restates what the tool fetches, leaving the agent to infer when it 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Fetch', which implies read-only behavior. It does not mention pagination, sorting defaults, filtering semantics, output structure, rate limits, or any operational caveats.

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

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

The description is a single sentence with no filler words, so it is concise. However, for a 24-parameter API with many sibling tools, it is under-specified rather than helpfully structured; the parenthetical endpoint is useful but the description barely goes beyond the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 schema is rich, but there are no annotations and no output schema, so the description must provide more context. It fails to explain what the results look like, how filters interact, or when this target-based endpoint should be preferred over the many sibling tools, leaving the agent to infer too much.

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

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

The input schema already documents all 24 parameters with 100% coverage, so the baseline is 3. The description adds little beyond the 'target' hint in the endpoint, and does not clarify the relationship between the required source and target parameters.

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

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

The description states a clear action: 'Fetch AI Overviews domain keywords by target', and includes the endpoint for reference. It distinguishes itself from brand-based sibling tools via the 'by target' phrasing, though it does not explicitly name sibling alternatives.

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

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

No guidance is given on when to use this tool versus siblings like domainAioKeywordsByBrand, domainAioOverview, or domainKeywords. There are no conditions, exclusions, or hints about which scenario calls for this specific endpoint.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' implies a read operation, but the description does not cover limits, authorization, scope behavior, or what the response contains.

Agents need to know what a tool does to the 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 filler, and it front-loads the core action and resource before the endpoint. It could include more guidance, but what is present is 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?

With no output schema and no annotations, the description needs to compensate by explaining what metrics are returned and how this tool relates to similar AIO tools. It does neither, leaving the tool underspecified for an agent operating in a large sibling set.

Complex tools with many parameters or behaviors need more documentation. 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 parameter semantics are already fully documented in the schema. The description adds no extra meaning beyond the endpoint and general resource type.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Fetch') and a clear resource ('AI Overviews domain metrics'), so an agent can infer the operation. However, it does not distinguish this tool from the related AIO sibling tools like domainAioDiscoverBrand or domainAioKeywordsByTarget.

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

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

There is no guidance about when to use this tool versus the many sibling tools. The description simply states what it fetches, leaving the agent to guess whether this is the right tool for a given task.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the fetch action and endpoint, without explaining the output shape, whether this is a read-only operation, rate limits, or how competitor data is determined.

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

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

The description is concise and front-loaded with the verb and endpoint, but it is under-specified. It provides little beyond restating the tool name, so its efficiency does not translate into useful guidance for an 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?

There is no output schema and no annotations, so the description should explain expected results and usage context. It does neither, leaving an agent unable to anticipate the response or confidently choose this tool among many similar sibling tools.

Complex tools with many parameters or behaviors need more documentation. 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 the schema already documents all four parameters including the 'type' enum, 'stats' flag, 'domain', and 'source'. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Fetch domain competitors' with the endpoint v1/domain/competitors. It is clear about the action, but it does not differentiate itself from sibling tools like domainKeywords, domainAdsByDomain, or domainOverview, so it falls 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention the organic/paid distinction (even though the schema has a 'type' parameter), nor does it name related tools or exclusion conditions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' weakly implies a read operation, but the description does not mention pagination behavior, default result sets, sorting, filtering semantics, or what the output contains.

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

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

The description is extremely concise—a single sentence with no filler or redundancy—and it efficiently includes the raw endpoint. However, given the tool's complexity, the brevity edges toward under-specification rather than ideal structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 26-parameter tool with no output schema, no annotations, and a one-line description, the context is severely lacking. An agent gets no orientation about return values, default behavior, sorting, filters, or how this tool relates to the extensive sibling set, making the definition inadequate.

Complex tools with many parameters or behaviors need more documentation. 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 input schema already documents all 26 parameters thoroughly. The description itself adds no parameter meaning, but the schema fully compensates, warranting the baseline score of 3.

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

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

The description clearly states a specific resource with the verb 'Fetch' and the endpoint 'v1/domain/keywords', so an agent understands the basic operation. However, it does not differentiate this from sibling tools like domainAdsByKeyword or keywordsSimilar, which also involve domain or keyword retrieval.

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

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

No guidance is provided about when to use this tool versus alternatives, and no exclusions or preferred scenarios are mentioned. The description simply identifies the operation without context on how it fits among the many sibling keyword and domain 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?

With no annotations, the description carries the burden of explaining what happens when invoked. It does convey the core behavior: comparing two domains and returning either common keywords or a directional gap. However, it does not mention whether the operation is read-only, what the default mode is when diff is omitted, or any pagination/ordering behavior—the schema covers those, but the description adds little beyond purpose.

Agents need to know what a tool does to the 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 the core comparison front-loaded and the gap definition in the second sentence. It is tight and readable, though 'Analyzes and compares' is slightly generic and the sentence could have started with the specific common-vs-gap behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 captures the tool-selection-critical distinction from siblings and the schema fully documents the 10 parameters, making invocation possible. But with no output schema and no annotations, it leaves the agent to infer return shape, default common-mode behavior, pagination, and ordering implications, so it is only minimally 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 coverage is 100%, so the baseline is 3. The description reinforces the roles of domain and compare in the gap analysis, but this largely duplicates the schema descriptions for domain, compare, and diff. It adds no new parameter syntax or format beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain 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 names a specific action ('Analyzes and compares') and resource ('keyword rankings of two websites'), then defines the two supported modes: common keywords and a keyword gap. It explicitly states the gap direction ('domain ranks, compare does not'), which distinguishes it from the sibling domainKeywordsReverseComparison.

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

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

The description gives clear context for when to use this tool—whenever two domains need keyword overlap or gap comparison—and the directional wording helps an agent avoid the reverse-comparison sibling. It stops short of explicitly naming alternatives or stating when not to use it, so it is not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether this is a read-only operation, what output format to expect, how pagination or sorting behave, or what 'reverse' means. The description only restates the operation without disclosing 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 a single concise sentence with no redundant content. It is brief, but this brevity comes at the cost of missing important context.

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

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

This tool has 9 parameters, no output schema, no annotations, and a closely related sibling tool (domainKeywordsComparison). The description provides only a minimal phrase and fails to explain the reverse comparison semantics, result behavior, or when to choose this tool, leaving agents under-equipped.

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

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

The input schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds no parameter meaning beyond the schema, but it does not need to because the schema is self-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 states a clear action and resource: 'Compare keywords across domains.' However, it does not explain what 'Reverse' adds relative to the sibling tool domainKeywordsComparison, so it does not fully distinguish itself.

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

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

There is no guidance about when to use this tool versus domainKeywordsComparison or any other sibling. The description only implies a general use case and provides no exclusions or alternative routing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation and endpoint, without explaining response behavior, limitations, or any side-effect/read-only guarantees beyond the implication of 'Fetch'.

Agents need to know what a tool does to the 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 the key endpoint included, making it easy to scan. It repeats the tool title somewhat, but the endpoint reference adds useful precision without introducing clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no annotation coverage, yet the description does not explain what a domain overview contains or how this endpoint differs from the many adjacent overview-related tools. An agent would struggle to know what response to expect or which sibling to choose.

Complex tools with many parameters or behaviors need more documentation. 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 100% coverage for the single 'domain' parameter, including its own description, so the description does not need to add much. The description adds no parameter-specific meaning, but the schema already handles the semantics, 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?

The description uses a specific verb ('Fetch') and names the resource ('domain overview') plus the endpoint (v1/domain/overview), so an agent knows what the tool operates on. However, it does not differentiate this from closely related siblings like domainOverviewDb, domainOverviewWorldwide, or domainOverviewHistory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 about when to use this tool versus the many sibling overview tools. Given the large sibling list with overlapping names, the lack of any selection criteria is a significant gap.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but the description does not explain how the regional database selection works, what data is returned, whether authentication is required, or how with_subdomains alters the behavior. The endpoint string adds minimal 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 concise sentence with no wasted words, which is good. However, it is so terse that it borders on under-specification, and the endpoint path largely restates the tool name rather than adding useful structural context.

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

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

For a tool with no output schema and no annotations, the description should explain what 'by database' means, how it differs from sibling tools, and what the response contains. It only names the operation; the schema covers parameters but not the contextual behavior needed for correct selection and 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 all three parameters. The description adds little beyond the schema; 'by database' loosely connects to the source parameter, but source is already described as the regional keyword database in the schema.

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

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

The description uses a specific verb ('Fetch') and a resource ('domain overview by database'), and includes the endpoint path, making the core operation clear. However, 'by database' is ambiguous and the description does not explicitly differentiate this tool from sibling tools like domainOverview or domainOverviewWorldwide.

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

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

There is no guidance on when to use this tool versus alternatives such as domainOverview, domainOverviewHistory, or domainOverviewWorldwide. The description does not state any conditions, exclusions, or decision criteria, so the agent must infer usage from the endpoint and parameter names.

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?

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only says 'Fetch domain historical overview' and gives an endpoint; it does not describe what the historical data includes, time ranges, metric units, pagination, or any other runtime 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 a single sentence with a front-loaded verb and resource, followed by the endpoint in parentheses. There is no filler or redundant content; every part of the 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?

There is no output schema and no annotations, so the description alone must provide sufficient context. It explains only the basic action and endpoint, but omits important context such as what metrics are returned, what time range is covered, and how this history tool relates to the broader domainOverview family. Parameter coverage is acceptable due to the schema, but overall context is thin.

Complex tools with many parameters or behaviors need more documentation. 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 input schema already documents type, domain, and source clearly. The description adds no additional parameter context, but the schema handles the heavy lifting, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb and resource: 'Fetch domain historical overview' and includes the endpoint. The word 'historical' helps distinguish it from the sibling domainOverview, but it does not explicitly call out the difference or other related variants like domainOverviewWorldwide, so it stops short of full sibling differentiation.

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

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

The word 'historical' implies this tool is for retrieving historical overview data rather than current data, giving some usage signal. However, there is no explicit guidance on when to choose this over the many sibling tools, no exclusions, and no mention of alternatives, leaving the agent to infer the use case.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Fetch' and names the endpoint. It does not describe whether the operation is read-only, what the response contains, whether pagination or rate limits apply, or how the worldwide breakdown behaves. The description is minimal and leaves the agent without meaningful behavioral context.

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

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

The description is a single sentence with no wasted words and includes the endpoint path, which is useful. However, the phrase 'domain worldwide overview' largely repeats the tool name and title, so it is not maximally informative per 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?

Given four parameters, no output schema, and no annotations, the description is too sparse. It does not explain the meaning of worldwide statistics, what fields like price/traffic/keywords represent in this context, or what the response will look like. An agent would struggle to correctly interpret results or choose this over domainOverview without additional external knowledge.

Complex tools with many parameters or behaviors need more documentation. 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 four parameters are already documented in the schema with descriptions and defaults. The tool description adds no parameter-specific meaning, but the baseline of 3 applies because the schema already does the heavy lifting.

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

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

The description states a specific verb ('Fetch') and a specific resource ('domain worldwide overview'), and includes the exact endpoint path (v1/domain/overview/worldwide), which helps distinguish it from the sibling domainOverview tool. However, it does not explicitly contrast it with domainOverview or other siblings, so it stops short of full differentiation.

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

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

No guidance is provided about when to use this tool versus alternatives such as domainOverview, domainOverviewHistory, or domainOverviewDb. The agent is left to infer from the 'worldwide' qualifier alone, which is not sufficient given the large sibling list.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the HTTP method (POST) and that source is in the query string, which is useful technical context. However, it does not describe response shape, pagination, rate limits, auth requirements, or whether this is a read-only operation, leaving significant behavioral ambiguity.

Agents need to know what a tool does to the 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 packs in the core action, the endpoint, the HTTP method, and a key transport detail. Every word earns its place, 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?

Given that there is no output schema and no annotations, the description should explain what the response looks like and provide more behavioral context. It names the endpoint and action but leaves the agent without enough information to know what to expect back or how the export behaves at scale. With 5 parameters and rich schema coverage, this minimal description is insufficient for full autonomous invocation confidence.

Complex tools with many parameters or behaviors need more documentation. 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 parameters, including defaults and formats. The description adds a small technical detail by noting 'source in query' and 'POST form-data', but it does not enrich parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: bulk retrieve metrics for a list of keywords. It also includes the endpoint path, giving concrete specificity. It doesn't explicitly differentiate from sibling keyword tools like keywordsSimilar or keywordsLongtail, but the 'bulk retrieve metrics' phrasing makes its core purpose evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 such as keywordsSimilar or keywordsRelated. It implies use for known keyword lists, but never states scenarios, exclusions, or why this tool should be preferred over a sibling.

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?

No annotations are provided, so the description carries the full burden. It only says 'Fetch', implying a read operation, but does not disclose response format, pagination behavior, rate limits, or any 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 compact sentence with the key concept front-loaded. The endpoint string 'v1/keywords/longtail' is somewhat redundant but does not add meaningful clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 19 parameters, no annotations, and no output schema, a one-line description is insufficient. It does not explain what the result contains, how longtail differs operationally from similar tools, or what the agent should expect after 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 all 19 parameters. The description adds no parameter-level meaning beyond the longtail/low-volume concept.

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

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

The description states a clear action and resource: 'Fetch longtail ... keywords' and clarifies the meaning with '(low search volume)'. It is distinct enough from siblings like keywordsSimilar or keywordsRelated, though it never explicitly differentiates from them.

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

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

The description gives no guidance on when to use this tool instead of alternatives such as keywordsSimilar or keywordsRelated. No use cases, exclusions, or selection criteria 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only indicates a read operation. It does not mention response format, pagination behavior, meaning of keyword questions, or any caveats such as required auth or API limits.

Agents need to know what a tool does to the 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 efficient, front-loaded sentence with no filler. It conveys the action and endpoint compactly, though it sacrifices useful context for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 20 parameters, no output schema, and no annotations, this single sentence is not enough context. The agent is left to infer what a keyword question is, what the response contains, and how limit/offset pagination behaves.

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

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

All parameters are already documented in the input schema, so the description does not need to repeat them. The schema covers defaults, enums, and filters, meeting the baseline for 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 states a specific verb and resource: 'Fetch keyword questions', and exposes the exact endpoint v1/keywords/questions. It is not a tautology and clearly names the operation, though it does not explain how it differs from sibling keyword 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?

No guidance is given about when to prefer this tool over alternatives such as keywordsSimilar, keywordsRelated, or keywordsLongtail. The intended use case is only implied by the name and the single verb 'Fetch'.

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?

With no annotations provided, the description carries the full burden, but it only adds 'Fetch' and the endpoint. It does not disclose read-only behavior explicitly, pagination behavior, default sorting, response shape, or any side effects, so the agent is left to assume 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 sentence with no filler and the essential action is front-loaded. However, it is so terse that it reads more like an endpoint label than a purpose statement, making it concise but not fully appropriately sized for a 20-parameter 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 20 parameters, no output schema, and several closely related siblings, yet the description provides none of the extra context needed to invoke it confidently. It omits return structure, pagination expectations, filter semantics, and any differentiation from sibling tools.

Complex tools with many parameters or behaviors need more documentation. 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 even though the description itself says nothing about parameters. The schema already documents all optional filters and paging fields, and the description adds no extra meaning to the two required parameters.

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

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

The description states a clear action and resource: 'Fetch related keywords' tells an agent what the tool produces. It does not, however, distinguish related from the similar-looking keywordsSimilar or keywordsLongtail siblings, so it stops short of full differentiation.

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

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

The text provides no guidance on when to choose this over keywordsSimilar, keywordsQuestions, or keywordsExport, and no exclusions are given. The only context is the endpoint string, which does not help an agent decide among the related-keyword 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool fetches data from the SE Ranking API; it does not mention authentication, rate limits, read-only confirmation, pagination behavior, or response characteristics. This adds little beyond the tool's name.

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

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

The description is a single sentence with no filler and the core action is front-loaded. It is appropriately concise, though the brevity contributes to the lack of depth in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 20 parameters, no output schema, and no annotations, this one-sentence description is insufficient. It does not explain return format, pagination, filter behavior, or how this tool relates to its siblings, leaving significant gaps for an agent to navigate.

Complex tools with many parameters or behaviors need more documentation. 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 20 parameters. The description adds no parameter-level semantics beyond identifying the endpoint, which is consistent with the baseline of 3.

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

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

The description states a specific verb ('Fetch'), a precise resource ('similar keywords') and the API endpoint path ('v1/keywords/similar'), making the core purpose clear. However, it does not explicitly differentiate this from the sibling 'keywordsRelated', 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?

The description provides no guidance on when to use this tool versus siblings such as keywordsRelated, keywordsLongtail, or keywordsQuestions. There is no context, prerequisite, or exclusion criteria, leaving the agent to infer usage only from the tool name.

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