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

Goes well beyond the readOnly/openWorld annotations: requires an APIFY_TOKEN, bills per round row plus a run start, notes include_press bills separate article events, and specifies that no_results and input_invalid rows are free while failed runs return an error with a run ID. It also discloses a data limitation — Form D names no round label or investors — which prevents misreading the 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?

Purpose and source are front-loaded in the first sentence, followed by filters, then return shape, then billing/error semantics — a sensible order. The long comma-separated list of returned fields is dense but defensible given there is no output schema, though it pushes the description toward the verbose end.

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 16 optional parameters, no output schema, and no siblings, the description covers the missing pieces an agent needs: the full return row shape, the special no_results/input_invalid/error behaviors, auth requirements, and the cost model. Nothing material for correct invocation is left out.

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 already 100%, so the baseline is 3; the description earns above that by tying parameters to behavior, e.g. that round_label and press_url appear only when include_press is set and that SPV/fund and real-estate exclusions are on by default. Most of the enumerated return fields duplicate the schema's parameter docs rather than adding new 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?

Opens with a specific verb and resource — 'Find US companies that just raised private funding' — and names the data source (SEC Form D notices from EDGAR). It also states scope decisions the agent would otherwise have to infer, such as funds/SPVs/real estate being dropped by default and that round_label/press_url exist only with include_press.

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

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

Explains filter dimensions and their defaults (filed_within_days vs date_from/date_to, min_amount_usd, include_press cost caveat), which tells an agent how to steer the query. It does not state explicit when-not-to-use conditions or tradeoffs between filter modes beyond the schema's own notes, so it falls 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.