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

With no annotations, the description carries the full behavioral burden. It discloses one useful trait — the default destination when parent_id is omitted — but says nothing about whether an upload requires auth, whether duplicate names are rejected or overwritten, size/mime limits, or 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 short sentences, front-loaded with the core action and then the two decisions an agent must make (which content field, which parent). Nothing is wasted or repeated from the schema.

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 mutation tool with no annotations and no output schema, the key input decisions are covered, but gaps remain around permissions, name-collision behavior, and return values. Adequate but not complete for an agent calling it correctly on first try.

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 20%, so the description has to compensate, and it does: it clarifies that text_content and base64_content are mutually exclusive alternatives and maps each to a content type (UTF-8 vs binary), plus explains the parent_id default. Only `name` and `mime_type` semantics remain thin.

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 first sentence gives a specific verb and resource ('Upload a file'), which immediately distinguishes it from read-oriented siblings like read_file, get_file, and list_files. It stops short of explicitly naming or contrasting with any sibling, but the purpose 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 statement of when to use this versus alternatives (create_folder, share_file) and no prerequisites or permission/auth context. The parent_id fallback is a behavioral detail, not usage guidance, so the agent gets no routing help.

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 it does disclose one genuinely useful behavioral trait: omitting parent_id places the folder in the My Drive root. However it says nothing about required permissions, duplicate-name handling, or what is returned, leaving significant gaps for a mutation 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 zero filler, and the default-location caveat is placed immediately after the core action. Nothing could be removed without losing information.

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 two-parameter create tool with no annotations and no output schema, the description covers the essential action and the one non-obvious default. It is minimally adequate but omits return-value expectations and any permission or naming caveats an agent might need.

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. It usefully documents parent_id's default behavior when omitted, but the required 'name' parameter gets no explanation of constraints or format. Partial compensation warrants a middle score.

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 is unambiguous and distinguishable from the read/write file siblings. It doesn't differentiate against a sibling that also creates containers or explain scope beyond the resource name, so it stops short of a 5.

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 use this versus alternatives, and no prerequisites or preconditions are stated. The only context given is the default location behavior, which is a behavioral fact rather than usage routing.

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 behavioral burden. It implies a read operation but says nothing about permission requirements, error behavior for unknown ids, or how folder metadata differs from file metadata.

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 waste. It is efficient, though arguably so terse that it borders on under-specification.

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 read tool with no output schema and no annotations, the description leaves the return shape ('full metadata' is vague), failure modes, and permission behavior unexplained. Adequate to call correctly, but thin on what to expect back.

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 0%, and the only parameter (file_id) is undocumented in the schema. The description partially compensates by saying 'by id' and noting the id may refer to a file or folder, but adds no format, prefix, or lookup guidance.

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 (Get) and resource (full metadata for a file/folder by id). The word 'metadata' implicitly distinguishes it from read_file (which presumably returns content), but the description never names or contrasts a sibling explicitly.

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 statement of when to use this versus read_file, list_files, or list_permissions. The agent must infer from the name alone that this is the metadata-fetch path, and there are no prerequisites or exclusions given.

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 it does disclose one real behavioral trait: folder_id restricts to direct children, i.e. the listing is non-recursive. It omits permissions/auth requirements, pagination and rate-limit behavior, and the fact that trashed files are excluded by default.

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 with the core purpose front-loaded, then query syntax, then folder scoping. The inline example is the only slightly heavy element, though it earns its place by showing the exact dialect.

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 4-parameter search tool with no output schema and no annotations, the description covers half the parameters and one behavioral constraint. It leaves the agent without any sense of the result shape, ordering, or how the 50-default/200-max result cap interacts with paging.

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 50% (query and folder_id described, max_results and include_trashed undocumented). The description adds genuine meaning for `query` by naming the Drive query dialect and giving a concrete compound predicate, and clarifies folder_id as non-recursive, but contributes nothing for the two uncapped/undocumented parameters.

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 pair (list/search) and resource (files), which an agent can distinguish from read_file/get_file/create_file siblings by the act of enumerating rather than fetching a known file. It stops short of explicitly naming those siblings or stating the boundary between searching and fetching.

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 when-to-use guidance and no explicit alternative; the agent must infer that this is the enumeration counterpart to get_file/read_file. Nothing tells it when searching is preferable to directly retrieving a known file, nor when folder scoping is appropriate versus a query.

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, but it does disclose the return content (subjects and their roles), which is useful behavioral context. It stops short of stating permission/auth requirements, pagination, or behavior on inaccessible or nonexistent files.

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?

