Rowfeed Search & Market Data

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the no-effect-on-terminal-states rule, which is exactly what makes the idempotent hint meaningful, plus the fact that updated run details come back. It omits auth/permission requirements and any rate-limit behavior.

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

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

Front-loaded with the core action and the state constraint, and every prose sentence earns its place. The 'USAGE EXAMPLES' block of raw user_input lines is mostly decorative and pads the definition slightly.

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

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

With an output schema present, return values need not be spelled out, and the description still notes that updated run details are returned. For a two-parameter mutation with full annotation coverage, only auth requirements are unaddressed, which is a minor gap.

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

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

Schema description coverage is 100%, so both parameters and the 30-second graceful-abort timeout are already documented in the schema. The description only gestures at 'gracefully' via an example, adding no syntax or semantic meaning beyond the schema. Baseline 3 applies.

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

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

Specific verb (Abort) plus resource (Actor run) and a state qualifier ('currently starting or running'), which immediately distinguishes it from siblings like call-actor and get-actor-run. An agent can select it without opening the schema.

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

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

Explicit when-to-use ('stop a run that is taking too long or misconfigured') and an explicit no-op condition (terminal statuses such as SUCCEEDED, FAILED, ABORTED, TIMED-OUT). It does not name an alternative tool or describe prerequisites, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, but the description adds real behavioral context beyond them: the summary vs. nextStep semantics, and that waitSecs blocks for up to 45s (default 30) before returning the current state. This is substantive added value, though it doesn't cover error/failure modes.

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

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

Front-loaded with the core purpose, then segmented into Returns/USAGE/EXAMPLES blocks. Every line carries information, though the two usage examples are somewhat redundant with the USAGE prose, adding minor length.

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 100% parameter coverage, the description need only orient the agent, which it does fully: purpose, when to use, wait semantics, and concrete invocation examples. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by framing waitSecs as a blocking/wait mechanism with its cap and default, and by describing what runId's run produces. Slight above-baseline value over the 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?

States a specific verb and resource ('Get detailed information about a specific Actor run') and enumerates the returned result fields (status, storages, stats, summary, nextStep). It does not explicitly distinguish itself from siblings like call-actor or abort-actor-run, so it falls just short of the 5 benchmark.

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 USAGE block names the condition ('check the status of a run started by any Actor-running tool') and explains when to pass waitSecs > 0 to block until terminal. It gives clear context but stops short of explicit exclusions or naming the sibling to use for other run operations.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description adds value by disclosing the default limit of 20, what clean=true does, and that results are the raw rows. Return-shape details are largely deferred to the existing output schema, which is appropriate.

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

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

Front-loaded with the core purpose and the anti-scope sentence, followed by short usage notes and examples. Slightly redundant in repeating the limit default and the clean flag across sections, but nothing wasteful enough to hurt.

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

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

For a read tool with full schema coverage and an output schema, the description supplies the purpose, trigger, and key defaults an agent needs. Pagination interaction (offset/limit) and flatten behavior are left to the schema, which is reasonable given the output schema exists.

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 eight parameters in depth. The description only restates the default limit and clean=true semantics, adding little beyond the structured fields; baseline 3 applies.

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

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

States a specific verb and resource ('Get items (rows) from a dataset') and immediately delimits scope by saying it returns rows themselves, not metadata, counts, or schema. An agent can distinguish the intent without opening the schema.

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

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

Gives a clear trigger ('When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly') plus a usage section and two concrete examples. It lacks explicit when-not guidance relative to any alternative, but the sibling list contains no competing dataset-read tool.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered elsewhere. The description earns credit for adding behavioral context beyond that: the 'requires the exact key name' precondition and the note that the response preserves the original Content-Encoding, which most clients decompress automatically — a real return-value trait callers would otherwise trip over.

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 key facts — scope, exact-key requirement, encoding caveat — are front-loaded in three tight sentences. The subsequent USAGE and USAGE EXAMPLES blocks are somewhat redundant with the first paragraph, costing a little efficiency.

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?

A two-parameter read tool whose annotations, 100% schema coverage, and output schema already cover safety, inputs, and return shape. The description closes the remaining gap with the Content-Encoding behavior, which is exactly the non-obvious detail an agent needs.

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

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

Schema description coverage is 100%, including the keyValueStoreId resolution rules (name vs. username~name) and minLength constraints in the schema itself. The description only reinforces that the key must be exact, adding little semantics beyond what the schema already documents, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the value stored under a specific key in a key-value store') and preemptively scopes it against a listing tool: 'a single record, not a listing of all keys.' An agent can immediately tell this is a point lookup, not an enumeration.

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 says when to use it ('when you need to retrieve a specific record (JSON, text, or binary)') and includes two concrete usage examples showing the store identifier formats. However, it never states when NOT to use it or names an alternative/sibling for enumeration, so the guidance is implied rather than comparative.

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, openWorldHint=true and destructiveHint=true, so the safety profile is already known; the description's 'calls the Actor' and 'Pay per answer' add the useful cost model that annotations do not supply. However, the 'retrieves its output results' framing understates that this launches a live, billable, long-running run whose results must later be polled via get-actor-run. Rate limits and run lifecycle are left to the waitSecs schema text.

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: a boilerplate wrapper sentence followed by the substantive Actor description. The marketing copy ('Full answer, brands and sources per prompt. Pay per answer.') is compact and the core capability is front-loaded, but the generic first sentence earns little and the fragment style is less scannable than a single well-formed lead.

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 7 fully documented parameters, an output schema, and explicit annotations, the description does not need to explain return values or field formats. What is missing is usage context: when this beats sibling visibility/SEO tools, and that live lookups require a paid plan. Adequate but with clear gaps for a paid, multi-engine research tool 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 every parameter (brand, engines, prompts, language, location, waitSecs, competitors) is already documented in detail in the input schema. The description adds only the conceptual framing of prompts x engines = one answer, without extra syntax or constraints. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: ask the same customer questions across ChatGPT, Google AI Mode, Gemini and Perplexity and detect whether the brand is mentioned, its rank versus competitors, and which sources are cited. That is far more informative than the generic 'calls the Actor and retrieves its output results' opener. It never names the closest sibling (rowfeed--google-ai-overview-tracker), but the multi-engine scope still makes the tool identifiable.

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 routing versus the many sibling rowfeed tools. 'Pay per answer' hints at cost but does not tell the agent when this tracker is the right choice over the single-engine Google AI Overview tracker or a plain SERP tool. The only exclusion-like signal, the paid-plan requirement, lives in the schema description rather than here.

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, and openWorldHint=true, so the safety profile is structured. The description adds genuinely useful context the annotations do not: licensed data, no blocked runs, and $1 per 1,000 products pricing. However, it never says the call starts a billable Actor run, nor how waitSecs/nextStep polling behaves, leaving the cost-incurring behavior only half explained.

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

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

