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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds context the annotations cannot express: 'Uses no credits' (important for an agent that calls estimate_cost elsewhere) and 'Returns items[] with the id to pass on', which tells the caller what to do with the result. It does not mention pagination limits or totals, which keeps it off a 5.

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?

Front-loaded with what the tool returns before the filter options, and every clause carries information (ordering, preview fields, filters, sibling alternative, return shape, cost). The middle sentence is dense and slightly run-on ('to plan a mix or find a piece'), but no sentence is filler.

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, the description correctly compensates by stating the return shape ('items[] with the id to pass on') and per-item contents. For an 8-parameter, paginated list tool it covers the essentials; only pagination/total-count behaviour and the drafts-vs-library distinction (left to the schema's kind description) are unaddressed.

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 88%, so the schema already documents kind, text, offset, status, platform, pillar_id and funnel_stage, including the enum meanings. The description only restates the filter dimensions generically ('status, pillar, funnel stage, platform or words in the title') without adding format, defaults or edge-case behaviour beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Lists the creator's saved library items and delivered drafts') and immediately scopes it with ordering ('newest first') and returned fields (preview, pillar, funnel stage). It also names the sibling it is not ('get_library_item returns one in full'), so an agent can choose between listing and fetching without opening a schema.

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?

Gives a concrete motivation for the tool ('to plan a mix or find a piece') and the available filter axes, plus an explicit redirect to get_library_item for full content. What is missing is an explicit when-not (e.g. use find_competitors or list_my_posts instead when the items aren't the creator's own library), so it stops just short of full routing guidance.

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