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

Goes well beyond the annotations (readOnly/openWorld/non-idempotent/non-destructive) by disclosing that the run executes on the caller's own Apify account, costs $0.004 per audited page, that empty runs are not charged per result, and that spend is hard-capped by run_max_charge_usd. These are exactly the billing and account facts an agent needs before invoking a paid, open-world tool.

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

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

Front-loaded with the purpose sentence, then an Input/Output line, then a compact paragraph on actor, price, and spend cap. No filler or marketing padding; the only slight redundancy is re-mentioning the charge cap that the schema already explains.

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

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

With no output schema, the description carries the burden of describing returns and does so concretely (SEO/AI scores, blocked crawlers, schema, FAQ, author/date, llms.txt, prioritized fixes, Excel). Combined with the pricing, account, and timeout context, an agent has everything needed to decide and invoke 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 all seven parameters are already documented with defaults, ranges, and behavior (e.g. crawlInternalLinks, generateLlmsTxt, maxPages cost capping). The description only restates 'Input: URLs' and echoes the run_max_charge_usd cap, adding no format or interaction detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: audit web pages for SEO and AI search (ChatGPT, Perplexity, Claude, AI Overviews) readiness. It also names the concrete outputs (scores, blocked crawlers, schema, FAQ, author/date, llms.txt, prioritized fixes, Excel), so an agent can distinguish it from every sibling tool in the list, none of which is an SEO/GEO auditor.

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?

Opens with an explicit 'Use this to...' trigger naming the exact task, which gives clear context for selection. It does not state when NOT to use it or name an alternative, but no sibling tool overlaps in function, so the absence of exclusions is a minor gap rather than a real ambiguity.

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, non-idempotent, non-destructive) it discloses the execution model, per-citation pricing of $0.003, that unresolved references are not charged, and that spending is hard-capped per call by run_max_charge_usd. This is exactly the billing and side-effect context an agent cannot get from 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?

Front-loaded with the capability and input/output contract before the operational boilerplate, and each sentence carries information. There is mild redundancy from the 'Input:'/'Output:' labels restating what the schema already enumerates, but nothing is wasted at length.

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

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

For a 14-parameter tool with no output schema, the description covers the return shape (per-reference APA/MLA/Chicago/Harvard/IEEE/Vancouver plus BibTeX and RIS), resolution source (Crossref), billing, and caps. Remaining gaps are minor, such as the structure of run results beyond the bibliography files.

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 14 parameters is already documented in the schema, including enum and range details. The description adds only framing (which identifier types are accepted, that all six styles are included in the price) rather than new per-parameter semantics, so 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 ('turn DOIs, ISBNs, PMIDs, arXiv IDs, titles or messy references into citations'), enumerates both accepted input forms and the eight output formats, and is clearly distinguishable from siblings such as reference_checker or literature_search.

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

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

Gives clear context for use: paste a bibliography or .bib/.ris contents, or pass individual references, and it explains that BibTeX/RIS entries are converted without a lookup while other identifiers are resolved. It never explicitly excludes cases or names a sibling alternative (e.g., when to prefer reference_checker), so it stops short of full when/when-not guidance.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds substantial behavioral context on top: the underlying Actor and that it runs on the caller's own Apify account, the $0.003 per-company price, the fact that zero-result runs are not charged, and a per-call spending cap. It also discloses ATS coverage (Greenhouse, Lever, Ashby and more), which tells the agent what the signal is derived from.

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

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

Two short paragraphs, front-loaded with the use case before the operational details, and almost no filler. The second paragraph blends a few topics (Actor, price, billing, cap) and the cost message is repeated from the schema, but the overall size is proportionate to an eight-parameter tool.

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

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

With eight optional parameters, no output schema, and an open-world web-scraping behavior, the definition covers everything an agent needs: accepted input forms, output columns, cost per company, no-charge conditions, a spending cap, and the existence of timeout/item defaults via environment variables. The output shape is described in prose precisely because no output schema exists.

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

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

