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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations lack: the pay-per-result cost model with specific prices (run start $0.003, per website $0.02, google search page $0.004). It doesn't cover return format or rate/pagination behavior, so a 3 is appropriate.

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

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

Two sentences, front-loaded with the core capability, followed by the cost model. Every clause carries information. The pricing enumeration is slightly dense but relevant to an agent assessing execution.

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 detection tool with full schema coverage and no output schema, the description covers purpose and cost reasonably well. However, with no output schema present, it could describe what the detection returns (tech categories, identity fields, signals) and it omits usage routing, leaving the definition adequate but with clear gaps.

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 both parameters (websites, includeIdentity). The description adds no syntax or format 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+resource ('Detects the technologies of websites') and quantifies scope ('280+: CMS, e-commerce, analytics, consent tools'). It also mentions the company-identity/sales-signal enrichment, though it doesn't explicitly distinguish itself from the sibling get_company_behind_website, whose scope overlaps via the legal-notice identity extraction.

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 never says when to use this tool versus alternatives or in what scenarios. With a sibling like get_company_behind_website and get_run_results, an agent gets no routing guidance. The only extra context is pricing, which is not usage guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely extra context beyond the structured fields: official-register provenance, an explicit exclusion (no director names), a domain-creation-date signal, and per-result pricing tiers, which functions like a rate/cost disclosure.

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 is returned before the pricing detail, and every clause carries information (geography, source, exclusions, cost). It is dense but not padded; only the pricing enumeration at the end is slightly heavy for a description field.

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, zero-required, filter-style tool with no output schema, the description supplies what the schema cannot: data provenance, geographic coverage caveats, the meaning of the lead signals, and cost per result. Nothing essential 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% and the enum for 'output' is documented in the schema itself, so the baseline is 3. The description only restates the scope (US/UK/FR, official registers, companies only) and adds pricing tied to result types, without meaningful parameter 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 precise verb and resource (find newly registered companies without a website) plus exact scope: UK, France, and five named US states, sourced from official registers. This is readily distinguishable from siblings like search_uk_companies or search_french_companies because the no-website filter and recency window are named 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?

The description conveys the context in which this tool applies (new companies lacking a website) but never routes the agent between this and the overlapping sibling tools (search_uk_companies, search_french_companies), nor states when not to use it. Usage is implied rather than explicit.

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 and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely useful non-obvious context: the pay-per-result cost model with per-call and per-result prices, which affects how an agent should budget and invoke the tool. It stops short of any rate-limit or reliability notes.

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 functional scope before the pricing detail. Every clause carries information. The pricing sentence is dense with three price points but is relevant to invocation cost, not 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 9-parameter, no-required-parameter tool with no output schema, the description covers both modes and the cost model, which is what an agent needs to decide and budget. It does not describe the returned structure or any caps on result volume, leaving a minor gap that the schema partially fills via maxDestinationsPerAirport.

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

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

Schema description coverage is 100%, and the schema itself explains modes, defaults, formats, and even the per-leg pricing note. The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific resource (Ryanair fares) and cleanly separates two operating modes: the per-day fare calendar for a route, and every destination under a price cap from an airport. An agent can tell what it does without opening the schema. It does not, however, differentiate itself from the sibling search_flights tool, which is the nearest 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?

The two modes are implied by which parameters are supplied (routes vs airports), so usage is inferable rather than stated. There is no explicit 'use this instead of X' guidance and no exclusion relative to search_flights, so the agent must reason about selection. Adequate but with a clear 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely new context beyond structured data: the pay-per-result billing model with specific prices (run start $0.003, review delivered $0.0002) and the aggregated summary output. Only the run-behavior (async job, pagination) is left 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 sentences, front-loaded with the capability and returned fields, then pricing. Every clause carries information, though the title's 'All Countries' is somewhat redundant with the body.

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, zero-required tool with no output schema, the description covers what it returns, the two stores, and the cost model, which is enough to call it correctly. Minor gaps (async execution, run limits) remain but are non-blocking.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, including examples and the country enum. The description only loosely references 'the countries you choose' and 'summary by version and country,' adding no syntax or default detail beyond the schema. Baseline 3 is correct.

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 App Store and Google Play reviews of an app) and enumerates the returned fields (rating, text, version, date, developer reply, summary by version/country). No sibling tool covers reviews, so the agent can distinguish it instantly.

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 purpose (use it to scrape reviews for chosen countries), but there is no explicit when-to-use vs when-not, no prerequisites, and no alternative named. Adequate but leaves selection reasoning to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful beyond-annotation context: the per-event cost model (run start $0.003, website identified $0.004, google search page $0.004) and the Apify account billing requirement, which the 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?

