drive_dedupe

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

Despite no annotations being provided, the description thoroughly discloses behavioral traits: it's read-only, reuses a bulk-search path (no per-file follow-up), groups by md5Checksum (broadest coverage), skips files without checksums (folders, Google-native docs), omits groups of one, describes default limit and hard cap behavior, and explicitly states 'Read-only.' This is comprehensive behavioral disclosure for a tool with no annotations.

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 dense but not bloated; it packs key information into a few sentences. It front-loads the core purpose first, then covers scope, behavior, defaults, safety, and output format in order. Every sentence adds value: the syntax reference, the grouping logic, the limit behavior, the read-only note, the CLI mirror, and the output format. No filler or repetition.

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 no annotations and no output schema, the description is remarkably complete. It tells the agent what the tool does, how to scope it, what files are skipped, what the default and maximum limits are, that it's read-only, and what the output format is (YAML). An agent has everything needed to call it correctly without opening the schema or guessing.

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?

The schema has 100% description coverage, so the schema already documents the parameters well. The description adds some value by explaining the query syntax reference to drive_search and the default limit behavior, but these are already present in the schema's parameter descriptions ('same syntax as `drive search`'s query argument', 'Defaults to 50 when omitted'). The description reinforces what's in the schema rather than adding new meaning, so a baseline score of 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 purpose: 'Find Drive files sharing the same content hash, within the results of a Drive query.' It specifies the resource (Drive files), the action (dedupe by content hash), and the scope (within query results). It also distinguishes itself from siblings by referencing drive_search's query syntax and noting it groups by md5Checksum, which is a distinct operating mode from the general search sibling.

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 explains when to use this tool vs alternatives: it points to drive_search's query syntax for the query parameter, and implicitly differentiates from regular search by focusing on deduplication. It also provides a concrete example ('<folder-id>' in parents to dedupe within one folder) and explains the trade-off of using this path over a per-file follow-up call. This is clear usage guidance for an agent.

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