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

Annotations already cover readOnly/no-destructive/no-open-world, so the description only needs to add context, and it does: 'Spends nothing' (no credits consumed), the empty-state behavior ('With nothing connected, it says where to connect'), and that each entry carries a status ('whether it is posted or going there already'). Time-zone and fallback-time computation are also disclosed. Missing: whether results are cached or how to detect an account that cannot accept pictures.

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?

Every clause carries information, but the whole thing is one long colon-chained sentence that is hard to parse on first read ('Where a picture you made can be posted and when: each of the project's connected accounts that takes a picture, with a time for it...'). Front-loading is acceptable, but the dense nesting and the trailing 'Spends nothing' fragment would be clearer as separate short sentences or a bulleted shape.

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 zero-required-parameter, read-only query with no output schema, the description does the important work of describing the shape of the return (one entry per connected account, with time and status) and the degenerate case (nothing connected). Nothing critical is missing for correct invocation; only the relationship to neighboring scheduling tools is left implicit.

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 coverage is 100%, so the schema already documents day, set_id, item_id, and project. The description reinforces the day default ('the day the owner named, else the next good time') and the project time zone, which mirrors the schema text rather than extending it, and says nothing extra about set_id/item_id resolution beyond 'the picture you made'. Baseline 3 is appropriate when the schema carries the load.

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 thing being returned: where a picture can be posted (each connected account that accepts pictures) and when (a computed time in the project's time zone), plus posting status. That is more specific than a name restatement. It stops short of naming the sibling it complements or contrasts with, such as scheduled_posts_read or slot_add, so an agent must infer the boundary from product vocabulary.

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?

Use is only implied: you call it to see posting destinations and times, presumably before scheduling. The description never says when to prefer it over scheduled_posts_read (what is already scheduled) or slot_add (creating a slot), and no prerequisites or exclusions are given. 'Spends nothing' hints it is a safe pre-check, but that is inference.

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