Get the user's agenda across all boards

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

No annotations exist, so the description carries the full behavioral burden and does so unusually well: it discloses the section breakdown, ordering rules, per-item field set, the meaning of `blocked`, pagination-with-totals behavior, exclusion of archived cards/lists/boards, local-time semantics for 'today', and an offline fallback to the last on-disk export. These are exactly the non-obvious traits an agent cannot infer from structured fields.

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-loaded with the core purpose, and virtually every clause adds usable information. It is dense as one undivided block (~180 words) with section names, field lists, and caveats interleaved, so a light structural separation would improve scanability, but there is no filler to cut.

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 no annotations and no output schema, the description itself supplies the return shape, field semantics, ordering, defaults, exclusions, and degraded-mode behavior. Nothing an agent needs in order to call this correctly or interpret the result 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 0%, so the description must compensate, and it does: `limit` gets default 50 per section and max 100, `upcomingDays` default 7, `completedDays` default 7 plus newest-first ordering. It also clarifies that `totals` counts untrimmed cards, which is a semantic distinction no schema could convey.

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 concrete verb-and-resource framing ('What's on the user's plate, across every board in one call') and immediately enumerates the four returned sections, which distinguishes it from any per-board reading tool. An agent knows exactly what this produces without opening the 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 explicit trigger phrasings ('what should I work on', 'what is overdue', 'what did I get done this week') and an explicit alternative to avoid ('instead of walking every board'). It stops short of naming specific sibling tools (e.g. list_boards/get_board or search_cards) and gives no when-not-to-use exclusion, so it is strong but not maximal.

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