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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's contribution is the enumeration of returned attributes, which is real added context given there is no output schema. It stops short of saying how audio-only or image files are handled, or what happens when the media id is not found.

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?

One short sentence fragment with zero padding, and the key information (what you get back) comes first. The telegraphic 'What a media file is:' phrasing is slightly awkward and reads more like a heading than an instruction, but it wastes no space.

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 two-parameter read tool with full schema coverage and no output schema, the description does supply the return-field overview that would otherwise be missing. Still absent are any behavioral edge cases and any hint about the shape of the response (flat fields vs. nested metadata block), leaving it merely adequate.

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% — both 'media' and 'project' are documented in the schema with concrete identification hints. The description adds nothing about parameter formats or resolution order, so the baseline 3 applies; the schema carries the full burden here.

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 the resource (a media file) and enumerates the attributes that characterize it (kind, duration, size, frame rate, codec, audio), which conveys roughly what the tool returns. However, it is a noun-phrase fragment with no verb, so the action (inspect/report metadata) is only inferable from the title. It also does no sibling differentiation — nothing distinguishes it from list_media, matte_media, or transcribe_media.

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?

There is no guidance on when to call this tool versus alternatives such as list_media or check_timeline, and no preconditions (e.g., that the media must already be added to the project) are stated. The agent must infer usage entirely from the title and the field list.

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