AIsa On-Page Audit

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

Annotations already declare destructiveHint=true and openWorldHint=true, so safety is covered. The description adds valuable behavior: independence of items (one failure doesn't cancel others) and per-call billing. These are not derivable from annotations and help the agent set expectations.

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

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

Three short sentences with zero filler. The action and limit are front-loaded. The phrase 'tool-router's batch_use' is redundant since it restates the tool name, but it's a minor flaw. Overall it is 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 annotations covering destructive behavior and an output schema presumably describing results, the description covers the key operational aspects: concurrency limit, independence, and billing. It doesn't mention error reporting formats, but those likely live in the output schema. It is sufficiently complete for a batch tool.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds no parameter-specific details. The calls parameter's description already explains the structure and batching context, so the baseline of 3 applies; the description doesn't need to compensate.

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 (execute) and resource (operations) with a concrete limit (up to 20) and concurrency. It doesn't explicitly name the sibling 'use' for single operations, but the distinction is clear enough from the concurrency and limit. The redundancy of 'tool-router's batch_use' is minor.

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 the sibling 'use' tool. The schema note about 'steps at the same execution_level of a plan go in one batch' is helpful, but it lives in the schema, not the description. The description only implies batching via concurrency but doesn't state when to choose it over the single-operation alternative.

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, so the safety profile is fully covered elsewhere. The description adds almost nothing beyond that: it does not describe the shape, volume, or format of what is returned, despite being a lookup/reference tool where that context would be valuable.

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, but both are verbose and partly redundant ('customizable crawling parameters... adapt the extraction to your requirements' and 'all the necessary information about filters and thresholds'). The core point could be one sentence; the second half largely restates the title.

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?

An output schema exists, so return values need not be explained in prose. Still, for a reference-lookup tool competing with ~25 siblings, the description is thin: it conveys the topic area but not the specific payload or how the result should be used downstream, leaving the agent to open the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter meaning is needed or missing.

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

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

The name and description together imply the tool returns reference information about available filters and thresholds for OnPage endpoints, so the broad purpose is discernible. However, the description never states plainly 'returns a list of supported filters' and does no sibling differentiation against the many post_/get_ OnPage tools. The phrasing 'Here you will find all the necessary information' is filler rather than a concrete verb+resource statement.

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 statement of when an agent should call this tool versus the sibling endpoints. A natural use case — fetch supported filters before constructing a filtered OnPage request — is left entirely to inference, and no alternatives or prerequisites are named.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on rate limits, result freshness, or what an audit payload contains — so it earns no credit for 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?

It is a single short sentence with no filler, which is efficient. However, it is not front-loaded with the tool's own action, instead leading with background about the API the tool belongs to, so the structure is adequate but not optimized for tool selection.

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 output schema exists, so return values need not be explained, and there are no parameters to document. What is missing is the operation itself and any differentiation from the many sibling Lighthouse endpoints, which is the key information an agent needs to invoke this zero-arg getter correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter semantics for the description to clarify or for the schema to leave ambiguous.

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 never states what the tool does; it describes the underlying OnPage Lighthouse API rather than the 'get ... audits' operation. 'Provides data on the quality of web pages' is a vague restatement of the API family, not a specific verb+resource for this tool, and it does nothing to separate it from siblings like get_dataforseo_on_page_lighthouse_versions or post_dataforseo_on_page_lighthouse_live_json.

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 when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent choosing among the many on_page_lighthouse_* siblings receives no signal about when this audit-retrieval endpoint is the right pick over the live JSON or versions endpoints.

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, covering the safety profile. The description adds only that the response is 'JSON-encoded data containing a tasks array', which is redundant given an output schema exists, and discloses nothing extra about auth, quotas, or 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 first sentence is front-loaded and functional, but the second sentence is boilerplate about JSON response structure that restates what the output schema already provides. It is short but the trailing sentence does not earn 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 zero-parameter read tool with an output schema, the description covers the minimum: it says what is returned. But it omits any routing information distinguishing it from the many sibling reference/list endpoints, which is the main gap given how crowded the sibling set is.

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 is 4. There are no argument semantics for the description to clarify, and it introduces no misleading parameter information.

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

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

The description does state the resource ('list of languages') and ties it to the OnPage Lighthouse API, so the agent can roughly identify it. However, it never names a distinct verb+resource in a crisp way and does not differentiate itself from sibling list tools such as get_dataforseo_on_page_lighthouse_audits or get_dataforseo_on_page_lighthouse_versions beyond the word 'languages'. Purpose is inferable but not sharply stated.

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

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

No guidance on when to call this versus the sibling list/reference tools (available_filters, lighthouse_audits, lighthouse_versions), no prerequisites, and no mention of whether it needs an input. The agent is left to infer usage entirely from the name.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond that — no auth requirements, rate limits, caching, or freshness of the version data — and the generic API-background sentence provides essentially no behavioral value.

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

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

It is a single short sentence, so it is not bloated, but it is not front-loaded with the tool's function either. The one sentence spends its words on project provenance instead of the action the tool performs, making it inefficient for its size.

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?

An output schema exists, so return values need not be described, which covers the biggest potential gap. However, the description never states that this returns the set of supported Lighthouse versions, leaving the agent to infer the entire purpose from the tool name alone; for a zero-parameter lookup this is a meaningful omission.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and complete, and there are no argument semantics for the description to clarify; nothing is missing on this dimension.

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 never says what the tool does. It only explains that the OnPage Lighthouse API is based on Google's Lighthouse project and returns page-quality data — background about the API family, not this specific endpoint. The name implies a list of supported Lighthouse versions, but the description neither confirms nor clarifies that, so an agent cannot distinguish it from siblings like lighthouse_audits or lighthouse_languages.

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 when-to-use guidance, no mention of alternatives among the many sibling lighthouse/on-page tools, and no prerequisites or context for invocation. The sentence gives no operational direction at all.

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 safety is covered. The description adds one piece of real context — that the site must already have been scanned, implying the task id refers to a completed Task POST — but says nothing about result freshness, pagination, or failure states of an incomplete task.

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, but the lead-in 'Using this function, you can' is pure filler before the actual content arrives, and 'drill down into exact on-page issues' overstates what a summary endpoint returns. The second sentence carries the real value and should have led.

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 an output schema present and read-only annotations, return values and safety need no explanation here. What is missing is sibling routing among the many get_*/post_* OnPage tools, which is the main open question an agent would have when selecting this 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?

There is one parameter with 100% schema description coverage, and the schema already explains that 'id' is the task identifier obtained from the Task POST response. The description adds nothing about the id, so the baseline 3 for full schema coverage 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 states a recognizable verb+resource: retrieving overall on-page information for a website that has been scanned. It frames the result as a summary view that precedes the detail tools, which gives it an identity distinct from the post_* detail endpoints. It does not, however, explicitly distinguish itself from the generic sibling get_details.

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 implies a workflow — call this first to learn which functions to use for detailed data on each issue — which is genuinely useful routing context. But it never names an alternative tool or states an explicit when-not condition, so the guidance stays at the implied level rather than actionable selection criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it is free, stops before any spend, and explains how price.model varies (quoted, list, dynamic, composed). It also clarifies that suggested_max_price_usd has headroom. This goes beyond the annotation flags and gives the agent a clear model of what happens.

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 moderately long but well structured: it opens with the core purpose, then explains the price model in a dedicated paragraph. No redundancy or filler. It front-loads the most critical information (contract fields) and then gives necessary detail about price semantics. Slightly dense but not overly 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?

The tool has an output schema, so return values need no description. The description covers the key behavioral aspects (no spend, pricing models, max_price headroom) and clarifies edge cases like routes without a price. For a read-only informational tool, this is complete enough for an agent to use 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 description coverage is 100%, so parameters are already documented. The description adds some nuance, such as how arguments affect pricing and that required parameters may be needed before a price can be quoted. It also clarifies with_quote's purpose (one round trip, spends nothing). These are useful but not essential given the schema's completeness.

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 purpose: returning the full contract of one or more operations, including schemas, read_only, side_effects, price, and known_pitfalls. It clearly distinguishes this from executing operations (use, batch_use) and from discovery (search, list_categories). The verb 'get' and the noun 'details' align with the title, and the first sentence is explicit.

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

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

The description implies the tool is used to assess an operation before spending (e.g., 'A quote authenticates like a call but stops before any spend'), and the schema says 'One operation_id from search', hinting at a flow. However, it never explicitly states when to choose this over siblings like use or search, nor does it give exclusions. The guidance is implied, not stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: the tool is free, requires no key, and can direct users to a category-specific endpoint that lists tools directly rather than through search.

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 moderately detailed but every sentence adds useful information: output scope, cost/auth, sibling differentiation, and endpoint usage. It is slightly longer than strictly necessary but remains well-structured and front-loaded with the core purpose.

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

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

For a zero-parameter, read-only tool with an output schema and safety annotations, the description is complete. It covers what the tool returns, the free/no-key access model, and provides the category endpoint for specialized use, leaving no essential gap for an agent to call 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?

The tool has zero parameters, so the baseline is 4. The description includes a <category> placeholder only in the endpoint examples, not as a tool parameter, which is appropriate supplementary guidance rather than a parameter-semantics gap.

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 what the tool does: it presents the AIsa catalogue at a glance, including categories, servers, tool counts, and a dedicated category endpoint. It also distinguishes itself from search by explaining that the endpoint lists tools directly instead of via search.

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

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

The description provides clear usage context: use list_categories for a catalogue overview, and use the provided endpoint when you only need one category. It explicitly contrasts with search ('instead of via search') and notes tool-router has no equivalent, although it does not exhaustively cover all sibling 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?

The description frames this as a benign retrieval ('parsing the content ... will return the structured content'), while the annotations declare readOnlyHint=false and destructiveHint=true with openWorldHint=true. That safety profile is nowhere acknowledged in the text, and the credit/billing and task-based execution model behind a POST endpoint are also undisclosed. The description actively contradicts the annotation safety signal.

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, front-loaded with the endpoint's action, and the returned-fields list is packed efficiently with no padding. It could be shortened or split only marginally; there is no wasted 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?

An output schema exists, so return values need not be re-explained, but for a task-queue POST endpoint with a nested required body and destructive annotations the description omits the async workflow, the id prerequisite, and any cost implication. An agent cannot safely call this 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?

Only one top-level parameter (body) and the signaled schema description coverage is 0%, so the description is the only place param meaning could be filled in — and it only offers 'any page you specify.' It says nothing about the required task id, the array-of-objects shape, or the markdown_view flag, though the nested schema does carry some of that detail.

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 (parsing page content) and enumerates the returned artifacts (link URLs, anchors, headings, textual content). That is enough to distinguish it from most siblings, but it never explicitly contrasts itself with post_dataforseo_on_page_raw_html or post_dataforseo_on_page_links, which an agent could easily confuse with a 'structured content' endpoint.

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 when-to-use guidance, no named alternative, and no mention of the prerequisite that the referenced task must have been created by the Task POST endpoint with enable_content_parsing set to true. The agent must infer usage context entirely on its own.

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=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, but the description frames this purely as a retrieval ('returns a list of pages') and never discloses that it is a POST/task-based call that consumes resources, nor that it needs a task id produced by a prior submission. With annotations carrying the safety profile and the description adding no operational context, this is a significant 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?

Two compact sentences with the core purpose front-loaded and no filler. It is slightly misallocated, spending its second sentence on return content that the output schema already covers.

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 task-based POST endpoint with a required task id and zero top-level schema coverage, the description omits the workflow prerequisite (obtain id from the Task POST endpoint) and any cost/consumption note. Since an output schema exists it need not describe return values, but the input-side workflow context 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?

Top-level schema description coverage is 0% (the single 'body' array parameter is undocumented). The description compensates only partially by implying a page URL and referencing a 'similarity index,' but it never explains the required task 'id', or the limit/offset/similarity controls, so an agent cannot infer how to shape the request.

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: it 'returns a list of pages that have content similar to the page specified in the request,' which clearly identifies duplicate-content detection and separates it from siblings like duplicate_tags or keyword_density. It does not explicitly name or contrast with any sibling, which is what keeps it from 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'the page specified in the request' gestures at input but never says when an agent should pick this endpoint over the other OnPage endpoints.

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 implies a read/retrieval operation ('returns a list'), but annotations declare destructiveHint=true and readOnlyHint=false. It does not disclose any destructive behavior, side effects, authentication needs, or cost implications, so the description contradicts the annotations rather than adding transparency.

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

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

The description is two sentences, front-loaded with the main purpose and a note about the response. It is concise and well-structured, though the second sentence about 'data related to page performance' is vague and adds little actionable detail.

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 an output schema exists (so return values need not be explained), the description omits critical context for a POST endpoint with a nested body: no mention of required task IDs, request body structure, pagination, or destructive/side-effect warnings. The annotation contradiction further leaves an agent without reliable behavioral 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?

With schema description coverage reported at 0%, the description must compensate, but it does not explain the required body array, the id/type fields, or optional limit/offset/accumulator parameters. The mention of 'duplicate title or description tags' loosely maps to the type enum, but overall parameter meaning is largely absent.

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: returns a list of pages containing duplicate title or description tags. This is clear and distinguishes it from a generic duplicate-content tool. However, it does not explicitly name or contrast with sibling tools such as post_dataforseo_on_page_duplicate_content, 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 gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as requiring task IDs from a prior POST. It only states what the endpoint returns, leaving usage entirely 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 destructive=true, idempotent=false, and readOnly=false, so the safety profile is covered. The description adds genuinely useful context beyond that: all tasks tied to the supplied IDs are stopped, and partial data from already-scanned pages remains retrievable. It does not mention auth requirements or rate limits, keeping it short of a 5.

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

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

Three sentences, front-loaded with the core action and no filler. The phrasing is slightly wordy ('This endpoint is designed to force stop...'), but every sentence contributes substance about scope and retained data.

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 an output schema present, return-value explanation is unnecessary, and the description covers the important behavioral question of what happens to in-progress crawls and their partial results. It is complete enough for correct invocation, missing only explicit guidance on when to stop versus wait.

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 description only alludes to 'IDs indicated in your request' without elaborating on the body array, batching, or the ID format. The schema's own embedded description (example UUID and the up-to-1000-IDs note) carries most of the parameter meaning, so the description neither compensates nor detracts.

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 precise verb+resource: force-stopping the crawl process for tasks identified by their IDs. This is unambiguous and clearly separable from sibling tools like post_dataforseo_on_page_submit, which starts a crawl rather than stopping one.

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 ('force stop the crawl process of websites you specified in a task') and references the Task POST endpoint as the source of IDs, but it never states when to use this versus letting a crawl finish, nor any exclusions or prerequisites. Guidance is implied rather than explicit.

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

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

The description implies a read/retrieval operation ('provide you with ... data', 'data that will be retrieved'), while annotations declare destructiveHint=true and readOnlyHint=false. No destructive effects, permissions, or side effects are disclosed, creating a direct contradiction.

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

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

Two sentences, front-loaded with the tool's purpose. The second sentence is somewhat redundant but not wasteful enough to undermine conciseness.

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 an output schema present, return values need not be explained. However, the destructive annotation is unaddressed, usage guidance is absent, and parameter details are not compensated for—leaving the definition incomplete for safe 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 reported as 0% for the top-level parameter, so the description must compensate. It only vaguely references filtering and sorting, without explaining the required body array, required id, or keyword_length requirements.

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 ('provide') and resource ('keyword density and keyword frequency data') with scope ('terms appearing on the specified website or web page'). It clearly conveys the tool's function, but does not explicitly differentiate itself from sibling on-page tools like summary or content_parsing.

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 when-to-use or when-not-to-use guidance is provided. The description mentions that data can be filtered and sorted, but that is a capability statement, not usage guidance relative to 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 declare openWorldHint, destructiveHint, and non-idempotency, but the description adds nothing: it does not mention that this performs a live outbound fetch of the target URL, that it may be slow or rate-limited, or why a measurement operation is flagged destructive. Note a mild tension between the 'measuring quality' framing and destructiveHint=true, though the text makes no explicit read-only claim.

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?

It is a single short sentence with no padding and the relevant framing is front-loaded, but the sentence earns little of its place since it conveys background rather than actionable tool information. Brief, but briefness here stems from under-specification.

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?

An output schema exists so return values need no explanation, but for a single-parameter tool with many nested sub-fields and no useful annotations, the description omits the essential fact that it triggers a live Lighthouse run on one URL and returns the scored result. It is inadequate 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 top-level schema description coverage is 0%, so the description is expected to compensate for the single 'body' parameter, and it does not. It says nothing about required URL formatting, audits, categories, version, for_mobile, or language fields, all of which matter for calling this correctly; only the nested schema fields carry that 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 defines what the underlying OnPage Lighthouse API is based on, not what this tool does. It never states the action (run a live Lighthouse audit against a URL) or the output form, so an agent cannot distinguish it from siblings like get_dataforseo_on_page_lighthouse_audits or post_dataforseo_on_page_page_screenshot. It borders on restating the name rather than describing the 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?

There is no when-to-use guidance, no indication that this is the endpoint that actually executes a run versus the metadata endpoints (languages, versions, audits), and no exclusions. The agent must infer usage purely 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.

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation/one-shot profile is covered without the description. The description adds no behavioral context of its own — it does not mention task submission, the dependency on a prior Task POST, or async result retrieval. It also never mentions that page_to/page_from isolate internal links, which is the only behavior-shaping constraint it could have surfaced.

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 opening sentence is front-loaded and effective, but the link-type enumeration is a single run-on sentence that mixes format boilerplate with content and could have been condensed to a short list. Nothing is outright wasted, yet the structure is dense and hard to scan.

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

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

For a POST task endpoint whose single parameter is an array-of-objects body containing a required id and six optional fields, the description omits the task lifecycle entirely (submit -> id -> poll), which is the key thing an agent needs. An output schema exists so return values need not be described, but the prerequisite and pagination context is absent.

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?

Coverage is reported at 0% for the parameter surface, so the description is expected to compensate and does not: it says nothing about id, limit, offset, filters, page_to/page_from, or search_after_token. The only indirect help is the link-type enumeration, which hints at values usable in the 'direction'/'type' filters, but no parameter is explained.

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: 'provide you with a list of internal and external links detected on a target website,' then enumerates the supported link types (anchor, image, canonical, meta, alternate, redirect). This lets an agent distinguish it from generic crawl tools, though it never contrasts itself with close siblings like resources or uncrawlable_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?

There is no when-to-use guidance at all: no statement that this is a task-submission endpoint, no note that the required id must come from the Task POST endpoint before this can be called, and no routing between this and the other on_page link-adjacent siblings. The agent must infer everything from the 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?

Annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, which is a surprising profile for a 'validate' endpoint that the description never explains or qualifies. It also omits the behavioral facts an agent needs for a POST task endpoint: that it creates a task, that results are retrieved asynchronously, and what resource/cost implications the non-idempotent, destructive hints 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?

Three sentences, reasonably front-loaded with the purpose, but the first two largely restate each other ('designed to validate structured JSON-LD data and Microdata' / 'obtain microdata ... and detailed results of its validation'). The final sentence is the only one carrying operational information, and it is the one that is unactionable.

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?

An output schema exists so return format need not be described, but for a mutation-style POST submission with annotations flagging destructive, non-idempotent behavior, the description supplies no task-lifecycle context, no routing guidance among the many sibling on-page endpoints, and no valid schema-level parameter detail. The picture an agent needs to invoke it correctly is incomplete.

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 description explains none of the actual request body semantics: the array-of-task-objects shape and the required id/url fields are left entirely to the schema, which has low description coverage at the top level. Worse, it directs the agent to a validate_micromarkup parameter that is not part of the schema at all, adding noise rather than meaning.

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

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

The description names a specific verb (validate) and resource (structured JSON-LD data and Microdata) and states the outcome an agent obtains (microdata present on the target page plus validation results). It is distinguishable from siblings like duplicate_tags or content_parsing, though it never contrasts itself with them 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?

The only usage guidance is 'set the validate_micromarkup parameter to true in the POST request to OnPage API', and that parameter does not appear anywhere in the input schema, so the instruction cannot be acted on from the structured fields. There is no statement of when to prefer this endpoint over sibling on-page endpoints or what prerequisites (task submission, page URL source) must be met.

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 destructiveHint=true and readOnlyHint=false, yet the description characterizes the operation purely as a retrieval ('returns a list of pages'). An agent reading the description would assume a safe read, directly conflicting with the destructive annotation, so the safety profile is misrepresented.

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, well-formed sentence that front-loads the core purpose with no filler. It is appropriately sized, though it omits any usage or prerequisite framing that would make it more 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?

An output schema exists, so return values need not be explained, but the description omits the task-ID prerequisite, any usage guidance, and any parameter/pagination context. For a POST endpoint that requires an id obtained elsewhere, this leaves meaningful gaps 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?

With 0% schema description coverage reported and a single required 'body' array parameter, the description carries the full burden of parameter explanation, yet it says nothing about limit/offset pagination, filters syntax, or the required task id. The description adds no parameter meaning beyond what the nested 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?

The description names a specific verb and resource ('returns a list of pages that are blocked from being indexed') and even defines what 'non-indexable' means via robots.txt/HTTP headers/meta tags. It is clearly distinguishable from other OnPage endpoints conceptually, though it does not explicitly contrast itself with the many sibling post_/get_ 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of the prerequisite workflow. The schema's 'id' field reveals you must first obtain a task ID from the Task POST endpoint, but the description never states this dependency, leaving the agent without the context needed to invoke it successfully.

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 openWorldHint=true, destructiveHint=true, and idempotentHint=false, so the agent knows this is a non-idempotent, side-effectful outbound call. The description adds useful render semantics (crawler/Googlebot-equivalent view, full-page capture), but says nothing about task submission, asynchronous result retrieval, cost, or rate-limit behavior that the annotations do not cover.

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 with no filler, and the core capability is front-loaded. It is efficient, though the second sentence is somewhat promotional rather than informational.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a POST-based endpoint with an array body and an extensive sibling tool set, the description omits task/async semantics and any routing guidance, leaving it 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?

Reported schema description coverage is 0% at the top level, and the description contributes no parameter meaning at all — no mention of the body array, url requirement, or the browser preset / proxy pool knobs. Although the nested schema properties carry rich text, the description does not compensate for the coverage gap it is measured against.

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 ('capture a full high-quality screenshot of any webpage') and adds the differentiating angle that the render matches what the DataForSEO crawler and Googlebot see. It does not name any sibling tool, but the resource is distinctive enough within the OnPage family that confusion is unlikely.

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 'review the target page as the DataForSEO crawler and Googlebot see it' implies the use case (visual/crawler-view verification of a page) but there is no explicit when-to-use versus alternatives such as raw_html, content_parsing, or resources, and no prerequisites or exclusion criteria are given.

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

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

Annotations declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, but the description is silent on any of this behavior nor on the task-based workflow. It also omits the non-obvious prerequisite that a task must first be created via the Task POST endpoint, whose ID is what the request actually carries.

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 tight sentence with no filler, so nothing is wasted. It is arguably under-specified rather than concise, but structurally it is clean 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?

An output schema exists, so return values need not be explained, and the requirement lift is low. Still, the description omits the task-creation workflow that governs this call, which is the main context an agent would need to invoke it correctly on the first try.

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 reported at 0% for the top-level `body` parameter, the description needs to compensate, and it does not. Saying 'the page you indicate in the request' gestures at a URL but says nothing about the required task `id` that the body actually requires.

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 ('returns the HTML of a page'), which is clear enough for an agent to select it. However it makes no attempt to distinguish itself from close siblings such as post_dataforseo_on_page_content_parsing, post_dataforseo_on_page_resources, or post_dataforseo_on_page_page_screenshot, all of which operate on the same target page.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many OnPage siblings. An agent gets a purpose and nothing about selection criteria.

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 (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true) are unusual for a data-listing endpoint, and the description neither reconciles nor explains them. It adds no behavioral context such as batching, cost, timeouts, or the fact that a task ID from a prior submit is required.

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 with no padding; the second sentence ('detailed overview of every resource') is mildly redundant but the description is front-loaded and easy to scan.

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

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

For a POST-based task-query endpoint with rich filtering and pagination options, the description is far too thin. An output schema exists, so return values needn't be explained, but the missing prerequisite (a completed task ID), usage context, and the mismatch with the destructive annotation leave the agent under-informed.

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 single 'body' object param carries no description at all, and the description does not describe any parameter semantics (task id, filters, pagination, search_after_token). All meaning lives in the nested schema, which the description does nothing to reinforce or 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 names a specific verb+resource: it returns a 'list of resources, including images, scripts, stylesheets, and broken elements.' An agent can tell it retrieves crawled page resources, though it doesn't distinguish itself from close siblings like post_dataforseo_on_page_uncrawlable_resources or _links.

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 only states what the endpoint returns; it gives no when/when-not guidance, no prerequisites, and no mention of the sibling tools (e.g. _links, _uncrawlable_resources) that overlap in scope. The agent must infer usage entirely.

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 destructiveHint=true, openWorldHint=true and idempotentHint=false, but the description adds nothing behavioral: it doesn't say this is an asynchronous task submission, that it consumes credits/charges (several schema params mention additional charges), or that results must be retrieved via separate endpoints/pingback. With the annotation bar already low, the description still fails to add useful 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?

Three sentences of generic API prose that never front-load the tool's actual action. Nothing is wasted in a harmful way, but the content is misallocated — the reader finishes without knowing what invoking this tool does.

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?

An output schema exists, so return-value explanation isn't required, but for a destructive, non-idempotent, credit-consuming task submission with a complex 40+ field body, the description omits task-submission semantics, cost implications, and result-retrieval flow. It is materially incomplete for the tool's complexity.

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

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

Schema description coverage is reported at 0%, so the description must compensate for the single top-level 'body' array parameter — and it does not mention the body, required fields, target, or max_crawl_pages. The rich per-field documentation lives entirely in the schema, so the description adds no parameter meaning of its own.

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 never states the tool's action — it explains what the OnPage API is and what it checks, not that this tool submits/creates an OnPage crawl task. Only the title ('Setting OnPage Tasks') hints at the verb, and the description never distinguishes this from sibling endpoints like force_stop or raw_html. This is closer to API marketing copy than a tool-purpose statement.

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 when-to-use guidance, no prerequisites, and no mention of alternatives despite a large sibling set (e.g., force_stop to cancel, content_parsing/keyword_density to consume results). An agent gets no routing signal at all.

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 and destructiveHint=true, so the safety profile is covered. The description adds useful domain semantics (what makes a resource uncrawlable) but says nothing about pagination limits (default 100 / max 1000), result volume, or the required task context. The 'returns a list' phrasing reads like a read, which sits uneasily with a destructive annotation, but it does not explicitly contradict it.

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

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

Two tight sentences with the core concept front-loaded and no filler; every clause defines the tool's output scope.

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?

An output schema exists, so return values need not be explained, and the description explains the semantic meaning of the returned data well. However, it omits the task-ID prerequisite, pagination behavior, and any differentiation from sibling endpoints, which are material for a POST endpoint with an array body.

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 reported as 0%, so the description is expected to compensate for undocumented parameters. It adds nothing about id, limit, offset, filters, or order_by, leaving the agent to rely solely on the raw schema 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 gives a specific verb (returns a list) and resource (resources that could not be crawled) and even defines the 'uncrawlable' criterion (content type mismatch between server response and HTML reference). This differentiates it from the sibling post_dataforseo_on_page_resources, though it does not explicitly name that sibling as the adjacent alternative.

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 versus sibling on-page endpoints, and no mention that this is a follow-up call requiring a task ID produced by an earlier Task POST. The agent must infer the workflow entirely.

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 frames the tool as providing/retrieving information ('get detailed information'), but annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction: the implied read-only nature conflicts with the declared destructive, non-idempotent, open-world 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 short and mostly front-loaded with purpose, but the first sentence ('This endpoint is designed to provide you with the page speed insights') is filler that merely restates the title. The second sentence carries the useful metric list.

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?

An output schema exists, so return values need not be explained. However, with destructive annotations and no parameter guidance, the description omits critical context about side effects, safety, and required inputs, leaving the definition incomplete 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?

Context signals report 0% schema description coverage, and the description mentions no parameters at all. The required `body` array and its `id`/`url` fields are left entirely to the schema, so the description adds no semantic value for invocation.

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 resource and outcome: page speed insights with page loading time, secure connection time, and resource load timing. It does not differentiate from siblings such as lighthouse_audits, resources, or summary, so it lacks explicit sibling routing.

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 endpoint instead of alternatives. There is no mention of prerequisites, task-submission flow, or when not to use it relative to the many OnPage 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?

The description discloses meaningful behavior beyond annotations: search spans the entire AIsa catalogue, candidates may belong to modules other than the current one, multiple providers for the same metric are surfaced, and no API key is required. This gives the agent a clear picture of scope and output 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 front-loaded with the core purpose and is dense with useful information: scope, no-auth requirement, response shape, and relationship to the catalogue. Each sentence adds operational value, and the structure makes the tool's behavior predictable.

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 complex discovery tool with output schema, the description is unusually complete: it explains the response modalities, candidate fields, direct pass-through to `use`, full-catalogue search behavior, and cross-provider visibility. An agent has enough context to invoke and interpret the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining that the category parameter is not a hard boundary—search spans the full catalogue—and that queries are plain-language task descriptions, which clarifies how to use the tool effectively.

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

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

The description clearly states the tool finds AIsa data operations across many categories via a plain-language query. It distinguishes itself from siblings like get_details and use by emphasizing that search covers the full catalogue, not just the pinned category.

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 conveys when to use search: when you need to discover operations across the full catalogue, even those not in the current tools/list. It also implicitly contrasts with get_details by noting that returned candidates already include input_schema, so they can be passed directly to `use` without an extra call.

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 provide readOnly=false, openWorldHint=true, and destructiveHint=true. The description adds valuable behavior beyond that: billing per call, the BatchCallResult response shape, and the error structure with retryable status. It does not spell out side effects, but the destructive flag is already carried by annotations, so the additional context is sufficient.

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: purpose, cost, response shape, and routing guidance. Key behavioral facts are front-loaded, and nothing is redundant 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?

Given that an output schema exists and all parameters have descriptions, the tool description is complete enough for correct invocation. It covers cost, return/error contracts, and how routing to this tool differs from calling pinned tools directly, leaving no practical 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 parameter is already clearly documented: operation_id as returned by search, search_id provenance, arguments matching input_schema, and max_price_usd as a spend guard. The description does not need to add parameter detail, so baseline 3 is appropriate.

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

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

The description opens with 'Execute one AIsa operation,' a specific verb+resource statement. The word 'one' distinguishes it from the sibling batch_use, and the closing note distinguishes it from calling pinned tools directly. An agent can tell what this tool is for immediately.

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 the tool: 'this is the way to call anything found through search.' It also gives the alternative: 'Pinned tools in tools/list can also be called directly.' This is clear when-versus-alternative guidance with no ambiguity.

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