docs_export

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial context beyond them: user credentials are used, the 10 MB Drive API export ceiling, the 50,000-character text window with an `offset` continuation note, and the fact that PDF exports land in a local file whose path must be opened. These are real behavioral traits an agent could not infer from the 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?

Well front-loaded – purpose first, then constraints, then Args/Returns. Every clause earns its place except the Returns block, which restates structure already captured by the output schema, adding mild redundancy.

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 3-parameter tool with 0% schema coverage, no enums, and no nested objects, the description covers selection criteria, per-type MIME legality, auth context, size limits, pagination continuation, and non-text return handling. Nothing an agent needs to call this correctly 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 0%, so the description carries the full burden and does: `file_id` is the Google-native document id, `mime_type` is constrained to the enumerated allowed list, and `offset` is the character start point that is explicitly ignored for PDF. Each parameter gains meaning not present in the bare schema.

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 (Export) and resource (a Google Doc or other Google-native file), with the output form (text) named up front. It also immediately distinguishes itself from the sibling drive_download by restricting scope to Google-native files.

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 routing rule: 'For files that are not Google-native (uploaded PDFs, xlsx, txt, ...) use `drive_download` instead.' It further specifies which export MIME types are legal per source type (Docs vs Sheets vs Slides), so the agent knows both when to use this tool and which arguments are valid.

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