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

With no annotations, the description carries the full behavioral burden. Leading with 'WRITES.' usefully flags the mutation, and the folder exclusion sets a boundary, but it says nothing about permission requirements, whether sharing/permissions are replicated to the copy, or any rate/quota effects.

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?

Two short sentences, mutation flag front-loaded, every clause carrying information. No filler or 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 no-annotation, no-output-schema write tool, the description covers purpose and one constraint but omits behavior an agent would want before chaining, notably what the call returns (e.g. the new file's ID) and any permission/sharing carry-over. Adequate but with clear gaps.

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 67%, and the description's 'optionally with a new name and into another folder' merely restates the optionality and meaning already documented in the schema defaults. It adds no format, syntax, or ID-handling detail beyond what the properties provide.

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 ('Copy a file') and adds a real scope constraint ('Folders cannot be copied'), which separates it from create_file/upload_file and prevents a mistargeted call. It stops short of naming which sibling to use for the cases it excludes.

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 no when-to-use framing relative to the many adjacent siblings (create_file, upload_file, update_file_content). The only routing-adjacent statement is the negative constraint about folders, which is a limitation rather than guidance.

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

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

With no annotations, the description carries the full burden. It does disclose the write nature ("WRITES"), the conversion side effect of convertTo, and the empty-file behavior when content is omitted, plus the mimeType defaulting rules. It says nothing about permissions required, what happens on name collision, whether an existing file is overwritten, or where in Drive the file lands beyond the schema's folderId note.

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?

Roughly four short sentences, all of which add information, with the core verb front-loaded. The leading "WRITES." is redundant capitalization noise, but nothing else is wasted.

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 six-parameter creation tool with no annotations and no output schema, the description covers the tricky part (conversion mode vs plain file vs empty Google file) adequately. Remaining gaps such as auth requirements and collision/overwrite behavior are real but secondary for a create operation.

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 67%, and the description fills the most important gap: the interaction between content, mimeType, and convertTo ("With convertTo, the text is imported as a Google Doc ... Without it a plain file of the given mimeType is created"), which the schema only states per-parameter. It does not address folderId, description, or name semantics beyond the 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?

Opens with a specific verb and resource ("Create a file from text") and immediately distinguishes the create-with-conversion case from the plain-file case via convertTo. It does not, however, contrast itself against siblings like upload_file (binary content) or create_folder, so an agent still has to infer which creation tool applies when the source is not text.

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 conditional usage: use convertTo to import Markdown/HTML/CSV as a Google-native Doc/Sheet/Slides, omit it for a plain file, and omit content to make an empty Google file. That is clear context, but it names no alternative tool and gives no exclusions (e.g., when to prefer upload_file or update_file_content).

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

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

No annotations are provided, so the description carries the full burden. The "WRITES." tag correctly flags this as a mutation, but nothing is said about required permissions, whether the operation fails on duplicate names, what happens to the parent, or any rate/side-effect behavior.

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 short and front-loads the mutation flag, which is good. But two fragments this terse tip into under-specification rather than earning their brevity, leaving key behavior unstated.

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 write tool with no annotations and no output schema, the description should explain the parent/location semantics and any failure conditions. Instead it stops at four words, leaving the agent under-informed relative to the tool's complexity.

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 50%: parentId is documented as defaulting to My Drive root, but name has no description. The tool description adds no meaning for either parameter, so it fails to compensate for the uncovered half.

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 ("Create a folder"), which clearly separates it from sibling mutation tools like create_file and upload_file. However it gives no scope or differentiation detail beyond the verb+noun, so it does not reach the top of the scale.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. parent folder existence), and no routing to alternatives. The agent must infer everything from the bare imperative.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses Google-native export behavior with per-type defaults, the format override, and the explicit refusal to overwrite unless overwrite=true — a key destructive-safety trait. It omits authentication requirements, error/partial-write behavior, and whether it creates parent directories.

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?