One compact sentence with the resource and scope front-loaded and the return content neatly bracketed. No padding 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 simple read-only single-parameter tool with no output schema, the description is adequate: it explains return content in lieu of a schema. It still omits auth/permission prerequisites and scope of listing (direct vs inherited permissions), which an agent might need.

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 0% and the single parameter is required, so the description must compensate. Saying permissions apply to a "file/folder" adds mild meaning by implying file_id accepts both resource types, but it does not explain ID format or behavior for invalid IDs.

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 ("List") and resource ("permissions") scoped to a file/folder, and the parenthetical clarifies the returned content (who has access and with what role). It is clearly distinguishable from write siblings like share_file and remove_permission, though it never explicitly names an alternative.

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, when-not-to-use, or alternative guidance. The agent must infer that this is the read-side counterpart to share_file/remove_permission from the name and siblings alone; the description offers no routing signal.

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 discloses important behavioral traits: content format varies by file type (text vs binary) and Google-native docs are exported/transformed rather than returned raw. However, it omits permissions requirements, large-file handling, rate limits, and whether the downloaded content is cached or fresh.

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 primary action and progressively adding format details. No waste; every sentence adds value.

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?

The description covers output formats and Google-native handling, which is the most important behavioral context. But without annotations or an output schema, it should also state basic operational facts: whether this requires read permission, if there are size limits, and how errors (e.g., file not found) are surfaced.

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 file_id parameter, but the description doesn't need to explain its format (it's a standard identifier). The description focuses on explaining the tool's output behavior instead. With one parameter and clear implied semantics, a 4 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 ('Download') and resource ('file content'), with useful detail on output formats (UTF-8 vs base64) and Google-native export behavior. This distinguishes it from siblings like get_file (metadata) though the description doesn't explicitly name that distinction.

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?

Implied usage is clear: use this to retrieve file content. However, there's no explicit guidance on when to use this vs get_file (which likely fetches metadata), and no prerequisites or edge cases mentioned beyond the format handling.

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 behavioral burden. It says 'revoke', implying mutation, but discloses nothing about permissions required, whether revocation is reversible, cascade effects on inherited permissions, or error behavior for nonexistent ids. Only the minimum is covered.

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 tight sentence with no waste. The prerequisite pointer is front-loaded and 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?

Given the 0% schema coverage and absence of annotations, the description is minimally adequate: it covers the permission_id source but omits file_id context, mutation consequences, and any output/pagination information. It leaves the agent with gaps for a destructive 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 0%, so the description must compensate. It clarifies that permission_id comes from list_permissions, adding real meaning beyond the schema's bare string type. However, file_id is never mentioned in the description, leaving its semantics entirely undocumented.

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 clear verb+resource ('Revoke a specific permission') with the identifier used. It distinguishes itself from read-only siblings like list_permissions, though it does not explicitly contrast with other write tools such as share_file which are related (both affect permissions).

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 prerequisite for the permission_id by directing the agent to list_permissions to obtain ids. It doesn't state when not to use it (e.g., versus share_file for modifying permissions), but the prerequisite is concrete and actionable.

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. It usefully discloses that send_notification defaults to false and therefore no email reaches the recipient, which counters a natural expectation. It does not state permission requirements, whether an existing grant is overwritten, or reversibility.

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 core action, then role semantics, then the notification caveat. No padding, though the 'Missing in the official connector' clause is of questionable value.

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 mutation tool with no annotations, no output schema, and 40% schema coverage, the description covers roles and the notification default but omits authorization needs, overwrite/merge behavior, and error conditions. Adequate but with real 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 only 40%, but the description compensates meaningfully by glossing the role enum (reader=view, commenter, writer=edit, fileOrganizer, organizer, owner) and explaining the send_notification default behavior. file_id, email and message remain undocumented 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 gives a specific verb and resource ('Share a file or folder with someone'), which is immediately distinguishable from siblings like list_permissions and remove_permission. It stops short of explicitly naming which sibling handles permission removal or listing, so it isn't a 5.

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 use this tool versus list_permissions/remove_permission, nor any stated prerequisites (e.g. caller must already have sharing rights). The 'Missing in the official connector' note is meta-commentary about origin, not usage guidance.

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