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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description instead adds genuinely non-obvious behavior: dates are projected from the company's own filing cadence, 'held, not rolled', and marked overdue when lapsed. Ordering (nearest first) is also stated. It stops short of failure modes or coverage 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?

Front-loads the resource and ordering, then usage, then exclusions — a sensible order with no filler. The closing 'Args:' list is redundant with a 100%-covered schema and is the one part that does not earn 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 an output schema present, return format need not be described, and annotations cover the safety profile. What remains — what the events are, how they are derived, ordering, and routing against siblings — is all present, so nothing an agent needs to call it correctly 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 each parameter already documents itself (limit, types with both enum values, entity formats). The trailing 'Args: entity; types; limit' merely restates the schema and adds no new meaning, 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 ('upcoming dated events for a company') with concrete content: next projected earnings date and trial readouts. It explicitly names the siblings it is not (get_filings for past events, answer for actual results), so an agent can route without opening either 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?

Gives literal user phrasings that select this tool ('when does X report next', 'what's coming up for X') and an explicit not-for clause with the correct alternative for each excluded case. Both when-to-use and when-not are covered.

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