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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description spends its words on genuinely new behavior: cursor/boardCursor pagination, the 100-board page and locked-field semantics (`locked` list, `lockedCount`), and the instruction to tell the user the data is on a higher plan rather than estimate it. The only wobble is 'Returns up to 100 boards' against a schema `limit` maximum of 40, which leaves page-size expectations slightly ambiguous.

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?

Purpose is front-loaded in the first sentence, then pagination, then the `kind` modes, then plan-gating guidance — a sensible order. It is dense but each sentence carries operational content; the only minor slack is repeating the two cursor mechanisms in both prose and schema.

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 and seven optional parameters, the description does the necessary work of sketching the response (boards plus count summary, item lists, `locked`/`lockedCount`, two cursors) so the agent knows what it will get back. The one gap is the unresolved 40-vs-100 page-size tension, which an agent paging results could misinterpret.

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%, so every one of the seven parameters is already documented in the schema, and the description mostly restates that (boardCursor to continue, nextCursor as cursor, kind modes). It adds modest value by tying cursor continuation to 'this same call' and by naming where boardId comes from, but not enough to exceed the baseline.

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 states a specific resource (the user's collected/saved items in Sightglass) and enumerates what comes back: boards, or saved ads, site_pages, companies and followed brands when `kind` is set. That is enough to separate it from search-style siblings like sightglass_find_ads, but the differentiation is only implicit — the description never says 'use find_ads to search all ads, this only lists what's saved'.

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 `kind` semantics ('omit for just the boards and a count summary') imply when to use the summary mode vs. a typed listing, and the plan-gating sentence tells the agent how to report results. However, there is no explicit when-to-use-vs-alternative statement against the many sightglass_find_* / sightglass_search_* siblings, so the agent must infer the choice.

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