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

With no annotations provided, the description carries the behavioral disclosure burden. It explains that queue mode executes operations sequentially, supports $N.field chaining, and that batch mode reduces round trips but only where Google publishes a batch method. This is meaningful behavioral context, though it does not discuss side effects, error behavior beyond the schema's onError field, or return shape.

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 two sentences, front-loads the core purpose, and packs the essential mode distinction into a compact, readable form. Every clause earns its place, and the queue/batch contrast is immediately clear.

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 complex 7-parameter tool with no output schema and no annotations, the description plus a 100%-covered input schema is nearly complete. It explains the two modes, sequencing, chaining, and the batch limitation. It does not warn about destructive side effects or enumerate which Google operations have batch support, but the schema's operation description points to the error message for that.

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%, so the baseline is 3. The description reinforces the mode distinction and the 'one call' semantics, but it does not add parameter-level information beyond what the input schema already provides for tool, email, items, detail, operation, and operations.

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 function: perform many operations in a single call, with two distinct modes. It differentiates the internal modes (queue vs batch) but does not explicitly distinguish itself from its sibling queue_operations, so it stops just short of full sibling differentiation.

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 practical guidance: queue is the default and works for every tool, while batch is appropriate when one operation applies across many resources and Google exposes a batch method. It clearly contrasts the two modes, though it does not explicitly state when to prefer individual sibling tools over this bulk tool.

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 full responsibility for disclosing behavioral traits. It names operations like 'authenticate' and 'remove accounts' but does not mention that authentication opens a browser, removal deletes credentials, or that read-only access has caveats. Some of these details appear in the schema parameter descriptions, but the tool description itself is thin on side 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?

A single front-loaded sentence that names the resource and immediately lists the supported operations. It is efficient and scannable, though the list is somewhat dense and could be broken out for easier parsing.

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 input schema is rich and compensates for much of the missing operational detail, so the overall tool definition is usable. However, with no annotations and no output schema, the description leaves workflow-level behavior such as the browser-based auth flow, return values, and removal consequences implicit rather than explicit.

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%, and the schema provides rich detail for every parameter, including the operation enum, access modes, and confirmWriteAccess flow. The description adds no parameter-level meaning itself, so it earns the baseline but no extra credit.

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 and scope: Google Workspace account lifecycle, and enumerates distinct operations (list, authenticate, status, refresh, scopes, remove). This clearly distinguishes it from sibling resource tools like manage_calendar or manage_drive without needing to open 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?

The description gives clear contextual scope: account lifecycle management, and the operation list implies the concrete cases where this tool is appropriate. It does not explicitly name alternatives or state when not to use this tool, but the scope is unambiguous enough for an agent to route correctly.

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 itself must disclose behavioral traits. It only lists broad capabilities and never mentions that create/update/delete mutate data, that update uses patch semantics, that attendees are replaced, or that deleting is irreversible. Some behavioral detail appears in the parameter descriptions, but the main description does not carry the burden for an unannotated 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?

The description is one short sentence with no fluff and front-loads concrete capabilities. The trailing phrase 'or manage calendar events' is redundant and generic, preventing a 5, but the overall text is concise and readable.

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?

This is a complex tool with 20 parameters, 9 operations, and no output schema, yet the schema parameter descriptions cover almost all invocation concerns: per-operation behavior, default calendars, shared-calendar requirements, patch semantics, and availability ranges. The top-level description is thin, but the definition as a whole is sufficiently complete for an agent to select and call the tool safely.

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 the input schema already documents all 20 parameters in detail. The description text adds no parameter-level meaning, meeting the baseline for high coverage. The schema's own descriptions are unusually rich (e.g., allDay boundary handling, attendee replacement), but that is schema content, not description-added value.

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 identifies the resource (calendar events, agenda, availability) and gives concrete verbs: list, view, check, manage. It is not a mere tautology, though 'manage calendar events' is broad and duplicates the tool name rather than enumerating the create/update/delete operations 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?