Two front-loaded sentences: the first states purpose and return payload, the second states the cost model. No padding 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?

With no output schema, the description carries the return-value burden and does so by enumerating the extracted fields. Combined with readOnly/openWorld annotations and 100% schema coverage, an agent has everything needed 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 both parameters (websites, verifyInRegistry) are fully documented in the schema. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource (reads the legal notice/Impressum of European websites) and enumerates the returned fields, so the agent knows exactly what it extracts. This clearly separates it from siblings like search_uk_companies or validate_eu_vat_numbers, which search or validate by name rather than resolving a website to a company.

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 input (you supply websites), but there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings. The agent must infer that this is the website-to-company path rather than a registry lookup.

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 and openWorld, so the safety profile is covered. The description adds real behavioral value beyond that: the pay-per-result cost model ($0.003 start, $0.0002 per row) and the fact that tomorrow's data is published around 13:00 CET — both actionable expectations.

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?

Dense and front-loaded: resource and scope first, then defaults, then pricing. Every sentence earns its place, though the pricing sentence is somewhat tangential to invocation.

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 steps in to describe the returned shape (per-zone/day summary with cheapest window, min, max, average, negative-price hours), covering what an agent needs to interpret results.

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 five parameters are already documented in the schema, including defaults and semantics. The description's mention of summary fields and negative-price hours adds context but no parameter-level syntax beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('Day-ahead electricity prices') with scope (40+ European bidding zones, hourly or 15-minute) and output content. An agent can immediately tell what this tool returns and no sibling covers the same ground.

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

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

Gives concrete usage context: omitting dates returns today and tomorrow, with the publication timing noted. It doesn't state exclusions or point at alternatives, but the tool's niche is unique among its siblings so no routing guidance 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-annotation context: per-result pricing (run start $0.003, building permit $0.003) on the Apify account. It does not describe rate limits, pagination, or result ordering beyond what the schema states.

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, both front-loaded: what data is returned first, then cost. No filler. Slightly terse on usage, but structure is clean and efficient.

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 helpfully enumerates returned fields (project, dwellings, floor area, status, applicant SIREN), compensating well. Annotations cover safety and the schema covers all parameters. Missing only minor operational detail like pagination or ordering, which the schema partly implies.

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 each parameter (statuses, locations, monthsBack, permitTypes, etc.) is already fully documented in the schema, including defaults and semantics. The description adds no parameter syntax or format detail beyond that, 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 resource (French building permits from the official Sitadel register) and enumerates the returned fields — project, dwellings, floor area, status, and applicant company SIREN. It is clearly distinct in domain from siblings like get_france_property_sales or search_french_companies, though it does not name 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?

No guidance on when to use this tool versus alternatives. There are several adjacent French/company siblings (get_france_property_sales, search_french_companies) and no routing or exclusion is offered. The agent must infer usage entirely from the data domain.

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 and openWorldHint=true, so the safety profile is covered. The description goes beyond them by disclosing the pay-per-result cost model (run start $0.003, energy rating $0.001), a genuinely useful economic trait absent from structured fields. It does not describe pagination cost behavior, which keeps it short of 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 with zero waste: the purpose and returned fields are front-loaded, then the pricing detail follows. 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?

