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

The description provides rich behavioral context that goes well beyond annotations: it explains the brand-collision mitigation (search runs against the company's own domain), the separate reporting of own conferences, the low hit rate (~2 in 10), honest empty rows, and the flagged out-of-year events. It also discloses the APIFY_TOKEN requirement and credit consumption. This fully complements the read-only/idempotent annotations.

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

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

The description is long but every sentence carries useful operational or behavioral information. It is front-loaded with the core purpose and then expands on edge cases and limitations. There is minor redundancy (e.g., 'Read only' duplicates the annotation; the domain-filter rationale is stated twice), but overall it is well-structured for such a nuanced tool.

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

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

Given the absence of an output schema, the description does a good job explaining the return shape (flat row, empty row) and key output fields (coverage, fetch_status, queries_failed). It covers limitations, cost, and error interpretation. It does not enumerate all possible output fields, but for a tool with a simple flat-row structure and 100% parameter schema coverage, the description is sufficiently 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 coverage is 100%, so all six parameters are already documented. The description adds some context relevant to parameters, such as the behavior of years ('Events dated outside the years you ask for are still returned and flagged') and the domain-scoping rationale, but it does not add significant new meaning beyond what the schema descriptions provide. Baseline 3 is appropriate.

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

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

The description opens with 'Give it a company domain. It returns the third party conferences and trade shows that company publicly says it attends' – a specific verb, resource, and scope. It also distinguishes itself from potential misinterpretations ('This is not an events database and not an exhibitor list') and clarifies the company-domain focus, which differentiates it from generic event lookups.

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 clearly states the input (a company domain), the output (attendance list with year), and what the tool is not for ('not an events database', 'not an exhibitor list'). It also gives practical guidance on filtering years and interpreting empty results via coverage fields. However, it does not explicitly name alternative tools (no siblings exist), so it stops short of a 5.

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