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

Beyond annotations that mark it read-only, idempotent, open-world, and non-destructive, the description discloses important operational details: it runs the Apify Actor tacps126/innovation-radar on the user's Apify account, costs about $0.03 per field, and caps spend at $0.5 per call. These details materially help an agent understand cost and external dependency behavior.

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

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

The description is dense but front-loaded with the core analysis purpose, followed by relevant output categories, cost, and Actor details. It is appropriately sized for a complex analysis tool, though the long list of outputs could be tightened marginally.

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

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

Given the output schema exists, the description does not need to fully explain return values, but it still gives a rich overview of what the analysis returns. Annotations cover safety semantics, and the description adds cost, account, and Actor context, leaving no critical gap for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents fields, years, and extra_input. The description adds useful context that multiple fields can be supplied and ranked, and that cost is per field, but it does not explain the years parameter or advanced extra_input behavior 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 description clearly states the resource and scope: a landscape analysis of a technology or research field, with a detailed list of outputs such as opportunity score, momentum, researchers, patents, and ranked fields. It does not explicitly differentiate itself from sibling tools like search_research or validate_idea, so it falls short of a 5 despite being highly specific.

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

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

The description implies when to use it by describing the analysis it performs and notes that written opportunities should use the field-opportunity-analysis prompt instead. However, it does not name alternative MCP tools or state explicit exclusions such as when to use search_research instead.

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), but the description adds genuinely non-derivable behavior: it runs the named Apify Actor on the caller's account, costs about $0.004 per store, and hard-caps spend at $0.5 per call. It also discloses that non-Shopify domains cost nothing, which affects how an agent should batch inputs.

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

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

One long enumerating sentence followed by two short ones on skipping and cost; output contents are front-loaded before operational caveats. Dense but every clause carries information, 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 structure needn't be spelled out, and the description still summarizes it; combined with the cost ceiling, the free-skip rule, and the Actor reference, an agent has everything needed to call this correctly and cheaply. Nothing material is missing for a read-only bulk-enrichment tool.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds no syntax or format guidance for stores, countries, or extra_input. It only echoes the cost behavior already noted in max_items ('Cost scales with this').

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 and resource ('For each Shopify store') and enumerates the exact output fields (city/country, currency, product and collection counts, catalog snapshot, contacts), so an agent knows precisely what it gets. It never names or contrasts with the closest siblings (get_shopify_products, find_website_contacts), so the boundary between this and those tools must be inferred.

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

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

Implies usage through 'Non-Shopify sites are skipped for free', which signals this is a bulk qualification pass over a store list, and the countries parameter is mentioned indirectly. There is no explicit statement of when to prefer this over get_shopify_products or find_website_contacts, and 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-schema context: it runs an Apify Actor on the caller's account at ~$0.0025 per company with a $0.5 per-call spend cap — critical for an agent deciding whether to call it or how to size max_items.

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

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

A single dense paragraph with the core framing front-loaded ('Official company registers in one schema'), then mode 'new', mode 'search', returned fields, and cost. Every sentence carries information, though the country lists make it long and a bulleted mode split would scan faster.

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

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

Covers both modes, jurisdiction coverage, filter dimensions, cost model and spend cap — enough for an agent to call correctly even for a 9-parameter tool with a nested extra_input object. The returned-field list is partly redundant given the output schema exists, and extra_input is left unexplained beyond 'advanced'.

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 adds cross-parameter logic the schema states only piecemeal: names apply to 'search' mode, events apply to France/'new', and other countries fall through to the LEI index. That mapping is real semantic value beyond the per-field descriptions.

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

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

States a specific verb and resource ('Official company registers in one schema', 'find companies') and immediately splits the tool into two named modes with the jurisdictions each covers. No sibling tool in the list covers company registers, and the description makes the two-mode structure unmistakable.

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

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

Explicitly routes the caller: mode 'new' for registrations/register events with event types, mode 'search' for lookup by name, and it states which countries each mode supports. It does not name alternative tools or say when NOT to use this one, which keeps it 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 this as read-only, open-world, idempotent, and non-destructive. The description adds meaningful operational context beyond that: it runs the Apify Actor tacps126/events-scraper on the user’s Apify account, costs about $0.001 per event, and caps spend at $0.5 per call. It stops short of covering auth setup or failure modes, but the paid external dependency and cost cap are important disclosures.

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

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

The description is front-loaded with the core purpose and stays to three sentences. The long field list in the first sentence earns its place by clarifying output breadth, and the use-case and cost sentences add actionable context 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?

For a seven-parameter tool with a nested extra_input object and an output schema, the description covers the important context: input modes, supported sources, return content, intended use cases, and the paid actor cost model. Remaining schema-level details are already documented in structured fields.

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 carries most parameter detail. The description still adds useful meaning by clarifying the two input modes—topic/city search versus URL/link scraping—and by tying cost to per-event pricing, which helps an agent choose max_items and sourcing parameters appropriately.

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

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

The description uses a specific verb and resource: it finds upcoming events by topic/city or from Luma, Eventbrite, Meetup, or schema.org event pages. It also lists the returned fields (dates, venue, organiser, prices, attendance), making the tool clearly identifiable against the job/news/Reddit-oriented siblings.

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

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

