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

Goes well beyond the readOnlyHint annotation: it quantifies output size (~120K chars for 5 pages, ~750K for 20), discloses the SSRF guard (host must end in "amazonaws.com" and contain "s3", otherwise a 400), notes the fetch is server-side, and states OAuth is auto-attached. No output schema exists, so the explicit return shape {"file_name", "media_type", "report"} earns further credit.

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?

Front-loads the verb-and-resource plus the fallback role, then layers conditions, size warnings, constraints, and return shape in a sensible order. Slightly padded by repeating the S3 host rule already present in the schema, and the paragraph break mid-thought about size is a little awkward.

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 no output schema, the description covers selection criteria, size/shape of the result, error behavior, auth handling, and the return payload — everything an agent needs to decide and call correctly. Nothing material is missing.

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 both parameters are already documented in the schema, including the same S3 host constraint. The description restates the URL restriction but adds no new semantics for file_name (e.g., whether it affects the returned file_name field) or for URL edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ("Fetch a presigned S3 PDF URL server-side and return the document as base64") and immediately frames its role as "The FALLBACK for reading a report." That framing distinguishes it from both get_latest_report (which only returns the URL) and a plain client-side HTTP fetch.

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?

Explicitly names the preferred path (fetching the link yourself is "the normal way to read the PDF") and states the exact conditions that select this tool: the client cannot reach the link but can run code to decode base64. It even adds a disqualifying condition — the payload is useless to a model that cannot decode it.

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