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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful context beyond that: the result may render as an interactive panel in app-capable hosts and the agent should not duplicate it in text. That host-dependent rendering behavior is real information not derivable from the schema or annotations, though pagination and return-shape behavior remain unstated.

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, front-loaded with purpose before the presentation rule, with no filler. The second sentence is slightly dense with the em-dash aside, but every clause carries actionable instruction.

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?

No output schema exists, so the description does carry the burden of explaining results — and it does describe the interactive-panel rendering well. However, it omits result volume, pagination behavior, and what fields assets expose, which an agent needs when the panel does not render (non-app hosts).

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 0% — neither 'page' nor 'limit' carries any explanation in the schema, and the description does not mention pagination, defaults, or the 100 maximum at all. With two undocumented parameters and a tool that can return many assets, the description fails to compensate for the schema gap.

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 ('List the user's uploaded media assets') and clarifies provenance with '(from upload_file or the app)'. This is clearer than a bare name restatement, but it never contrasts itself with the many other list_* siblings (list_generations, list_posts) that could plausibly return overlapping content, so an agent must infer the boundary.

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?

Provides a clear directive for how to present results in app-capable hosts, but no guidance on when to choose this tool over list_generations or list_posts, nor any indication of when the tool is unnecessary. The negative instruction ('do NOT repeat its contents') is useful but is about response formatting, not tool selection.

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