It gives clear usage contexts: event prospecting, sponsorships, and community research. It does not explicitly state when not to use the tool or name alternative event tools, but the intended scenarios are well framed.

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 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that it runs a specific Apify Actor (tacps126/contact-details) on the caller's account, the per-business price, the surcharge when contacts are found, and a $0.5 per-call spend cap. It also explains the enrichment pass (emails, phones, social profiles, email-on-site flag, site-liveness flag), which is exactly the behavioral context an agent needs before paying for a 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?

It is a single front-loaded paragraph that leads with what is produced and then layers enrichment, legality, and cost. Dense but every clause carries information; only the parenthetical data-field list borders on schema duplication.

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 9-parameter, open-world, paid scraping tool with an output schema, the description covers cost model, data source, enrichment behavior, and legal caveats. It omits runtime expectations and failure/partial-result behavior, which would matter for a job that scans many websites.

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 adds real meaning by tying cost to result volume ('about $0.00125 per business' plus the spend cap), which clarifies the practical effect of max_items. It does not, however, add anything about categories, radius_km, or extra_input beyond what the schema already documents.

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

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

The description gives a specific verb and resource: it finds every business of given kinds in a city/area and enriches each with contacts scraped from its website. The opening phrase 'Lead lists without a list of websites' obliquely contrasts it with website-first siblings like find_website_contacts, but no sibling is named outright.

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 (lead generation for business outreach) and a legal constraint is stated ('Use only for lawful business outreach (GDPR / CAN-SPAM)'), but there is no explicit when-to-use vs. when-not guidance and no named alternative such as find_website_contacts or find_companies for other starting points.

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/openWorld, and the description adds what they cannot: it runs the Apify Actor tacps126/auctions-radar on the caller's own Apify account, costs about $0.015 per lot with a hard $0.5 per-call spend cap. That is exactly the auth and cost context an agent needs before calling a paid, open-world search.

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

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

The scoring/cost sentences are front-loaded and earn their place, but the first sentence is a long enumeration of return fields (price, valuation, debts, area, price per m2, deposit, case number, photos) that duplicates an output schema the agent already has. Roughly half of that sentence is redundant payload.

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 15 optional parameters, an output schema and full annotations, the description supplies the missing operational layer (cost model, spend cap, actor dependency, scoring basis). Little is absent beyond an explicit statement of result limits or how the profile enum changes scoring.

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

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

Schema coverage is 100% with enums and defaults documented, so the baseline applies. The description links scoring to the budget, place and date inputs and lists which currencies/regions are supported, but it adds no syntax or interaction detail beyond what the schema already spells out.

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 (finding foreclosure, court, tax and bank auctions) plus the four countries covered and the scored-lot output, which clearly separates it in kind from a plain listings search. It never names the adjacent sibling (search_german_property_listings), so the differentiation is inferable rather than stated.

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

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

"Use for finding below-market property, screening distressed assets and auction alerts" gives concrete use cases that map well to an agent's intent. It stops short of exclusions or a named alternative for when not to use it.

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?

Goes well beyond the annotations: it discloses that this runs a specific third-party Apify Actor on the caller's own Apify account, quotes per-lead and per-post-read pricing, and states a $0.5 per-call spend cap — critical operational context an agent cannot get from readOnlyHint/idempotentHint. It also describes what each returned lead contains (intent tag plus the triggering phrase), which is genuinely additive.

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

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

Three sentences with no filler: purpose first, output contract second, cost/execution model third. Every sentence carries information an agent needs before calling, and the most decision-relevant content (what a lead is, what it costs) is front-loaded.

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

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

An output schema exists, so return values needn't be spelled out, yet the description still summarizes the lead structure usefully. With zero required parameters, six optional knobs, and a nested free-form extra_input, the definition is nearly complete — the only real gap is not telling the agent what happens if categories/competitors are omitted, i.e. what the default search actually covers.

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 carries an example-bearing description ('CRM', 'HubSpot', 'smallbusiness'), so the schema does the heavy lifting and baseline 3 applies. The description adds nothing parameter-specific — notably silent on extra_input, the riskiest parameter, which merges arbitrary fields over Actor defaults.

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

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

States a specific verb-and-resource with a clear qualifier: Reddit posts/comments exhibiting buying intent, enumerated as asking for a tool, seeking alternatives, comparing, or complaining. The four named intent tags make the output shape concrete. It stops short of explicitly contrasting itself with the sibling search_reddit, leaving the agent to infer the difference from 'buying intent' 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?

The use case is strongly implied by 'people ask for a tool like yours' and the competitor/category framing, so an agent can infer when this fits. But there is no explicit when-not guidance and no mention of when to prefer the sibling search_reddit for generic Reddit lookups — that routing decision is left entirely 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 read-only, idempotent and non-destructive, so safety is covered; the description adds real operational context beyond them: it runs a specific Apify Actor on the caller's own account, charges roughly $0.002 per job, and caps spend at $0.5 per call. What it does not disclose is result latency or behavior when the cap truncates results.

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

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

