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

With no annotations present, the description carries the full disclosure burden and does most of it: it reveals the 100MB cap, the 1-hour expiry of the signed URL, and the non-obvious auth rule that the PUT must omit Authorization. It stops short of failure semantics — what happens on an expired URL, a size mismatch, or an unsupported byte payload.

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?

Three tightly packed sentences: purpose and precondition first, then the exact call sequence, then the expiry caveat. Every sentence carries information an agent cannot get from structured fields.

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, but the description names the returned artifacts (upload_url, headers, video_url) that the agent must consume, so the missing output schema is compensated. For a two-parameter presign tool, nothing needed to call it correctly is absent beyond error handling.

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 coverage is 50% (content_type has only an enum, no prose), so the description needs to compensate, and it does add a real constraint the schema does not express: the 100MB practical limit, since the schema's maximum is 2^53. It does not explicitly tie content_type to the accepted video containers, leaving that mapping implicit in 'local video file'.

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 (get a signed upload URL for a local video file) with the exact precondition 'when it has no public URL'. It also names the downstream sibling upscale_video, so the agent can place this tool in the workflow without inspecting the other schemas.

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?

Gives an explicit trigger condition (no public URL available), an ordered procedure (PUT bytes to upload_url with returned headers, then pass video_url to upscale_video), and an exclusions-style note that no Authorization header should be sent. There is no ambiguity about when to reach for this versus upscale_video.

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