Three tight sentences, front-loaded with the core action, then the two behavioral caveats that matter most. No filler or repetition of the tool name.

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 download tool with no output schema and no annotations, the description covers the essential behaviors (export mapping, overwrite protection). Missing are the return value or returned path and any auth/permission context, but nothing critical to invoking it correctly is absent.

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?

With 50% schema description coverage, the description compensates: it explains format's default-per-file-type behavior and clarifies overwrite's polarity ('refuses to overwrite unless true'), which the bare boolean property does not. destinationPath's file-or-directory duality is left to the schema, and fileId is never described, but the added meaning exceeds the baseline.

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 with clear directionality ('Save a file to a local absolute path'), which inherently separates it from upload_file (local→Drive) and read_file_content. An agent can identify the tool's job without opening the schema.

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?

Usage is implied rather than stated: nothing says when to prefer this over read_file_content or upload_file, and no prerequisites (auth scopes, target directory existence) are given. The export-format and overwrite notes are operational detail, not when-to-use guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints at the return contents (folder path, web link) but says nothing about read-only safety, permissions required, or behavior when the fileId is missing or trashed — thin for a tool with zero annotation coverage.

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?

A single front-loaded sentence with no filler, and the payload hint is attached at the end. Appropriately sized, though it is terse to the point of leaving gaps rather than being a model of efficiency.

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?

With no output schema, the description must convey the return shape; it does so only partially (folder path, web link) and omits param documentation in a context where the schema also omits it. Minimum viable for a simple one-parameter read, but not complete.

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% and the description never mentions fileId, so the single parameter's format and provenance are undocumented. The name is self-explanatory enough to be usable, but no meaning is added beyond the 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+resource ('Full metadata for one file') and previews the payload ('folder path and web link'), which distinguishes it from read_file_content and get_file_permissions among the siblings. It stops short of explicitly naming those alternatives, but the read-only intent is unambiguous.

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?

There is no guidance on when to call this versus get_file_permissions, read_file_content, or list_folder, nor any stated precondition (e.g., a valid fileId obtained elsewhere). The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation but doesn't state whether it requires specific permissions, what the return format is, or any behavioral traits. Minimal disclosure beyond the basic purpose.

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 a single, efficient sentence that is front-loaded and contains no waste. It's appropriately sized for a simple 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?

Given no annotations, no output schema, and 0% schema coverage, the description is incomplete. It should describe the return structure (e.g., list of users and roles) and any prerequisites. As is, an agent lacks necessary context to invoke confidently.

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%, and the description doesn't explain the 'fileId' parameter. However, the parameter name is self-explanatory, and baseline for 1 parameter is typically low. The description adds no meaning beyond the 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?

The description 'Who can access a file and with what role' clearly states the tool retrieves file permissions, a specific resource distinct from siblings like get_file_metadata or share_file. It implies a read operation but doesn't explicitly name the verb 'get' as the name does, slightly reducing clarity.

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?

No guidance on when to use this tool versus alternatives like get_file_metadata or share_file. The description doesn't specify prerequisites such as authentication or ownership.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema: results are ordered folders-first-then-by-name. But it says nothing about pagination behavior, permission requirements, or what happens with an invalid folderId, leaving meaningful gaps for a no-annotation tool.

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?

Two tight sentences with no filler; the core listing behavior and ordering are front-loaded, and the 'root' targeting hint follows. Every clause earns its place.

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 simple list tool with no output schema and no annotations, the description covers the essentials of what is listed and in what order. It is incomplete on pagination (pageToken is undocumented and there is no output schema to reveal whether more results exist), which an agent needs to page correctly.

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 67%; folderId and maxResults already document their defaults, and the description's 'root' hint largely duplicates the folderId schema default. pageToken remains unexplained in both the schema and the description, so the tool does not fully compensate for the coverage gap.

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?

Specific verb+resource: 'List the direct children of a folder', with the scoping word 'direct' making the non-recursive semantics explicit and the ordering rule stated. It distinguishes itself from browse-style siblings like list_recent_files, though it never names a sibling directly to sharpen the contrast.

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?

