fetch_adl_events

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 does disclose one genuinely useful fact: API credentials are required. It does not say whether the operation is read-only (implied by 'history'), how results are ordered, whether the limit paginates, or how far back history extends — gaps that matter for a data-retrieval call with no annotation coverage.

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 sentence that front-loads the purpose, spends a few words defining ADL accurately, then appends the hard constraint (credentials). Every clause earns its place and nothing is padded.

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 two-parameter, read-only history lookup with no output schema, the description covers what the data is and the auth requirement. It leaves the relationship to the three sibling ADL tools unresolved and says nothing about result ordering or pagination, which is the main remaining ambiguity for correct invocation.

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%, with market_id documented (including an example format) and limit documented with its max. The description adds only the 'one market' scoping, which the schema already enforces via the required market_id; 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 (get) and resource (ADL settlement history) and even explains the domain concept — force-closed positions covering a shortfall — so an agent unfamiliar with ADL still understands the return. The scope phrase 'for one market' implicitly separates it from account-scoped siblings like fetch_adl_history and get_adl_history, but it never names them, which matters given three near-identical ADL tools in the sibling list.

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 'for one market' scope constraint implies when this variant applies rather than the account-wide ones, which is some inferred guidance. There is no explicit statement of when to use this versus fetch_adl_history, get_adl_history, or get_market_adl_events, and no exclusion criteria or prerequisites beyond credentials.

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