Schema description coverage is 100% and every parameter carries its own prose explanation, so the schema does the heavy lifting and the baseline is 3. The description reinforces the primary input shape ('company domains, names or job-board links') and echoes the cost model, but it adds no parameter-level semantics 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 states a specific verb and resource: 'see which companies are hiring and for what', and then names the concrete output — one row per company with open jobs, new jobs in 7/30 days, teams hiring, leadership roles, and a hiring score. That is far more specific than a restated title. It never explicitly distinguishes itself from nearby siblings such as company_team_finder or company_website_enricher, which an agent could plausibly confuse with a hiring-intent tool.

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 this to see which companies are hiring' plus the accepted input forms (domain, name, or job-board link) gives a clear triggering context. The 'leave empty for a 3-company demo' note further helps an agent decide how to call it. There are no exclusions or named alternatives telling the agent when to pick a different tool 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 declare readOnly, openWorld and non-destructive, but the description adds material behavior the annotations cannot convey: the tool runs a specific Apify Actor on the caller's own account, costs $0.002 per person found, does not charge for runs that find nobody, and is capped per call by run_max_charge_usd. It also discloses the return formats (Excel and CSV), which is essential for an agent that later needs to consume output.

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 output fields and source constraint are front-loaded in the first sentence, with operational and pricing details in the second paragraph. Two short paragraphs with no filler. Slightly dense packing of output fields into one sentence keeps it from a 5.

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 ten-parameter, zero-required tool with no output schema, the description supplies exactly what is missing: the shape of the results (person attributes plus email pattern and file formats), the sourcing rule, and the billing model. Combined with the fully documented schema and readOnly annotations, an agent has enough to call it correctly and predict the outcome.

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 ten parameters is already documented in the schema, including defaults, ranges and the PANDA_* environment fallbacks. The description only reinforces the cost semantics of run_max_charge_usd, which the schema already states. Baseline 3 applies because the description adds little parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: find the people behind a company, sourced from its own team, leadership and staff pages, returning names, titles, seniority, department, emails, LinkedIn links and the email pattern. It also rules out a competing source ('No LinkedIn scraping'), which separates it from LinkedIn-based people search. It never names a sibling tool such as company_website_enricher or local_business_leads, so the differentiation is implicit rather than 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 opening 'Use this to find...' establishes the primary use case, and 'No LinkedIn scraping' plus 'from its own website' imply a source constraint. However, there is no when-not guidance, no prerequisites (other than the pricing/account note), and no named alternative for the case where a company has no team page or the agent needs LinkedIn-sourced contacts.

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 past the annotations by disclosing the economic profile that annotations cannot express: it runs the named Apify Actor on the caller's own account, costs $0.003 per enriched domain, non-matching/filtered domains are not charged, and spending is capped by run_max_charge_usd. That charge-on-read behavior is exactly the kind of hidden trait an agent needs before calling a readOnlyHint tool at scale.

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 paragraphs: capability and output fields first, then execution/cost mechanics. Every sentence carries information an agent needs, and the Actor URL plus pricing are compact rather than padding.

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, no-output-schema tool this covers the essentials: what comes back, what it costs, how spend and runtime are bounded, and how domains may be filtered without charge. The only gap is no indication of result shape or delivery mode (sync vs. dataset/Excel download), which matters since no output schema exists.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including ranges and defaults. The description adds only the cost linkage for maxDomains and the caps for run_max_charge_usd, both of which are also present in the schema text, so no meaningful meaning is added beyond structured data.

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 ('enrich a list of company domains') and enumerates the exact output fields: name, description, emails, phones, socials, tech stack, mail provider, DNS-verified SaaS, domain age. This is clearly distinguishable from the lead-gen siblings (trucking_company_leads, local_business_leads, company_team_finder) which target different entity sets.

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

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

Gives clear activation context ('in one run' over a list of domains), the input forms accepted, and a sensible default behavior when the list is empty (3-domain demo). It does not explicitly state when to prefer a sibling tool instead, and does not warn about which domains will be skipped, so it stops short of full alternative routing.

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

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

