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

Beyond the annotations (which already declare readOnly, idempotent and openWorld), the description discloses an authentication rule for private versus public folders, a hard truncation limit of 2000 files or 200 folders, and the workaround of listing a subfolder to get the rest. It also explains that each result carries a `ref` for prepare_launch, and that the aspect ratio is detected from the source Drive file.

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?

The structure is front-loaded: the purpose appears in the opening sentence, then the mechanics, then the limits. The first fragment ('Every video and image of a Google Drive folder, subfolders included, to launch as ads') largely restates the sentence that follows it, a minor redundancy.

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 listing with no output schema, the description covers authentication, result handles (`ref`), format detection and truncation behavior, so an agent can act on it. It leaves out what else each file record contains besides `ref` and how a malformed or inaccessible folder id surfaces as an error, but neither is essential to calling it correctly.

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?

`url` is already described in the schema as 'Drive folder link or id', so the description adds little for that parameter beyond restating 'link or id'. The `recursive` boolean has no schema description, and the description says only 'subfolders included' as if the recursion were unconditional, so it does not clarify what the flag actually controls; that is a real gap at 50% coverage.

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 second sentence names a specific verb and resource: 'Inventory the videos and images of a Google Drive folder (link or id), subfolders included.' That scope, a Drive folder rather than the ad creatives covered by get_ad_creatives, separates it from that sibling clearly, and the phrase 'to launch as ads' adds the purpose of the listing.

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 description states the purpose (choose media to launch as ads) and the prerequisite conditions: a folder shared as 'Anyone with the link' needs no connection, while a private folder requires the Apogee-connected Drive account to be able to open it. It does not explicitly name an alternative tool for the case where the media are already ad creatives, so the when-to-use guidance is clear but not fully exclusive.

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