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

With no annotations provided, the description carries the full behavioral burden and adds meaningful context: billing is charged to the user's own Apify account at roughly $0.05 per company, most sub-data comes from named scraper Actors, and the hiring-signals component returns warnings rather than errors when no ATS board is found. It still does not state authentication requirements or explicitly confirm read-only 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 two sentences, front-loaded with the core purpose and followed by pricing. The long first sentence is an efficient enumeration of included data categories, and no sentence 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?

For a complex 8-parameter aggregate with no annotations and no output schema, the description explains the row-level output, the main data categories, the one-row-per-domain behavior, and the cost model. It is nearly complete, though it omits explicit auth requirements and alternative-tool routing.

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, including the domains format and each include flag. The description adds no parameter-level syntax or constraints beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: it turns a domain into a rich company profile row. It enumerates the merged data categories (contacts, tech stack, DNS/e-mail security, TLS, SEO, hiring, company facts) and makes clear this is an aggregate rather than a single-purpose sibling like hiring_signals.

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 explains what the tool does but gives no explicit when-to-use, when-not-to-use, or alternative guidance. It does not say whether to prefer this aggregate over individual sibling tools such as hiring_signals or wikidata_entity_enrichment when only one data category is needed.

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?

With no annotations, the description carries the full burden and does so well: it discloses cost and billing model (~$0.0005/email billed to your own Apify account), output cardinality (one scored row per address), the DNS-over-HTTPS mechanism, and the key limitation of not probing SMTP mailboxes.

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 capability list and followed by a compact pricing note; both earn their place. Slightly dense but free of 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 tool with no output schema or annotations, the description supplies the return shape (one scored row per address) and the classification dimensions a consumer can expect, plus cost and method. It stops short of enumerating the exact fields in each scored row, which is a minor residual gap.

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

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

Schema description coverage is 100%, so both the emails array and checkMx flag are already thoroughly documented in the schema (including defaults, examples, and behavior). The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (validates) and resource (list of email addresses) and enumerates the exact checks performed: syntax, MX/A DNS records, disposable/free-provider/role classification, and typo suggestions. It also scopes out what it does not do (no SMTP mailbox probing), so an agent knows precisely what it gets.

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 of use — validating a batch/lead list, one row per address — and a meaningful boundary (no SMTP mailbox probing). It lacks explicit when-to-use-vs-alternative guidance, but the sibling tools are unrelated Apify actors, 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?

With no annotations the description carries the full behavioral burden, and it delivers unusually well: it discloses billing to the user's own Apify account with a per-result price, notes that maxJobsPerCompany is deliberately ignored in company mode, and warns that SmartRecruiters/Workday never return descriptions. It omits failure modes and any rate/quota behavior beyond cost.

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 purpose and pricing front-loaded; every clause carries information. It is slightly run-on, but nothing is 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 four-parameter scraper with no output schema and no annotations, the description covers output shape, cost, and per-source limitations well enough to call it correctly. Return-field details are left implicit, which is a minor gap given 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 all four parameters in detail; the description adds only the cost framing around result count. 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?

States a specific verb+resource ('Scrape company job postings and hiring signals') and names the exact ATS sources (Greenhouse, Lever, Ashby, Workable). The output-shape clause ('one row per job, or one hiring summary per company') further distinguishes it from the sibling remote_jobs_aggregator.

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?

Each outputMode option carries an explicit 'best for' context (job aggregators/recruiters vs. sales intelligence/competitor watching), which is genuine when-to-use guidance. It stops short of naming or excluding sibling tools, so it is clear context without 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?

With no annotations, the description carries the full behavioral burden and discloses important traits: delayed rather than real-time data, no API key requirement, billing to the user's Apify account, and approximate per-quote cost. It omits rate limits, error behavior, and data coverage caveats, so it is strong but not exhaustive.

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

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

The description is two well-structured sentences, front-loading what the tool does and then adding billing context. Every clause contributes useful information without repetition or 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?

Given a rich input schema and no output schema, the description supplies the key return fields, data delay, source, and cost. It could elaborate slightly on output shape or symbol limits, but it is complete enough for an agent to call 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 all four parameters thoroughly. The description only alludes to optional history and does not add syntax, constraints, or enum meaning 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—live-delayed quotes for stocks, ETFs, indices, crypto, and FX—and specifies the scope of one call returning price, change, day range, volume, and optional history. This clearly distinguishes it from the unrelated sibling tools.

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

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

The description provides useful context such as live-delayed data, free public endpoints, no API key, and Apify billing, but it does not explicitly say when to use this tool versus alternatives 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?

