drive_file_read

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

No annotations exist, so the description carries the full load — and it excels. It discloses read-only semantics, exact behavior differences between metadata/content modes, binary content refusal and the workaround, export default for Docs/Sheets/Slides, error naming behavior for unsupported export types, and the verify flow including how it fails on Google-native files. This is unusually complete behavioral disclosure.

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?

Dense but disciplined. It opens with the primary action and default mode, then elaborates in a logical cascade: mode → content fetch behavior → binary handling → output_file → verify. Each sentence carries distinct information with no repetition of schema text. Slightly dense (long sentences), but front-loaded and efficiently organized for a 6-parameter tool.

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 tool with 6 parameters and no output schema, this description is exceptionally complete. It covers input modes, content-type handling, output formats, all parameter interactions, failure semantics on checksum mismatch, and even the mirror command. An agent has everything needed to invoke this tool correctly across all supported scenarios, including edge cases like binary or oversized content.

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 100%, but the description meaningfully augments it beyond the JSON — e.g., that 'format: metadata' returns checksums when available, that content is exported for Google-native files, that binary content is refused inline, and that output_file yields a YAML summary. The verify description in the prose adds behavioral constraints not obvious from the bare property docs. This exceeds the schema's literal text by clarifying mode interactions.

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 leads with a crystal-clear statement — 'Read a file by id' — and immediately disambiguates its two modes ('metadata' vs 'content'). It precisely explains what each mode returns, how Google-native files are handled, and what 'content' mode does beyond metadata. There is no ambiguity about the tool's core purpose or its primary input.

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 gives strong operational guidance: when to use content mode, when binary requires output_file, when verify is valid, and how export_mime_type affects native files. It implicitly signals usage ('Set verify: true for integrity checking'). It does not explicitly compare to drive_search/drive_list siblings, but for a read operation the mode-selection guidance is more pertinent and well covered.

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