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

The description openly explains behavior beyond the annotations: it is not purely read-only because the positioning path may trigger a background LLM re-judgment and write back, matching readOnlyHint=false. It also discloses failure degradation to null, the meaning of degraded[], and why null ≠ 0, along with rate-limit safeguards ensuring repeated calls are safe.

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?

Although long, the description is densely structured with clear sections (when to use, combination chains, pitfalls/scope) and every sentence carries actionable information. It front-loads purpose and uses explicit formatting to make the length navigable.

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 output schema, the description must compensate, and it does: it lists all six returned components, provides the exact field paths used in chains, explains degradation semantics, and covers the non-read-only cost guards. An agent has enough to call the tool and interpret the response correctly.

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?

With zero parameters, the schema leaves nothing to explain; the baseline is 4. The description adds no parameter detail but does enrich understanding of the response structure through field paths like unread, attention.top[].viewerId, deadlines[].slug, and chatQuota.remaining, which supports the separate return-value semantics.

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 is explicit and specific: it aggregates six named items scattered across six screens into one response for 'today' queries, naming each item (unread messages, recent viewers, chat quota, deadlines, top three actions, pending review counts). It also distinguishes itself from siblings like get_my_work and get_my_dispatch, making its purpose unmistakable.

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?

It states exactly when to start here ('any how is today / what needs handling / daily report' scenario') and gives explicit routing rules: use get_my_work for collaboration goals, get_my_dispatch for dispatch, get_my_invite when chatQuota.remaining=0, and get_my_positioning for the full task list. This is exemplary when-to-use vs alternative guidance.

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