'Use "root" for My Drive' tells the agent how to target the top level, and 'direct children' implies this is the browsable, non-recursive listing. However there is no guidance on when to prefer this over search_files or list_recent_files, and no mention of pagination prerequisites despite a pageToken parameter.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose two useful traits: trash exclusion and the default result count. It omits ordering behavior, pagination, and whether shared/drive files are covered, leaving meaningful gaps for a listing tool with zero annotation coverage.

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?

Two terse sentences with the scope constraint front-loaded and no wasted words. It is efficient to the point of being slightly thin, which is a mild weakness rather than a style problem.

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, non-required, read-style list tool with full schema coverage and no output schema, the description is minimally sufficient. It would benefit from noting ordering/pagination behavior and what result set is actually covered, but nothing essential blocks correct invocation.

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 (orderBy, maxResults) are already documented in the schema; the description only restates the default of 10, adding no new semantics. This meets the baseline for schema-driven tools.

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 resource (most recently modified files) with a clear scope qualifier (not in trash) and default size, so an agent can distinguish it from search_files or list_folder. It stops short of naming those siblings explicitly, so differentiation is implied rather than stated.

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 'recently modified, not trashed' framing implies the appropriate context (quick recency listing) but never says when to prefer this over search_files or list_folder, nor any prerequisites. Usage is inferable but not spelled out.

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

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

No annotations provided, so the description carries the full burden. It discloses export transformation behavior and binary file limitation, plus truncation semantics via the maxChars parameter description. Missing details on errors or auth, but solid for a read tool.

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?

Three sentences, front-loaded with the core purpose and followed by format-specific behavior. No wasted words, though could be slightly tighter.

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?

Complete for a read tool with no output schema, covering what is returned, format transformations, binary file limitation, and truncation. Lacks error handling or pagination details, but sufficient for correct invocation.

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 67% (fileId undocumented, format and maxChars described). The description explains format behavior (Docs→md, Sheets→csv, Slides→txt) which overlaps with the schema's enum description, adding little beyond it. 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?

