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

Beyond the non-destructive and non-read-only annotations, it discloses supported video formats, a 50 MB limit, 30-minute link expiry, 20-file capacity, and where uploaded files subsequently appear. It also clarifies that media is uploaded after link creation through the returned URLs rather than by the tool call itself.

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 description is compact and moves logically from purpose to upload workflow, then constraints and outcome. Its first sentence is dense and grammatically awkward, but nearly all of the included details are operationally useful.

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 one-parameter tool with no output schema, it provides strong response and workflow context by naming `upload_url`, `curl_example`, and `page_url`, along with expiry, limits, and downstream visibility. Explicit `document_id` provenance and clarification of whether 50 MB applies per file or in total would remove the remaining minor ambiguity.

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?

With 0% schema description coverage, the description only indirectly explains the sole parameter by referring to "a deck's library"; it never explicitly states that `document_id` identifies the target deck or where to obtain that ID. Nevertheless, the deck-specific context makes the single required string reasonably inferable.

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 identifies the resource, supported media, and destination deck library, distinguishing the workflow from listing or placing existing deck media. However, the opening phrase "A link that adds..." is less direct than explicitly saying the tool creates or returns an upload link, and no sibling is named.

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 explicitly explains when the workflow is needed: when a person's own files cannot be carried in a tool call. It also gives concrete alternatives for completing the upload, using `upload_url` with `curl_example` for direct uploads or `page_url` for manual file dropping.

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