With no output schema, the description carries the return-value burden and does so explicitly (energy and CO2 class, surface, consumption, estimated bill). Safety is covered by annotations and cost by the description, leaving nothing an agent needs 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 schema already documents all four parameters (including the F/G 'passoires thermiques' nuance and Paris/Lyon/Marseille arrondissement behavior). The description only obliquely echoes the 'city or postal code' location input and adds no syntax 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 (energy performance certificates / DPE for homes in a French city or postal code) and names the authoritative source (ADEME open data). The listed payload (energy and CO2 class, surface, consumption, estimated yearly bill) makes it unmistakably distinct from sibling French-data tools like get_france_property_sales and get_france_building_permits.

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 data is but gives no routing guidance: no when-to-use conditions and no mention of alternatives against siblings like get_france_property_sales. An agent must infer the use case from the resource name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful cost behavior (pay-per-result: run start $0.003, station $0.001) and the sorting rule, but says nothing about auth, rate limits, or return shape.

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 with the core purpose front-loaded and the pricing note trailing. No filler or restated naming.

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, 100%-documented search tool with no output schema, the description covers purpose, ordering, and cost. Only the returned fields/format are left implicit, which is a minor gap.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description only reinforces the 'cheapest first / first fuel drives sorting' behavior already stated in the schema, adding no new syntax or format detail.

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 (live official fuel prices of stations), the geographic scope (French city, postal code or GPS point), and the ordering (cheapest first). It is unmistakably distinct from siblings like get_electricity_prices or get_france_property_sales.

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 the tool is useful (looking up nearby station fuel prices for a French location), but it names no alternatives and gives no when-not-to-use guidance. Usage 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond structured fields: an explicit pay-per-result pricing model (run start $0.003, $0.0005 per sale), which is actionable operational information for an Apify actor.

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 purpose and output fields, with the pricing note parked at the end. Dense but every clause adds information; 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 8 fully-documented parameters, no output schema, and read-only annotations, the description covers what the tool returns, its geographic scope, and its cost model. Nothing essential for correct invocation is missing, though return-format and volume expectations 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 8 parameters in detail (year ranges, INSEE codes, surface filters, yield/energy flags). The description adds little parameter-level meaning beyond restating that a city or postal code is the target. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description gives a specific verb+resource (real property sales in France, official DVF data) plus the returned fields (price paid, price per m2, surface, rooms, date, energy class, median summary). This is clear enough to distinguish from generic data tools, though it never explicitly distinguishes itself from France-specific siblings like get_france_building_permits or get_france_energy_ratings.

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 scope ('for a city or postal code') but gives no when-to-use/when-not guidance and names no alternative among the France siblings. The agent must infer usage from the domain alone.

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

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

Annotations already declare readOnlyHint=true, and the description adds genuinely new behavioral context beyond that: 'Free: no new run is started', which tells the agent this poll costs nothing and does not re-trigger work. It does not describe what the result payload contains, but it covers the cost/idempotency trait that matters most for a polling call.

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

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

Two short sentences, front-loaded with what the tool does and followed by the cost behavior. Nothing is redundant and no padding 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?

For a one-parameter async polling tool with full schema coverage and a documented read-only annotation, the definition supplies everything needed: the trigger condition, the argument source, and the fact that it is free. No output schema exists, so return-shape documentation is not required.

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 a single required parameter whose schema description already says it is 'the runId returned by a previous tool call.' The description restates that origin, adding no syntax, format, or edge-case 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 (fetches the results of a previous call) plus the qualifying condition that the call was still running. This is unambiguous and clearly distinguishable from every sibling tool, which are all discovery/search tools rather than an async continuation endpoint.

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 an explicit trigger condition ('a previous call that was still running when it returned') and tells the agent where the argument comes from ('use the runId it gave you'). No alternatives or exclusions are named, but no sibling occupies this niche, so the omission 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 only declare readOnlyHint and openWorldHint. The description goes beyond them with concrete cost behavior: pay-per-result pricing ($0.003 per run start, $0.003 per open tender, $0.005 per award) and billing tied to maxItems. It does not cover pagination or rate limits, but the economic traits are the operationally important 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?