With no annotations, the description carries the full burden and does a good job: it discloses the data source (free Overpass API), the cost model (~$0.0005 per place, billed to the caller's Apify account), and the result cardinality (one row per POI). It omits auth prerequisites and rate/quota limits, which is the remaining gap.

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

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

Two sentences, front-loaded with what the tool returns and how the search area is defined, followed by the billing caveat. No filler or 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?

No output schema exists, but the description states the return shape ('one row per point of interest') and the cost implication, covering what an agent needs to decide and call. Missing only ancillary details such as how categories combine with modes and any hard caps beyond maxResults.

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 (mode, bbox, areaName, latitude/longitude, categories, maxResults, radiusMeters) is already fully documented with examples. The description only restates the three area modes and the merge behavior for categories, adding little 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 concrete verb+resource ('returns shops, cafes, restaurants and any tagged place') with explicit scope (radius, bbox, named area) and output granularity (one row per POI). No sibling tool (hiring_signals, market_quotes, etc.) overlaps with POI extraction, so differentiation is implicit and 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?

Names the three search-area modes and the backing service, which tells the agent how to frame a request, but offers no explicit when-to-use/when-not or alternative tools to prefer for other geodata needs. Context is clear; exclusions are absent.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: results are merged and de-duplicated across feeds, billing hits the caller's own Apify account at ~$0.001/job, and the schema adds that bad board slugs return an error row instead of failing. It stops short of covering rate limits, runtime, or partial-failure semantics, but the billing and de-dup disclosures go well beyond 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?

Two sentences, front-loaded with the core action and resource before the pricing note. No filler, no repetition of schema content, and every clause earns its place.

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

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

For a 6-parameter, all-optional aggregation tool with no annotations and no output schema, the description covers the source set, the de-duplication/row model, the returned fields, and the cost model — enough for an agent to call it correctly. Minor gaps remain around failure modes and result volume, but those are largely covered by the schema.

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

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

Schema description coverage is 100%, so every parameter (maxJobs, sources, keywords, ashbyBoards, greenhouseBoards, postedWithinDays) is already fully documented in the schema, including examples and edge-case behavior. The description adds no additional parameter semantics beyond restating the aggregated fields, so the baseline of 3 applies.

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

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

States a specific verb (merge and de-duplicate) applied to a specific resource (remote job listings) from three explicitly named sources, and describes the output shape (one clean row per job with title, company, salary, tags, apply link). No sibling tool overlaps this function, and an agent can tell exactly what it produces.

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

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

The description implies the use case (aggregating remote job feeds) and gives useful cost/billing context, but never states when to use it versus alternatives or when not to use it (e.g. vs. a single-source scraper). Usage is inferable rather than directed.

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?

No annotations are provided, so the description carries the full disclosure burden. It does add genuinely useful behavioral context — per-result billing to the caller's own Apify account (~$0.001/result) and the 'one row per entity' output shape — but it omits auth/credential requirements, rate limits, and failure behavior on unresolved names.

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 resolution capability and output contents before the billing note. Efficient and readable, with no padding or repetition.

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 appropriately lists the return contents (facts, identifiers, social/media links, one row per entity) and notes the billing model. For a read-only enrichment tool this is nearly complete, though credential expectations for the Apify account are unstated.

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 entities, language, and entityType with examples and enum meanings. The description adds no parameter-level detail beyond what the schema supplies, making 3 the correct baseline.

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 ('resolves a QID, company name, or Wikipedia URL to its Wikidata item') and enumerates the returned fact categories, so the agent knows exactly what the tool produces. It does not, however, distinguish itself from overlapping siblings like company_360, which also appears to produce company enrichment.

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 explains what inputs are accepted but never states when to choose this tool over the alternatives (company_360, yc_companies_scraper, etc.), nor any exclusions or prerequisites beyond the billing note. Usage is only weakly implied by the input-type enumeration.

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?

With no annotations, the description carries the full behavioral burden and does well: it discloses billing to the user's own Apify account (~$0.002 per result), explains that maxCompanies is the billed unit, and notes that includeFounders triggers an extra profile request and can return null for speed. It does not cover authentication setup or rate limits, 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?

Two sentences, front-loaded with the purpose and output fields, followed by the cost model. Every phrase earns its place, and there is no redundant 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?

No output schema exists, so the description usefully summarizes the return shape as 'one row per company' and lists the included fields; it also covers non-obvious cost behavior. It lacks details on auth/rate limits, but it is complete enough for selection given the rich input 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 fully documents all 8 parameters with defaults, enums, and constraints. The description adds no parameter-level syntax or behavior 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 states a specific verb and resource: 'Y Combinator company directory scraper,' and enumerates the returned fields (batch, industry, hiring status, one-liner, description, founder details), so the agent knows exactly what it does and returns. It does not explicitly differentiate itself from siblings such as company_360 or hiring_signals, so it falls short of a 5.

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

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

It offers no when-to-use or when-not-to-use guidance relative to alternatives, and does not name or exclude any sibling tool. The mode and query options are parameter-level, not routing guidance, so an agent must infer its place in the toolset entirely from the resource name.

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