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

With no annotations provided, the description discloses several important behaviors: that guests are restricted to allowedRecipients, that no notification mail is sent unless sendUpdates is 'all', and that endDate is exclusive. It also clarifies timed versus all-day event requirements. These go beyond the schema, which is valuable for an agent anticipating side effects (e.g., no emails by default). Minor gap: it doesn't state whether events can overlap or what happens on partial failures (e.g., one guest invalid), but the key side effect of mail sending 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?

The description is a single, dense paragraph that front-loads the key distinction between timed and all-day events. It is concise, with no fluff, and each sentence adds meaningful information. It could be slightly improved by breaking into bullet points, but for its length, it is efficient and well-organized.

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 11 parameters but no output schema, the description covers the most critical usage nuances: how to specify timed vs all-day events, the exclusive endDate rule, guest restrictions, and email notification behavior. Given the tool's complexity, the description addresses the likely failure points (format issues, guest acceptance, notification side effects). It is complete enough for an agent to correctly construct a request without additional external context.

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 provides detailed descriptions for most parameters (82% coverage), including format examples for start and startDate, and the role of attendees. The description adds value by clarifying the relationship between start/end and startDate/endDate (timed vs all-day) and reiterating the exclusivity of endDate, but since the schema already covers most semantics, the description's additional meaning is supplemental rather than essential. The baseline of 3 is appropriate because schema coverage is high, and the description does not introduce extra parameters or new clarified meaning beyond the schema's.

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 verb 'Create' and the specific resource 'event on one Google Calendar', distinguishing it from sibling tools like calendar_update_event and calendar_delete_event. It covers the primary purpose without ambiguity, making it immediately clear what the tool does.

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 focuses on mechanics (timed vs all-day events, guest restrictions) but does not provide explicit guidance on when to use this tool versus alternatives like calendar_update_event. There is no mention of prerequisites (e.g., calendar must exist) or scenarios where another tool would be more appropriate, leaving usage context implicit.

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 thoroughly discloses irreversibility (no trash), the confirm flag's dry-run behavior, and the refusal of recurring series without confirmSeries. This is exemplary transparency for a destructive operation.

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, with the most critical warning front-loaded. The second sentence is dense but packs essential behavior. No filler; every clause adds value. Slightly long but justified.

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 destructive tool with no annotations and no output schema, the description is remarkably complete. It covers the core action, the confirm mechanism, the recurring series edge case, and even hints at the return value when not confirmed. An agent has everything needed to invoke it 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 100%, so baseline is 3. The description adds meaningful semantics beyond the schema for confirm (explaining it must be true to delete and that false returns the event) and confirmSeries (explaining it removes every occurrence). This elevates it above 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?

The description clearly states the action ('Delete an event') and the resource. It distinguishes from siblings like calendar_update_event and calendar_respond_to_event by focusing on deletion. The additional context about irreversibility and confirm flags further clarifies its specific role.

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 implies when to use it (to delete an event) and provides key usage conditions: the need for confirm:true and confirmSeries for recurring events. While it doesn't explicitly name alternatives or say 'use this when...', the context makes the intended use clear.

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 of behavioral disclosure. It states 'can read', implying read-only, but does not mention any permissions, error conditions (e.g., invalid account), or response characteristics. For a simple list, this is a significant gap given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that fully conveys the tool's purpose. No wasted words, and the key information is front-loaded. Excellent structure.

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 low-complexity tool with one parameter fully documented in the schema, the description is minimally adequate. However, since there is no output schema, the description does not hint at the return format (e.g., list of calendar IDs and names) or any pagination/limits. Given the simplicity, this is acceptable but not thorough.

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 provides 100% coverage of the 'account' parameter with a clear description and example. The tool description adds no additional semantic information beyond what the schema already provides. Baseline of 3 applies due to high schema coverage.

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 the specific verb 'List' with the resource 'Google Calendars' and the scope 'an account can read'. This clearly distinguishes it from sibling tools like calendar_list_events (which lists events) and gmail_list_accounts. No ambiguity in purpose.

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 implies the tool is for listing calendars readable by an account, but it does not explicitly state when to use it versus alternatives. There is no mention of when not to use it or any exclusions. The name and context make the use case obvious, but explicit guidance is absent.

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 disclose behavioral traits. It does disclose two important behaviors: recurring events are expanded into occurrences, and it is read-only. However, it does not go beyond that to mention potential rate limits, authentication requirements, or how pagination works (though maxResults is in the schema). For a read-only list operation, the disclosed behaviors are sufficient to set expectations, but the description could add more context about what is returned.

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 short sentences with zero filler. The core purpose is front-loaded, and the recurring-expansion note adds key behavior without bloating the text. Every word 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 read-only list operation with no output schema, the description covers the essential behavior: what it lists, the scope, and the recurring-event expansion. It does not describe the return format, but the agent can infer that events are returned. The lack of explicit exclusions or error handling is minor given the simplicity of the tool. The description is adequate for an agent to invoke it 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 100%, so all five parameters have descriptive text. The description adds no additional parameter-level information beyond what the schema already provides. It mentions 'time range' which maps to timeMin/timeMax, but this is redundant with the schema. The baseline of 3 applies because the schema does the heavy lifting, and the description does not compensate with extra syntax or format details.

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'), a clear resource ('events from one Google Calendar'), and a scope ('within a time range'). It also notes that recurring events are expanded, which adds precision. This distinguishes it from sibling tools like calendar_list_calendars (which lists calendars, not events) and ical_list_events (which handles iCal feeds, not Google Calendar). 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?