The description does not explicitly state when to use this tool instead of alternatives such as manage_meet or manage_tasks, but the calendar resource and availability/agenda wording imply its scope. The operation parameter descriptions provide detailed internal routing (e.g., use 'calendars' to discover IDs, 'agenda' for shared calendars), so usage guidance is partially covered within the schema rather than the top-level description.

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 for behavioral disclosure. It does convey the high-level mutability (create/update/delete) and the meaningful scope of 'addresses you have corresponded with but never saved' and 'organization's directory.' However, it does not disclose important behavioral traits such as update replacing existing phone/email values, directory operations being Workspace-only, or pagination behavior; some of this is delegated to schema property descriptions.

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 well-structured sentence that front-loads the action verbs and uses a colon to enumerate the three data scopes. Every word earns its place, and there is no redundant or filler language.

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 13 parameters, 10 operations, and no output schema, the description provides a solid orientation while the rich input schema carries the operational detail. The only notable gap is that return-value structure is not described anywhere, but it is not heavily needed given the schema's references to pagination tokens and printed ids.

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 the baseline is 3 even though the main description contributes no parameter-level meaning. The schema descriptions themselves are detailed and clarify subtle distinctions like `email` being the account email versus `contactEmail` being the contact's email, which is valuable. The description adds no extra parameter context beyond that.

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 opens with a specific verb set — search, read, create, update, delete — tied to Google Contacts, and then distinguishes three data scopes: saved contacts, unsaved 'other contacts', and the organization directory. This makes the tool's purpose unmistakable and clearly separates it from sibling domain tools like manage_calendar or manage_email.

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 provides clear context for when the tool applies by naming the resource and the three contact scopes it covers. It does not explicitly state when not to use it or name alternatives, but the sibling tools cover different domains, so ambiguity is low.

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 of behavioral disclosure, and it only names the operations. Critical mutation traits are absent: write appends rather than overwrites, edits without tabId target the FIRST tab while replaceText spans every tab, character indices are per-tab, and an email is required for authentication. These nuances exist in the schema's parameter text, not in the tool description, so the agent gets no behavioral warning before invoking.

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 12-word single sentence with no wasted words, and the verb list is front-loaded so the agent immediately knows the operation families. However, the brevity veers toward under-specification; it reads as a tagline rather than a specification, which is acceptable for conciseness but shifts substance burdens to other dimensions.

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?

This is a five-operation, 10-parameter, mutation-heavy tool with no annotations and no output schema, yet it gets only a one-line summary. The schema compensates with detailed operation and parameter text, but the tool-level description still omits what get returns, create's default behaviors, per-tab indexing pitfalls, and auth expectations. Not complete enough for an agent to select and call it correctly without deep schema parsing.

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% with strong per-parameter descriptions (tabId explains first-tab targeting, operation explains each enum value, text explains append vs insert semantics), so the baseline of 3 applies. The tool description itself adds zero parameter meaning, but the schema carries the load thoroughly, so no penalty beyond baseline is warranted.

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 specific verbs (read, write, insert, find-replace) and a concrete resource (Google Docs documents), making the tool's domain unmistakable and distinct from siblings like manage_sheets or manage_tasks. It does not differentiate at the operation level, but the operation enum in the schema fills that role. The one-line headline is accurate, if minimal.

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?

Nowhere does the description say when to choose manage_docs over siblings such as manage_drive or manage_sheets, nor does it give selection criteria among the five internal operations. The schema's operation descriptions explain mechanics (append, insert, replace) but offer no when-to-use or when-not-to-use guidance. An agent must infer the intended use case.

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 present, and the description alone does not disclose side effects such as permanent deletes, 30-day trash recovery, missing setRole notifications, or partial tree results. Those traits are documented in the schema's operation enum, which mitigates the transparency gap, but the description field itself carries little behavioral weight.

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 front-loaded sentence with a clear verb series and no significant waste. The final 'or manage files' is somewhat redundant and vague, but overall the length is appropriate given that the schema carries the detailed operational semantics.

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 24-parameter tool with no output schema and no annotations, a high-level verb list is not fully complete on its own; the agent must rely on the schema's extensive operation enum to understand per-operation behavior and outputs. The schema is rich enough to make the definition usable, but the description leaves the tool's full behavioral surface to be discovered elsewhere.

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 the input schema already documents all 24 parameters, including operation-specific meanings, defaults, and required conditions. The description adds no parameter-level meaning, so the baseline of 3 applies even though it does not compensate for anything.

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 lists specific actions (search, upload, download, share, comment) and names Google Drive as the resource, so an agent can tell this is a Drive file-management tool. It lacks explicit differentiation from siblings like manage_docs or manage_sheets, and the trailing 'or manage files' is generic, so it is a clear but not exceptional purpose statement.

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 Google Drive scope and operation list imply when this tool is useful, but the description gives no explicit when-to-use or when-not-to-use guidance and never names alternatives. The useful operational tips (viewImage vs download, trash vs delete, setRole no-notification) live in the schema's operation enum rather than in the description itself.

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 discloses meaningful behavioral details: returned HTML is sanitized and wrapped in a Spotlighting block, archive saves locally without downloading attachments, attachments force draft mode, uploads are capped at 35MB, forward includes original attachments, and replyAll treats cc as additional recipients. This is unusually transparent for an email 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?