One dense paragraph, front-loaded with sources and scope before the normalization and cost details. Every sentence carries information, though the field list ('title, company, country, seniority, salary and skills') borders on redundant given the output schema.

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 needn't describe return values, and it correctly focuses on source coverage, remote filtering, normalization and cost. The remaining gap is coverage limits (e.g., which countries or boards are weakly represented), which matters for an open-world scraper.

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 all six parameters are already documented, including country, title filter, salary floor and recency. The description only adds the framing that filtering preserves postings marked remote and that cost scales with result count, matching the max_items note in the schema rather than extending it.

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 ('remote jobs straight from employers') and enumerates the exact sources (company boards plus Remote OK, Jobicy, Working Nomads, Himalayas), which differentiates it from the sibling job searchers like search_tech_jobs and search_indeed_jobs by the remote-only filter. It never names those siblings, so the differentiation is implicit rather than routed.

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 'keeping only roles the posting marks as remote', which tells an agent this is for remote-only searches. However, there is no explicit statement of when to prefer this over get_company_jobs or search_indeed_jobs, nor any exclusion or prerequisite beyond the cost note.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds behavior the annotations cannot: it runs the Apify Actor tacps126/alerts-radar on the caller's account, costs about $0.002 per alert with a $0.5 per-call spend cap, and returns results most-severe-first. The billing/spend-cap disclosure is exactly the kind of consequence an agent needs before invoking.

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 claim, then sources, then returned fields, then ordering and cost – a sensible information hierarchy. The parenthetical source list is dense but each item earns its place by establishing coverage; only the duplicated 'plus worldwide'/'plus' phrasing is slightly loose.

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 optional params, a full output schema and rich annotations, the definition supplies what structured data cannot (sources, ordering, cost, actor identity). The one substantive gap is filter-combination semantics across the four geographic/hazard arrays, which an agent must guess.

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

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

Schema description coverage is 100%, so per-parameter documentation is already handled by the schema and the baseline of 3 applies. The description adds only indirect semantics – 'Most severe first' hints at ordering despite min_severity, and nothing clarifies how areas/states/countries/hazards combine (AND vs OR), which is the real ambiguity.

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 ('Official warnings in force') and pins it down with the exact issuing sources (NWS, MeteoAlarm, NDMA/IMD/CWC, INMET, GDACS, USGS) and the returned fields. An agent can tell this is an authoritative-alerts aggregator and not a generic government-document search like search_gov_updates, 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?

The phrase 'in force' and the source list imply the use case (current official hazard warnings), but there is no explicit when-to-use/when-not statement and no named alternative among the siblings (e.g. search_gov_updates). Usage is inferable rather than instructed.

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 declare readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely new context: it runs the Actor tacps126/jobs-harvester on the caller's own Apify account, costs about $0.001 per job, and caps spend at $0.5 per call. The only gap is failure behavior when a company or URL is not resolvable.

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

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

One dense paragraph that front-loads the output shape, then inputs, then billing — every clause carries information. The long ATS enumeration is useful but is the one place it could be trimmed.

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

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

With an output schema present and rich annotations, the description need not explain returns; it covers scope, input modes, cost, and supported systems. The remaining hole is that with zero required parameters it never says whether at least one of career_page_urls/company_names is mandatory or how the tool behaves otherwise.

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 reinforces the two main input modes and notes that cost scales with result count, but adds no syntax detail (ISO vs. name handling, what extra_input overrides) beyond what the schema already states.

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 (all open jobs from company career pages) and enumerates the normalized output fields and the 13 supported ATS systems, so the agent knows exactly what comes back. It never names a sibling job-search tool (search_indeed_jobs, search_tech_jobs, find_remote_jobs) to differentiate itself, 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?

"Give career-page URLs ... or just company names" clarifies the two accepted input modes and the schema's filters imply narrowing use, but there is no explicit when-to-use-vs-alternatives guidance against the many sibling job tools, and no statement about what happens if neither URLs nor names are supplied (0 required params).

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 and open-world, so the safety bar is met; the description goes well beyond with the concrete cost model (~$0.003 per notice, $0.5 spend cap per call), the backing Apify Actor, result ordering (newest first), and the language caveat on titles. Cost and spend-cap disclosure is exactly the kind of context annotations cannot carry.

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 geographic scope, then cost and provenance. The parenthetical stacking ('about $0.003 per notice; spend per call is capped at $0.5') is dense but every clause carries useful information, so nothing 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?

Return values are covered by an output schema and safety by annotations, so what remains for the description – source, ordering, cost, language caveat – is present. The only mild gap is that the 120-districts-per-call limit lives in the schema rather than the description, which is acceptable given full schema coverage.

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 description repeats rather than extends it – it mentions states/districts and the language of titles but adds no syntax or format guidance beyond the schema (e.g. what to do with extra_input). The schema is doing the heavy lifting here.

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

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