Goes well beyond the annotations by disclosing that it runs the Apify Actor pandadad0214/email-domain-security-checker on the caller's own Apify account, the per-domain price ($0.002), that empty runs are not charged per result, and that spend is capped by run_max_charge_usd. That billing/account context is exactly the costly, non-obvious behavior an agent needs before calling an openWorld tool.

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

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

Purpose and output are front-loaded in the first sentence, then cost/execution detail, which is a sensible ordering. It is dense but slightly redundant, since the pricing and cap are stated again in the run_max_charge_usd schema entry.

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

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

There is no output schema, but the description summarizes the return shape (per-domain rows, letter grade, risk, provider, senders, fixes, Excel/CSV), and it covers execution model, cost, and timeout behavior. For a zero-required-parameter bulk audit tool, 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 structured form, which sets the baseline at 3. The description adds little parameter-level meaning beyond restating the spend cap that already exists in run_max_charge_usd's schema 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?

States a specific verb+resource: check SPF, DKIM, DMARC, MX provider, BIMI and MTA-STS for a list of domains or emails. It also describes the shape of the result (one row per domain with an A-F grade, spoofing risk, provider, senders, fixes), so the agent knows exactly what it gets back. None of the listed siblings overlap, so no explicit differentiation 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?

"Use this to check ... for a list of domains or emails" gives a clear triggering context, and the empty-input behavior (3-domain demo) tells the agent it can call without arguments. There is no explicit when-not guidance or named alternative, which keeps it from 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?

The annotations already declare readOnlyHint, openWorldHint, non-idempotent and non-destructive, so the safety profile is largely covered. The description adds genuinely useful context annotations cannot carry: it runs on the caller's own Apify account, costs $0.002 per contract found, empty runs aren't charged, and spend is capped by run_max_charge_usd. However, it doesn't disclose runtime behavior, pagination/truncation of the result set, or failure modes when no filter matches.

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

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

Two short paragraphs: the first front-loads what the tool does and what goes in and out, the second covers execution, cost and caps. Nearly every sentence earns its place; the pricing sentence is dense but necessary given the per-result billing model.

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

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

For a 19-parameter tool with no output schema, the description does what's needed: it summarizes the result row shape (incumbent, UEI, amount, agency, end date, link, top competitors) and explains the billing and spend-cap model. An agent can decide whether to call this and predict the response without further information.

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

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

Schema description coverage is 100%, so the schema already documents all 19 parameters in detail, including enums, examples, defaults and ranges. The description's 'Input: keywords, NAICS, PSC, agency, state or set-aside' largely restates what the schema provides and adds no syntax or format guidance beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource — 'find US federal contract awards and contracts ending soon (recompete leads) from USAspending.gov' — and names the two operational modes (awards vs. recompete radar). An agent can tell this apart from adjacent lead-generation tools without opening the schema, since the sourcing domain and entity type 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?

It states the use case (award discovery and recompete lead generation) and the mode descriptions inside the schema clarify which mode serves which intent. It also notes the at-least-one-filter constraint. What's missing is an explicit 'use X instead when…' against the closest sibling, grants_finder, which targets a different but easily confused funding type.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false. The description adds valuable non-schema behavior: it runs a specific Apify Actor on the caller's own account, costs $0.003 per grant found, uncharged runs when nothing is found, and that spending is capped by run_max_charge_usd. It omits async/timeout failure behavior, which keeps it from a 5.

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

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

Three short paragraphs: purpose and I/O first, then execution/pricing/cap context. Front-loaded and free of filler, though the parenthetical '(Grants.gov scraper)' and repeated pricing framing add a little redundancy.

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 17-parameter scraper with no output schema, the description supplies the output shape (one row per grant with agency, dates, amount, eligibility, link), cost model, and spending cap. Cost, dispatch and pagination subtleties across sources are mostly covered; only runtime/timeout and failure behavior are left to the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly. The description adds only the broad filter categories (agency, date, amount) and the output row fields; it doesn't explain any parameter in more depth than the schema, so baseline 3 applies.

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

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

