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

Annotations already declare this a safe, idempotent read, so the description is free to spend its words elsewhere — and it does, describing the shape of each returned entry (source item, last-run outcome, failure reason) plus the 400 error for SlideDeck. Missing are pagination, ordering, or what an empty sync list looks like, so it is strong rather than exhaustive.

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?

Three dense sentences, front-loaded with the resource and its scope, then the downstream action, then the error edge case. No filler, though the middle sentence's colon-and-list construction packs several ideas together and could be split for faster scanning.

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 single-parameter read tool with no output schema, the description supplies exactly what is otherwise unknowable: what a 'sync' contains, what a failure looks like, the SlideDeck exclusion and its 400, and the natural next call. Nothing an agent needs to select or invoke it correctly 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?

The tool takes exactly one parameter, `id`, and the description never says anything about it; the schema's own `id` description carries all the weight. Worse, the only parameter-like token in the description, `syncIds`, is not a parameter of this tool at all — it belongs to `startReportRun` — so an agent skimming for argument guidance has to disambiguate that itself.

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 the resource precisely ('the syncs of a report other than a SlideDeck') and enumerates what each entry holds — charts, tables or text pulled from a source with last-update status and failure reason. It actively excludes SlideDeck reports, which is the key boundary versus the datasheet siblings. It stops short of an explicit front-loaded verb like 'Lists', but the intent is unambiguous.

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 when to call it (non-SlideDeck reports), when not to (SlideDeck reports, which have datasheets and return 400), and what to do with the result by routing failed sync ids into `startReportRun` via `syncIds`. That is an explicit when/when-not/alternative triad, which is rare in this toolset.

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