get_board_events

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

No annotations are provided, so the description carries full behavioral burden. It discloses that the time window is optional, but says nothing about permissions, pagination/limit behavior beyond what the schema states, ordering semantics, or the shape of returned events.

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, tightly scoped sentence with zero filler, front-loading the resource and the audit-log clarification. Nothing 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?

Adequate minimum for a read tool with a well-documented schema, but with no annotations and no output schema, the description could stand to mention permissions, result count defaults, or return shape. It leaves behavioral gaps that annotations would normally cover.

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 80%, so the schema already documents all five parameters including formats (ISO 8601/epoch ms), default/max limit, ordering enum, and board_name. The description adds nothing parameter-specific beyond the optional-window framing, so 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 (board-level events / audit log). The audit-log clarification and time-window scoping distinguish it clearly from get_board, get_time_entries_for_board, and other board siblings.

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 explicit when-to-use, when-not-to-use, or named alternative. The 'audit log' parenthetical marginally suggests the appropriate context, but there is no routing guidance versus get_board or get_time_entries_for_board.

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