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

Annotations already cover read-only/idempotent/open-world, but the description goes further with billing and safety context: it runs a specific Apify Actor on the caller's own Apify account, costs ~$0.01 per company with a matching signal, companies without a signal are free, and spend is capped at $0.5 per call. That is exactly the cost/auth/limit disclosure annotations cannot provide.

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

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

Front-loaded with the value proposition and the key scoping fact (which companies are hiring) before inputs and cost. It is a single dense paragraph; the 'Buying-intent signal' opener is slightly marketing-flavored, but little of the text 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, annotations covering the safety profile, and full schema description coverage, the description supplies everything else an agent needs: the two discovery modes, supported ATS sources, and the cost ceiling. Nothing required for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all seven parameters. The description adds meaning by enumerating the supported ATS boards (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Recruitee, Personio, Teamtailor), which constrains what the 'companies' URL values may be — a modest but real addition.

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

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

States a specific verb+resource — discovering which companies are hiring — and enumerates the output dimensions (how many roles, freshness, seniority/locations), so the agent knows this returns companies rather than job listings. The 'discover companies you do not know yet' framing implicitly separates it from a single-company job fetch like get_company_jobs.

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

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

Explains the two input modes clearly: pass target-account jobs-page URLs for known accounts, and/or job-search phrases to discover unknown companies. It gives context for when each mode applies but names no alternative sibling tool and states no exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description goes further with genuinely useful operational detail: the backing Apify Actor, per-site pricing with no charge when nothing is found, and a $0.5 per-call spend cap. It still omits what a partial/failed crawl looks like, but the cost and execution model are well disclosed.

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 dense sentences that lead with what is found and where, then follow with legality and execution economics. Every clause carries information, though the second sentence packs legality, Actor identity, unit pricing, free-miss policy and a cap into one run-on that could be split.

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 annotations cover the safety profile. The description supplies the remaining agent-relevant context (legal use, crawl behavior, cost model), leaving only minor gaps around error/partial-result handling.

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

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

Schema description coverage is 100%, with websites, max_items, max_pages_per_site, require_email and extra_input all self-documented, including defaults, ranges and the cost-scaling note on max_items. The description adds no parameter-level meaning beyond this, so the baseline 3 applies.

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

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

Specific verb (Finds) plus the exact resources (business emails, phone numbers, addresses, social profiles on named platforms) and mechanism (visits contact and about pages itself). This makes it trivially distinguishable from siblings like search_google_news or get_company_jobs, which are single-source retrieval tools rather than website contact scrapers.

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

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

Provides a usage constraint ('Use only for lawful business outreach (GDPR / CAN-SPAM)') and cost framing, which implies the appropriate context. However, it never names an alternative or states when a different sibling tool would be the better choice for a related need, so selection guidance is only implied.

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, openWorld), so the description is free to add operational context, which it does: it runs the Apify Actor tacps126/app-reviews on the caller's account, costs ~$0.0002 per review, and caps spend at $0.5 per call. That cost/execution detail is genuinely additive beyond the annotations, though latency and pagination behavior remain unstated.

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

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

Two tight sentences that front-load what the dataset contains and then the execution/cost note. The 'Mix both stores and several countries' clause is slightly redundant with the opening clause but overall there is no wasted prose.

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 return values, and annotations carry the safety profile; the added cost and Actor-execution context rounds it out well. Minor gap: it doesn't reconcile the max_items ceiling with the $0.5 spend cap or mention result limits in practice.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema; baseline is 3. The description's mention of mixing stores and countries loosely maps to the countries parameter but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Reviews from the Apple App Store and Google Play'), names the two data sources, and enumerates the returned fields. This is immediately distinguishable from the sibling get_trustpilot_reviews because the store sources are explicit.

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

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

The description implies usage ('Mix both stores and several countries') but never states when to prefer this tool over the similar sibling get_trustpilot_reviews or any exclusion criteria. Usage is inferable from the resource rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds genuinely new context beyond them: the tool runs the Apify Actor tacps126/jobs-harvester on the user's Apify account, costs about $0.001 per job, and spend is capped at $0.5 per call. That cost/ownership disclosure is exactly the kind of extra behavioral value that matters 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 dense sentences that are front-loaded with the outcome, then the input format, then the cost model; nothing is redundant. It is slightly list-heavy but every clause earns its place.

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

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

