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

Annotations already declare readOnlyHint=true, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds genuine behavioral context beyond that: what states the payload surfaces (failed platforms with error codes, deleted media, pending schedules) and that scheduled_post_id is what you need before moving or cancelling. It says nothing about pagination, version limits, or auth, so it is additive but not rich.

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?

It is front-loaded and has no filler, but a large share of the text enumerates return fields (video_cover sub-fields, gallery description nullability) that the output schema already declares, so those sentences do not fully earn their place. The three-sentence structure is dense and readable but back-weighted toward output detail.

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 getter with two documented IDs, an output schema, and clear annotations, the description covers the remaining ambiguity — the response_format branch and the notable edge states (failed platforms, deleted media, null gallery description). Return-value detail is somewhat over-explained given the output schema exists, but nothing an agent needs to call 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?

post_id and brand_id are documented in the schema, but response_format's enum values carry no schema description — the description compensates by spelling out what concise (newest version) and detailed (all versions with platform content and media) actually return. That is real meaning beyond the structured fields, well above the 67%-coverage 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 opens with a specific verb+resource: "Reads a brand library post," and immediately scopes the payload (live URLs, failed platforms, pending schedules, versions). It could still be confused with syncbooster_preview_post or syncbooster_get_post_activity, which it never names as differentiators, so it is clear but not sibling-differentiated.

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 only routing guidance is implicit: the concise-vs-detailed sentence tells the agent how to choose a response_format, and the schedule mention hints at when to fetch (to get scheduled_post_id for moving/cancelling). No explicit when-not-to-use or named alternative tools are given, so the agent must infer that metrics/activity/preview live elsewhere.

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