The description names a specific verb and resource set ('find US federal funding: open and forecasted Grants.gov opportunities plus funded NIH and NSF awards') and distinguishes the three sources' semantics (opportunities to apply to vs. awards already made). That differentiation from sibling tools like federal_contract_finder is explicit within the text.

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 when to use it ('Use this to find US federal funding') and gives the required input (keywords) plus optional filters, with source semantics explaining Grants.gov vs. NIH/NSF selection. It doesn't explicitly name a sibling alternative such as federal_contract_finder for contracts, so it stops 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?

Goes well beyond the readOnly/openWorld annotations by disclosing the execution model (runs the Apify Actor pandadad0214/literature-search on the caller's own Apify account), the billing rule ($0.003 per paper found, empty runs uncharged), and the per-call spending cap. That cost and auth-ownership context is exactly what an agent needs before invoking a paid, non-idempotent operation.

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

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

Two tight paragraphs: purpose and input/output first, then execution and pricing mechanics. Every sentence carries information an agent would otherwise have to dig out of structured fields, and nothing is redundant.

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 21-parameter paid tool with no output schema, the description compensates by enumerating the returned fields (DOI, citations, PDF link, retraction flag, citation and BibTeX) and the billing model. The remaining gap is routing guidance versus sibling research tools, which is not covered here.

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

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

With 21 parameters at 100% schema coverage, the schema already documents every field including enums and defaults. The description only summarizes them at a high level ('query or seed DOIs plus year and citation filters') and repeats the cost note for run_max_charge_usd, adding grouping but no new per-parameter meaning. 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 ('find real scholarly papers on a topic') plus the underlying corpus (250M+ OpenAlex works) and explicitly positions itself as a Google Scholar scraper alternative. It also names the input shape (query or seed DOIs plus year/citation filters) and the output fields, so an agent can tell this is a discovery tool rather than the citation/reference-checking 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?

'Use this to find real scholarly papers on a topic' gives a clear triggering context, and the seed-DOI framing clarifies the two operating modes (topic query vs. citation-graph exploration). It stops short of naming alternatives such as reference_checker or pubmed_evidence_table, so there is no explicit when-not guidance.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing the billing model ($0.001 per business found), that empty runs are not charged per result, the per-call spending cap via run_max_charge_usd, and that it executes a named Apify Actor on the user's own account. That is exactly the cost/auth/execution context an agent cannot infer from 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?

Front-loaded with what it does and what it returns, followed by a compact execution/pricing paragraph; every sentence carries information. The pricing and charge-cap sentence slightly overlaps the run_max_charge_usd schema text, which is the only redundancy.

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 13-parameter, no-required-input tool with no output schema, the description supplies both the invocation gist and the return shape (one row per business with address, phone, email, website, hours, socials, plus Excel/CSV). Combined with annotations covering safety and open-world behavior, 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 detail (including enums, ranges, and defaults), which sets the baseline at 3. The description only lightly reinforces cost control through run_max_charge_usd and adds no meaning about parameters the schema does not already cover.

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 ('list local businesses by category and city') with a concrete example ('dentists in Tempe AZ'), and names the data source (OpenStreetMap) so an agent can tell it apart from vertical lead tools like trucking_company_leads or podcast_leads_finder 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?

'Use this to list local businesses by category and city' gives a clear use case with an example query shape. It lacks any explicit exclusion or routing statement (e.g. when to prefer a sibling lead-finder over this one), so it stops short of the 5 bar.

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/non-destructive, and the description adds material context beyond them: it runs on the caller's own Apify account, costs $0.0015 per provider, empty runs are not charged per result, and spend is hard-capped via run_max_charge_usd. It stops short of describing runtime behavior (timeout defaults, long-running/async semantics for large states), which matters for a scraping tool.

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

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

Three short blocks ordered purpose → inputs/outputs → execution and pricing, with zero filler and the value proposition front-loaded. Minor redundancy ("NPI Registry" repeated, SEO-style parenthetical) keeps it from being maximally 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 14-parameter tool with no output schema, the description usefully states the returned columns and the billing model, and 0/14 required parameters is partially mitigated by naming the intended input trio. It never clarifies what happens if all geographic filters are omitted, which is the main open question for a call with no required 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 explains every one of the 14 parameters in detail (wildcards, ZIP prefixes, city/state interaction, primary-specialty toggle). The description adds only a high-level hint ("specialties in plain words plus states, cities or ZIP codes") and repeats the cost cap already in the schema, so it neither adds nor loses meaning.

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

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

Opens with a concrete verb+resource+source (build provider lists from the official NPI Registry) and immediately specifies the input shape (specialties plus states/cities/ZIPs) and output shape (one de-duplicated row per provider with NPI, name, specialty, address, phone). This is unmistakably a healthcare-provider lead builder, distinct from domain-adjacent siblings such as local_business_leads or trucking_company_leads.

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 this to build lists of US healthcare providers" plus the Input line gives a clear trigger condition and the minimum viable call shape. It does not, however, name any alternative tool or state when not to use it (e.g. versus local_business_leads for non-clinical businesses), so the routing guidance stops short of explicit 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?

Goes well beyond the readOnly/openWorld annotations: it discloses the per-page, per-table and per-OCR-page pricing, that empty runs are not charged per result, and that spend is hard-capped by run_max_charge_usd. It also names the underlying Actor and states it runs on the caller's own Apify account — key operational context for a paid, external run.

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 purpose and input/output shape in one tight sentence, followed by a separate paragraph on Actor, pricing and caps. Both paragraphs earn their place, though the pricing sentence is dense and packs several distinct facts (per page, per table, per OCR page, minimum-charge exclusion) into one run-on.

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 parameters and no output schema, the description does the necessary work by describing the return shape (one row per table with pages, header, row/column counts, cell data, plus Excel and CSV files). Combined with the schema's own cost-control parameters, an agent has enough 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 description coverage is 100%, so every one of the 15 parameters is already documented in the schema, including the enum meanings for detection and headerDetection. The description only restates 'PDF URLs or uploads plus optional page ranges', adding no syntax or trade-off detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('extract every table from PDF files into Excel and CSV') plus the OCR dimension for scans. No sibling tool touches PDFs, so the agent can identify this as the table-extraction tool 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?

'Use this to extract every table from PDF files...' gives clear context for when to reach for it, and the input line clarifies accepted sources (PDF URLs or uploads plus page ranges). It stops short of explicit exclusions (e.g. text-only PDFs or extraction of figures/non-tabular content), but with unrelated siblings that 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, openWorld, non-idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond that: per-result pricing of $0.004, no charge for empty runs, a per-call spending cap, and the requirement that it runs on the caller's own Apify account with a named Actor. It does not disclose runtime behavior such as typical latency or failure modes, so a 3 rather than higher.

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

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

Three short paragraphs, front-loaded with purpose, then output shape, then execution and pricing. Every sentence carries distinct information, and the repeated Actor URL is the only minor redundancy.

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 13 optional parameters and no output schema, the description compensates well by enumerating the returned fields (host, RSS email, website, socials, episodes, last episode date, has-guests signal) and the Excel/CSV formats. The remaining gap is that it does not clarify how the safety or cost profile changes if run_max_items and maxResults conflict.

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 13 parameters are already documented, which sets the baseline at 3. The description adds only marginal parameter meaning, tying cost to returned results and noting that run_max_charge_usd caps spend per call, but it does not explain the interaction between maxResults, run_max_items, and the charge cap.

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 and resource plus the intent: "find podcasts to pitch by topic," then immediately names the inputs (keywords, country) and the per-show output. No sibling tool in the list covers podcast discovery, so the purpose is unambiguous without cross-referencing anything.

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 context is clear: pitch prospecting by topic and country, with the note that an empty keywords list returns a 20-podcast demo, which tells the agent how to probe cheaply. It stops short of explicit when-not-to-use guidance or named alternatives, so it is clear context rather than full routing.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description still adds genuinely new operational facts: it runs a named Apify Actor on the caller's own account, charges $0.004 per article found, gives free runs that find nothing, and enforces a per-call spend cap via run_max_charge_usd. The cost and billing model is the key thing an agent could not infer from annotations. It does not explain how the Excel artifact is delivered back, which stays opaque.

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

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

Two tight paragraphs with an explicit Input/Output structure, front-loading the purpose before the billing details. The Actor URL is arguably filler for an agent, but otherwise every sentence carries information.

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

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

For an 18-parameter, no-output-schema tool, the description does the important work: it names the output columns, mentions PRISMA counts and the Excel deliverable, and explains the cost model. The remaining gap is how the returned Excel file is accessed, which an agent needs in order to complete the workflow.

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

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

Schema description coverage is 100%, so the parameters are already documented, and the description only summarizes them at a high level ('query strings plus optional date and study-design filters'). The one linkage it surfaces, that spending is capped per call by run_max_charge_usd, is also stated in the schema for maxResults and run_max_charge_usd. Baseline 3 is appropriate 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 and resource ('search PubMed and get a screening-ready evidence table') and enumerates the return columns (PMID, journal, study design, sample size, retraction status, PRISMA counts, Excel). This is far more than a restatement of the title. It never names the overlapping siblings literature_search or citation_formatter, so an agent must infer which one to pick.

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 this to search PubMed and get a screening-ready evidence table' implies the use case (systematic review screening) but gives no explicit when-not or routing to alternatives. With siblings like literature_search and citation_formatter in the same family, the absence of differentiation is a real gap.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false, openWorldHint=true), the description discloses the cost model ($0.01 per reference, no charge for runs that find nothing), the spending cap mechanism, and that the run executes on the caller's own Apify account. It also previews the result shape (one row per reference with OK/CHECK/FIX status), which the annotations do not convey.

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 paragraphs: use case and input/output up front, then operational facts (Actor, price, billing, cap). Every sentence carries information, though the Actor URL is slightly noisy and the second paragraph could be trimmed 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 14 optional parameters and no output schema, the description does the necessary extra work by summarizing the return shape and the billing/pricing behavior. Mode semantics (check vs monitor) are left to the schema rather than the description, but they are well covered there, so nothing critical 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 one of the 14 parameters is already documented in structured form, including modes, caps and defaults. The description adds only a high-level mapping of the three input types and the run_max_charge_usd cap, which is marginal beyond the schema — the baseline 3 applies.

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

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

The description names a specific verb (check) and resources (bibliography, DOIs, paper titles) and states the exact failure classes it detects: fake/AI-hallucinated, miscited, and retracted references. That framing cleanly separates it from sibling tools like citation_formatter or literature_search, which an agent can rule out from the description alone.

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

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

It gives a clear when-to-use statement and enumerates the three accepted input forms, so an agent knows how to invoke it. It stops short of explicit exclusions or naming the alternative tools (e.g. citation_formatter) for adjacent tasks, so it lands at 4 rather than 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?

Goes well beyond the annotations by disclosing the pricing model ($0.0025 per expert), the no-charge-for-empty-runs policy, that the call runs on the user's own Apify account, and that spend is hard-capped via run_max_charge_usd. These are exactly the operational facts an agent needs before triggering a paid, open-world 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?

Front-loads purpose, then input, then output, then operational/cost details — a readable order with no filler. The second paragraph is dense but each sentence (actor, price, billing exception, cap) carries distinct information.

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

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

For an 18-parameter paid tool with no output schema, the description supplies the missing return-value shape (ranked experts with ORCID, affiliation, h-index, topic papers) plus cost and timeout behavior. Minor gap: it doesn't mention the ranked-pool size limit (200 authors) or latency expectations in prose.

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

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

Schema description coverage is 100%, so every parameter is already well documented; the description only summarizes the input as "a topic plus country, institution and year filters." That summary adds almost nothing beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource — finding academic experts and KOLs on a research topic — and positions itself against an external reference ("Google Scholar author search alternative"), which makes it clearly distinct from siblings like literature_search or pubmed_evidence_table.

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 opening "Use this to find..." gives a clear usage context and the Google Scholar framing implies when an agent would pick it over a paper-search tool. It does not, however, explicitly name a sibling tool or state when-not to use it, so routing still requires 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?

The annotations already establish read-only, open-world, non-idempotent behavior, and the description adds important operational details: it runs the named Apify Actor on the user's own account, charges $0.002 per topic, does not charge per result for runs that find nothing, and supports a hard spending cap. It does not explain data freshness beyond the schema's 'ending yesterday' note or the exact response shape, but the cost and execution behavior are unusually 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?

The description is front-loaded with the core use case and then adds pricing and execution details in a compact second paragraph. The Apify Actor link and price information are relevant rather than filler. It could be slightly tighter, but there is little wasted wording.

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 10-parameter tool with an optional schema and no output schema, the description covers the main outputs (daily and monthly views, 30-day and year-over-year change, peaks, spike days, a 0–100 index, Excel and CSV), cost model, and execution environment. It does not describe pagination or precise response structure, but the schema already documents inputs thoroughly and the annotations cover safety semantics.

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

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

Schema description coverage is 100%, so every parameter is already documented in the input schema. The description does not add parameter-level meaning beyond mentioning topics, Excel/CSV output, and the spending cap. This meets the baseline for a fully documented schema but does not enrich parameter interpretation.

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 statement: compare public interest in topics, brands, products, or people over time using Wikipedia pageview counts. It clearly distinguishes the tool from Google Trends by naming the underlying data source and listing the metrics it returns. The purpose is immediately understandable 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 a clear use case: comparing public interest in topics over time with real view counts. It does not name when-not-to-use conditions or explicit alternatives, but the sibling tools are largely unrelated research utilities, so there is little ambiguity to resolve. The usage context is adequate, though not fully prescriptive.

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, non-destructive, open-world, non-idempotent, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: it runs a named third-party Apify Actor on the caller's own Apify account, charges $0.002 per carrier returned, does not charge per result for empty runs, and enforces a per-call spend cap via run_max_charge_usd. Latency expectations (run_timeout_secs) are left to the schema, which keeps this just 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?

Two tight paragraphs: the first front-loads the value proposition and data fields, the second covers execution, pricing, and the spend cap. Every sentence carries weight, though the field list in sentence one is somewhat dense and could be trimmed for scanability.

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 24-parameter tool with no output schema, the description does the necessary work: it lists the returned data fields and the export formats so the agent knows what comes back. The main remaining gap is that mode selection — the single most important parameter — is explained only in the schema, not the description.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already explains every filter. The description's 'filter by state, date, fleet and cargo' merely summarizes a subset of the 24 parameters and adds no syntax, defaults, or interaction rules (e.g. how daysBack behaves differently per mode). It does add that output is available as Excel and CSV, which is return-format information rather than parameter meaning.

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

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

States a specific verb and resource ('get fresh trucking company leads from official FMCSA data') and enumerates exactly what a lead contains: USDOT carriers, brokers, freight forwarders, phone, email, officers, fleet size, drivers, cargo, authority. The FMCSA/trucking domain cleanly separates it from siblings like local_business_leads and podcast_leads_finder without needing to name them.

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

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

The opening 'Use this to get fresh trucking company leads' plus the filter list implies the lead-generation use case, but the description never states when to prefer this over a sibling lead tool, nor any exclusion. The three operational modes (new/search/lookup) that really drive selection are documented only in the schema, not the description.

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