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

The description discloses behavioral traits beyond annotations: it states the server fetches the URL itself ('We fetch it (up to 500 MB, streamed)'), the job runs exactly like an upload, requires a stored contact email and consent, and mentions rate limiting (429). Annotations only say readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description adds meaningful context about remote fetch behavior and constraints.

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 information-dense but well-structured: a clear opening statement, followed by key details on fetch limits, equivalence to upload, requirements, replacements, error recovery, and rate limits. While somewhat long, every sentence adds useful information and the most important behavior is front-loaded. The only minor issue is the use of parentheticals ('streamed', 'error') that could be slightly clearer, but overall it's efficient.

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?

Given the tool's complexity (remote fetch, multiple constraints, rate limits, error handling), the description covers most required context: what it does, when to use it, exclusions, prerequisites, limits, and error recovery. It doesn't explicitly describe the response shape, but there is no output schema, and the description references polling GET /jobs/{id}, which adequately informs the agent of expected flow. Slight gap: it doesn't explicitly state what happens on success besides polling, but this is acceptable.

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%, so the schema already documents all four parameters thoroughly. The description adds context about how the parameters are used, e.g., 'Needs the stored contact email and consent, like /upload-url' and that 'http' URLs are refused, but it doesn't add significant new semantics beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool's function: 'Server-side handoff: give us a public https URL of the walkthrough instead of uploading it from a browser.' It uses a specific verb ('give us a public https URL') and identifies the resource (walkthrough video). It also explicitly distinguishes from related tools by naming '/upload-url', '/upload-complete', and '/submit' as replaced by this endpoint, which helps an agent distinguish it from siblings.

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 explicitly states when to use this tool: when the caller 'already holds the file' and wants to skip uploading from a browser. It names alternatives it replaces and provides exclusion criteria: 'Private hosts and http are refused,' and notes that a job with a failed fetch may be handed a new URL. It also states that it 'Counts toward the mover's daily analysis cap (429),' giving clear usage boundaries.

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