States a specific verb (get) and resource (tenders, recruitment and announcements from India's 748 district collector-office sites), plus the returned fields and ordering. An agent can tell this apart from generic siblings like search_tenders or search_gov_updates because the source geography and granularity 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?

Usage is implied by the domain scoping ('India's 748 districts ... by state and district'), and the one-call budget cap hints at cost-conscious use. However, it never names an alternative or an exclusion (e.g. when to prefer search_gov_updates or search_tenders instead), so selection is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by disclosing the underlying Apify Actor, per-row cost (~$0.003), and a $0.5 per-call spend cap — operationally important context an agent can't get from the annotations. It does not describe pagination or failure behavior, but the cost model is the key disclosure 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?

Front-loaded with the main capability, but the single dense sentence enumerating thirteen games is redundant with the schema enum and makes the definition longer than needed. The cost information is valuable; the game roll-call is not.

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, open-world data-fetch tool with a full output schema, the description supplies what's missing from structured fields: coverage of games, history depth, mode semantics, and the spend cap. Only minor gaps (pagination/row ordering) remain.

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 all seven parameters are already documented, including the draws/stats enum and date formats. The description adds a little meaning (frequency stats include what pure chance would produce, history back to 1980) but largely restates the game list already captured by the enum; baseline 3 is appropriate.

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

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

States a specific verb and resource (winning numbers / number frequency) and names the concrete games covered, plus the history window back to 1980. The long enumeration of games partly duplicates the enum in the schema, but the core purpose is unambiguous.

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

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

Clearly describes the two modes an agent would choose between — per-draw winning numbers versus hot/cold frequency stats over a date range — and notes the frequency mode includes a pure-chance baseline. No explicit exclusions are stated, but sibling tools are unrelated so there is no real alternative to route against.

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/openWorld/idempotent/non-destructive, so the description isn't carrying the safety burden. It adds genuinely new operational facts the annotations don't: the tool proxies the Apify Actor tacps126/prediction-markets on the user's own Apify account, costs about $0.003 per market, and hard-caps spend at $0.5 per call. It does not discuss run latency or failure modes for unsupported tickers.

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?

Lead sentence is a very long stacked list of every returned field, which is redundant given the tool has an output schema. The cost/execution note is valuable and belongs early, but the enumeration of return columns should have been trimmed in favor of the schema.

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 an 11-parameter, open-world scraping tool with no required params, the description covers cost model, spend cap, platform defaults and history option — enough to call it correctly. Return-value explanation is unnecessary since an output schema exists, so that omission costs 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 description coverage is 100%, so every parameter is already documented with enums, defaults and units. The description restates the search-modes and the optional daily price history without adding format or edge-case detail (e.g. what happens when both `search` and `markets` are supplied, or how `markets` interacts with `platforms`). 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 prediction markets') plus the four source platforms and the exact fields returned (implied probability, bid/ask, volume, liquidity, close date, settlement result). No sibling tool covers prediction markets, so the domain is unambiguous.

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

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

Explicitly names the retrieval modes ('search by keyword or category, or pass market links or tickers') and the intended use cases ('event forecasting, news context and research'). It lacks any when-not guidance or comparison to an alternative tool, which keeps it below a 5, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/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 declare readOnly/idempotent/non-destructive/openWorld, and the description adds the material behavior an agent cannot get from them: it runs a specific Apify Actor on the user's own account, itemized per-unit pricing, and a hard $0.5 per-call spend cap. That cost and account-execution disclosure is exactly the kind of context annotations omit.

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

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

Front-loads the data types, then the league list, then the filter knobs, then the pricing/cap caveat — a sensible order with no filler sentences. The long league enumeration and odds-detail parenthetical are dense but each clause carries distinct information, so it stays close to appropriately sized for a 12-parameter, 24-league tool.

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

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

An output schema exists, so return-shape explanation isn't needed. The description covers domain scope, filtering, per-unit cost, spend ceiling, and the external Actor dependency — everything an agent needs to decide to call it and to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema doesn't: what an 'odds' row contains (opening vs current/closing moneyline, spread, total, line movement, no-vig probability, settlement) and that tennis rankings come back under 'standings'. It also flags that cost scales with max_items, tying a spend consequence to a parameter.

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 set: scores and schedules, box scores, betting odds, standings and rosters, enumerating the 24 leagues covered. No sibling tool in the list touches sports, so an agent can immediately route sports queries here.

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?

"Filter by date, status and team or player" plus the data_type breakdown gives clear context on how to scope a call, and the schema's data_type description notes box scores/teams/rosters are team-sports-only. There are no explicit when-not-to-use conditions, but no sibling overlaps this domain, so the exclusion burden is low.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds important operational context beyond annotations: it runs an Apify Actor on the caller’s account, costs about $0.004 per award with free summaries, and 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?

The description is front-loaded with the purpose and data sources, then covers output shape, use cases, and cost/account details. Every sentence adds useful information for calling or interpreting the tool.

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

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

Given the output schema, rich annotations, and fully documented input schema, the description supplies the remaining context an agent needs: source coverage, result structure, cost model, and account dependency. Nothing material appears missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already carries parameter-level meaning. The description adds general cost context tied to award volume and the per-call cap, but it does not explain suppliers, countries, or awarded_within_days 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 description states a specific resource and scope: public contracts won by named companies across US federal, EU/EEA, and UK sources. It clearly explains the returned structure (company summary followed by individual awards). It does not explicitly contrast with the sibling search_tenders tool, so it stops short of full sibling differentiation.

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

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

It names concrete use cases: competitor tracking, sales prospecting, and supplier due diligence. However, it gives no explicit when-not-to-use guidance or direct alternative such as search_tenders, so an agent must infer boundaries.

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?

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the underlying Apify Actor, per-exhibitor pricing (~$0.002), a hard $0.5 spend cap per call, and the caveat that contact coverage depends on what the organiser publishes. Those are exactly the cost and reliability facts an agent needs before invoking a paid scrape.

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

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

Three sentences, front-loaded with what is returned and then the sources. The long enumerations of 11 shows and 9 platform names are dense but earn their place by signalling coverage; slight trimming would still leave room for an explicit alternative.

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 output schema, rich annotations and 100% parameter coverage, the description still supplies the cost model, source universe and data-quality caveat, leaving nothing an agent needs in order to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by giving concrete show-id examples, explaining that a URL's own show and year are used, and tying cost to result volume. It doesn't add much for extra_input or changes_only beyond what the schema already states.

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 (exhibitor lists of trade shows as B2B leads) and immediately enumerates the returned fields (company, booth/hall, email, phone, website, address, socials, categories). This clearly separates it from sibling lead/research tools like find_website_contacts and find_events.

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 in detail: 91 built-in show ids, or any exhibitor-list URL or show homepage, with the show and year inferred from the link. It does not explicitly say when to choose this over siblings such as find_website_contacts, so the routing guidance is clear but not exhaustive.

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 cover safety (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavior: the upstream Apify Actor, per-transcript pricing (~$0.0025), free videos without captions, and a $0.5 per-call spend cap. It also discloses caption-selection preference (written over auto-generated), best-effort translation, and newest-first channel ordering.

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?

Zero filler — every clause carries payload (sources, output shape, metadata, cost). The opening sentence is a dense multi-clause list that front-loads scope well but is long enough to be parsed in several passes.

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. For an 8-parameter, nested, open-world scraping tool, the description supplies the cost model, source coverage, and language behavior an agent needs to call it safely and correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns more by explaining caption-selection logic that the schema only gestures at with "in order of preference" and by flagging that max_items drives cost. It does not clarify extra_input merging or translate_to semantics beyond what the schema says.

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 (fetch full transcripts of YouTube videos) and enumerates supported source types: single videos, playlists, channels (newest first), and searches. No sibling tool covers this domain, and the description makes the resource boundary unmistakable.

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

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

"Use for summaries, RAG, research and content repurposing" gives clear situational context, and the cost note implicitly steers toward bounded use. It never states when NOT to use it or names an alternative, but the sibling set contains no overlapping transcript tool to route against.

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, and the description goes well beyond them: it discloses that the call runs the Apify Actor tacps126/sanctions-screener on the user's own Apify account, that cost is roughly $0.003 per name with a hard $0.5 cap per call, that matching applies transliteration and name-normalisation rules, and that output is a verdict plus matched entries. The account-dependency and spend cap are exactly the operational facts an agent needs before calling.

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 scope and covered lists are front-loaded, followed by matching behaviour, output shape, disclaimer, and finally cost/account mechanics — a sensible order with no filler sentences. Despite being a dense paragraph, every clause carries information an agent would otherwise have to guess.

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 7-parameter tool with a nested object and an output schema, the description covers everything material: data sources, matching logic, result semantics, cost model, spend cap, and account prerequisite. Return-value detail is somewhat redundant given the output schema, but that is a minor surplus rather than a 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 coverage is 100%, so the baseline is 3; the description earns a bump by decoding the opaque `lists` enum values into publisher names (e.g. 'us-ofac-cons' → OFAC consolidated non-SDN, 'ch' → Switzerland SECO). It also explains the fuzzy-matching behaviour that `min_score` controls (transliteration, word order, patronymics, initials, company forms), though it does not directly discuss `country`, `date_of_birth`, or `extra_input`.

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

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

States a specific verb and resource ('Screens people and organisations against the official sanctions lists') and enumerates the exact publishers covered (OFAC SDN/consolidated, UN, EU, UK, Canada, SECO). No sibling tool does anything comparable, so the tool is unambiguously identifiable from the name and first sentence 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?

The description establishes clear usage context (compliance/AML screening of persons and entities) and adds the important caveat 'A screening aid, not legal advice,' which frames when the output should and should not be relied on. It does not explicitly state exclusions or name an alternative tool, but no sanctions-related sibling exists to route away from.

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 the safety profile is covered. The description adds valuable execution context: it runs the Apify Actor tacps126/clinical-trials on the user's account, costs about $0.003 per study, and caps spend per call at $0.5 — details an agent cannot infer from annotations or 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?

Three sentences are front-loaded with what the tool returns, followed by use cases and cost transparency. The long first sentence packs many fields but every phrase earns its place; no filler or redundancy is present.

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

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

The tool is complex (11 params, nested extra_input, output schema) but the description covers the key dimensions: data source, filters, returned fields, use cases, execution environment, and cost. With an output schema present, it needn't explain return values in detail, though it could briefly mention pagination or result shape to be fully complete.

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

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

Schema description coverage is 100%, so the schema already documents every parameter with examples and enum values. The description only restates the filterable dimensions (condition, sponsor, status, phase) without adding syntax or format guidance beyond the schema, which is the expected baseline 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 names a specific resource (ClinicalTrials.gov trials) and enumerates the filters and returned fields, so an agent knows exactly what data it retrieves. It does not explicitly contrast with sibling tools like search_research or search_fda_device_clearances, so it stops short of the sibling-differentiation bar for 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?

It provides concrete use cases — trial landscapes, site and patient recruitment, competitive intelligence, and new-study alerts — which clearly signal when to reach for this tool. It gives no when-not guidance or named alternatives, but the context is clear enough for most selections.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the baseline is covered. The description adds genuinely useful behavior beyond that: it names the backing Apify Actor, discloses per-decision cost (~$0.004) and a $0.5 per-call spend cap, and notes that cost scales with max_items — material facts for an agent deciding whether to call it or how to size the request.

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

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

Three sentences, front-loaded with the resource and scope before filtering and cost details. The opening field enumeration is long but each item informs what a caller can retrieve; little is wasted, though the list 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?

An output schema exists, so return values need not be described, and the schema plus description together cover filters, cost, and execution model. The main residual gap is that the description doesn't warn that results default to only the last 30 days of decisions, which an agent could easily miss when interpreting an empty or narrow result 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 one of the 9 parameters is already documented with examples and constraints. The description's filter summary ('date, company, device words, product code, specialty and class') merely restates the schema and does not flag the consequential default of decided_within_days=30, which silently narrows results.

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

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

The description opens with a specific verb and resource ('FDA medical device 510(k) clearances and PMA approvals') and enumerates exactly what data is returned (applicant, product code, panel, class, review days, decision, links). This is unmistakably distinct from siblings like search_clinical_trials or search_recalls, which cover different regulatory datasets.

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 states a clear usage context ('medtech competitive intelligence and sales prospecting') and lists the available filter axes, so an agent knows what this tool is for. It stops short of explicit when-not guidance or naming an alternative sibling (e.g. clinical trials vs. clearances) for overlapping research questions.

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 (readOnly, openWorld, idempotent, non-destructive), the description discloses substantive behavior: it runs a specific Apify Actor on the caller's account, costs roughly $0.001 per listing, and caps spend at $0.5 per call. That billing and external-dependency detail is exactly the kind of context annotations cannot convey. It stops short of covering failure modes or pagination, 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?

Two dense sentences with no filler; geography scope is front-loaded and cost information follows immediately. The enumeration of returned fields is somewhat wasted effort since an output schema already exists, which slightly dilutes the value-per-sentence ratio.

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 an 11-parameter, nested, open-world scraping tool with an output schema, the description covers the essentials an agent needs: geographic coverage, cost model, spend cap, and account dependency. Gaps remain around the incremental 'changes_only' mode and the 'extra_input' override, but those are fully documented 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 one of the 11 parameters is already documented in the schema, making the baseline 3. The description reinforces a few fields (price, area, rooms, country scope via 'Not Switzerland') but adds no syntax, format, or interaction semantics beyond the schema. Notably, neither the nested 'extra_input' escape hatch nor 'changes_only' is mentioned in the description.

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

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

The description clearly identifies the resource (rental/sale apartments and houses on ImmoScout24 in Germany/Austria) and enumerates the returned fields, so an agent knows exactly what domain of data it gets. It deliberately excludes Switzerland, which sharpens the boundary. The verb 'search' is only implicit from the name rather than stated in the description, which keeps it from a 5.

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

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

Usage is implied by the domain ('property listings in Germany or Austria') and one exclusion is given ('Not Switzerland'), but there is no explicit statement of when to call this versus when not to, and no mention of prerequisites such as the Apify account being required. Since no sibling tool covers the same domain, the practical ambiguity is low, but the guidance is inferred 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 (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/openWorld/idempotent/non-destructive, and the description adds substantial context beyond them: the tool runs a named Apify Actor on the caller's own Apify account, cost is ~$0.003 per update with a $0.5 per-call spend cap, and robots.txt is respected for scraped list pages. Cost/quota and billing-surface disclosure is exactly the kind of behavior an agent needs and that annotations cannot express.

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 resource and a clear coverage enumeration, then closes with filtering and cost. The long source list is dense but each item earns its place by telling the agent which regulators are actually reachable, though it could be tightened into a shorter source grouping.

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 structure need not be explained, and the description covers the remaining gaps an agent would care about: source scope, filter dimensions, jurisdiction reach, cost model, and the external account dependency. Nothing needed 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 coverage is 100%, so the schema itself already documents all nine parameters and their defaults, making 3 the baseline. The description adds only modest value: it hints at feed_urls/page_urls ('any RSS feed or official "What's new" list page you name') and notes results are sector-tagged, but it also names a filter ('authority') that does not exist as a parameter, which can mislead rather than clarify.

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

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

States a specific resource (official government updates) and enumerates exactly which sources are covered (Federal Register, SEC, GOV.UK, EC, Indian regulators, custom RSS/list pages). This makes it trivially distinguishable from siblings like search_google_news or search_reddit, which cover general news/social rather than regulator-published documents.

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

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

The description makes clear what the tool is for (regulatory/news harvesting across named jurisdictions) and the filtering dimensions available, which implicitly steers an agent away from generic news search tools. It stops short of explicit 'use X instead when Y' routing or stated exclusions, so it earns a 4 rather than 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/openWorld, and the description adds genuinely non-obvious behavior: it runs a named Apify Actor on the user's account, costs ~$0.003 per call with a $0.5 per-call cap, and returns results sorted soonest-deadline-first. That cost and billing context is real added value not in the structured fields.

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 the what and where, then the returned fields, then ordering and billing. The field enumeration (title, funder, programme, grant size...) is slightly redundant with the output schema but stays tight.

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 multi-source aggregator with an output schema present, the description covers sources, geography mapping, sort order, forecast inclusion and cost model — everything an agent needs before calling. Return-value detail is correctly delegated to the output schema.

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

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

Schema description coverage is 100%, so every one of the 8 parameters is already documented, including the cost-scaling note on max_items. The description adds no parameter-specific syntax or semantics beyond restating that results carry grant size, deadline and eligibility fields, 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 ('Open and forecast public funding calls') and enumerates the exact sources (Grants.gov, EU Funding & Tenders, UKRI), so an agent immediately knows the scope. It doesn't explicitly distinguish itself from the sibling search_tenders, which is the closest potential overlap.

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 search-and-filter shape and the source enumeration, but there is no explicit 'use this instead of X' guidance against search_tenders or search_gov_updates. Deadlines and forecast inclusion are described, which helps framing, but selection criteria are 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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior the annotations do not: it runs the Apify Actor tacps126/npi-providers on the caller's Apify account, costs about $0.003 per provider, is capped at $0.5 per call, and cost scales with max_items. It does not describe pagination or what happens when filters combine, so the disclosure is valuable but not complete.

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

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

It is front-loaded with the resource and field list before moving to filters and then cost, and almost every clause carries information. The prose is dense and slightly run-on, packing fields, filters and pricing into one long sentence and a half, but there is little true 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, the description need not explain return values, and it still covers the non-obvious operational facts an agent needs: account dependency, per-provider pricing and the per-call spend cap. For a 12-parameter, zero-required search tool with full schema coverage, nothing essential 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 every parameter is already documented in the schema, including examples for states, specialties, organization_name wildcards and the max_items cost note. The description reinforces the filter categories but adds no syntax or constraint detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names a specific resource (US doctors, dentists, therapists, clinics and hospitals from the official NPI Registry), enumerates the returned fields, and is clearly distinct from nearby siblings such as search_clinical_trials and search_fda_device_clearances. An agent can identify the tool's domain without opening the schema.

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

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

It gives concrete selection axes — search by specialty, state, city, ZIP, name or NPI, and optionally restrict to new practices or providers with a phone — which tells the agent when this is the right tool. It stops short of naming an alternative or an explicit when-not-to-use case against sibling search tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description correctly spends its words elsewhere: it discloses that it runs the Apify Actor tacps126/us-import-records on the caller's Apify account (an auth/credential dependency), quotes per-unit pricing, and states a hard $0.5 per-call spend cap. Cost and credential requirements are exactly the kind of behavioral context annotations cannot express.

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 scope statement is front-loaded and every clause carries information; nothing is filler. The middle sentence is a long comma-chained enumeration that reads as a run-on, which slightly hurts scanability, but no sentence could be deleted 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 ten parameters, nested objects, and a published output schema, the definition covers intent, cost, and credentials well enough to call correctly, and it does not waste space restating return values the output schema defines. The one real omission is that no parameter is marked required, and the description never states that at least one of companies or suppliers must be supplied for a meaningful 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 the schema already documents every one of the ten parameters including defaults, ranges, and the cost note on max_items. The description implies the two primary modes (importer lookup vs. supplier lookup) but adds no syntax, format, or interaction detail beyond that. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource pair ("US customs sea import records for a US importer or an overseas supplier") and then enumerates the payload: shipments and 12-month trend, suppliers/customers, weight, HS codes, products, countries, ports, carriers, bills of lading, and lookalikes. That is far more specific than any sibling tool name suggests, and it makes clear this is customs/bill-of-lading data rather than generic company firmographics or news.

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 names four concrete use cases (sourcing, supplier discovery, importer prospecting, supply-chain research), which gives an agent a clear sense of the situations this tool fits. It does not, however, contrast itself with plausible siblings such as find_companies or get_supplier_contracts, nor does it state when not to use it.

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

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

Annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful operational context beyond annotations: it runs the named Apify Actor on the user's account, costs about $0.003 per job, and 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?

The description is front-loaded with the core search action and scope, then adds cost details. It is dense but largely free of filler, though the enumerated return fields are somewhat lengthy given the presence of an output schema.

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 an eight-parameter search tool with full schema coverage, rich annotations, and an output schema, the description supplies the key missing operational context: supported countries, return-field scope, detail behavior, and cost bounds. Nothing essential for correct invocation appears absent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters, including enums and defaults. The description reinforces country coverage and the include_details behavior, but mostly repeats or lightly contextualizes what the schema already provides.

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

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

States a specific verb and resource ('Search Indeed job listings') and scopes it by keyword, location, and nine country sites. The Indeed-specific framing distinguishes it from sibling job-search tools such as search_tech_jobs, search_naukri_jobs, and 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?

The description makes the intended use clear through its keyword/location and country-site scope, but it does not explicitly say when to choose this over sibling job-search tools or when not to use it. Usage is implied rather than guided.

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/openWorld/idempotent/non-destructive, and the description adds materially more: it runs the external Apify Actor tacps126/legislation-radar on the caller's own Apify account, costs roughly $0.003 per law, and enforces a hard $0.5 spend cap per call. It also discloses result ordering (newest first) and the default recency window — real operational facts an agent cannot get from the annotations.

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

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

Three front-loaded sentences: scope by source first, returned fields second, cost/ordering constraints last. The jurisdiction enumeration is dense but each item disambiguates coverage, and there is no filler or repetition of the title.

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

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

For a zero-required-parameter search tool with full schema coverage and an output schema, the description covers everything an agent needs to decide and call correctly: coverage, jurisdiction set, recency default, ordering, external Actor dependency, and spend ceiling. Return fields need not be enumerated given the output schema, yet a brief listing is included without bloat.

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 kinds, keywords, countries, max_items, posted_within_days, and extra_input are all documented in the schema itself; the description adds only the ordering behavior and a per-law cost hint that reinforces max_items. The advanced extra_input escape hatch and the interaction between cost and max_items are never mentioned in the description, so it stays at the baseline 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?

States a specific verb (search) and resource (new legislation) plus the exact source registries (EUR-Lex, legislation.gov.uk, GovInfo, Federal Register of Legislation, Canada Gazette Part II) and the DBpedia-style record fields returned. This clearly separates it from siblings like search_gov_updates, search_tenders, or get_india_district_notices, which cover adjacent but distinct content.

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

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

The description establishes clear usage context: only legislation published by official sources across exactly five jurisdictions, newest first, defaulting to the last 7 days. It stops short of naming an alternative sibling or stating when not to use it (e.g., vs. search_gov_updates for non-legislative government news), so the routing decision is left partly to inference.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive traits, yet the description adds genuinely new operational context: it runs a specific Apify Actor on the caller's account, costs roughly $0.0015 per job, and enforces a $0.5 per-call spend cap. It also flags the include_details speed/fidelity tradeoff. Rate limits and failure behavior are not covered, 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?

Two sentences, no filler: the first front-loads what is returned, the second front-loads cost and execution mechanism. Every clause carries information an agent cannot get from structured fields.

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

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

For a six-parameter tool with an output schema and full annotation coverage, the description supplies the missing pieces an agent needs: cost model, spend ceiling, account requirement, and the details-on/off latency tradeoff. It stops short of mapping itself against competing job-search siblings, which is the main remaining 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 coverage is 100%, so every parameter is already documented in the schema and the baseline of 3 applies. The description adds only a light gloss — '(with details)' for include_details and the list of fields that toggle with it — without clarifying formats for query, location, or date_posted_days 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+resource+scope: job listings from Naukri.com filtered by keyword and city, plus the exact fields returned. The Naukri/India framing implicitly separates it from the other job-board siblings (search_indeed_jobs, get_company_jobs, find_remote_jobs), but it never names or routes against them explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for India-based job searches because the description says 'India's largest job board.' There is no explicit when-to-use vs when-to-use-a-sibling guidance and no stated exclusions (e.g. remote-only roles, company-specific lookups).

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/non-destructive/openWorld, so the description correctly spends its words elsewhere: it discloses that the tool runs the Apify Actor tacps126/podcasts on the caller's own Apify account and gives a precise cost model ($0.004/podcast, $0.001/episode, $0.5 per-call cap). That is exactly the kind of billing and side-effect context an agent needs before spending money. Missing only failure behavior (e.g., invalid links, empty results).

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

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

A dense but well front-loaded two-sentence block: purpose and output fields first, then use cases and cost. Every clause carries information, though the enrichment-field list is long enough to be slightly sing-song; no filler sentences.

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 10 optional parameters, zero required fields, and a nested object, the description should state that at least one of search_terms, chart_genres, or podcasts must be supplied, and that mode inputs can be combined or not. It also leaves extra_input ("Advanced: extra Actor input fields") unexplained. The output schema covers return values and annotations cover safety, so the remaining gap is specifically invocation guidance.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the conceptual grouping behind the flat parameter list — search terms, top charts qualified by country and genre, or direct Apple/RSS links — and by linking "the latest episodes with audio and transcript links" to the include_episodes branch. It does not, however, mention the escape-hatch extra_input parameter or the interaction between inputs.

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?

Opens with a specific verb+resource ("Podcasts from Apple Podcasts search, top charts ... or links") and then enumerates exactly what comes back (owner name, contact email, website, language, categories, episode count, cadence, last episode date, optional episodes with audio/transcript links). No sibling tool covers podcasts, and the phrase "search, top charts ... or links" immediately conveys the three operating modes.

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

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

"Use for guest booking, sponsorship outreach and podcast research" gives concrete use cases and implicitly frames the audience for the tool. It stops short of when-not-to-use or how to choose among the three modes (search terms vs charts vs direct links), leaving that inference to the agent, so it is a clear 4 rather than a 5.

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