States a specific verb (Return) and resource (file's content as text), and clearly differentiates from download_file for binary files. The per-format behavior (Docs→Markdown, Sheets→CSV, etc.) makes the scope unambiguous.

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 says when NOT to use: binary files like PDFs/images, and names the alternative (download_file). However, it doesn't cover other alternatives like get_file_metadata or update_file_content, leaving some selection ambiguity.

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

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

With no annotations present the description carries the full burden, and it does disclose meaningful behavioral traits: results are metadata only, filters are ANDed (not ORed), and trashed files are excluded unless includeTrashed is true. It omits permission/auth requirements and pagination mechanics beyond the schema's pageToken, which keeps it short of a 5 for an annotation-free tool.

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?

Three sentences, each doing distinct work: capability statement, filter-combination rule, and result-scope/routing note. The most decision-relevant information is front-loaded and there is no filler.

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 an 11-parameter, no-required-args search tool with no output schema, the description covers what is returned (metadata only) and the key default behavior (trash exclusion), which is enough to call it correctly. It leaves pagination and ordering expectations to the schema, which is acceptable but not fully self-contained.

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 91%, so the baseline is 3, but the description adds genuine semantics the schema lacks: the AND-combination rule across all constraints, and the meaning of includeTrashed (which has no schema description at all). It still doesn't elaborate on ordering defaults or page token usage beyond the schema text.

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 states a specific verb (Search) and resource (Drive files) and enumerates the filter axes (name, full text, type, folder, modification date) in the first sentence. It also names the sibling tools (read_file_content, download_file) that handle the content-retrieval use case this tool deliberately does not cover, so the agent can distinguish it from neighbors without opening a schema.

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?

It gives clear routing guidance: use read_file_content or download_file when you need file contents rather than metadata, and it explains that filters combine with AND. It does not address when to prefer list_folder, list_recent_files, or get_file_metadata over this tool, so the sibling boundaries are only partially drawn.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses that the operation writes and grants access to others, and that no email is sent unless sendNotificationEmail is true, but it omits permission requirements and whether existing sharing is replaced.

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 three short sentences, front-loading the mutation/exposure warning, then the core purpose, then the notification default. It is efficient and has no filler, though the opening fragment is slightly terse.

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 an 8-parameter mutation tool with no annotations and no output schema, the description omits critical context such as required permissions and whether the call overwrites existing sharing. It covers purpose and notification behavior, but not enough to handle edge cases confidently.

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 63%, so the schema documents some but not all parameters. The description maps 'user, group, domain, anyone with the link' to the type enum and clarifies the notification default, but adds little for fileId, role, emailAddress, expirationTime, or message beyond the 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?

The description names a concrete action—granting access—and enumerates the targets: user, group, domain, or anyone with the link. It also signals the write/external-sharing nature with 'WRITES and reaches other people,' though it does not explicitly name the inverse sibling, unshare_file.

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 no when-to-use guidance relative to alternatives such as unshare_file or get_file_permissions. The only conditional detail concerns sendNotificationEmail, which is parameter behavior rather than routing guidance.

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

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

With no annotations, the description carries the behavioral burden and does so well by flagging 'WRITES.' and disclosing reversibility for 30 days and that nothing is permanently deleted. It omits permission/auth requirements and any non-obvious side effects, keeping it short of a 5.

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?

Three short clauses, front-loaded with the write signal, and no filler. Every sentence adds essential information about operation and reversibility.

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 one-parameter write tool with no annotations or output schema, the description covers purpose and important reversibility behavior. However, it leaves the sole required parameter undocumented, so an agent still lacks guidance on what fileId should contain.

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% for the single required fileId parameter, and the description never names or explains fileId's expected format. It only implies the ID can refer to a file or folder; that is minimal compensation for the missing schema documentation.

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 ('Move a file or folder to the trash') and immediately distinguishes the operation from its inverse by naming untrash_file. An agent can identify the tool's job without reading the schema.

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?

Provides clear context for when the tool applies (reversible trashing) and names untrash_file as the restoration alternative. It does not explicitly state exclusions or when not to use this versus permanent delete, but the reversible window supplies useful selection context.

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

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

With no annotations, the description must carry the behavioral burden; the 'WRITES' marker and 'Remove one permission' disclose the mutation and its narrow scope. However, it omits reversibility, error/idempotency behavior, and whether both identifiers can be supplied together, leaving notable gaps for a destructive-style write.

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?

Extremely compact, with the operation class front-loaded ('WRITES.') and the identifier options following immediately. Every clause carries information; nothing is padded.

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 single-purpose mutation tool with no annotations and no output schema, the description covers the essential inputs and the link-sharing special case. It stops short of describing failure modes or whether the operation is idempotent, but it is sufficient to invoke correctly.

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 must compensate, and it does for two of three params: permissionId's provenance (get_file_permissions) and the emailAddress special value 'anyone' for link sharing. Only fileId is left implicit, but that is self-evident.

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 ('Remove one permission'), scoped to a single permission, which clearly distinguishes it from the sibling share_file and from get_file_permissions. The 'WRITES' prefix immediately signals the operation class.

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 clear context: identify the permission either by id obtained from get_file_permissions or by the granting email, and names the 'anyone' value for link sharing. It does not explicitly contrast with share_file or state when-not-to-use, but the conditions for each input path are spelled out.

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

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

With no annotations provided, the description carries the full behavioral burden. The 'WRITES.' prefix usefully flags that this is a mutating operation, which is genuine added value. But it does not disclose permission requirements, whether the restore overwrites an existing item at the same path, idempotency, or behavior on a non-trashed ID.

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?

Two short fragments with the mutation signal front-loaded ('WRITES.'). Every word earns its place; nothing redundant or padded.

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 simple single-parameter mutation tool with no output schema and no annotations, the description covers the core action but omits the details an agent most needs before invoking: permission requirements, what happens to conflicting items, and the semantics of fileId.

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% and the description says nothing about fileId. It is unclear whether the single parameter accepts a file ID, a folder ID, or both, or what format is expected. The description does not compensate for the undocumented parameter.

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+resource: restore a file or folder from the trash. This clearly contrasts with the sibling trash_file (the inverse operation). However, it does not name or differentiate against any sibling explicitly, and 'file or folder' leaves the fileId resource type ambiguous.

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?

Usage is implied by the phrase 'from the trash', suggesting the target must currently be trashed, but there is no explicit when-to-use, no prerequisites, and no mention of the trash_file sibling as a complementary operation. An agent can infer the context but is given no routing guidance.

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

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

With no annotations, the description carries the full burden and does meaningful work: it flags a destructive whole-document overwrite and names what is preserved (file id, name, sharing, location). It omits permissions/auth requirements, reversibility, and response behavior, so it is strong but not complete.

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?

Three tight sentences with the mutation warning front-loaded; every clause conveys distinct information about behavior or format. No filler.

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 content-mutating tool with no annotations, no output schema, and thin schema descriptions, the definition covers the destructive semantics, format expectations, and preservation guarantees well. Remaining gaps are auth requirements and return/error behavior.

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 only 33%, so the description must compensate, and it does: it defines what `content` should be per target type (Markdown/HTML/plain text for Docs, CSV for Sheets) and implicitly explains `mimeType` defaults. `fileId` is still left unexplained.

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 ("Replace a file's content") and resource, and the leading "WRITES." makes the mutation unmistakable. It is distinguishable from sibling update_file_metadata because it scopes itself to content, not properties.

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 Doc-vs-Sheet format guidance (Markdown/HTML/plain text vs CSV) implicitly tells the caller which content to pass, but there is no explicit when-to-use statement and no named alternatives (e.g., update_file_metadata, upload_file). Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose two important behaviors beyond the schema: partial-update semantics ('Only the fields passed are changed') and move semantics ('Moving replaces the current parent folder'). It still omits permission requirements, reversibility, and error behavior, keeping it short of a 5.

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?

Three short sentences, front-loaded with the mutation warning 'WRITES.' and with every sentence contributing a distinct fact. Zero filler.

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 5-parameter mutation tool with no annotations, no output schema, and 20% schema coverage, the description covers the mutation and partial-update profile but omits permissions, failure modes, and the return shape. Adequate minimum, but clear gaps remain.

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 only 20%, so the description must compensate. It maps operations onto the fields (name/description/starred/moveToFolderId), but adds no format or constraint detail (e.g., fileId format, folder-not-file validation for moveToFolderId), leaving the mapping implicit.

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?

Names a specific verb (WRITES) plus the exact resource and the four operations it performs: rename, move, describe, star. This cleanly distinguishes it from sibling tools like update_file_content and get_file_metadata.

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 listed operations imply when the tool is useful, but there is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as update_file_content or share_file. Usage is inferred rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. The leading 'WRITES.' correctly signals a mutating operation, and it usefully explains that convertTo imports into a Google-native type. However, it omits permission requirements, overwrite/collision behavior, and any indication of what the call returns.

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?

Three compact sentences, front-loaded with the mutating nature via 'WRITES.' and then the core action. Nearly every phrase earns its place, with only the terse 'WRITES.' banner being slightly cryptic in isolation.

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 five-parameter write tool with no annotations and no output schema, the description covers the conversion nuance well but leaves out permissions, name-collision behavior, and return value. Adequate but with clear gaps an agent would want before invoking.

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 80%, so the baseline is 3, but the description adds real meaning for convertTo (which has no schema description) by explaining that it imports into a Google-native document/spreadsheet/presentation with format examples. This exceeds the schema's bare enum for the most consequential parameter.

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 states a specific verb and resource ('Upload a local file') and clarifies the conversion behavior with concrete format examples. It is clear what the tool does, though it never explicitly distinguishes itself from the sibling 'create_file', leaving the upload-vs-create boundary to inference.

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?

There is no explicit when-to-use guidance and no comparison against alternatives such as create_file or copy_file. Usage is only implied by the phrase 'Upload a local file', so an agent must infer the selecting condition itself.

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