The tool description is a single front-loaded sentence naming the resource, major actions, and search syntax support. The operation enum descriptions are long, but each clause is operation-specific and earns its place across 16 distinct operations, with 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?

Given the high complexity — 20 parameters, 16 operations, no annotations, and no output schema — the description is substantially complete. It covers operation behaviors, attachment handling, draft behavior, and limits. It falls just short of fully complete because return shapes for operations like search, labels, and threads are not described, and no auth/account prerequisites are stated beyond the required email parameter.

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 the baseline is 3 and the schema already documents all 20 parameters. The tool-level description adds no parameter-level semantics. The operation enum clarifies behavior, but that detail is part of the schema rather than something the description contributes beyond it.

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 opens with explicit actions on a concrete resource: 'Search, read, send, forward, or manage emails in a Google Workspace account.' It also adds a distinguishing capability, Gmail search syntax support. Sibling tools are calendar/drive/tasks, so this is unambiguously the email tool.

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 operation enum provides detailed routing guidance: read says to pass bodyFormat 'html' when the plain-text part is a stub; viewAttachment says use it for quick preview and use getAttachment to save; archive clarifies it is a local archive, not Gmail's remove-from-inbox. This gives the agent explicit context for choosing among operations.

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 adds one useful behavioral fact (Workspace Business Standard+ required for transcripts/recordings) but otherwise frames the tool as read-only. It does not disclose that operations like updateSpace and endActiveConference mutate or terminate live meetings, which is material behavior for an agent to know.

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?

Both sentences earn their place and front-load the domain plus the license caveat. It is compact and free of filler, though the brevity contributes to under-specifying active-management capabilities.

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 16-operation tool with 12 parameters, no output schema, and no annotations, two sentences about browsing and licensing are insufficient. The definition omits entire categories of behavior, such as active conferences, creating/updating spaces, and ending calls, and gives no account of mutation effects or required permissions. The rich operation enum in the schema compensates only partially.

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 input schema covers 100% of parameters with descriptions and detailed enum explanations, so the baseline is 3. The prose description adds only the licensing constraint tied to transcripts/recordings, not parameter-level semantics beyond what the schema already provides.

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 core read/browse function is explicit: 'Browse past Google Meet conferences, participants, transcripts, recordings, and AI-generated smart notes,' and 'Google Meet' clearly distinguishes this from sibling tools. However, the description understates the full operation set, which also includes createSpace, updateSpace, and endActiveConference, so the purpose is not fully represented.

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 a clear context for historical reads and a hard licensing prerequisite for transcripts/recordings, so an agent can infer when browsing Meet data is appropriate. It offers no guidance about when to prefer this over sibling tools or when to use the mutation operations, leaving that entirely to the schema.

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 burden of behavioral disclosure. It usefully states the workflow: compose, edit by line or JSON path, attach files, and send to any target. However, it does not disclose side effects, irreversibility of sends, lifecycle/destruction of scratchpads, auth requirements, or error behavior, so important behavioral context is left to the schema.

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 tightly packed sentences: purpose, workflow, and a functional exclusion. Every sentence earns its place, the main payload is front-loaded, and there is no fluff or repetition that wastes an agent's context window.

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 19-parameter tool with 17 operations and no output schema, the description supplies a clear mental model that the schema cannot provide, and the schema supplies the per-operation and per-parameter detail. The main gap is that the generic 'service tool' alternative is not mapped to a concrete sibling, and import/copy/list/discard aspects are only discoverable from the schema.

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 the schema already documents all 19 parameters. The description adds a useful high-level grouping (line editing, JSON path, attachment, delivery) but does not add syntactic or semantic detail beyond what the parameter descriptions already provide; 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?