For a scraper with a full input schema, output schema, and annotations covering the safety profile, the description adds the missing operational context (provider support, auto-detection, cost and per-call cap). Only the explicit when-to-use-this-versus-siblings guidance is absent, which keeps it just shy of complete.

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

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

Schema description coverage is 100% and an output schema exists, so the schema already documents all 7 parameters including defaults, ranges and cost scaling. The description adds no parameter-specific syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (all open jobs from company career pages) and names the nine supported board providers. It also enumerates the normalized output fields, which clearly separates it from siblings like search_indeed_jobs and find_hiring_companies without opening either schema.

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

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

Gives clear operational context: paste career-page URLs from a specific list of ATS providers and the board type is auto-detected, which tells the agent exactly what input this tool expects. However, it never explicitly contrasts itself against alternatives such as search_indeed_jobs or find_hiring_companies, so the choice between them is left to inference.

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

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

Annotations already declare readOnly/idempotent/destructive=false, so safety is covered. The description adds genuinely new behavioral context beyond structured data: it runs the external Actor tacps126/shopify-products on the caller's Apify account, at ~$0.001 per product with a $0.5 per-call spend cap. It omits runtime/latency and pagination behavior, keeping it short of a 5.

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

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

Four short sentences with the payload front-loaded: what you get, at what scope, what it's for, and what it costs/how it runs. No sentence is filler, and the cost caveat is placed last where it reads as a constraint rather than the headline.

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 all six parameters are documented in the schema. The description supplies the missing economics (per-product cost, per-call cap) and execution model (external Apify Actor), which is everything an agent needs to decide whether and how to call it.

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

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

Schema description coverage is 100%, so the schema already explains stores, keywords, max_items, only_on_sale, only_available, and extra_input. The description restates scope (store/collection/product links) and cost scaling but adds no syntax or format detail beyond what the schema already 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?

States a concrete verb+resource ('Products from any Shopify store') and enumerates the returned data (prices, sale prices, discounts, stock, variants, SKUs, images, descriptions) plus the three scopes it supports (whole stores, collections, single products). None of the sibling tools overlap, so no sibling disambiguation is needed.

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

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

'Useful for price and stock monitoring' names a concrete use case, and the scope sentence tells the agent it can pass store domains, collection links, or product links. There is no explicit when-not guidance or named alternative, but no sibling competes for this task, so the gap is minor.

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 readOnly/idempotent/openWorld, but the description adds genuinely useful context beyond them: it runs the Apify Actor tacps126/trustpilot-reviews on the caller's own Apify account, costs ~$0.0005 per review, and caps spend at $0.5 per call. It stops short of describing latency or async/polling behavior, so not a full 5.

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

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

Three compact sentences, front-loaded with what is returned before filters and cost. Dense and mostly waste-free, though the parenthetical field list is long and the actor/cost sentence could be tightened.

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

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

With an output schema present and 100% schema description coverage, the description need not explain return values, and it does supply the missing operational context (cost, spend cap, backing actor). The only gap is the absent guidance on choosing this tool over review-related siblings.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description's mention of 'language' and 'verified' filters is slightly out of step with the top-level schema (those would have to go through extra_input), and it only adds marginal semantics such as cost scaling with max_reviews.

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 Trustpilot reviews for one or more companies) and enumerates the returned fields (rating, title, text, reviewer, country, date, company reply) plus TrustScore and review counts. This clearly separates it from siblings like get_app_reviews and search_reddit without needing 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?

The description implies its domain (Trustpilot company reviews) and lists the available filter dimensions, which hints at when it applies. However, it never names an alternative tool or states when NOT to use it (e.g., app-store reviews belong to get_app_reviews), so routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real operational context annotations cannot: it runs a specific Apify Actor on the caller's account, costs roughly $0.001 per listing, and hard-caps spend at $0.5 per call.

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 dense sentences: result scope first, geographic constraint second, then billing/implementation. Every clause carries information and nothing is repeated, though the field enumeration is long and sits closer to an output summary than to purpose.

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

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