The description clearly states what the tool does but does not explicitly mention when to use it versus alternatives. It implies usage for Google Calendar events, but there is no explicit exclusion of iCal feeds or other calendar systems. Since the sibling list includes ical_list_events, a clearer 'use this for Google Calendar, not iCal' would improve guidance, but the purpose is clear enough that an agent can infer the right 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 present, the description carries the full burden of behavioral disclosure. It clearly states that the operation affects only the calling account's own participation status, cannot affect others, and does not create/move/delete events. This is substantive behavioral context beyond the input schema, though it stops short of describing response behavior or prerequisites.

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 tightly written sentences, no filler, and the most important facts (what the tool does, the allowed responses) are front-loaded. The scope limitation is stated crisply.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description covers the essential calling context: purpose, allowed values, limitation to the current account, and the 'not create/move/delete' guardrail. It is sufficient for an agent to decide when to use it, though it could perhaps note that eventId comes from calendar_list_events.

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 all five parameters are already described in the input schema. The description adds some context (for example, confirm the response values and framing the comment as a note to the organizer), but it does not materially extend the per-parameter semantic detail. 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 names a specific verb ('Answer a calendar invitation'), the resource (calendar event), and the possible outcomes (accept, decline, or tentatively), and it explicitly differentiates itself from create/move/delete actions. An agent can tell exactly what this does relative to siblings like calendar_create_event.

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 clearly states when to use the tool—responding to an invitation—and what it cannot do (create, move, delete, or change others' answers). It does not name sibling tools explicitly as alternatives, but the exclusion language makes the intended use unambiguous.

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 discloses several critical behaviors: partial updates (only passed fields written), attendees replacing the whole list, etag-based conflict detection, and the requirement for confirmSeries on recurring series. This is strong transparency beyond the schema, though it omits details about permissions or error responses.

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 sentences with no wasted words. It leads with the core purpose, then provides essential behavioral nuances. Each sentence adds critical information, making it both concise and well-structured.

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 and complex behaviors like partial updates, etag guarding, and series handling, the description covers the essential decision points. It lacks an explicit mention of return values or detailed error conditions, but given the absence of an output schema, this is acceptable. The description is sufficiently complete for an agent to invoke the tool correctly in most scenarios.

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 85%, so the baseline is 3. The description adds valuable semantics: it clarifies that fields not passed are left unchanged, that attendees replaces the entire guest list, and that confirmSeries is required for series. These nuances are not in the schema, enhancing parameter understanding.

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 action ('Change fields of an existing event') and specifies the resource and scope, listing exactly which fields are affected. It immediately distinguishes this from creation or deletion of events, making the tool's purpose 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?

The description implies this is for updating existing events, but it does not explicitly contrast it with calendar_create_event or calendar_delete_event. It provides no 'when not to use' guidance, leaving some inference to the agent. However, the main purpose is clear enough to route correctly in most cases.

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 of behavioral disclosure, and it delivers richly: server-side copying, type preservation, description appending, name-conflict refusal, folder-source refusal, and no source mutation. It even explains cross-location behavior like copying from My Drive into a shared drive. This is far beyond the minimum.

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 long but every section earns its place given the lack of annotations. It is front-loaded with the core action, then covers mechanics, edge cases, and exclusions. Minor redundancy exists between 'rather than overwriting it' and 'it cannot ... overwrite anything,' but the overall structure remains efficient for the behavioral depth provided.

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 is thorough for a four-parameter tool with no annotations and no output schema: it covers what happens server-side, edge cases, refusal conditions, and what the operation does not do. The only notable omission is the shape of the return value, which is not described at all, but everything needed to invoke it correctly and predict behavior is present.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter behavior beyond the schema: it clarifies the 'same account' constraint, the destination folder semantics, the copy-name conflict rule, and that fileId must not be a folder. This enriches the parameters without being redundant.

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 and resource: 'Copy a Google Drive file into a folder on the same account, optionally under a new name.' This clearly distinguishes the tool from siblings like drive_move_file, drive_trash_file, or drive_export_file. The rest of the description reinforces the scope by listing what the tool cannot do.

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 strong context for when this tool is appropriate: it is a copy-only operation that never deletes, moves, renames, shares, or overwrites. It also states explicit refusals for name conflicts and folder sources. It does not name the sibling tools to use for those other operations, but the exclusionary guidance is clear enough for an agent to route around them.

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 excellently discloses the idempotent behavior (returns existing folder if duplicate name), which is a non-obvious and critical behavioral trait. It also explicitly states limitations (cannot rename, move, delete, upload, share), giving the agent a clear picture of what it cannot do. This goes beyond what any schema could convey.

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 with zero fluff. It front-loads the primary purpose, then immediately gives the key behavioral nuance (idempotency) and a brief list of exclusions. Every word earns its place, and it is highly scannable.

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 3 parameters (all documented in schema) and no output schema, the description covers the essential behaviors and limitations. It lacks information about the return value (what the created or found folder object looks like) and possible permissions or auth requirements, but given the absence of an output schema and annotations, these are not strictly required. It is fairly complete for safe invocation, though a bit more about return format would push it to 5.

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%, and the schema already describes each parameter (name, account, parentId). The description adds no additional parameter-level meaning beyond what the schema provides, such as format or examples for parentId. It does mention default behavior ('Defaults to root') which is in the schema. Since the schema is complete, the baseline of 3 is appropriate; the description does not need to compensate.

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 verb ('create') and resource ('folder in Google Drive'), and goes beyond a simple definition by specifying the idempotent behavior (returns existing folder if name already exists under parent). This clearly differentiates it from sibling tools like drive_create_spreadsheet and drive_move_file. The scope is precise and 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?

It clearly states what the tool does (create a folder) and implies when to use it for folder creation. It also explicitly lists what it cannot do (rename, move, delete, upload, share), effectively excluding those use cases. However, it doesn't explicitly name alternative tools for operations like moving or renaming, though these are evident from the sibling list. The exclusions are valuable but could be more explicitly tied to alternatives.

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 key behaviors: creation of a new file, refusal when a name exists, never writing into existing spreadsheets, never sharing, and the valueInput interpretation (USER_ENTERED vs RAW). It also specifies limits (20 tabs, 20000 cells). It does not mention the response format or error handling beyond name conflict, but the described behaviors are sufficient for an agent to understand the tool's side effects and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence adds value. It opens with the core purpose, then explains the parameter structure and limits, then clarifies behavioral constraints and valueInput semantics. No filler or redundancy. It is well-organized and front-loaded, making it easy for an agent to parse quickly.

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 five parameters and a nested sheet structure, the description is remarkably complete. It covers the purpose, the input format, the constraints (name conflict, limits), the value interpretation, and the non-actions (no sharing, no overwriting). While it doesn't describe the return value, there is no output schema, and the description provides enough context for an agent to call the tool correctly. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful context beyond the schema: it explains the structure of the sheets array, the meaning of USER_ENTERED (parsing numbers/dates) and RAW (literal text), and the refusal behavior. This enriches parameter semantics and helps the agent construct correct inputs.

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 clear verb ('Create'), a specific resource ('a new Google Sheet in a Drive folder'), and the key action ('fill its tabs in one call'). It also details the parameter structure and limits, making it distinct from sibling tools like drive_create_folder or drive_copy_file. This fully clarifies what the tool does and how it differs from others.

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 implicitly defines when to use it: for creating a new spreadsheet with content, and explicitly states it never writes into an existing spreadsheet, which signals not to use it for modifications. However, it does not name alternative tools for editing existing files, leaving the 'when not to use' somewhat implicit. Still, the context is clear enough for an agent to choose this tool for new spreadsheet creation.

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 transparency burden and succeeds impressively. It discloses read-only semantics ('Read-only'), failure modes ('refused'), a hard limit (200 KB cap), a precise truncation policy (line boundary), an unexpected side effect (full text written into the download directory), and the return shape ('savedTo'). This is exactly the kind of behavioral context an agent needs.

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 earning its place: the first defines core functionality, the second clarifies exclusions, and the third covers limits, side effects, and return behavior. It's dense yet readable, front-loads the primary action, and contains 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?

Despite having no output schema and no annotations, the description covers inputs, supported vs. refused content, size limits, truncation behavior, side effects, and the return path. For a tool with only three parameters and a straightforward output, nothing critical is missing for an agent to invoke it 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 100%, so baseline is 3. The description reiterates what the schema already says: 'sheet' selects a tab by title, fileId must be a Google Sheet or Doc, and account is an alias. It adds no new parameter-specific semantics beyond the schema, so the baseline score stands.

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 and resource: 'Read the content of a Google-native document on Drive' and then expands on the two supported forms (Sheet → CSV, Doc → plain text). It clearly distinguishes this tool from the many drive siblings by announcing what it will refuse (PDF, image, uploaded .xlsx). An agent can determine exactly what this tool does 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?

The description gives implicit selection guidance: use it for Google-native documents, and avoid it for binary/file uploads. It explicitly states the supported file types and the refusal behavior, which tells an agent when not to call it. However, it never names alternatives (e.g., drive_get_attachment or drive_list_files), so the guidance is clear but not fully explicit.

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, and it clearly discloses that the tool is read-only and returns only metadata ('name, type, size, modified time, parent folders, link, checksum'), explicitly ruling out content access. It could add more operational detail such as pagination or rate-limit behavior, but the safety profile and metadata scope are well 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?

The three sentences are dense but purposeful: purpose first, then behavior and metadata scope, then the invocation constraint. There is no filler or repetition of schema content.

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 six parameters, no output schema, and no annotations, the description covers the modes, metadata scope, and the key constraint. It omits explicit return shape and pagination details, but the schema's pageToken and nextPageToken references mitigate that gap reasonably well.

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 83%, so the schema already documents most parameters. The description adds the crucial mutual-exclusion rule 'Pass folderId or nameContains, not both,' which is absent from the schema and resolves ambiguity about how to choose between folder listing and Drive-wide search.

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 and resource: 'List files and folders in a Google Drive folder, or search all of Drive by a name fragment.' It clearly covers both modes of operation and the read-only scope, which distinguishes it from sibling mutating Drive tools like create, move, trash, and export even without naming them 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?

It states when to use the tool: to list a folder's children or search Drive by name fragment. It also clarifies when not to use it if file content is needed ('never opens, downloads, or reveals file content') and gives the explicit instruction 'Pass folderId or nameContains, not both.' It does not name a specific alternative tool, but the read-only constraint effectively routes content-needing calls elsewhere.

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 of behavioral disclosure. It discloses that the tool refuses on name conflicts, cannot delete/copy, and cannot move across Google accounts. These are meaningful behavioral constraints beyond the schema and help an agent predict outcomes, though it omits some details like permission requirements or return 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?

Three sentences, no filler, and the primary purpose is front-loaded. Every sentence earns its place: the first states the operation, the second notes the conflict behavior, and the third clarifies exclusions.

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 the core operation, optional combinations, conflict refusal, and account-scope restriction. It does not describe the return value or error format, but no output schema exists and the essential behavior for calling the tool is present. Minor gaps around permissions and response shape keep it from being 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 four parameters. The description adds that folderId and name are optional and can be combined, but it does not provide new parameter-level detail beyond what the schema states. 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 states a specific verb ('Move'), resource ('a Google Drive file'), and the operations supported: move to a different folder, rename, or both in one call. It clearly distinguishes itself from copy/delete tools by explicitly saying it cannot delete or copy, and the singular 'file' differentiates it from the batch-oriented sibling drive_move_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says what the tool does and what it cannot do (delete, copy, cross-account move), but it does not explicitly say when to use this tool versus alternatives like drive_move_files or drive_copy_file. It lacks clear if-then routing or named alternatives, so an agent must infer when to choose this tool over the sibling list.

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 well: it discloses per-row processing order, that each row yields a result, and that specific failure conditions (name collision, missing target, trashed source) only refuse that row while others proceed. It also states explicit non-capabilities. This is comprehensive behavioral disclosure.

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 sentences, no filler. The key point (batch form of drive_move_file) is front-loaded, and every clause contributes: row structure, limit, ordering, per-row behavior, and exclusions. Highly efficient.

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 tool's complexity (batch with per-row outcomes) and no output schema, the description should specify the result format more concretely. It says 'one result row per item' but does not detail what that row contains or how success/failure is indicated. It references the single tool's checks, which helps, but the missing explicit result structure is a slight gap for an agent expecting a precise response shape.

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 parameters are already documented. The description adds value by explaining the row structure ({fileId, folderId?, name?}) and the semantics of processing in order with one result per item, which goes beyond the schema's field descriptions. This slightly exceeds the baseline for fully covered schemas.

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 it is a batch form of drive_move_file, specifying the action (move/rename up to 100 files) and the resource. It differentiates itself from the sibling drive_move_file by being batch-oriented, making its purpose 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?

It references the single-tool drive_move_file and lists exclusions (cannot delete, copy, or move to another account), which helps rule out alternatives. However, it does not explicitly state when to prefer batch over single (e.g., 'use when moving multiple files') or compare with other drive operations like copy or trash, leaving some inference to the agent.

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 zero annotations, the description carries the full burden, and it delivers: discloses the streaming mechanism (Gmail→Drive direct, never through local disk), the non-overwrite collision behavior, that nothing is returned in the result, and that it is non-destructive and narrowly scoped to existing Gmail attachments. This is unusually rich behavioral disclosure for a tool with no annotation safety net.

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 dense sentences, each earning its place: the core action with mechanism, the collision/refusal behavior, and the capability exclusions. Information is front-loaded — the action and key constraint appear in the first sentence — and there is no filler, no restatement of the tool name, and no repetition of schema content.

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 description covers the essentials: what it writes, where, what it will not overwrite, what it returns (nothing in the result), and what it cannot do. Minor gaps remain — the shape of the success/error result and Drive permission requirements — but nothing an agent needs to avoid a destructive or wrong call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all five parameters clearly — including the name default ('Defaults to the attachment's own (sanitised) filename') and the cross-reference in attachmentId ('from gmail_read_message'). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 action ('Save a Gmail attachment straight into a Google Drive folder') with a clear resource and scope. It behaviorally distinguishes itself from siblings like gmail_get_attachment by noting the bytes 'never come back in the tool result' and from a hypothetical upload tool by insisting it 'cannot upload a local 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 clear preconditions ('only an attachment already on a Gmail message') and explicit exclusions ('cannot delete anything, cannot upload a local file'), so an agent knows what not to attempt. However, it never names an alternative tool or states 'use X instead when...' — sibling routing is left to inference, which is a gap for a tool sitting between gmail_* and drive_* families.

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 disclosure burden and does so thoroughly. It reveals the 30-day retention, the absence of permanent-delete endpoints, the dry-run behavior without confirm, the folder-contents risk, and the already-in-trash refusal. This is exactly the behavioral context an agent needs before invoking a destructive-capable 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 dense but every sentence earns its place: action, safety model, two guards, folder hazard, and edge case. It is front-loaded with the core operation and then layers necessary cautions in a logical order for a risky 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?

For a 5-parameter mutation tool with no annotations and no output schema, this description is unusually complete. It explains all preconditions, guard behaviors, scope of effect, and failure cases. Nothing an agent needs to decide whether and how to invoke it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description reinforces the meaning of confirm, expectedName, and confirmFolder, but it mostly restates what the schema already says rather than adding substantial new parameter-level semantics. Some extra color like 'wrong or stale id is refused' is helpful but not transformative.

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 precise verb and resource: move one Google Drive file or folder to the Drive trash via files.update with trashed=true. The singular 'one' distinguishes it from the sibling drive_trash_files, and it clarifies this is a restore-able trash action, not a permanent delete.

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 usage context: it explains the confirm flag guard, the required confirmFolder for folders, and that already-trashed files are refused. However, it does not explicitly compare itself to sibling tools such as drive_trash_files, so the when-not-to-use guidance relies on inference from the word 'one'.

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 zero annotations, the description carries full behavioral weight and does so thoroughly: ordered processing, one result row per item, per-row refusal isolation with concrete refusal reasons, preview-only behavior without confirm: true, folder-specific confirmFolder requirement, 30-day restore window, and the explicit absence of a permanent-delete path. This goes far beyond a typical description.

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 dense sentences with the core purpose front-loaded and every clause adding value (batch limits, ordering, refusal isolation, guards, retention). Slightly long, and the middle sentence partially repeats schema content, but the density is justified for a guarded mutation tool with no annotations.

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?

Inputs are fully specified by the schema, and the description thoroughly covers behavioral semantics and failure modes given that no output schema exists. The main gap is that result-row fields are only hinted at ('one result row per item' plus refusal reasons) rather than enumerated, which an agent would need to parse the response reliably.

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 already documents confirm ('previews every row and changes nothing'), confirmFolder ('a folder row without it is refused'), and expectedName ('The file's current name, exactly'). The description mostly restates these guards rather than adding new parameter meaning, so the high-coverage baseline of 3 applies.

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 ('batch form of drive_trash_file ... trash') with a precise scope: up to 100 {fileId, expectedName} items in one call. Explicitly names the sibling it is the batch version of, and clarifies boundaries ('Trash only, restorable for 30 days; no permanent delete'). An agent can unambiguously distinguish it from drive_trash_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?

Establishes clear when-to-use context: batch trashing of up to 100 accepted items in a single call, and references the single-tool counterpart ('Same guards as the single tool'). It does not explicitly state 'use drive_trash_file for a single item' or enumerate exclusions, so it stops short of a 5, but the batch-vs-single differentiation is strong.

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 of behavioral disclosure. It explicitly warns about the destructive consequence of adding TRASH/SPAM (30-day purge) and the confirm requirement, which is a significant behavioral trait. However, it does not mention other potential side effects, permissions, or idempotency, leaving some 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 sentences, front-loaded with the main action and immediately followed by the critical destructive-warning. No unnecessary words; every sentence adds essential 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?

Given the tool's simplicity and lack of output schema, the description covers the key operational constraints (confirm requirement, label ID flexibility). It does not clarify the format of messageIds (e.g., that they are Gmail message IDs), but this is reasonably inferable from the tool name and context. The absence of an output schema makes return-value explanation unnecessary. Overall, sufficient for an agent 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?

The description adds value beyond the schema: it explains that label names may be Gmail label IDs (not in schema) and clarifies the confirm parameter's purpose in context of TRASH/SPAM. The schema covers only 40% of parameters (account and confirm have descriptions; messageIds, addLabelNames, removeLabelNames lack descriptions), so the description helps by implying the meanings of add/remove label arrays, though it does not explicitly define them.

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 action ('Add and/or remove labels') on a specific resource ('Gmail messages'), and clarifies that label names may be IDs. It clearly distinguishes from siblings like gmail_create_label or gmail_update_label which operate on label definitions, not messages.

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 crucial usage caveat (TRASH/SPAM require confirm:true, removal does not) but does not explicitly explain when to choose this tool over alternatives such as gmail_archive or gmail_read_message. The usage context is implied by the name and purpose, but no direct guidance on alternative selection is provided.

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 clarify the core behavior: archiving means only removing the INBOX label, not deleting messages. It does not discuss idempotence, error cases, or whether messages without other labels are affected, but the key side effect is explicitly disclosed.

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 active-voice sentence that is front-loaded with the action and resource, with no filler or redundant phrasing. Every word contributes to understanding the 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?

For a simple two-parameter mutation with no annotations and no output schema, the description is minimally viable. It omits the expected return value, behavior for already-archived or non-existent message IDs, and potential errors, leaving clear gaps for an agent relying solely on this definition.

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%; only 'account' is documented. The tool description says 'Gmail messages' but does not explain how messageIds should be obtained, what format they use, or any constraints beyond the schema's basic array items. The description adds little semantic value over the parameter names.

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 uses a specific verb ('Archive'), a clear resource ('Gmail messages'), and a precise mechanism ('removing the INBOX label'). This removes ambiguity around whether archiving deletes or moves messages)Skip to content, and distinguishes it from related label-management operations.

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 rather than gmail_apply_labels, gmail_search, or other Gmail operations. The intended use is implied by the verb 'Archive', but no prerequisites, alternatives, or exclusions are 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 provided, the description carries the full burden of behavioral disclosureString, and it does so exemplarily. It discloses the dry-run behavior, the ignore of forward action, the destructive potential (TRASH/SPAM with 30-day purge), and the confirmation gate. It also explains the exact condition for confirm (apply true + TRASH/SPAM) and stresses the dry run is never gated. This goes beyond mere annotation hints and provides actionable safety context.

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 paragraph of about three sentences, front-loaded with the core purpose and dry-run behavior. It efficiently packs the safety condition and the ignore-forward detail into the second sentence, and the confirm requirement in the third. It could be slightly more succinct by separating the confirm explanation, but it remains dense and purposeful with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers all necessary call-time info: the default behavior (dry run), the modification trigger (apply), the safety gate (confirm), and the pagination mechanism (pageToken in schema). It also addresses the ignored forward action, which is an edge case. For a tool with 6 parameters, this is exceptionally complete; an agent can call it correctly and safely with just this description and 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 67%, so the description complements it well. It explains the interaction between 'apply' and 'confirm' (confirm required when apply true and filter adds TRASH/SPAM), which goes beyond the schema's individual descriptions. It also mentions 'pageToken' implicitly by noting continuation, and 'maxResults' is described in schema. The description adds the crucial 'confirm' logic that is not fully clear from the schema alone, so it well supplements 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?

The description clearly states the tool applies a filter's labels to existing mail, using specific verbs ('apply', 'reports', 'modifies') and identifies the resource (filter's labels, mail in mailbox). It distinguishes from siblings by mentioning the forward action is ignored and the dry-run default, which is unique among the list. Strong differentiation from gmail_apply_labels and gmail_list_filters.

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 explicit usage context: it explains the dry-run default, the need to set apply to true for actual modification, and the confirm requirement for destructive filters (TRASH/SPAM). It also indicates the dry run is never gated, which guides safe experimentation. No explicit alternative is named, but the context clearly implies when to use this vs other Gmail tools, and the safety gating is effectively a when-not condition.

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?

The description discloses a key behavioral trait: the tool only creates a draft and does not send it. It also mentions that gmail_send_draft is gated on allowedRecipients, which is useful context. However, there are no annotations provided, so the description carries the full burden. It doesn't mention other behaviors like whether the draft is saved to the user's drafts folder or if there are any side effects, but the core non-sending behavior is clearly disclosed.

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 with no wasted words. The primary action is stated first, and the critical distinction from the sibling tool is front-loaded. Every sentence 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 draft-creation tool with no output schema and no annotations, the description is fairly complete. It clearly states the tool's purpose and the key behavioral boundary (no sending). The schema covers the parameters. The only minor gap is that it doesn't describe what the response looks like (e.g., draft ID), but since there is no output schema, that could be a small omission. Overall, it's sufficient for an agent to invoke the tool 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 50%, so the schema already documents several parameters (to, body, account, replyToMessageId, and the attachment variants). The description itself doesn't add parameter-level detail beyond what the schema provides. The description's main contribution is the non-sending behavior, which is not parameter-specific. Baseline 3 is appropriate because the schema covers half the parameters, and the description doesn't need to repeat 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 clearly states the tool's function: 'Create a Gmail draft.' It also explicitly distinguishes it from gmail_send_draft, which is a sibling tool, by noting that this tool does not send. This is a specific verb+resource combination that an agent can easily differentiate from the other Gmail tools.

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 'This tool does not send: use gmail_send_draft, which is gated on the account's allowedRecipients list.' This provides clear when-to-use guidance and names the alternative tool, making it easy for an agent to decide between creating a draft and sending one.

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?

Since no annotations are provided, the description carries the full behavioral burder and performs well: it discloses that filters only affect future mail, and importantly warns that adding TRASH or SPAM installs a 'standing rule that destroys future matching mail after Gmail's 30-day purge' and that confirm is required. This is valuable context.

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 efficient sentences with no filler. Each sentence serves a purpose: creation, scope, and destructive edge cases. The most important caveat about backfill is front-loaded early.

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 14 parameters, low schema coverage, no annotations, and no output schema, the description covers the most critical behavioral and destructive aspects but does not document many parameters or return behavior. While self-explanatory fields like from/to are fine, the omitted param semantics and lack of output information hold it back from being fully complete for a complex tool.

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 schema description coverage at 43%, the description partially compensates by explaining the semantics of addLabelNames, removeLabelNames, and confirm (e.g., at most one user-defined label, TRASH/SPAM requires confirm). Many other parameters such as negatedQuery, sizeComparison, and excludeChats are not explained, leaving gaps.

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 and resource, 'Create a Gmail filter', making the core purpose unmistakable. It also distinguishes itself from gmail_backfill_filter by clarifying that this tool only affects future mail, which helps an agent select correctly among siblings.

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 explicit when-not guidance: 'use gmail_backfill_filter for existing mail.' It also indicates when confirm must be true for destructive TRASH/SPAM labels. However, it does not mention broader alternatives like gmail_list_filters or gmail_apply_labels, but the primary route is clearly 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 transparency burden. It discloses the primary side-effect that a label is created and meaningfully explains that a slash in the name creates nested labels, which is real behavioral context. However, it does not disclose duplicate-label behavior, idempotency, permissions, or what happens to parent labels.

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-loaded with the core action, and contains no filler. The nesting example earns its place because it clarifies a non-obvious usage pattern.

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 is minimally adequate for a create-type tool with 6 parameters and 2 required fields, especially since the schema documents several parameters. It leaves gaps around duplicate label creation, parent label treatment, and expected return values, making it acceptable but not thorough.

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%, and the description adds important meaning to the 'name' parameter by showing that 'Clients/Acme' creates a nested label. It does not, however, compensate for the remaining param detail or clarify the expected palette/visibility parameter behavior 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 description states a specific action and resource: create a Gmail label. It also adds the distinctive nesting behavior via path names, which helps distinguish it from sibling label tools like update, delete, and list labels.

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 guidance on when to use this tool versus alternatives such as gmail_update_label or gmail_create_filter. There are no prerequisites, exclusions, or explicit selection criteria beyond the basic 'create a label' intent.

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 discloses the irreversible nature of deletion and non-recovery, which is the critical behavioral trait. It does not mention side effects like authentication, but that is less relevant for a delete operation.

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 concise sentence that front-loads the action and includes the essential warning about permanence. There is no fluff 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 delete operation with no output schema, the description covers the action, the confirm requirement, and the irreversible consequence. It does not describe failure behavior, but that is a minor gap given the simplicity.

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 67% (two of three parameters have descriptions). The description reinforces the 'confirm: true' requirement, but this is already present in the schema. It adds no significant new meaning beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb 'delete' and resource 'Gmail draft', and adds 'Permanently' to clarify scope. This distinguishes it from sibling draft operations like gmail_send_draft and gmail_update_draft, making the purpose 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?

The description explicitly requires 'confirm: true' and warns that deletion is permanent and unrecoverable, providing clear usage context. It does not mention alternatives, but this is a unique operation with no direct sibling, so the guidance is sufficient.

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 of disclosing side effects. It does this well by explicitly stating that without confirm: true nothing changes and that actual deletion requires confirmation. It also surfaces a non-obvious API limitation about updates. It does not cover every edge case like return values for confirmed deletions, but the critical behavioral facts are present.

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 tightly written sentences deliver the core purpose, the safety-critical guardrail, and the no-update API constraint with no filler. The most important behavior is front-loaded.

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 three-parameter destructive tool with no annotations and no output schema, this description is largely complete: it explains the confirmation requirement and why delete-and-recreate is the update path. A minor gap is the lack of detail about what happens on a confirmed deletion, but the agent has enough to call the tool safely and 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?

The schema already documents account and confirm clearly, and filterId is self-explanatory as a filter identifier. The description reinforces the confirm toggle but adds no new parameter detail, such as where filterId comes from or how to obtain it. With 67% schema coverage, the description is adequate but not additive on 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?

The description opens with the specific action 'Delete a Gmail filter', naming both the verb and resource. It also clarifies the dry-run behavior when confirm is not true, which prevents confusion with sibling listing or creation tools.

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 clearly states that confirm: true is required for an actual deletion and that without it the call only reports the filter. It also explains the Gmail API has no update operation, telling the agent that edits must be done by delete-and-recreate. It stops short of naming the sibling create_filter explicitly, but the guidance is still strong.

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 so thoroughly. It discloses that without confirm:true the call only reports and changes nothing, that deletion is permanent, and that messages are preserved but lose their categorization. These are exactly the critical behavioral traits an agent needs before invoking a mutation.

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: a direct action statement followed by two crucial caveats about the confirm flag and message preservation. Every sentence contributes essential information 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 a simple three-parameter tool with no annotations and no output schema, the description covers purpose, safety, permanence, and side effects well enough for correct invocation. The only meaningful gap is that it does not describe the dry-run report format or successful response, but this is minor for a delete 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?

The description adds real meaning to confirm by explaining the dry-run behavior beyond the schema's simple 'Must be true to actually delete.' However, the primary label parameter has no schema description and the tool description never clarifies whether a label ID, name, or display string is expected, leaving the most important parameter partially under-specified.

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 action and resource: 'Delete a Gmail label.' It adds meaningful boundary conditions by stating that deleting a label does not delete messages and that categorization is lost permanently, which distinguishes it from broader message-deletion tools and from sibling label tools.

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 implies when the tool should be used by explaining the confirm-gated dry run and the permanent loss of label categorization. However, it does not explicitly name alternatives such as gmail_update_label for preserving categorization or otherwise state when not to use this 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 the full burden. It discloses that the tool writes to the account's download directory, returns a path by default, or returns base64 inline with a size cap. It also notes that attachment ids come from gmail_read_message. This is good behavioral disclosure for a fetch tool, though it doesn't mention error cases or what happens if the attachment is too large for base64.

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 carrying distinct information: what it does, the two output modes with their trade-offs, and where attachment ids come from. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description covers the essential behavior: output format, encoding options, size cap, and input provenance. It could mention error handling or the exact download directory path, but those are minor gaps for an agent deciding whether and how to call it.

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 25% (only 'account' has a description). The description compensates by explaining the 'encoding' parameter's two modes and the base64 size cap, and by pointing to gmail_read_message for attachmentId provenance. It doesn't add detail for messageId, but that parameter is self-explanatory given the tool name.

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 ('Fetch'), a specific resource ('one attachment from a Gmail message'), and the two output modes. It clearly distinguishes itself from sibling tools like gmail_read_message (which returns attachment ids) and drive_save_attachment (which handles Drive attachments).

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 explains when to use it: after obtaining attachment ids from gmail_read_message. It also explains the encoding choice (file vs base64) and the 750 KB cap for base64. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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 behavioral burden. "Read" communicates a non-mutating operation, and "output feeds directly back into gmail_update_draft" adds a useful behavioral contract. However, it does not disclose details like output shape, required permissions, or side effects, leaving some burden unmet.

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, front-loaded with the primary operation and followed by a workflow hint. Every word earns its place, and nothing is redundant or bloated.

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 tool with only two required parameters trough no output schema or annotations, the description conveys the essential use case and a downstream integration. It stops short of explaining where draftId comes from or what the returned draft object contains, but the update-draft tie-in compensates reasonably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents account but leaves draftId undescribed, and the description adds no direct parameter semantics. The phrase "one Gmail draft" weakly reinforces that draftId identifies a single draft, and account is already well-described as an alias. This is adequate but not compensatory for the draftId 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?

"Read one Gmail draft" uses a specific verb and resource and clearly indicates this is a single-draft operation, distinguishing it from gmail_list_drafts and gmail_read_message. The statement also signals that it targets drafts specifically. The explicit tie to gmail_update_draft strengthens purpose by showing its role in a workflow.

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 usage context: call this to retrieve a draft so its output can be passed into gmail_update_draft. It does not explicitly state when NOT to use it or mention alternatives like gmail_list_drafts, but the intended workflow is evident.

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 description carries full burden. It only says 'Get' which implies read-only, but does not disclose what the profile contains, whether any special permissions are needed, or the response format. Very minimal disclosure.

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 short sentence with no waste. It is appropriately sized for a simple tool, though it lacks detail; still, conciseness is high.

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?

Incomplete because it does not explain what the profile includes or what the return value looks like, and there is no output schema to compensate. For a simple tool it's acceptable but not thorough.

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 single parameter 'account' is well-documented in the schema with examples (work, personal, support). Since schema coverage is 100%, description does not need to add more. It doesn't, which is fine.

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 'Gmail profile' for an account. It is clear that this retrieves profile information, but it does not explicitly differentiate from sibling tools like gmail_list_accounts, though the intent is distinct. Could be clearer about what 'profile' includes.

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. Does not mention when to retrieve a profile vs listing accounts or other operations. Lacks any context 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?

With no annotations provided, the description must carry the behavioral burden. 'List' clearly implies a read-only operation, and the description explicitly states what information is returned. It does not mention auth preconditions or pagination, but for a simple parameterless list tool this is reasonably transparent.

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 sentence, no filler, with the key message front-loaded. The description fits in the tool name and is immediately understandable.

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, parameterless list tool, the description is practically complete: it states the action, the data returned, and the scoping. There is no output schema, so it reasonably covers the expected return content. Minor omissions like number of aliases or batch behavior are trivial for this use case.

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 tool has zero parameters, so there is no schema semantics for the description to enrich. According to the rubric, the baseline for 0 parameters is 4, and the description adds relevant output semantics, so 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?

The description uses a specific verb ('List') and resource ('configured Gmail account aliases') and even states the returned fields (email address, authorization status). This clearly distinguishes it from sibling tools like gmail_list_labels or gmail_get_profile without needing to consult 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 intended use is implied: it is the tool to call when you need a list of Gmail account aliases and their auth status. However, it does not provide explicit when-to-use or when-not-to-use guidance, and it does not name alternatives like gmail_get_profile for single-account details.

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 adds a real behavioral disclosure: results exclude attachment info because 'format: metadata, which never populates the MIME parts tree.' This explains a non-obvious implementation consequence. The only gap is unspecified pagination behavior, but for a non-destructive list tool this is a strong transparency effort.

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 sentences with zero waste. The first states purpose and ordering; the second delivers the critical caveat and the routing to the sibling tool. Every sentence earns its place and the most decision-relevant information is front-loaded.

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 list tool, the description covers the essential gotcha (no attachments), names the fallback, and the schema covers account and maxResults constraints. The main omission is whether the listing returns all drafts or only the first page up to maxResults. Still, nothing an agent needs to invoke it correctly in the common case is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: the account parameter is well described in the schema, while maxResults has no semantic description. The tool description reinforces account scoping ('on one account') and adds that results are newest first, but it does not clarify maxResults semantics such as pagination or whether the cap represents a full page. With roughly half the parameters undocumented in both schema and description, a 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 + resource + scope: 'List Gmail drafts on one account, newest first.' The one-account scoping and ordering distinguish it from broader search tools and from gmail_get_draft, which the description explicitly contrasts. An agent can pick this tool confidently without inspecting 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?

Explicitly names the alternative and the condition selecting it: 'use gmail_get_draft on a specific draft to see its attachments.' This tells the agent exactly when not to use this tool (needs attachment info) and where to go instead. Nothing is left to inference.

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 of behavioral disclosure. It adds one meaningful behavioral trait — criteria rendered as equivalent search queries — but does not explicitly confirm the operation is read-only/non-destructive, nor disclose error behavior for unknown account aliases or auth requirements. Compared to a no-annotation bare list tool, it is adequate but not rich.

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 concise sentence that front-loads the action ('List Gmail filters') before the distinctive rendering detail. Every word earns its place; there is no filler, redundancy, or repetition of schema content.

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 low-complexity tool with one required parameter and no output schema, the description states the core action and one key output trait (search-query rendering). It does not describe the exact return shape (filter IDs, names, or full objects) or failure modes for invalid accounts, but these gaps are minor for a simple list-style read tool.

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%: the account parameter is already documented as a 'Configured Gmail account alias, e.g. work, personal, support.' The tool description adds no parameter-level detail beyond this, which meets the high-coverage 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?

States a specific verb ('List') and resource ('Gmail filters for an account') in the first clause. The second clause adds a distinctive rendering detail — criteria as equivalent search queries — that separates it from filter-mutation siblings like gmail_create_filter, gmail_delete_filter, and gmail_backfill_filter. Far from a tautology; an agent can tell exactly what this tool does.

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 annotations are provided, so the description carries the full burden of behavioral disclosure. It adds one meaningful behavioral trait — criteria rendered as equivalent search queries — but does not explicitly confirm the operation is read-only/non-destructive, nor disclose error behavior for unknown account aliases or auth requirements. Compared to a bare no-annotation list tool, it is adequate but not rich.

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 only says 'List Gmail labels' with no mention of read-only nature, potential side effects, authentication requirements, or response format. This is a minimal, opaque statement that leaves the agent without critical behavioral context.

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 concise sentence with no extraneous information. It front-loads the core action and resource, making it easy to parse and efficient.

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 one parameter and no output schema, the description is insufficient. It does not indicate what the return value will be (e.g., list of label names, IDs, metadata), nor does it clarify any side effects or permissions. An agent lacks key information needed to confidently call the tool.

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 a detailed description of the 'account' parameter (e.g., work, personal, support). The tool description adds nothing beyond the schema, so it meets the baseline for high schema coverage but does not enhance parameter understanding.

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 a specific verb and resource: 'List Gmail labels for an account.' It distinguishes from sibling tools like gmail_list_accounts and gmail_get_profile by naming the exact resource (labels) and scope (account). No 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?

The description provides no guidance on when to use this tool versus alternatives, such as gmail_get_profile or gmail_list_filters. There is no mention of context, prerequisites, or exclusions. An agent must infer the appropriate usage from the tool name alone.

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 of disclosing behavior. It only says 'Read one Gmail message' and does not describe whether attachments are included, what the response contains, error conditions, or authentication requirements. The read-only nature is implied by the verb but not explicitly stated in a useful way.

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 with no redundancy. It is front-loaded with the core action and resource, making it easy to scan and understand.

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 and no annotations, the description should explain what the tool returns and how to invoke it correctly. It does neither, and the missing messageId semantics plus lack of usage guidance leave a meaningful gap for an agent trying to use this tool reliably.

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 50%: 'account' is described, but 'messageId' has no schema description. The tool description does not compensate by explaining how to obtain a messageId or what format it should take. An agent receives minimal guidance beyond the parameter names.

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 clear action ('Read') and a specific resource ('one Gmail message'), which distinguishes it from the sibling 'gmail_read_thread' by explicitly focusing on a single message rather than a thread. It is unambiguous and directly reflects the tool's function.

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 indication of when to use this tool over alternatives like gmail_search or gmail_read_thread. It does not mention prerequisites, such as needing a message ID from a prior search, nor does it explain what distinguishes this tool from its siblings.

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 full burden of behavioral disclosure. It only says 'Read', implying a read-only operation, but adds no detail about side effects, authentication requirements, or whether the thread's state is altered (e.g., marking as read). This adds no value beyond the tool name and does not clarify potential behaviors.

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, clear sentence with no extraneous words. It is front-loaded and efficient, stating exactly the action and object. There is no waste 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?

The tool is simple, but with no output schema and no description of the return value, the agent cannot know what to expect when calling it. The description also fails to provide any additional context about the thread (e.g., whether it returns all messages or metadata). It is incomplete for successful 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?

The description does not mention any parameters or provide additional context for them. The schema covers 'account' but leaves 'threadId' undocumented, and the description fails to compensate for that gap. Since schema coverage is exactly 50% (not high), the description should add meaning for the undocumented parameter, which it does not.

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 clear verb ('Read') and a specific resource ('one Gmail thread'), which unambiguously distinguishes it from siblings like gmail_read_message (which reads a single message) and gmail_search (which finds threads). The phrasing also implies a single-thread scope, setting it apart from any batch operations.

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 no guidance on when to use this tool versus alternatives such as gmail_read_message or gmail_search. It does not state explicit conditions for choosing this tool or when to prefer a sibling, leaving the agent to infer based solely on 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 of behavioral disclosure. It does disclose a specific limitation (no attachment info) and explains why, which is useful. However, it does not describe the return format or pagination behavior, leaving the agent to infer what the result list looks like. While it covers a key behavior, it is not fully transparent about the operation's output.

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 with no fluff. It front-loads the core purpose and scope, then adds the critical limitation and a pointer to the alternative. Every sentence earns its place, and the structure is easy to scan.

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 search tool with 3 params and no output schema, the description covers the essential points: what it does, the single-account scope, the attachment limitation, and the alternative. The main gap is the lack of return format details, but this is not critical for deciding to call the tool, and the schema covers parameters. Overall, it is reasonably complete for its 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 67% (query and account have descriptions; maxResults only has constraints). The description adds no parameter-specific detail beyond what the schema provides. Since coverage is moderate, the baseline is 3, and the description does not compensate for the missing maxResults description, but the schema constraints give some 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?

The description clearly states the action (search), the resource (Gmail messages), and the scope (on one account). It also distinguishes from gmail_search_many by explicitly limiting to one account, and from gmail_read_message by noting the attachment limitation. This makes the tool's purpose unambiguous and differentiates it from siblings.

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 when-not: results lack attachment info, and directs the agent to use gmail_read_message for attachments. It implicitly distinguishes from gmail_search_many by saying 'one account,' but does not explicitly name that alternative. Overall, it provides actionable guidance for choosing between tools.

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 of behavioral disclosure. It explicitly states a key limitation: results are fetched with format:metadata, which never populates the MIME parts tree, so attachments are not included. It also notes results are grouped by account. This goes beyond a generic 'search' and gives the agent important operational context, though it omits details like rate limits or response fields.

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-loaded with the main purpose. The second sentence delivers a critical behavioral caveat and a direct pointer to the appropriate sibling tool. There is no wasted wording, and the structure is efficient and easy to parse.

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?

Without an output schema and annotations, the description must convey enough for the agent to know what to expect. It tells the agent results are grouped by account and that attachments are excluded, and where to go for attachments. It does not describe the result fields (e.g., message IDs, snippets) but for a multi-account search tool this is acceptable. The guide to gmail_read_message fills a key gap. Overall, it is fairly complete for 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 coverage is 67%: query and accounts have descriptions, but maxResultsPerAccount does not. The tool description adds no parameter-specific meaning beyond the schema, and does not compensate for the undocumented parameter. It does not explain how maxResultsPerAccount affects behavior or results, leaving the agent to rely on the schema's default/min/max. This meets the baseline for partial schema coverage but adds no additional 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 states a specific verb and resource: 'Search Gmail messages across multiple configured accounts.' It distinguishes itself from gmail_search (single-account) by emphasizing the multi-account scope, and from gmail_read_message by noting it does not return attachments. This makes the purpose unambiguous and clearly differentiated from siblings.

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 guidance on when to use this tool versus gmail_read_message: if you need attachment info, use the latter. It implies when to use this tool (when searching multiple accounts) versus single-account search, though it does not explicitly name gmail_search as an alternative for single-account queries. The indication that results are grouped by account clarifies 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?

With no annotations provided, the description carries the full disclosure burden. It explicitly warns 'THIS SENDS REAL MAIL,' which is a critical side effect. It discloses that confirm: true is required for the actual send, that all recipients must be in allowedRecipients, and that without confirm the tool returns what would be sent and changes nothing. This is thorough transparency about side effects and prerequisites.

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 sentences, each carrying essential information: the purpose, the real-mail warning, and the conditions for sending. It is front-loaded with the action and warning, then details the requirements. While not extremely terse, there is no filler and every sentence earns its place. It could be slightly more succinct but is well structured.

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 that sends email, the description covers the critical aspects: real-world side effect, required confirmation, recipient allowlisting, and dry-run behavior. It doesn't describe the return value or error cases, but given the complexity (and no annotations), it provides enough context for an agent to call it correctly. The lack of output schema is offset by the clear behavioral notes.

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% (only 'account' has a description), so the description must compensate. It explains the behavior of 'confirm' clearly (true triggers send, false is a dry run) and implies that 'draftId' refers to an existing draft. It does not add format details for draftId, but the tool name and description context make it predictable. The description adds meaningful semantics beyond the bare schema, though not exhaustive.

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 'Send an existing Gmail draft,' which is a clear verb+resource combination. It explicitly states the action (send) and the object (existing draft), and distinguishes it from sibling draft tools (create, list, get, update, delete) by emphasizing 'existing' and 'real mail.' The warning about sending real Mail further clarifies the tool's unique role among the draft operations.

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 concrete usage conditions: it requires confirm: true to actually send, and explains the allowedRecipients prerequisite for the account. It also explains the dry-run behavior without confirm. However, it does not explicitly state when to avoid using this tool in favor of a sibling (e.g., 'use update_draft to edit before sending'), so it falls short of a direct comparison, but the context is clear enough.

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 clearly warns that ANY ATTACHMENT NOT RE-SPECIFIED IS DROPPED, which is a critical side-effect. It also explains how to retain attachments via messageId/attachmentId. This is exemplary transparency for a mutating operation.

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 with no filler. It leads with the core purpose, then immediately states the critical caveat about attachments, and finishes with a concrete workaround. Every sentence earns its place, and the structure is ideal for quick agent 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?

For a mutation tool with 8 parameters, no annotations, and no output schema, the description covers the essential behavioral hazard (attachment loss) and provides a practical usage pattern. It does not describe the return value or mention prerequisites like the draft existing, but given the clarity of the operation and the schema's parameter descriptions, it is reasonably complete. A short note on the response would push it to 5.

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 low (38%), so the description must compensate. It adds significant meaning to the attachments parameter by explaining both the file-path variant and the re-attach variant, and it clarifies that messageId comes from gmail_get_draft. It does not elaborate on other parameters, but the schema already provides descriptions for to, body, and account, and the description's guidance on attachments covers the most complex 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 ('Replace') and a clear resource ('the contents of a Gmail draft'). It distinguishes itself from siblings like gmail_create_draft, gmail_get_draft, and gmail_delete_draft by emphasizing it is a full replacement, not a partial update. An agent can immediately understand what this tool does without 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?

The description explicitly notes that Gmail has no partial draft update, implying this tool should be used only when a full replacement is intended. It also provides a concrete usage pattern for preserving attachments by referencing gmail_get_draft. It does not explicitly contrast with alternatives like gmail_create_draft, but the context is clear enough for most cases.

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 does reveal a non-obvious behavior: renaming a parent label does not rename children unless renameDescendants is true. However, as a mutation tool it omits other relevant traits such as mutation permanence, permissions, or what the API returns on success.

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 with no filler. It front-loads the core purpose, then adds one important behavioral nuance; every sentence 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 an 8-parameter mutation with no annotations and no output schema, the description is only partially complete. It covers the core rename behavior and the hierarchy wrinkle, but relies on the schema for several parameters and gives no usage guidance or post-condition information.

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%, so the description partially compensates by clarifying the renameDescendants behavior and framing the label mutation as 'rename and/or restyle.' But newName, labelListVisibility, and messageListVisibility remain schema-only, and the description does not explain their meaning or usage beyond the bare schema entries.

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 'Rename and/or restyle a Gmail label,' giving a clear verb and resource. It is distinct enough from sibling operations like creating, deleting, or applying labels, though it does not explicitly name those alternatives.

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 explicit 'when to use' or alternative tool is mentioned, but the hierarchy note implies this tool is the correct one for renaming existing labels, especially parent labels. The guidance about renameDescendants gives a conditional usage clue but not a full decision framework.

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 discloses that the tool is read-only ('an .ics feed cannot be written to'), explains that recurring rules are expanded into individual occurrences and overrides are applied, and adds a security note about not fetching arbitrary hosts. These are meaningful behavioral details beyond the basic action.

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 sentences long, with no filler. It front-loads the core purpose, then adds behavioral and security context. Every sentence contributes new 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?

The description covers the tool's core behavior, security constraints, and expansion logic. However, it does not describe the return format or any pagination details, and since there is no output schema, an agent might wonder about the exact structure of the returned events. Given the read-only nature and clear parameters, this is a minor gap.

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 adds extra semantic value by explicitly stating that the feed parameter must be an alias from accounts.json and never a URL, which is a security constraint not fully expressed in the schema. Other parameters are adequately covered by the schema itself.

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 and resource: 'Read events from one subscribed iCal feed within a time range.' It clearly distinguishes this tool from sibling calendar tools by focusing on iCal feeds and explicitly notes it does not accept URLs, which differentiates it from potential alternative fetch tools.

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 context about what it does (reads events from a specific iCal feed) and states a security constraint (never accepts a URL), but it does not explicitly mention when to use this tool over alternatives like ical_list_feeds or calendar_list_events. No exclusions or alternative routing are provided.

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 and uses it well: it explicitly states that feeds are read-only and explains why (.ics is an HTTP-served file with no write protocol). This reassures the agent that the tool never mutates anything, adding meaningful behavioral context beyond the name.

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: the first delivers the core purpose, the second adds the key behavioral constraint. No filler, no redundancy, and the most important information is front-loaded.

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 zero-parameter, read-only list tool, the description is nearly complete: it states the resource, its source, and its read-only nature. It omits an explicit statement of the return format, but the absence of an output schema and the trivial complexity make this a minor gap rather than a critical one.

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 tool has zero parameters and an empty input schema, so the description has no parameter burden to carry. Baseline for 0 params is 4; the description appropriately adds no irrelevant parameter detail.

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 clear verb ('List') and resource ('subscribed iCal feeds') with a precise source location ('accounts.json under "calendarFeeds"'). This unambiguously distinguishes the tool from siblings like ical_list_events (events vs feeds) and calendar_list_calendars (Google Calendars vs iCal subscriptions).

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 implies when to use the tool—when you need to see subscribed iCal feeds—but does not explicitly name alternatives or state when not to use it. The read-only note hints that this tool is for inspection only, but no exclusion or routing guidance is provided for the closely related ical_list_events or calendar_list_calendars.

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