The description clearly identifies the tool as composing, editing, and delivering multi-line text content, and ties it to a distinct scratchpad workflow (edit by line/JSON path, attach, send). It does not explicitly differentiate among the named sibling tools beyond pointing to a generic 'service tool', so it misses the strongest sibling-differentiation credit.

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 an explicit when-to-use signal ('any multi-line content: emails, documents, descriptions') and an explicit when-not-to-use signal ('short one-liners... use the service tool directly'). The alternative is named only generically, not tied to a specific sibling, which is a partial gap.

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 of behavioral disclosure, but 'read, write, and manage' only vaguely signals mutation. It does not mention side effects, irreversibility like deleteSheet, creation behavior, or output shape; those details appear later in the schema but are absent from the description itself.

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 front-loaded sentence with no filler, and every word earns its place. It is appropriately terse given the schema's rich parameter and operation documentation, though it offers no structured guidance for the many operations.

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 input schema is rich and covers all parameters and operation semantics, so the generic description is not fatal. However, with no output schema and no usage direction beyond 'Google Sheets,' an agent must rely almost entirely on the schema to understand call patterns, operation selection, and expected results.

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%, and every parameter has a detailed description, so the baseline is 3. The tool description adds no parameter-level meaning beyond identifying the domain, but the schema fully compensates.

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, 'Read, write, and manage Google Sheets spreadsheets,' names a specific resource and clear high-level verbs. It distinguishes the tool from sibling manage_* tools by explicitly targeting Google Sheets, though it does not enumerate the 13 operations or contrast directly with tools like manage_docs or manage_drive.

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 is implied by the resource phrase 'Google Sheets spreadsheets,' which gives basic context among the manage_* sibling suite. There is no explicit when-to-use/when-not-to-use guidance, and no alternatives are mentioned.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Manage' implies mutation and side effects but does not state that deletions are destructive, updates use patch semantics, or that operations may permanently remove tasks. The schema's operation descriptions contain some of this, but the description itself does not.

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 short sentence with no filler or redundant content. It is front-loaded with the domain and resource type, though it may be too terse to be fully useful on its own, the conciseness itself is appropriate.

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?

This is a complex tool with 10 parameters, 10 distinct operations, no annotations, and no output schema. A one-sentence overview is insufficient context for an agent to safely select and invoke operations, understand return values, or know prerequisites. The description leaves substantial gaps that the schema alone only partially fills.

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 the input schema already documents every parameter in detail, including enum meanings, defaults, and special notes like due-date storage. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline of 3.

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 the specific resource domain — 'task lists and tasks in Google Tasks' — which distinguishes it from sibling tools like manage_calendar or manage_drive. The verb 'Manage' is generic, but the object is clear enough for an agent to identify the tool's scope.

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 is provided about when to use this tool versus alternatives, when not to use it, or which operation to choose in a given situation. The operation enum does provide choices, but the description itself offers no selection criteria or prerequisites.

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 must carry behavioral disclosure. It only mentions nested-path support and the file-exchange context. It does not disclose that operations like delete, move, or write are mutating or potentially destructive, nor any overwrite semantics, irreversibility, or permission requirements.

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 with no filler: purpose, path capability, and integration context are each stated once and front-loaded. The example path 'reports/q1/summary.csv' is concrete and 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?

The workspace-scope and nested-path context combine well with a high-coverage schema that spells out operations and defaults. However, with no annotations and no output schema, the description leaves destructive-operation caveats, expected return shapes, and path-boundary limits implicit, making it adequate but not fully 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 100%, so the schema already documents all six parameters and explains each operation enum value and destination default. The description adds the nested-path convention and workspace role, but this is contextual rather than necessary parameter semantics.

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 opens with 'Manage files and directories in the workspace sandbox,' naming a concrete resource and scope that separates it from siblings like manage_drive or manage_docs. The nested-path example further clarifies the file-operation role. 'Manage' is somewhat broad, but the schema's operation enum removes ambiguity.

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 says the workspace is 'the exchange point for file operations (attachments, downloads, exports),' which implies use when exchanging files with the workspace. However, it does not explicitly state when to prefer this over alternatives such as manage_drive, nor does it mention exclusions.

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 of behavioral disclosure. It discloses the two execution modes, the default mode, result chaining with $N.field, and the deprecation status. However, it does not mention potential side effects, permissions required, or what the operation result/return shape looks like, which are relevant for a tool that can execute arbitrary operations.

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 compact and front-loaded with the most important information: the rename and deprecation. Each sentence earns its place by explaining mode selection, sequencing, chaining, and batch limitations without repetition or fluff.

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 complex tool with seven parameters, two modes, and no output schema, the description covers the core decision points: mode choice, chaining mechanics, batch constraints, and deprecation. The parameter schema fills the remaining details. It is slightly incomplete only because it does not discuss output/return behavior or authorization/side-effect considerations, but overall it is 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 description coverage is 100%, so the baseline is 3. The text adds meaningful context beyond the schema by explaining that 'queue' works for every tool, that 'batch' is beneficial due to fewer round trips but only where batch methods exist, and that $N.field references chain results. This goes beyond the enum descriptions in 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 clearly states that the tool does many things in one call and explains the two modes ('queue' and 'batch'). It also identifies this as a deprecated alias of 'bulk_operations', which gives the agent a concrete point of reference, though it does not distinguish itself from that sibling because it is the same tool.

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 says when to use each mode: 'queue' for sequential operations with chaining, 'batch' for one operation across many resources with fewer round trips. It also warns that batch is only available where Google publishes a batch method, and it tells the agent the preferred alternative name is 'bulk_operations' since this name will be removed.

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