List insights

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: the empty-list-is-expected semantics to prevent fabricated alerts, the data source/refresh cadence, required scopes, and 'data sensitivity: redacted'. It does not describe pagination/truncation behavior, which is a minor gap given the maxPages parameter.

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?

The prose portion is front-loaded and efficient, leading with what the feed is and following with the filter and empty-state caveat. The template metadata lines (operation, scopes, idempotency note) add bulk but each carries operational information; the 'Does not require idempotency' line sits awkwardly next to idempotentHint=true.

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 read-only list tool with an output schema, the description covers what the agent most needs: scope requirements, workspace override, ordering, and the honest-empty-state warning. It is essentially complete, with pagination behavior left to the schema.

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 75%, so several params (maxPages, workspaceId, workspaceSlug) are documented in-schema while nested query fields (limit, cursor, status) are not. The description explains the status filter's meaning and the workspace override, adding some value, but says nothing about limit/cursor pagination semantics, so the baseline 3 is right.

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 names a concrete resource (the coach's proactive-insights feed) and lists its content categories (metric drops/spikes, opportunities, risks, milestones) plus its source and ordering (daily cron, newest first). It clearly distinguishes itself from the mutation siblings (mark_read, dismiss, mark_actioned), though it never explicitly names the closest read sibling, luca_insights_unread_count.

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 the optional status filter with an example ('unread') and how to override the default workspace, which is useful invocation context. However, it gives no explicit when-to-use/when-not guidance relative to alternatives such as luca_insights_unread_count or the triage/recommendations tools, leaving selection to inference.

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