Two sentences, front-loaded with the resource and sources, followed by filter dimensions and price. Dense but no filler. The pricing roster is slightly list-heavy within a description, though it earns its place given pay-per-result billing.

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 compensates by enumerating the returned fields for both modes and disclosing cost per result, which an agent needs before setting maxItems. It omits result format and pagination details, keeping it short of fully complete for a 9-parameter, 0-required search 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 schema already documents all 9 parameters, including enum values and defaults. The description adds only a high-level echo of the filter axes (keyword, CPV, country) plus the maxItems default of 25, which is a small increment over 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 (search public tenders and contract awards), names the data sources (TED, BOAMP, DECP), and enumerates the fields returned (buyer, value, deadline, winner, amount, bid count). No sibling tool overlaps, so differentiation is trivially satisfied.

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

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

Usage is implied through the filter axes (keyword, CPV code, country) rather than stated as when-to-use guidance. There are no competing siblings that require routing, and the schema fields carry the how-to-use load, so this is adequate but not explicit.

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 only supply readOnlyHint and openWorldHint, so the description adds meaningful behavior beyond them: the pay-per-result cost model with explicit run start ($0.003) and per-flight ($0.002) charges, which affects how an agent should batch calls. It does not discuss rate limits or result caps beyond maxFlightsPerSearch.

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 with no filler: purpose and return fields first, then the cheapest-day pattern, then cost. Each sentence earns its place, though the cost sentence could arguably live in metadata given other tools omit it.

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 read-only search with no output schema, the description covers what is returned (airlines, times, stops, price, route price range) and highlights the key param interaction, which is enough for correct invocation. It stops short of routing guidance versus the sibling flight 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 all 11 parameters are already documented in the schema, making 3 the baseline. The description adds only marginal parameter meaning by linking numberOfDates with cheapestOnly for price-calendar use, which the schema partially covers already (numberOfDates mentions finding the cheapest day).

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 ('Flight prices from Google Flights for a route and one or several departure dates') and enumerates the returned fields (airlines, times, stops, price, typical price range). However, it never distinguishes itself from the flight-related sibling find_ryanair_fares, leaving the agent to guess which flight source to use.

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 gives one concrete usage pattern ('Use numberOfDates with cheapestOnly to find the cheapest day to fly'), which is helpful but narrow. It offers no when-not guidance and does not mention the sibling find_ryanair_fares or any other alternative for flight fare 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context: pay-per-result billing granularity (run start $0.003, company $0.004, website & contacts $0.025) and the verification requirement inside findContacts (the SIREN must appear on the site's legal notice, billed only when a website is found). It does not, however, describe auth/account prerequisites or scraping latency.

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

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

Two sentences: the first front-loads the resource, filters and returned data; the second carries the pricing model. Dense and largely waste-free, though the cost figures could arguably be deferred to documentation.

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 scraper with no output schema, the description covers scope, filtering facets, returned data shape and cost behaviour, which is close to what an agent needs. It stops short of describing result structure or volume/pagination expectations, which is the main remaining gap given there is no 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 the schema already documents every parameter with examples. The description only restates the same facets (activity, department, size, optional contacts) at a higher level and adds no syntax or format 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 resource (French companies from the official SIRENE register) with a specific retrieval action and enumerates the returned data: legal data, headquarters, directors, and optionally a verified website with emails and phones. It is trivially distinguishable from siblings such as search_uk_companies or get_company_behind_website.

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 through the filter vocabulary (activity/NAF, department, size) but never states when to choose this tool over alternatives like find_new_companies_without_website or search_uk_companies, nor any exclusions. Usage is inferable but not 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 only declare readOnly and openWorld, so the description carries the burden of disclosing cost behavior: pay-per-result pricing with explicit rates (run start $0.003, hotel $0.002, booking-site $0.003) and the fact that includeBookingSites adds a billed extra page per hotel. This is genuinely useful operational context beyond the annotations, though it omits rate-limit/runtime or failure 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?

Three dense sentences that front-load what is returned and then the booking-site option and cost model. No filler, though the pricing sentence is appended rather abruptly rather than integrated into the flow.

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 usefully names the returned fields (price per night/total, rating, stars) and the cost model, and all 10 parameters are documented in the schema. It could be stronger on pagination/volume behavior and what happens with partial inputs, but it is adequate for this 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 schema already explains adults, nights, currency, dates, sortBy, minRating, locations and hotels in detail; the description adds little parameter-specific meaning. The baseline of 3 applies because 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 (hotel prices from Google Hotels) with the scope of what is returned: price per night and total, rating, stars, and optionally per-booking-site prices. It is easily distinguished from siblings like search_flights and find_ryanair_fares, which cover air travel rather than lodging.

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 through includeBookingSites ('the price of each hotel on every booking site') and notes it is 'Always on for tracked hotels', but it never says when to choose this tool over an alternative or when not to use it. There is no exclusion or prerequisite guidance, only conditional context for the booking-site option.

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 readOnlyHint=true and openWorldHint=true, so the description is not burdened with safety disclosure. It adds genuinely useful non-annotation context: a pay-per-result billing model with concrete unit prices and a note that cost scales with returned ads and detail level. It still omits pagination behavior and rate limits, 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, front-loaded with what is returned and followed by the cost model; nothing is wasted. The pricing sentence is dense but each clause carries distinct information an agent needs before invoking a paid 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?

For an 8-parameter, no-required-params search tool with no output schema, the description covers the return fields, geography, and cost — which is the material information. Pagination/ordering behavior and the shape of the result payload are left unspecified, but the schema carries defaults and the annotations cover the safety profile.

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

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

Schema description coverage is 100% and the schema already documents every parameter with examples and defaults (radius rounding, ~25 ads per page, keyword-per-location semantics). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description names the resource (ads from Kleinanzeigen, Germany) and enumerates the returned fields (price, location, posting time, deal score), so the agent knows exactly what it gets. It does not explicitly differentiate itself from close siblings like search_second_hand_europe or search_vinted, 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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The reader must infer from the parameter set (no required params) that this is a keyword/location search tool, and nothing tells the agent when to prefer it over the Europe-wide or Vinted alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds real value beyond them: currency conversion into euros, a deal score, a per-country median, and explicit per-result pricing ($0.003 run start, $0.002 per listing). Auth/rate-limit specifics are absent, keeping it out of the top band.

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, and the geographic scope plus output contents are front-loaded before the pricing note. The superlative claim ('the biggest') is mild marketing rather than wasted length.

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

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

With no output schema, the description usefully sketches what comes back (listings, euro prices, deal score, median price per country) and discloses the pay-per-result cost model. The main hole is sibling differentiation, which matters here given search_vinted and search_kleinanzeigen sit alongside 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 every parameter is already documented with useful detail (currency conversion targets, enum meaning, per-marketplace defaults). The description adds essentially nothing parameter-level beyond echoing euro conversion, 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 ('search... second-hand marketplace of up to 18 European countries') and names concrete marketplaces, so the agent knows this is a multi-country second-hand listing search. However, it never distinguishes itself from the direct siblings search_vinted and search_kleinanzeigen, which cover single marketplaces, so routing still needs inference.

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

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

There is no explicit when-to-use or when-not guidance, and the obvious alternatives (search_vinted, search_kleinanzeigen for single-marketplace queries) are never mentioned. Some usage hints live in the schema ('Newest first is best for monitoring'), but the description itself gives none.

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 readOnlyHint=true and openWorldHint=true already covering the safety profile, the description adds genuinely useful non-annotation context: the per-result cost model broken out by operation type (run start, shop, company profile, review) and the implicit requirement of an Apify account. It does not cover run duration, volume limits, or failure behavior, but the annotations carry the main burden.

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 before the pricing detail; no filler. The pricing clause is dense and list-like, but it is the only place cost is disclosed, so it earns its space.

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

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

With no output schema, the description does part of the return-value job by naming the fields coming back (company, contact, rating, review volume) and the dual shop-vs-review output modes. Missing are output format specifics and any mention of how results are delivered per run, but for a read-only scraper this is largely sufficient.

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 six parameters thoroughly (including the 12-month review window and the '10,000+ is a large shop' heuristic). The description's cost list loosely maps result types (shop, company profile, review) to what the run will produce, adding modest value beyond the schema, which justifies the baseline 3 rather than lower.

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 resource (Trusted Shops listings) and two distinct modes: shop discovery by keyword/country, and review retrieval for a given shop, plus the fields returned (company, contact, rating, review volume). It does not explicitly contrast with any sibling, but no sibling overlaps this domain, so ambiguity is low.

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 two modes (search by keyword/country vs. fetch reviews for named shops) imply usage, and the 'pay per result' line hints that broad runs are costly, but the description never states when to prefer this tool or which mode to pick for a given goal. The real routing guidance ('export the reviews of your own shop or competitors') lives in the shops parameter 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.

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

Annotations declare readOnlyHint and openWorldHint, and the description adds genuinely useful non-annotation context: the Apify pay-per-result billing model with concrete prices (run start $0.003, company $0.004, contacts $0.025). It still does not disclose pagination or result-volume limits for a tool that can return 10,000+ items, but the cost transparency is a real addition.

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 sentence covering data scope followed by a short pricing sentence; the core scope is front-loaded and there is little filler. Slightly compressed phrasing, but no wasted 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 no output schema, the description usefully enumerates what comes back (profile, registered office, officers, and optionally website/emails/phones). For an all-optional 8-parameter search that is largely complete; only return-volume/pagination behavior and the relationship to the new-companies sibling are unaddressed.

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 location, sicCodes, statuses, findContacts, etc. The description only restates the same fields at a high level (SIC code, town, incorporation date, optional website/emails/phones) without adding format or behavioral 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?

Specific verb ('search') plus resource ('UK companies from Companies House') and explicit filter dimensions (SIC code, town, incorporation date) and returned fields (profile, registered office, officers, contacts). This clearly separates it from siblings such as search_french_companies and find_new_companies_without_website.

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 use case (bulk B2B lead generation by SIC/location/age) but never states when to prefer it over alternatives, nor does it point to the related sibling find_new_companies_without_website for the 'new company' scenario. Usage is inferable but not 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 declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond structured fields: the pay-per-result model on the agent's Apify account with specific unit prices (run start $0.003, item $0.001/$0.002, sold detection $0.002), which is real cost-relevant information. It still omits return-format and rate/limit behavior.

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

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

Two sentences, front-loaded with the value proposition, and the pricing sentence is dense but relevant. No filler, though the pricing breakdown is fairly granular for a description slot.

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 100% schema coverage, read-only/open-world annotations, and no output schema, the description covers what comes back and what it costs. The notable gap is usage guidance (when to prefer this over the other second-hand tools), so it is strong but not 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 eight parameters are already fully documented in the schema, setting the baseline at 3. The description's mention of buyer-fee pricing and a cross-country price summary describes outputs rather than clarifying any parameter. It 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?

States a specific resource (Vinted listings) and scope (up to 26 countries) plus the data returned (price with buyer fees, brand, size, condition, seller rating, cross-country comparison). Naming Vinted directly distinguishes it from siblings like search_second_hand_europe and search_kleinanzeigen. It stops short of explicitly contrasting those alternatives, so not a 5.

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

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

The description never says when to reach for this tool versus the second-hand siblings, nor any prerequisites for use. The only usage-flavored hint ('newest = best for alerts and sniping deals') lives in the schema, not the description. Context is implied at best.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: per-result pricing ($0.003 start, $0.002 per number checked) and the legal-proof semantics of the requesterVatNumber flag — information an agent cannot get from the annotations. It stops short of describing throughput or rate limits for bulk runs.

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

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

Two tight sentences, front-loaded with what the tool does before the optional-flag and cost details. The pricing sentence is arguably extra but is decision-relevant for a paid tool, so little 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 only two optional params, no nested objects and no output schema, the description covers the return fields, the legal-proof behavior and the cost model. A bulk-call tool could say more about batch size limits or per-item failure handling, but nothing essential to a 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 both parameters are already fully documented in the schema, including the country-prefix formats. The description reinforces the consultation-number semantics of requesterVatNumber but adds no format or syntax detail beyond what the schema already provides — baseline 3.

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 (checks) and resource (EU VAT numbers) against a named registry (VIES), and spells out the returned fields (valid or not, registered name and address). An agent can distinguish this from unrelated siblings like search_eu_public_tenders or get_run_results without opening any 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 when the optional requesterVatNumber path matters ('each check returns an official consultation number'), which is conditional context, but it never states when to prefer this tool, when not to use it, or how it relates to any alternative. Usage is inferred rather than instructed.

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