Two sentences with the data scope front-loaded; the only waste is the boilerplate 'This tool calls the Actor ... and retrieves its output results' wrapper, which restates the obvious. It is short enough that no sentence is burdensome.

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 and the input schema is fully described, so return values and parameters need no explanation here. The description supplies pricing and licensing context appropriate for a paid scraping Actor; the main omission is run-lifecycle guidance (billing trigger, polling) for a tool that launches a run.

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

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

Schema description coverage is 100%, so every one of the 8 parameters (asins, searchQueries, trackAsins, maxProductsPerSearch, waitSecs, sortBy, language, location) is already documented in the schema. The description adds no parameter-level meaning beyond echoing 'keyword or ASIN', 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 names a specific resource and verb: it calls the 'rowfeed/amazon-product-tracker' Actor and returns Amazon search results and product details, enumerating the fields (rank, price, rating, reviews count, BSR, Amazon's Choice, sponsored flag). An agent can tell this is the Amazon marketplace scraper rather than a generic SERP tool, though it never names a sibling to contrast with.

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

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

Usage is only implied by 'for any keyword or ASIN' — there is no statement of when to pick this over neighbors such as rowfeed--google-shopping-prices or rowfeed--google-serp-api, and no note that live lookups require a paid plan (that constraint lives only in 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 already declare readOnlyHint=false, openWorldHint=true, destructiveHint=true, so the safety profile is covered structurally. The description adds genuinely useful cost context ($1 per 1,000 apps) but omits the run lifecycle behavior — that the call may return before terminal state and require polling — which is a critical trait for an Actor-launching tool and is only discoverable in the waitSecs schema field.

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 resource and capabilities, no filler beyond the necessary Actor-invocation framing. Slightly stiff boilerplate opener ('This tool calls the Actor X and retrieves its output results') but it earns its place by clarifying the execution model.

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 covers the data domains plus pricing. However, for a nine-parameter actor-launching tool with a polling/nextStep model, the definition leaves the async execution and sibling routing unaddressed, leaving material gaps an agent must fill from the schema 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?

Schema description coverage is 100%, so all nine parameters (appIds, charts, countries, categories, maxPerChart, searchTerms, maxPerSearch, includeDescription, waitSecs) are already documented in the schema. The description echoes the high-level modes but adds no semantics about parameter interaction or defaults, 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 actor description names concrete capabilities and resources: App Store top charts (free, paid, grossing, iPad, new), per country/category, app search, and app details, with an explicit field list (rank, developer, price, rating, etc.). The 'App Store' scope distinguishes it from google-play-scraper by name, but it never explicitly separates itself from app-reviews-scraper, which is the nearest ambiguous sibling.

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

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

Usage is only implied by the capability list — an agent can infer 'use this for App Store charts/search/details' but there is no explicit when-to-use statement, no exclusions, and no named alternative. Nothing tells the agent whether to pick this over google-play-scraper or app-reviews-scraper for overlapping intents.

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 and destructiveHint, and the description adds genuinely useful context beyond them: cost (~$0.10 per 1,000 reviews), the paid-plan requirement for live lookups, and that filtered-out reviews are not charged. It does not explain why destructiveHint is set for what reads as a scrape, which is the one 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 sentences, front-loaded with the resource and followed by the field list and pricing. The opening 'calls the Actor ... and retrieves its output results' is boilerplate that could be trimmed, but nothing else is wasted.

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

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

With an output schema present, return values need no explanation, and the description covers cost, plan requirements and the waitSecs polling behavior. For a 7-parameter, zero-required scraper this is close to complete, missing only explicit sibling differentiation.

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 apps, sortBy, country, language, waitSecs, newerThan and maxReviews in detail. The description adds only the cost implication of newerThan, 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 and resource: it exports Google Play and App Store reviews with the exact fields returned (rating, title, text, date, version, votes, developer reply). It is clearly distinguishable from metadata scrapers like google-play-scraper, though it never explicitly contrasts itself with those siblings.

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

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

Usage is implied through 'Paste store links, package names or App Store ids, any country' and the sort options, which tells an agent how to invoke it. There is no explicit when-to-use/when-not guidance and no mention of the sibling app-store scrapers that might be alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the bar is lower. The description usefully adds the cost model ('pay per link') and the 10,000-per-site ceiling, but it omits the run/polling semantics that matter here — waitSecs caps the wait and long runs return with an in-progress status plus a nextStep to poll, which is only documented in the schema, not the description.

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 resource and then the returned fields, with no filler. The wrapper boilerplate 'calls the Actor ... and retrieves its output results' is mild overhead but consistent with the other rowfeed tool definitions in this family.

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 needn't be described, and all five parameters are fully documented in the schema. What is missing is the operational context an agent needs before invoking: that this is a paid pay-per-lookup run, that live lookups require a paid Apify plan, and how to proceed when the run hasn't finished.

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 explains mode, targets format, waitSecs, dofollowOnly and maxBacklinks. The description adds only the aggregate 'Up to 10,000 per site' figure, which loosely maps to maxBacklinks; it adds no new meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: check backlinks for any website or page, and enumerates the returned fields (linking domain/page, anchor text, follow status, strength, spam score, first/last seen). It does not explicitly differentiate itself from nearby siblings such as broken-link-checker or da-pa-checker, 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?

Usage is only implied — 'Check backlinks of any website or page' plus the Ahrefs/Semrush comparison signals the scenario, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many rowfeed SEO siblings. An agent must infer the choice from the tool name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the agent knows this is a mutating/open-world Actor run. The description adds useful context ('Plain HTTP, robots.txt respected') and the Actor's checking scope, but it does not disclose charging behavior, rate limits, or what 'destructive' means in practice. No contradiction with annotations.

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

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

The description is compact at two sentences, but the first sentence is generic wrapper boilerplate and the actual useful purpose appears only in the second sentence. It is adequately sized but not front-loaded with the most useful information.

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

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

An output schema exists, annotations are present, and the input schema is fully described, so the description does not need to explain return values or every parameter. Still, for an 8-parameter Actor wrapper with destructive/open-world annotations, the description could better mention charging, long-running behavior, or run/poll semantics beyond what the schema states.

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

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

Schema description coverage is 100%, so the input schema already documents all 8 parameters in detail, including crawl vs. URL-list modes, output filtering, and waitSecs behavior. The description itself adds little parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool invokes the 'rowfeed/broken-link-checker' Actor and retrieves its output, and the Actor description specifies crawling a site to check links/images for 404s, redirects, timeouts, and blocked links, or checking a plain URL list. This distinguishes it from sibling tools like backlink-checker or seo-site-audit, though the first sentence is generic Actor-wrapper boilerplate.

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 Actor description implies two usage modes: crawling a website or checking a plain list of URLs. However, it does not explicitly say when to choose this over sibling tools such as rowfeed--backlink-checker or rowfeed--seo-site-audit, nor does it state exclusions or prerequisites beyond 'robots.txt respected.'

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, openWorldHint=true and destructiveHint=true, so the description's main added value is the cost model ('$1 per 1,000 jobs') and the monitor-mode note. It never explains why destructiveHint is true or that runs may return early before completion, both of which an agent needs to interpret the safety profile correctly.

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 'This tool calls the Actor ... and retrieves its output results' is framework boilerplate that carries no decision-relevant information, and the 'Actor description:' prefix is awkward. The substantive content that follows is dense and useful, but it is not 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?

With an output schema present and full schema coverage, the definition is adequate: purpose, sources, cost and monitor mode are covered. Gaps remain around the destructiveHint implication and the early-return/polling behavior, which matter for an open-world actor with nine 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 every one of the nine parameters is already documented in detail (including onlyNew's key-value store state and waitSecs polling). The description adds no parameter-level meaning beyond what the schema provides, 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 names a concrete verb and resource (retrieves open jobs from company career sites) and enumerates the five supported boards (Greenhouse, Lever, Ashby, Workday, SmartRecruiters) plus the returned fields. That implicitly separates it from aggregator siblings like google-jobs-api, but the differentiation is never made 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 only usage cue is 'Monitor mode returns only new jobs', which signals when to use the monitor behavior. There is no guidance on when to choose this over google-jobs-api or other job-related siblings, and no stated prerequisites for the company career page inputs.

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 openWorldHint=true, yet the description frames the tool as merely 'retrieves its output results', which reads like a safe read and does not explain that a run is started, that credits are consumed, or that live lookups require a paid plan (that caveat lives only in the input schema). The waitSecs/nextStep polling behavior is documented in the schema, not here. With the safety-relevant annotation unexplained, the description leaves real behavioral gaps.

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 a boilerplate 'calls the Actor and retrieves its output results' clause that carries no information, followed by a genuinely informative but marketing-flavored feature list ('no subscription'). The useful content is present but wrapped in 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?

Return values are covered by the output schema and all parameters by the input schema, so the core is present. What is missing is the operational context an agent needs before invoking an open-world Actor: run lifecycle, credit cost, and the paid-plan requirement, none of which appear in the description itself.

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 six parameters — including domains, language, location, maxPosition and maxKeywordsPerDomain — are already fully documented in the schema. The description adds no syntax, defaults, or interaction notes (e.g. that maxPosition also filters the summary row, which is covered in the schema). Baseline 3 applies when the schema does the heavy lifting.

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

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

The second sentence names a specific resource — Google keywords a website ranks for — and enumerates the returned metrics (position, URL, search volume, CPC, keyword difficulty, intent, estimated traffic) plus a per-domain visibility summary. That is enough to separate it from siblings like rowfeed--keyword-generator or rowfeed--keyword-search-volume, though it never names them explicitly. The first sentence ('calls the Actor ... and retrieves its output results') is generic wrapper boilerplate that adds nothing.

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 to choose this tool over the roughly 40 sibling SEO tools, and no prerequisites or exclusions. The 'Semrush, Ahrefs and SpyFu alternative' line is positioning against external products, not guidance for the calling agent. The agent must infer the use case (domain-level competitive keyword research) entirely from the actor blurb.

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 first sentence discloses the important operational fact that this invokes an Actor run and returns its output rather than doing a direct lookup — useful context beyond the annotations. Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, and the description does not contradict them. However, the wait-for-terminal-state behavior, the possibility of a capped response with a pending run, and the paid-plan requirement all live in the schema text rather than in the description.

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, no padding beyond the boilerplate 'This tool calls the Actor ... and retrieves its output results' wrapper that generic MCP-Actor tools carry. The substantive content is compact, but the leading sentence conveys little that the tool name and annotations do not already signal.

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?

Because an output schema exists, the description need not explain return values, and the input schema carries the billing prerequisite and wait semantics. What remains missing is the differentiating context an agent needs when choosing among several SEO lookup siblings, which the description does not supply.

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 both parameters (targets and waitSecs) are fully documented in structured fields, including the DA vs. PA distinction and the 0–45 second cap. The description adds only the 'up to 10,000' scale figure, which the schema already states, so the baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: check domain authority, page authority, and spam score for up to 10,000 domains or URLs, plus referring domains. The 'Moz-style bulk DA checker' framing makes the output metric clear. It never names the closest sibling (rowfeed--backlink-checker), so the distinction from that tool is left for the agent to infer.

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

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

Usage is only implied by the metric names: an agent can deduce that this is for bulk authority scoring rather than for link enumeration. There is no explicit when-to-use or when-not-to-use statement, and no alternatives are named, despite rowfeed--backlink-checker, rowfeed--seo-site-audit, and rowfeed--website-traffic-checker sharing the same neighborhood.

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?

Adds real context beyond the annotations: a concrete cost ($0.10 per 1,000 rows out) and the wait/cap behavior (0–45s, returns at the cap with current status, follow nextStep to poll, 0 = fire-and-forget). It does not clarify what the destructiveHint=true mutation actually is (presumably writing a new output dataset rather than mutating sources), which is the one notable omission.

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

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

Front-loaded with the tool's identity and action, then the actor summary, then pricing — the important facts come first. The wrapper boilerplate ('This tool calls the Actor ... and retrieves its output results') is somewhat redundant, but the whole thing is two sentences with little waste.

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

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

Output schema and annotations exist, so return values and safety are covered elsewhere, and cost/wait semantics are described. However, for a 9-parameter tool with zero required fields and three alternative input sources, the description never explains the input combinations (datasets vs pasted rows vs file URLs) or that one is needed — a meaningful gap an agent would hit immediately.

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 every parameter already has a rich description, so the baseline is 3. The prose does reinforce the semantics of keep ('first or newest row'), looseMatch, and dedupFields at a high level, but adds no syntax or constraint detail the schema lacks.

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?

Names a specific verb+resource ('Merge Apify datasets, CSV and JSON files into one table and remove duplicates') with the dedup key space (url, email, website) and the keep-first/newest policy. This is plainly distinguishable from every sibling, which are all scrapers/checkers or run-storage readers.

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

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

Usage is implied rather than stated: the agent can infer 'use this to combine datasets and dedupe' but there is no explicit when-to-use vs when-not, and no statement that at least one input source (datasetIds, rows, or fileUrls) must be supplied. The only routing hint is inside the waitSecs description, which points to get-actor-run for long runs.

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 and destructiveHint=true, and the description adds useful context that the data is licensed and runs are not blocked. However, it never explains the destructiveHint=true flag (unusual for a read-style scraper) or the paid-plan requirement beyond the schema note, and it does not describe run lifecycle behavior beyond what waitSecs documents.

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 text is short and front-loaded, but the first sentence ('calls the Actor ... and retrieves its output results') is pure boilerplate that consumes roughly half the description without informing tool selection. The remaining actor blurb is dense and useful.

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

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

With an output schema present, return values need not be explained, and the actor blurb covers scope and data provenance. Still missing is guidance on the asynchronous run model (waitSecs cap, nextStep polling) and the paid-plan constraint, which are only buried in the schema.

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

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

Schema description coverage is 100%, so every parameter including targets, onlyNew, and waitSecs is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific resource (Google Ads Transparency Center ads) and enumerates the returned fields (advertiser, format, preview image, first/last shown) plus the two use cases (find advertisers by name, monitor new ads). It is clear what the tool does, though the opening sentence is generic Actor-wrapper boilerplate that adds nothing.

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

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

Usage is only implied through phrases like 'Find advertisers by name, monitor new ads' and the schema's monitor-mode flag. There is no explicit guidance on when to pick this over siblings such as rowfeed--google-serp-api or rowfeed--google-shopping-prices, nor any mention of the get-actor-run/get-dataset-items follow-up path for long runs.

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 destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the agent knows this is a stateful, open-world, cost-bearing operation. The description adds the proxy mechanic ("calls the Actor ... and retrieves its output results"), which clarifies that work runs asynchronously on Apify. It does not disclose cost implications, the wait/polling behavior, or that results arrive as an Actor run output rather than a direct answer.

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 about calling the Actor is largely meta-boilerplate restating the tool name, and the genuinely useful capability detail is pushed into the second sentence. What remains is dense and free of filler, but the front-loading is poor for an agent scanning descriptions.

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 all six parameters are fully documented in-schema with sensible defaults. What is missing is the routing context an agent needs in this crowded sibling set: no statement of how this differs from ai-search-visibility-tracker or google-serp-api, and no plan/cost prerequisite in the description itself.

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 every parameter including waitSecs and trackDomains is documented in-schema, so the baseline is 3. The line "Any country, language and device" gestures at the location, language and device inputs but adds no syntax, format or constraint detail beyond what the schema already supplies.

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 second sentence names a specific verb and resource chain: check which keywords trigger a Google AI Overview, extract its full text and every cited source, and test whether given domains are cited or rank top 10. That is far more concrete than the boilerplate opener about calling an Actor. It does not, however, distinguish this from the close sibling rowfeed--ai-search-visibility-tracker, which an agent could easily confuse it with.

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?

Only an audience tag ("for SEO teams") hints at usage; there is no when-to-use, no when-not-to-use, and no reference to alternatives such as google-serp-api or ai-search-visibility-tracker. The one operationally critical condition — that live lookups require a paid Apify plan while the pre-filled example works free — appears only in the schema description, not here.

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, readOnlyHint=false and destructiveHint=true, so the safety profile is carried by structured data; the description does not contradict it. It adds one genuine behavioral claim — 'Licensed data, no blocked runs' — which is useful. It does not disclose that this is a long-running scrape run subject to waitSecs capping and nextStep polling, nor the paid-plan requirement, both of which live only in the schema text.

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

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

Two sentences with no bloat, but the opening sentence about calling an Actor and retrieving output is framework boilerplate that does not earn its place; the substantive content is entirely in the second sentence, which is buried behind it rather than 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 and the input schema is fully documented, so the description need not explain return values. However, for a 16-parameter, open-world, long-running scrape tool marked destructive, the description omits cost/plan requirements and the async run-and-poll behavior, leaving meaningful gaps that only appear in the schema prose.

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 16 parameters, including the non-obvious ones like hotelIds, bookingSites, maxHotels and waitSecs. The description only restates the filter concept ('Filters for stars, rating and price') and adds no semantics beyond the schema, which is the baseline case for a fully documented 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 second sentence names a specific resource and data set: Google Hotels prices for a city and dates, returning hotel, stars, rating, reviews, price per night, discounts, and optional booking-site prices, plus star/rating/price filters. That is concrete enough for an agent to distinguish it from siblings such as rowfeed--google-shopping-prices or rowfeed--tripadvisor-reviews-scraper. The first sentence is boilerplate boilerplate about calling an Actor and adds nothing, 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?

Usage is only implied: the description indicates this is for hotel price lookups with filters, and the schema hints that live lookups need a paid Apify plan. There is no explicit 'use this when' statement, no mention of when to prefer a sibling (e.g. Tripadvisor reviews for review depth), and no mention of the hotelIds path for booking-site-only lookups outside 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?

The description adds real context beyond annotations: per-image pricing, the up-to-700-images ceiling per search, and the shape of the returned records. But annotations declare destructiveHint=true and readOnlyHint=false, and the description frames the tool as merely 'retrieves output results' without saying that invoking it starts a billable Actor run that consumes paid plan credits (that plan caveat sits in the schema, not here). The lifecycle detail lives in the waitSecs schema text rather than the description.

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

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

Two sentences with no filler, and the operative content (what is returned and at what cost) is front-loaded. The opening 'This tool calls the Actor ... and retrieves its output results' is slightly boilerplate MCP-wrapper phrasing but still earns its place by identifying the execution model.

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

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

With a full input schema, an output schema, and annotations present, the description covers purpose, payload fields, volume ceiling, and cost, which is enough for correct invocation. The main omissions are the paid-plan prerequisite (present only in the schema description) and any polling/long-run behavior, which an agent would otherwise only discover after a capped waitSecs response.

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 waitSecs, searches, language, location and maxImages are all documented in-schema, so the schema carries the burden. The description corroborates scope ('up to 700 images per search, any country and language') but adds no new syntax or format meaning beyond that, which is the baseline-3 case.

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

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

The description names a specific verb (calls the Actor and retrieves its output) and a specific resource (Google Images results for a search), and the Actor blurb enumerates the returned fields (full-size URL, thumbnail, title, source page, website). It does not, however, distinguish this from closely related siblings such as rowfeed--google-serp-api or rowfeed--google-shopping-prices, so an agent must infer the split from the name and payload description alone.

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

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

Usage is only implied: 'every image Google Images shows for a search' tells the agent this is the image-retrieval option, and the '$2 per 1,000 images' line gives a cost signal. There is no explicit when-to-use/when-not statement and no named alternative (e.g., use google-serp-api for web results instead of images), so the agent gets context but no routing guidance.

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

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

Annotations already declare openWorldHint=true and destructiveHint=true, so the safety profile of kicking off an external Actor run is communicated structurally. The description adds real context beyond that — 'Licensed data, no blocked runs' and monitor mode semantics — but omits the monetization constraint that the input schema mentions (live lookups need a paid Apify plan) and doesn't clarify that calling it starts a run and consumes credits.

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 lead-in 'This tool calls the Actor ... and retrieves its output results' is boilerplate that adds little, but the actor description that follows is dense and front-loaded with the useful capability and filter information. No sentence is redundant enough to be a real liability.

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 described, and the description covers capability, filters, and data-quality/licensing notes. The main gap is operational: the paid-plan requirement (visible only buried in the input schema description) and the relationship to waitSecs/get-actor-run polling are not surfaced here.

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

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

Schema description coverage is 100%, including waitSecs polling behavior and the onlyNew monitor explanation, so the schema already carries parameter meaning. The description only restates the filter/monitor capabilities at a high level and adds nothing about query limits, location format, or maxJobsPerQuery beyond what the schema documents. 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 ('calls the Actor ... and retrieves its output results') and resource (Google Jobs listings), then enumerates the returned fields: title, employer, location, salary, contract type, posted date, source, apply link. An agent can tell this is a Google Jobs scraper rather than a hotels/maps/SERP tool, though it never explicitly contrasts with the closest sibling, rowfeed--career-site-jobs-scraper.

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 usage through feature mentions ('Filters for date posted and job type, monitor mode for new jobs only') and the schema's onlyNew note about scheduling for job alerts, but it gives no explicit when-to-use/when-not-to-use guidance and never names an alternative tool. The agent must infer the routing decision.

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 and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: 'Pay per point' (cost model) and 'Licensed data, no blocked runs' (reliability). It does not explain why a rank lookup is flagged destructive, nor does it describe run lifecycle or polling, which the waitSecs parameter only partially covers.

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 invocation and result, followed by the actor's capability summary. No filler or repetition. The 'Actor description:' prefix is slightly mechanical but does not waste meaningful space.

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 schema fully documents inputs. What remains thin is the operational picture: cost per point is mentioned but not quantified, and the relationship to sibling tools and to the run-polling tools (get-actor-run) is left implicit. Adequate but with clear gaps for a paid, long-running job.

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

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

Schema description coverage is 100%, so every one of the nine parameters is already documented in the schema, including the center/location interaction and the waitSecs polling behavior. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('calls the Actor rowfeed/google-maps-rank-tracker and retrieves its output') and the actor blurb specifies the deliverable: geo-grid rank positions, top-3 per point, average rank, top-3 share and competitors. That is far more concrete than a bare name restatement. It stops short of naming the sibling it is not (e.g. google-maps-scraper or google-maps-reviews-scraper), so an agent must infer the distinction from the grid/rank framing.

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

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

Usage is only implied: the grid/rank vocabulary signals 'use this to measure local ranking across a geo-grid', and 'Pay per point' hints at cost-sensitive use. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling such as google-maps-scraper for plain listing extraction. The agent has to derive the selection rule itself.

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 and openWorldHint=true, and the description does not explain or qualify that profile at all. It does add genuinely useful behavior beyond the annotations: pricing (~$0.30 per 1,000 reviews), the fact that filtered-out reviews are not charged, and the surface of returned data. Nothing is said about run duration, credit consumption on failed lookups, or what terminal results look like beyond the field list.

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

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

Two sentences with no fluff, but the first one is MCP wrapper boilerplate ("calls the Actor ... and retrieves its output results") placed ahead of the actual purpose, so the useful content is not front-loaded. The second sentence packs purpose, inputs, sorting and pricing efficiently.

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 documentation is unnecessary, and all eight parameters are fully described in the schema with defaults and bounds. For an open-world scraper that charges credits, the description covers cost and filtering economy; the only real gap is the missing guidance on which sibling scraper to pick and the paid-plan caveat being buried in the schema description.

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

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

Schema description coverage is 100%, so every one of the eight parameters is already documented in detail by the schema, including enum options for sortBy. The description adds only a broad statement of what can be passed as a place (links, IDs, names) and the per-1,000-review cost, which does not meaningfully extend the per-parameter semantics. 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 and resource ("Export Google Maps reviews of any business") and enumerates the returned fields (rating, text, date, owner reply, highlights, place rating/count), which makes it clearly distinct from rowfeed--google-maps-scraper (place data) and rowfeed--google-maps-rank-tracker. It never explicitly names those siblings, so an agent must infer the boundary from the resource noun alone.

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

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

"Paste Maps links, place IDs or names" plus "Newest, best or worst first" gives input-level guidance and the cost note hints at scale. There is no when-to-use/when-not guidance versus the many sibling scrapers or the rank tracker, and no mention that live runs require a paid plan except inside 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 already declare destructiveHint=true and openWorldHint=true, so the agent knows this launches a live, non-free run. The description does add genuinely useful behavior beyond that: explicit pricing at $2 per 1,000 places, a 700-result ceiling per search, and the reassurance of licensed data with no blocked runs. It omits the run lifecycle, however: nothing says the call returns at the waitSecs cap with a partial status and a nextStep to poll, and cost is framed as an advantage rather than as a warning tied to destructiveHint.

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 text is short but front-loaded with generic MCP boilerplate about calling an Actor and retrieving results, which conveys nothing the agent did not already know. The substantive content is a single run-on marketing sentence mixing data fields, per-search caps, price and a reliability claim, so the most decision-relevant facts are not surfaced first.

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, the description need not explain returns, and the actor summary does cover the payload fields. But for an 11-parameter tool with destructiveHint=true and no required parameters, the definition should say what the charges accumulate against and how a long run is followed up; that lifecycle detail lives only in the waitSecs schema text. Sibling disambiguation is also missing despite four adjacent Maps-related 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 all 11 parameters carry their own descriptions, including zoom granularity, center coordinates, the with/without enums for phone and website, and the minRating/minReviews skip rules. The description adds no parameter meaning beyond that, so the baseline 3 is the correct ceiling here.

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

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

The description names a specific verb and resource set: it scrapes Google Maps businesses for a search and returns address, phone, website, rating, reviews, opening hours and categories. That is far more informative than the generic wrapper sentence, and it distinguishes the tool from a plain Places lookup. It stops short of a 5 because it never differentiates itself from close siblings such as rowfeed--google-maps-reviews-scraper, rowfeed--google-maps-rank-tracker or rowfeed--google-hotels-api.

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, when-not-to-use, or alternative-routing guidance anywhere in the description. The only comparative statement, "Google Places API alternative", points at an external product rather than at the sibling tools the agent must actually choose between. The agent is left to infer from the field list alone whether this is the right Maps tool for a reviews task or a ranking 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description discloses a per-article cost model and the monitor-mode dedupe behavior, which explains why the tool is not purely read-only (seen IDs persisted). It still does not describe run lifecycle or latency, but the waitSecs schema field covers that. No contradiction with annotations.

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

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

Two sentences, front-loaded with the actor identity and then the substantive capability summary; nothing is redundant. The second sentence is dense but every clause (fields, monitor mode, pricing) carries information.

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

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

With 8 params, 100% schema coverage, annotations and an output schema, the remaining burden on the description is purpose, mode and cost, all of which are present. Return values need not be explained because an output schema exists, and polling behavior is documented in waitSecs.

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 topics, edition, onlyNew, queries, waitSecs, timeRange, resolveUrls and maxArticlesPerFeed in detail. The description's phrases ('any search or topic', 'any country and language') only loosely map to those params and add no operator, format, or default guidance. 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 names a specific resource (Google News articles) plus the dimensions that matter: query or topic, any country/language, returned fields (title, source, publish time, real publisher URL), and a monitor mode. It is clearly distinguishable from generic siblings like google-serp-api or google-trends-explorer. It stops short of naming a sibling for explicit contrast, so it is not 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?

Usage is implied rather than stated: 'any search or topic' plus 'monitor mode returns only articles you have not seen yet' tells an agent when monitoring applies. However, there is no explicit when-not guidance and no routing to alternatives such as google-serp-api for general web results or google-ai-overview-tracker for AI summaries.

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 and openWorldHint=true; the description neither contradicts nor explains that write-capable profile (it presumably writes dataset items). It does add value the annotations lack: an explicit cost model of $0.50 per 1,000 apps, which is genuine behavioral context for deciding whether to run a large batch.

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, no filler beyond the boilerplate Actor wrapper clause, and the concrete data payload and price are stated up front. The opening sentence is redundant filler that delays the useful content slightly.

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

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

An output schema exists so return shape needs no explanation; the description supplies the payload domain, geographic scope, and pricing, which covers what an agent needs to decide and call correctly. The remaining omission (sibling routing) is captured under usage guidelines.

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

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

Schema description coverage is 100%, including detailed notes on waitSecs capping and country-level reads, so the schema carries the parameter burden. The description only echoes 'package name or URL, in any country' and adds no new constraints such as the 10,000 app/country pair ceiling or the 50-country limit.

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

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

The description names the Actor and enumerates the exact resource returned: install count, rating, ratings histogram, price, IAPs, ads, genre, version, last update, developer. Paired with the 'Google Play app data by package name or URL' phrasing it clearly distinguishes this from the App Store sibling, though the generic first sentence ('calls the Actor and retrieves its output results') wastes the strongest opening slot.

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

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

Usage is implied by the data scope ('package name or URL, in any country'), but there is no explicit when-to-use guidance and no routing to obvious alternatives such as rowfeed--apple-app-store-scraper for iOS or rowfeed--app-reviews-scraper for user reviews. The agent must infer boundaries from sibling names alone.

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

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

Beyond the annotations, the description discloses two behaviors an agent cannot infer from structured fields: licensed data means 'no blocked runs' (reliability expectation) and pricing of $3 per 1,000 searches (cost consequence of batch size). The annotations already declare openWorldHint and destructiveHint, so the remaining burden is lighter. It does not mention run-time/polling behavior, but waitSecs and nextStep are already documented in 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 second sentence (the actor description) is dense and useful, but the opening sentence is boilerplate that restates the tool name and mechanism without adding information. The useful content is placed second rather than front-loaded, and pricing is buried at the end.

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 7 optional parameters, full schema coverage, an output schema, and annotations supplied, the description only needs to convey what data comes back, its reliability, and its cost — all of which it does. Minor omissions such as per-run limits and polling behavior are already covered by schema fields, so the definition is close to complete for this 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 100%, so every parameter (device, queries, language, location, waitSecs, targetDomain, resultsPerQuery) is already explained in the schema, including operator support and pricing implications of resultsPerQuery. The description adds no parameter-level meaning of its own, 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 actor description names the concrete resource and its contents: organic results, ads, featured snippet, People Also Ask, AI overview, local pack, and target-domain rank. That is far more specific than the wrapper sentence 'calls the Actor ... and retrieves its output results'. It does not differentiate from adjacent siblings such as rowfeed--google-ai-overview-tracker or rowfeed--google-images-api, 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?

Usage is only implied: the scope line ('any query, country, language and device') tells an agent what situations fit, and the price note hints at cost-sensitive use. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling for a narrower need (e.g. AI-overview-only or image-only tracking), which is a notable gap given ~40 sibling scrapers.

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 flag destructiveHint=true and openWorldHint=true, but the description adds real context beyond them: the sheet must be shared with the export account as Editor before the first run, no OAuth is required, replace clears the tab first (never when there is nothing to write), skipped duplicate rows are not charged, and pricing is $0.05 per 1,000 rows. Auth prerequisite and cost disclosure are exactly the kind of behavior the agent cannot infer from the schema. It stops short of describing failure modes or what the run log returns, which the output schema partly covers.

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 second sentence is dense and well packed, but the first sentence is boilerplate that restates the tool name and mischaracterizes the operation as output retrieval. The most useful fact for a first-time caller, the mandatory sheet-sharing step, is buried mid-sentence rather than front-loaded.

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

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

For a nine-parameter mutation tool with annotations and an output schema, the description covers the critical missing pieces: the Editor-sharing prerequisite, no-OAuth model, destructive replace semantics, dedup cost behavior, and per-row pricing. The waitSecs/get-actor-run polling flow and response shape are adequately handled by the schema and output schema, so their absence from the description is minor.

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

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

Schema description coverage is 100%, so all nine parameters, including the mode enum, waitSecs polling cap and skipDuplicatesBy semantics, are already documented inline. The description reinforces append vs replace and the duplicate-skipping behavior but adds no syntax, format, or interaction detail beyond what the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The actor description states a specific verb and resource: send Apify datasets, CSV and JSON files to any Google Sheet, with append/replace modes. It is clearly distinguishable from ingestion siblings like get-dataset-items or rowfeed--dataset-merge-dedup. The opening boilerplate ('calls the Actor ... retrieves its output results') is generic and slightly misdescribes the tool as a retrieval wrapper rather than a write-to-Sheets 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?

Usage is implied by the resource pairing (Apify dataset -> Google Sheet) and by the enumerated modes, but there is no explicit 'use this when X, not Y' guidance. Nothing tells the agent when to prefer get-dataset-items or dataset-merge-dedup instead, and no prerequisites beyond the sharing step are given. Adequate but clearly gapped.

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 and openWorldHint=true, so the description is not the sole source of the safety profile, and it correctly frames the tool as an Actor wrapper that both triggers a run and fetches results. It adds no cost/credit-consumption warning, no mention of run lifecycle or polling via nextStep/get-actor-run, and no note that each call spins up a billable run — meaningful gaps for a tool flagged destructive. It does not contradict the annotations, so no contradiction is flagged.

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, front-loaded with what the tool does, followed by the Actor's value proposition. The framing sentence 'This tool calls the Actor ... and retrieves its output results' is boilerplate but still informative, and nothing is padded.

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 output fields are summarized adequately. However, for a multi-parameter, billable, open-world scraper, the description omits the paid-plan requirement, the run/poll behavior at waitSecs cap, and any routing guidance versus sibling Actor tools, 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?

Schema description coverage is 100%, so all 7 parameters (sort order, language, location, waitSecs, trackSellers, searchQueries, maxProductsPerSearch) are already documented in the schema. The description adds no additional meaning about parameter interaction, defaults, or limits, 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 states a specific mechanism (calls the 'rowfeed/google-shopping-prices' Actor and returns its output) and the Actor summary enumerates the concrete output fields: price, old price and discount, seller, rating, ratings count, delivery and rank. It clearly distinguishes this as a Google Shopping price-scraping tool, though it never explicitly contrasts itself with close siblings like rowfeed--amazon-product-tracker or rowfeed--google-serp-api.

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

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

Usage is only implied through the line 'Track your own or competitors' shops,' which hints at the price-monitoring use case without saying when to pick this tool over sibling scrapers. There are no exclusions, no prerequisites, and no alternatives named; the key operational caveat (paid plan required, free plan only works with the pre-filled example) lives solely in the schema description.

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

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

The description adds genuinely useful behavior beyond the annotations: 'pay per use' cost model, 'licensed data, no captchas or rate limits', and the shared 0-100 comparison scale. However, with destructiveHint=true and readOnlyHint=false supplied, the description never explains what the run writes or persists, nor how the Actor-run lifecycle (waitSecs cap, polling) behaves. It adds cost/reliability context but leaves the write-side behavior opaque.

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 first is boilerplate MCP-wrapper phrasing ('This tool calls the Actor ... and retrieves its output results') that conveys nothing an agent cannot infer. The second sentence is a dense run-on packing scale limits, data licensing, and pricing into one clause chain, so it is compact but not 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 an output schema present and 100% parameter coverage, the description only needs to carry purpose and key behavior, which it mostly does. The gaps are sibling differentiation and the meaning of the destructive/write annotations for a scraping run. Adequate but not complete for a tool sitting among 40+ similar scrapers.

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

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

Schema coverage is 100%, so every one of the 7 parameters is already fully documented, including waitSecs polling semantics and the includeRelated cost note. The description restates the 'up to 5 compared on one scale' rule that compareTogether already explains, adding no new syntax or constraint information. Baseline 3 applies when the schema carries the burden.

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

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

The description names the concrete resource (Google Trends data) and enumerates the specific outputs: interest over time, interest by region, and top/rising related queries and topics. This distinguishes it from siblings such as rowfeed--keyword-search-volume or rowfeed--google-serp-api. The opening wrapper sentence ('calls the Actor ... and retrieves its output results') is generic, but the quoted actor description supplies real specificity.

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 or when-not guidance and no routing to alternatives among the ~40 sibling tools. The description never says whether to pick this over keyword-search-volume for demand data or google-news-monitor for news interest. Usage is only inferable from the domain ('Google Trends').

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

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

Annotations already declare openWorldHint=true, readOnlyHint=false and destructiveHint=true, which is unusual for what is essentially a read-only keyword scrape. The description adds nothing beyond the Actor's marketing blurb: no note on run duration, cost/credit usage, rate limits, or why a non-destructive scrape is marked destructive. It repeats 'calls the Actor and retrieves its output results' without explaining the async wait/poll behavior described only in the waitSecs schema field.

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 wrapper boilerplate ('This tool calls the Actor ... and retrieves its output results'), which carries no information for the caller. The second sentence is a pasted Actor blurb with promotional phrasing ('Generate hundreds of...', 'AnswerThePublic alternative'). Short, but a meaningful share of the text doesn't 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?

The presence of an output schema and 100% schema coverage means return shape and parameters needn't be re-explained. What is missing is sibling differentiation in a crowded keyword-tool family and any behavior around run duration or cost. Adequate but with clear gaps for a tool an agent must choose among 30+ alternatives.

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

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

Schema description coverage is 100%, including detailed enum semantics for expand and the waitSecs polling behavior, so the schema carries the parameter burden. The description itself says nothing about any of the 7 parameters. Baseline 3 applies when the schema is this rich.

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 concrete verb and resource via the embedded Actor summary: generate long-tail keywords from Google/YouTube/Bing autocomplete, expanded a-z/0-9 and question words, per country/language. That is specific enough for an agent to know what comes back. It never distinguishes this from sibling keyword tools like rowfeed--keyword-search-volume or rowfeed--competitor-keywords, 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the keyword-related siblings. The phrase 'AnswerThePublic alternative' hints at the use case but doesn't route an agent between this and competitor-keywords or keyword-search-volume. The agent must infer selection from the tool name alone.

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

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

Annotations already flag readOnlyHint=false, openWorldHint=true and destructiveHint=true, so the agent knows this is a billable, external, state-changing run rather than a pure read. The description adds one useful behavioral fact — 'No per-keyword fee for keywords without data' — but omits the per-lookup credit consumption, the paid-plan requirement, and the wait/cap/poll behavior that govern how results arrive. It also frames the tool primarily as 'retrieves its output results', which understates the cost-incurring run the annotations imply.

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

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

Two sentences, the first of which is a generic wrapper ('This tool calls the Actor ... and retrieves its output results'), with the substantive content in the Actor summary. The feature enumeration is long but dense with selection-relevant facts — volume, CPC, difficulty, intent, AI volume, ideas — with no filler.

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

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

An output schema exists, so return values need no explanation, and all parameters are fully described in the schema. What is still missing from the description is sibling routing (keyword-generator, competitor-keywords), the paid-plan/credit-cost reality of a run, and the polling behavior when waitSecs caps out — meaningful gaps for a billable 9-parameter Actor.

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

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

Schema description coverage is 100%, so every one of the 9 parameters (including mode-specific semantics, maxResults scope, and per-option cost multipliers) is already documented in the schema. The description adds no parameter meaning beyond that. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb and resource plus a full feature inventory, but no 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?

Usage is only implied through the feature list: measure volume for known keywords, or generate ideas from seeds. The volume-vs-ideas routing is spelled out only inside the 'mode' schema property, not in the description. There is no statement of when to prefer this tool over the keyword-generator or competitor-keywords siblings.

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

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

Annotations already state readOnlyHint=false, openWorldHint=true and destructiveHint=true, so the agent knows this creates external state; the description does not contradict that and adds the metric set produced. However, it does not disclose that this kicks off an Actor run that may exceed the wait, that polling via nextStep/get-actor-run may be required, or that live lookups need a paid plan — those facts live only in the schema's waitSecs and top-level description fields, not here.

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

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

Two sentences, with the actual capability front-loaded in the second. Efficient overall, though the first sentence is pure template boilerplate restating the tool name and could be cut without loss.

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 only three optional parameters, full schema coverage and an output schema, the description need not explain return values, and it does cover what the analysis measures. The main omission is asynchronous run behavior and cost/plan requirements, which matter for an open-world Actor invocation but are covered elsewhere in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already explains `urls`, `device` (with enum) and `waitSecs` including the 0–45 cap and fire-and-forget behavior. The description's mention of 'a list of URLs' and 'Mobile and desktop' lightly mirrors two parameters but adds no syntax, limits or defaults beyond what the schema provides.

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

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

The second sentence names a specific analysis (Google PageSpeed Insights on a list of URLs) and enumerates the concrete outputs: Lighthouse performance, accessibility, best-practices and SEO scores, LCP, CLS, TBT, INP, real-user Chrome data and Core Web Vitals pass/fail. That is enough to distinguish it from the purely technical checker siblings. The opening sentence ('calls the Actor ... and retrieves its output results') is generic boilerplate that adds no specificity.

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 pick this over the many adjacent SEO siblings (rowfeed--seo-site-audit, rowfeed--google-serp-api, rowfeed--website-technology-checker), and no stated prerequisites. The only situational cue is the implicit 'list of URLs' + mobile/desktop framing, which an agent must infer.

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?

Adds genuinely useful behavior beyond the annotations: per-page pricing ($3/1,000 pages with tables + $0.10/1,000 pages read) and the output shape (rows plus one Excel file per PDF). However, annotations declare destructiveHint=true and the description never explains what that means here — an agent could read that as file deletion. Cost is disclosed; the destructive flag is left dangling.

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 ('calls the Actor ... and retrieves its output results') is near-boilerplate inherited from the wrapper framing, but the Actor description that follows is dense and front-loads the capability, then inputs, then outputs, then price. Little waste beyond the opener.

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?

Output schema exists and all seven parameters are fully described in the schema, including the waitSecs polling/nextStep behavior, so the description only needs to establish capability, input options, cost and output format — all present. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's pricing sentence loosely corresponds to maxPagesPerPdf and the table-finder sentence to mode, but the schema already documents both in more detail (including cost per page), so little unique meaning is added.

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: convert PDF tables to Excel, CSV and JSON, with named input forms (PDFs or links) and named table-finding modes ('Finds ruled and unruled tables'). Clearly distinguishable from every listed sibling, all of which are scrapers/trackers rather than document converters.

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

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

Gives concrete use-case context — bank statements, invoices, price lists, reports — and both input routes (upload vs paste links), which tells an agent when this is the right tool. It stops short of explicit when-not-to-use guidance or naming an alternative for non-PDF documents.

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