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

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower, and the description still adds real context: the catalog size (139 assets), its cross-functional coverage, and the shape of each returned entry (what it is, business outcome, data requirement, current generatability). It does not discuss pagination behavior or result ordering, which is the only remaining gap.

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?

Two sentences, no filler, and the trigger scenarios that drive selection come first with the mechanism second. The parenthetical examples in sentence one are dense but each illustrates a distinct deliverable type, so they earn their place.

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?

There is no output schema, and the description compensates well by describing exactly what each catalog entry contains, which is what an agent needs to decide whether to call this or go straight to generate_asset. It is only short of complete on retrieval mechanics such as default result counts and paging.

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 all four parameters are already documented, giving a baseline of 3. The description does help indirectly by explaining that entries indicate whether an asset "can be generated today," which gives meaning to available_only, but it never discusses query syntax, group values, or limits beyond the schema.

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 a specific verb and resource — "Searches Andru's catalog of 139 assets" — and scopes the catalog's breadth (enterprise deals through hiring, fundraising, buying). An agent can tell this is catalog search rather than retrieval of one asset, though it never explicitly contrasts with siblings like list_my_assets or get_asset.

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 gives a concrete trigger ("the person needs a deliverable... something their champion will carry into meetings the person won't be in") plus a second trigger ("asks what Andru can make"), and routes the follow-up step explicitly: "Then call generate_asset with the asset's name." That is an unusually complete when-to-use and what-next.

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