For a read-only search tool with a full output schema and complete parameter descriptions, the definition covers the remaining gaps an agent needs: geographic restriction and the monetary cost ceiling that governs whether it is safe to call with a large max_items.

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 (locations, price/area/room bounds, offer_type, property_type, max_items, extra_input) are already documented inline. The description adds no parameter syntax or format detail beyond what the schema provides; the cost note merely reinforces max_items, which the schema already flags.

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 the resource (apartments and houses for rent or sale), the geography (Germany only), and enumerates the returned fields (price, area, rooms, coordinates, energy class, agent, photos). No sibling tool overlaps this vertical, so an agent can route to it unambiguously.

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 content (property search) and there is one exclusion ("Germany only"), but the description never states when to prefer this over alternatives or what a caller should do if listings are needed outside Germany. Adequate but no explicit 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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful operational context: it runs on the user's Apify account, costs ~$0.002/article, and spend per call is capped at $0.5. It stops short of describing failure modes or how the cap is enforced.

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

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

Three tight sentences that are front-loaded with purpose, then capabilities, then cost. Dense but every clause earns its place; no filler.

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

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

With an output schema present, return details need not be spelled out, and the description covers scope, cost, and account context for a 7-param nested-schema tool. Minor gaps remain around pagination or behavior when a query returns nothing.

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 baseline is 3, but the description adds real semantic value by enumerating supported Google operators ("exact phrase", -exclude, OR, intitle:) that the plain query schema does not document, and it ties cost scaling to max_items.

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

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

States a specific verb+resource ('Search Google News') plus the exact return payload (article URL, publisher, date, related coverage), which separates it cleanly from sibling search tools like search_indeed_jobs or search_reddit.

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?

Conveys how to use it (Google operators, site filters, language/country scope) and flags the cost model, giving clear context for invocation. It does not, however, state when to prefer this over a sibling news/review source or any exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description doesn't need to restate safety. It does add meaningful non-obvious behavior: it runs a specific Apify Actor on the user's own Apify account, costs about $0.003 per job, and caps spend per call at $0.5. That cost/credential context is valuable beyond the annotations; it stops short of describing return shape or pagination, but the output schema exists.

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

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

Two tight sentences, front-loaded with the core purpose and field list, then operational context (Actor, cost, cap). No filler, though the long parenthetical could be trimmed slightly.

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

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

For a read-only search over 7 params with full schema coverage and an output schema, the description covers purpose, scope, return fields, cost and spend cap. The only meaningful omission is guidance on choosing it over sibling job tools and any account/auth prerequisite.

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

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

Schema coverage is 100%, so every parameter is already documented with types, enums and defaults, setting the baseline at 3. The description adds little parameter-level meaning beyond confirming keyword/location search and the country list; it does not explain how max_items interacts with the $0.5 cap, which would have been useful.

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 (Search) and resource (Indeed job listings) plus the exact scope: by keyword and location across nine named countries, and enumerates the fields returned. An agent can distinguish it from siblings like find_hiring_companies or get_company_jobs 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?

Usage is implied by the query/location framing, but the description never states when to pick this over sibling job tools (find_hiring_companies, get_company_jobs) or any prerequisites such as needing an Apify account/API key. No exclusions are given.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it runs the third-party Actor tacps126/reddit-monitor on the caller's Apify account, costs roughly $0.001 per item, and is capped at $0.5 per call. It does not cover auth prerequisites or failure behavior, so not a 5.

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

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

Three compact sentences that lead with scope and filters before moving to cost and execution model. The field list (title, text, author, subreddit, score, links, dates) is somewhat redundant given an output schema exists, but the overall density is high.

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 description correctly spends its words on cost, execution environment, and filter scope instead. The main gap is the absence of any note on authentication or what happens when the spend cap is hit mid-call.

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 (sort, time, keywords, subreddits, max_items, include_comments, extra_input) is already documented in the schema. The description restates the filter dimensions but adds no format or syntax detail 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?

States a specific verb and resource (Reddit posts and optionally comments) with the filter dimensions (keyword, subreddit, user) and the fields returned. It is clearly distinguishable from siblings like search_google_news or get_trustpilot_reviews, which target entirely different sources.

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

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

"Good for brand and topic monitoring" implies a use case but gives no when-not guidance, no prerequisites, and does not route to any alternative sibling. The agent can infer intent but gets no decision boundary.

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