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

The description reveals that the tool initiates an OAuth flow and opens a browser for user sign-in, which is important behavioral context. However, it does not disclose post-conditions (e.g., the account being saved and available for other tools), potential blocking behavior, or any permission requirements. With no annotations, the description carries the burden but only partially fulfills it.

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 long and front-loaded with the primary action. Every word adds value, with no irrelevant details.

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 interactive OAuth tool, the description conveys the essential workflow and the browser opening. However, given the absence of an output schema and annotations, a bit more detail about the result (e.g., what happens after sign-in) would make it fully complete. Still, it covers the core behavior sufficiently for a user to select and invoke 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?

The input schema covers both parameters (name and openBrowser) with clear descriptions, so the global description need not repeat them. The description offers no additional semantic detail beyond what the schema already provides, resulting in a baseline score.

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

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

The description clearly states the tool's function with a specific verb ('Start the OAuth consent flow') and a distinct resource ('connect a new Google account'). This distinguishes it from sibling account management tools like google_account_list/remove/status, which operate on existing accounts.

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 used for adding a new Google account, but it does not explicitly mention when to choose this over alternatives (e.g., listing or removing accounts). No exclusions or alternative tool references are provided, leaving use cases to be inferred from the name and sibling context.

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

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

With no annotations, the description carries the full burden. It discloses the output fields (email, default status) and implies a read-only operation through 'List all.' However, it does not explicitly state that it is safe and non-destructive, nor does it mention any authentication prerequisites or response format beyond the fields listed. This is adequate for a simple read tool but lacks depth.

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 ('List all connected accounts') and adds essential detail ('with their email and default status'). Every word earns its place, 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?

For a simple list tool with no parameters, no output schema, and no annotations, the description is fairly complete. It states what is returned (email and default status), implying a collection result. It doesn't mention the exact return format or any edge cases, but given the low complexity, this is sufficient. A slight gap is the lack of explicit statement that it lists all accounts across all connections, though 'all connected accounts' conveys that.

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

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

The tool has zero parameters, and the schema coverage is 100% (effectively no parameters). According to the baseline for 0 params, a score of 4 is appropriate. The description does not need to elaborate on parameters since there are none, and the absence of any parameter mention is acceptable.

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: 'List all connected accounts with their email and default status.' It identifies the resource (connected accounts) and the specific action (list all). It differentiates from siblings like google_account_add/remove/set_default by indicating a read operation, but does not explicitly contrast with google_account_status, so it doesn't fully distinguish itself.

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

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

There is no guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning that it should be used when you need an overview of all accounts, or that google_account_status might be used for a single account. No exclusions or alternative tool references 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?

The description discloses one important side effect—deleting stored tokens—but does not clarify whether the removal is permanent or reversible, what happens to connected services, or any authorization requirements. With no annotations to buffer, the description carries the full burden of behavioral disclosure, and this is insufficient 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?

The description is a single sentence that gets straight to the point. It is concise, front-loaded, and contains no unnecessary words.

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 tool with one parameter and no output schema, the description covers the basic action but lacks important contextual details such as reversibility, impact on the default account, and whether the account is removed from all Google services. It is minimally adequate but leaves notable gaps for a destructive operation.

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

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

The schema fully describes the only parameter 'name' as 'Account nickname to remove,' and the tool description adds no further meaning. Schema coverage is 100%, so the 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 action: 'Disconnect an account and delete its stored tokens.' This specifies the verb and resource, and distinguishes the tool from siblings like google_account_add, google_account_status, and google_account_set_default. It unambiguously communicates 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 provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention that this is a destructive action requiring caution, or what happens if the account is the default one. Without this context, the agent may misuse the 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 of disclosing behavior. It only restates the title in slightly different words and does not mention side effects, persistence, authentication requirements, or error handling for invalid names.

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 wasted words. It is front-loaded and efficient, though it could have included useful context without becoming verbose.

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

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

For a one-parameter setter with no output schema, the description is thin. It does not mention that the account must already be added via google_account_add, whether the setting persists, or how it interacts with google_account_status. This leaves the agent under-informed for a complete 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 input schema fully documents the single parameter 'name' with the description 'Account nickname to use as default,' giving 100% schema coverage. The tool description adds no additional semantic value beyond what the schema already provides, so it remains at the baseline of 3.

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

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

The description uses the specific verb 'Set' and clearly identifies the resource as 'which account is used when no account is specified.' This distinguishes it from sibling account management tools like google_account_add, google_account_list, google_account_remove, and google_account_status.

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 establishing a default account when no account is specified, but it does not explicitly state when to use this versus sibling tools or mention any prerequisites (e.g., account must already exist). No alternatives or exclusions are noted.

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 disclose behavioral traits. It says 'Show', implying a read-only operation, and lists the information categories, which gives some transparency. However, it does not mention potential side effects (e.g., token refresh) or failure conditions, nor the exact format of the output. For a status tool, this is adequate but not fully 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?

The description is a single, front-loaded sentence that directly states the action and key objects. It is appropriately concise, with no filler words or repetitive details, making it efficient for an agent to parse and act upon.

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: no parameters, no output schema, and no nested objects. The description adequately covers the scope by enumerating the four content areas (credential config, data directory, connected accounts, token health). While it does not detail return structure, the lack of complexity makes this listing sufficient for the agent to understand the tool's purpose and 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?

The tool has zero parameters and the schema is empty, so there is no parameter semantic burden. Per the rubric, the baseline for 0 params is 4; the description adds no confusion and correctly implies no inputs are needed. The schema coverage is effectively 100%, so the description is not required 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 begins with the action 'Show' and specifies four concrete subjects: 'credential configuration, data directory, connected accounts and token health'. This clearly identifies the tool's function and differentiates it from sibling tools like google_account_list (which only lists accounts) by focusing on broader status/health information.

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 guidance is given about when to use this tool compared to alternatives such as google_account_list (account listing only) or google_account_add/remove (account management). The description states what it does but not when it should be preferred over sibling tools, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full disclosure burden but only mentions the all-day date format (already present in the schema). It fails to disclose that this is a mutating operation, whether it creates in the primary calendar by default, or any permission requirements.

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

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

The description consists of two short sentences with zero unnecessary words. It front-loads the core purpose and adds a single key operational detail, making it extremely concise and 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?

Given 8 parameters, no annotations, and no output schema, the description is too sparse. It does not mention default calendar behavior, how account selection works, optional fields, or any side effects. It leaves the agent with significant gaps for correct invocation.

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

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

Schema description coverage is high (75%), so baseline is 3. The description adds minimal value beyond schema, restating the all-day date format that already exists in start/end descriptions. It does not help with undocumented parameters like location or description, but the schema still reveals their 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 clearly states the tool creates a calendar event, specifying it can be timed or all-day. This distinguishes it from sibling tools like google_calendar_create_meet (which creates Meet events) and other calendar event operations (list, get, update, 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?

No explicit guidance is given on when to use this tool versus alternatives like google_calendar_create_meet or when to use date-only vs datetime formats. The only hint is the all-day date format note, which is more about parameter usage than selection criteria.

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 the core effect (creating an event and attaching Meet link) but omits potential side effects such as sending invitations, requiring auth, or overwriting existing data. 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?

Single sentence with no unnecessary words. The key point (Meet link attachment) is front-loaded and the structure is perfectly concise.

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 create tool with well-documented parameters, the description is sufficient to invoke it correctly. It lacks return value information but that is non-critical for a create operation. The sibling distinction is implicit via the Meet link mention.

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 high at 86%, so most parameters are already described. The description adds no additional meaning beyond the schema; it does not clarify formats, defaults, or relationships between 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?

Description clearly states it creates a calendar event with an attached Google Meet link, using a specific verb and resource. This distinguishes it from the sibling google_calendar_create_event, which presumably creates an event without a Meet link.

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

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

No guidance is provided on when to use this tool versus google_calendar_create_event, nor any prerequisites like an existing account or calendar. The context is implicit from the name/description but no explicit alternatives or exclusions are given.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Delete an event by ID.' It does not disclose that deletion is permanent, whether special permissions are needed, or any side effects on attendees or recurring events. This is a significant gap 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?

The description is a single sentence that is appropriately sized and front-loaded. Every word earns its place, and there is no redundancy or filler. It is as concise as possible while conveying the core purpose.

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 tool with 3 parameters and no output schema, the description is too minimal. It omits critical context such as the permanence of deletion, the optional calendarId behavior, and potential side effects. Given that this is a destructive operation and annotations are absent, the description should provide more guidance.

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 for all three parameters with descriptions, so the baseline is 3. The tool description itself adds no parameter semantics beyond what the schema already includes, but it does not need to since the schema is self-sufficient.

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') and the resource ('event by ID'), using a specific verb and resource that distinguishes it from sibling tools like google_calendar_update_event or google_calendar_get_event. This is unambiguous and matches the tool name exactly.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description merely states the action without context on selecting a calendar or event validity, leaving the agent to infer 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states a read operation but does not mention what happens if the event is not found, permission requirements, or any response details. This is a minimal disclosure similar to low-scoring examples.

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 zero unnecessary words. It is fully front-loaded and 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 get-by-ID tool with a fully described schema, the description is adequate. It could mention the return format or error behavior, especially given there is no output schema, but the core functionality is clear and the tool's simplicity reduces the need for additional 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?

Schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond identifying eventId as the key, and does not elaborate on account or calendarId 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 clearly states the tool fetches a single event by ID, using a specific verb and resource. It distinguishes itself from sibling tools like list_events (multiple events) and create/update/delete 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 intended usage is implied by the phrase 'by ID' – you need the specific event ID to fetch one event. However, there is no explicit guidance on when to choose this over list_events or any alternates, so it stops short of clear usage instructions.

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 operation is read-only and scoped to accessible calendars, but it does not mention return format, pagination, or other behavioral traits. Given the minimal complexity, this is acceptable 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?

The description is a single sentence with no redundant words. It is front-loaded with the verb and resource, making it highly concise and 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 list tool with one optional parameter and no output schema, the description is sufficient. It clarifies the scope (accessible calendars) and implies a return of calendar objects. However, it lacks explicit details about the response structure, which would be helpful but not essential for this basic 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 schema description covers the only parameter 'account' with 'Account nickname to use', giving 100% coverage. The description adds no extra meaning beyond the schema, so the 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?

The description uses the specific verb 'List' with the resource 'calendars', making it clear what the tool does. It also distinguishes from siblings like google_calendar_list_events by explicitly stating it lists calendars, not events.

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

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

The description provides clear context by noting 'the account can access', implying it lists calendars available to the authenticated account. It does not explicitly mention alternatives or when not to use it, but for a simple list tool the usage is 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 provided, the description carries the full burden of behavioral disclosure. It only states that events are listed and optionally filtered, but fails to mention default behaviors (timeMin=now, maxResults=25, calendarId=primary), result ordering, pagination, return format, or the read-only nature of the 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 immediately states the action and key filtering options. It avoids redundancy and is well front-loaded, though 'upcoming' could be clarified.

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 has six parameters, no output schema, and no annotations, the one-line description is incomplete. It does not explain what data is returned, how results are ordered, default values, or limitations. A more thorough description is needed for an agent to confidently invoke this 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%, so all six parameters already have meaningful descriptions in the schema. The description adds only a high-level mention of time range and query filters, which does not exceed the schema's own 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 uses a specific verb ('list') and resource ('events in a calendar'), and mentions optional time range and query filters. This distinguishes it from sibling tools like get_event which retrieves a single event, though 'upcoming' is slightly imprecise since past events can be listed with a custom time range.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_event for single events or list_calendars for calendars. The description only implies its use case without specifying exclusions, prerequisites, or alternative scenarios.

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 full burden for behavioral disclosure. It only states 'partial update' which hints that unspecified fields remain unchanged, but it does not disclose that this is a destructive/irreversible write, mention permissions, or explain error behavior. For a mutation tool, this is a significant gap.

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

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

The description is a single, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's purpose and behavior, making it very 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?

With 9 parameters and no output schema, the description is too minimal. It does not explain the return value, the default for calendarId, how account affects behavior, or how fields interact (e.g., start/end validation). The one-liner is insufficient for a tool of this 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%, leaving summary, location, and description undocumented. The description adds the important semantic that the update is partial, meaning only provided fields are modified. However, it does not compensate for the three parameters with missing schema descriptions, so the 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 'Update fields of an existing event (partial update)' uses a specific verb and resource, clearly indicating it modifies an already-created event. It also distinguishes itself from sibling tools like create_event, get_event, and delete_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 phrase 'existing event' and 'partial update' provides clear context that this tool is for modifying, not creating or deleting. It implies the when-to-use case, though it does not explicitly name alternatives or list exclusions. This absence of explicit exclusions keeps it at a 4 rather than a 5.

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 full responsibility for behavioral disclosure. It only states the creation action and does not reveal side effects, return behavior, account handling (e.g., default account use), or permission needs, which are important 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?

The description is a single, front-loaded sentence that states the action and key optional fields with no noise. Every word adds value, achieving high conciseness without fluff.

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

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

The tool is a simple creation operation, but with no output schema and no annotations, the description needed to clarify what happens after creation (e.g., return value) and how account selection works. The current text is too minimal, leaving the agent without guidance on account usage or possible side effects.

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% (name and account have descriptions; email and phone do not). The description adds that email and phone are optional contact fields, helping clarify two undocumented parameters, but it omits the account parameter entirely and does not add format details. This partially compensates for the schema 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 explicitly states 'Create a new contact' with a specific verb and resource, and differentiates from sibling tools like google_contacts_list and google_contacts_search by focusing on creation. It further specifies the core fields (name and optional email/phone), making the intent unmistakable.

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, nor does it mention prerequisites like account selection or any conditions under which to prefer another tool. It simply states the action without contextual direction.

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 for behavioral disclosure. It does not state that this is a read-only operation, any authentication requirements, rate limits, or pagination behavior beyond the schema. It only lists the output fields, which is minimal for full transparency.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose and return fields.

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

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

For a simple list tool with no output schema, the description adequately explains the return values (names, emails, phones). However, it omits details about default page size or that it lists all contacts unless limited, though these are covered in the schema. Overall, sufficient 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 100%, with descriptions for both 'account' and 'pageSize'. The description adds no additional meaning to the parameters, though it reaffirms that contacts belong to the account. Baseline 3 is appropriate as the schema already defines each 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 clearly states the action (List), resource (contacts), and scope (the account's contacts). It also specifies the returned fields (names, emails, phones), making it distinct from siblings like google_contacts_search and google_contacts_create.

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

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

No guidance is provided on when to use this tool vs alternatives such as google_contacts_search. The description does not mention exclusions, prerequisites, or specific scenarios, leaving the choice to the agent without 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds a meaningful trait ('including non-connected') but does not explain return format, pagination, or sorting behavior. This is minimal but acceptable for a simple read tool.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to the tool's purpose and behavior.

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

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

This is a simple 2-parameter read tool with no output schema. The description covers the core purpose, searchable fields, and the non-connected scope. With full schema coverage and low complexity, the description is adequately complete even though it doesn't discuss return format.

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%, providing descriptions for both 'query' and 'account'. The description adds crucial meaning to 'query' by specifying it matches name, email, or phone, going beyond the schema's generic 'Search text.'

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

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

The description clearly states the verb 'Search' with the resource 'contacts' and adds specific scope ('including non-connected') and searchable fields ('by name, email or phone'). This distinguishes it from sibling tools like google_contacts_list and google_contacts_create.

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

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

The description provides clear context: use this tool when you need to find a contact by name, email, or phone, including non-connected contacts. It doesn't explicitly name alternatives or exclusions, but the search verb and field list imply when it's appropriate versus listing all contacts.

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 bears the full burden of disclosing side effects and behavior. It only says 'Send raw... requests' without explaining required permissions, error handling, atomicity, or what happens on failure. This is a mutation tool with no 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, front-loaded sentence with no filler. It communicates the essence of the tool efficiently, using parentheses for examples.

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

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

This is a complex tool taking arbitrary batchUpdate request arrays, yet the description provides no guidance on request construction, response format, or typical use cases. With no output schema and no annotations, the description leaves too much unspecified for an agent to use it confidently.

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

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

Schema description coverage is 100%, so the description does not need to document parameters. The examples (styles, tables, headers) add a little context about the kinds of requests allowed, but the description does not materially enhance the schema's parameter descriptions.

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 exactly what the tool does: 'Send raw Docs batchUpdate requests' with examples (styles, tables, headers). This clearly distinguishes it from sibling tools like google_docs_insert_text or google_docs_replace_text, which are higher-level 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 no explicit guidance on when to use this tool versus alternatives. The word 'raw' hints at advanced use, but there is no mention of when-not-to-use or references to simpler docs tools. Sibling names exist but are not called out.

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

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

No annotations are provided, so the description carries the full burden. It only states the creation action without disclosing what is returned (e.g., document ID), whether the document is empty, or any account-related behavior. For a mutation tool, this is insufficient.

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 sentence of nine words, front-loaded with the action and resource. It contains no fluff or redundant 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?

With no output schema and no annotations, the description should explain return values and any side effects, but it does not. It also lacks context about how this tool differs from other document creation/edit tools, leaving the description minimally viable but incomplete.

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% for both 'title' and 'account', so the schema already documents the parameters. The description merely echoes 'title' and adds no extra meaning beyond the schema, so a baseline score 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 action ('Create') and the resource ('a new Google Docs document'), distinguishing it from sibling tools like google_docs_get or google_docs_insert_text which operate on existing documents. It is specific 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?

The description provides no guidance on when to use this tool versus alternatives such as google_docs_batch_update or google_docs_insert_text. There is no mention of use cases, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states that it retrieves the full document, but does not mention whether the operation is read-only, potential performance implications, authentication requirements, or any side effects. The return type hint 'structural JSON' is a small credit, but overall it's insufficient.

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 conveys the core purpose without any redundant words. It is appropriately sized and front-loaded with the action.

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 get operation with no output schema, the description gives a basic understanding of the return format but lacks usage guidance and behavioral details. It is minimally sufficient but leaves gaps that could confuse an agent choosing between similar document tools.

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% for the two parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, such as details about the account parameter or documentId format.

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 retrieves the full Google Docs document in structural JSON format. This is a specific verb and resource, and the mention of 'structural JSON' distinguishes it from sibling tools like google_docs_read, which likely returns plain text or a different representation.

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 google_docs_read or google_docs_get. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction on tool selection.

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

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

No annotations are provided, so the description carries full burden. It discloses the core insertion behavior and location options but lacks depth on side effects, permissions, error handling, or formatting. This is adequate but minimal.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the essential action and behavior.

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 insert operation with complete schema, the description is mostly self-sufficient. However, it omits guidance on edge cases or return behavior, though no output schema exists. It is nearly complete for the task.

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 descriptions cover all four parameters (100% coverage). The description only mirrors the index parameter's default behavior ('or at the end') and adds no new meaning beyond the schema.

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

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

The description clearly states the action (insert), resource (document), and location behavior (at an index or at the end). It distinguishes from siblings like google_docs_replace_text, which replaces rather than inserts.

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 usage for inserting text but does not explicitly mention when to use this tool over alternatives such as replace_text or batch_update. No when-not-to-use or alternative guidance 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?

The description clearly indicates a read operation returning plain text, which conveys the primary behavior. However, with no annotations, it does not disclose any potential limitation, permission requirements, or error behavior, leaving the agent to infer these.

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, direct sentence: 'Read a Google Docs document as plain text.' It is concise, front-loaded, and contains no unnecessary 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 low-complexity tool with minimal schema and no output schema, the description adequately conveys the action and output format. However, it lacks explicit differentiation from sibling tools like google_docs_get, which 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 description coverage is 100% for both parameters (account, documentId) with clear descriptions. The tool description does not add meaning beyond what the schema provides, so 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 uses a specific verb ('read') and resource ('Google Docs document'), and specifies output format ('plain text'). It is clear, though it does not explicitly distinguish this tool from sibling tools like google_docs_get, which may serve a different but related 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?

No guidance is given about when to use this tool versus alternatives. There is no mention of scenarios where google_docs_get would be preferred, or any exclusions 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose that the operation replaces 'all occurrences' and notes template filling, which implies a write operation. However, it does not mention that the change is permanent or require specific permissions, leaving some behavioral aspects undisclosed 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?

The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core purpose and a key use case.

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 has five parameters and no output schema or annotations. The description covers the core action and template use case, but for a tool that modifies documents, it would benefit from additional context about irreversibility or permissions. It is adequate but not rich enough for full completeness.

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 descriptions cover 100% of the parameters, so the baseline is 3. The description adds the 'template filling' context, which helps interpret the find/replace parameters, but does not add specific details beyond the schema, such as the meaning of matchCase or the account 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 clearly states the action ('replace all occurrences') and resource ('if a string in a document'), and highlights the template filling use case, which distinguishes it from sibling tools like google_docs_insert_text and google_slides_replace_text. The verb+resource+scope is specific 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?

The description implies usage for template filling, providing some context for when to use the tool. However, it does not explicitly state when to use this versus alternatives like google_docs_batch_update or google_docs_insert_text, nor does it mention any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It discloses the critical permanence of deletion, which is valuable, but omits other behavioral context like permission requirements or return value. It adds some transparency but is minimal.

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 is front-loaded with the action and resource. Every word earns its place; there is zero 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 tool, the description covers the core purpose and irreversibility, but with no output schema and no annotations, there are gaps around return behavior and permissions. It is adequate but not complete.

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

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

Schema coverage is 100% for both parameters, so the schema already documents fileId and account. The description adds nothing beyond that, hence the baseline score of 3.

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

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

The description clearly states 'Permanently delete a file from Drive' with a specific verb and resource. It distinguishes itself from sibling tools like google_drive_list, google_drive_get, and google_drive_update.

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

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

No guidance is given on when to use this tool versus alternatives, prerequisites, or exclusions. Usage is implied by the name but not explicitly stated.

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

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

With no annotations, the description carries the full burden. It discloses that the operation is read-only and limited to metadata (not file content), which is a useful behavioral trait. However, it does not mention authentication, error handling, or account selection, leaving some gaps.

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

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

The description is a single, front-loaded sentence that states the purpose directly with no unnecessary words. It is appropriately concise for the tool's simplicity.

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 the schema's full parameter coverage, the description is complete. It specifies the action (get metadata), the target (single file), and the required identifier (ID), which adequately defines the tool's behavior without needing an output 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?

The input schema already provides full descriptions for both parameters (fileId and account) with 100% coverage. The description adds little beyond implying that fileId identifies the target file, so it does not significantly enhance the schema's semantics.

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

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

The description clearly states the action ('Get metadata'), the resource ('single file'), and the scope ('by ID'). This distinguishes it from sibling tools like google_drive_list or google_drive_update, 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 provides a clear usage context: the tool should be used when you have a specific file ID and need metadata. It does not explicitly name alternatives, but the 'by ID' condition effectively signals when to use this tool versus listing or updating files.

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 adds useful details like 'newest first' and 'optional query,' but it does not disclose return format, scope (e.g., all files vs. folders), or authentication requirements. This is a minimal but not misleading 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?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key behavior. There is no redundant information or wasted words.

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 with 3 parameters all described in the schema, but the lack of output schema and annotations means the description should clarify return values and scope. It does not mention what is returned or any limitations, making it adequate but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it merely says 'optional query,' which is already indicated by the schema. However, it also mentions 'newest first,' which relates to sorting behavior but not directly to 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 'List files in Drive, newest first, with an optional query' clearly states the action (list), the resource (Drive files), and key modifiers (newest first, optional query). This distinguishes it from sibling tools like google_drive_get (single file), google_drive_upload, and google_drive_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 implies usage for listing Drive files, but it does not explicitly state when to use this tool versus alternatives such as google_drive_get or other list tools. There is no mention of exclusions or differentiators beyond the basic purpose, so guidance is only implied.

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 fully disclose behavior. It only says 'Share a file', but does not mention that this modifies existing sharing permissions, that it may overwrite prior roles, that it sends a notification by default, or that the account parameter selects which Google account to use. This lack of behavioral detail leaves significant gaps for a mutation tool.

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

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

A single, front-loaded sentence exactly states the core purpose with zero filler. Every word earns its place, and the description is sufficiently concise for the tool's simplicity.

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 rich schema coverage, the description fails to provide essential context for practical use, such as whether existing permissions are replaced, whether the account parameter is required for multi-account scenarios, or how notifications behave. For a tool with no output schema and no annotations, this under-specification leaves the agent with incomplete guidance for invocation.

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

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

Schema description coverage is 100%, so all five parameters have descriptions in the schema. The tool description adds no extra meaning beyond 'by email and role', which aligns with the schema. Thus, the 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 action (share), the resource (a file), and the intended recipient (by email and role). This uniquely distinguishes it from other Drive tools like google_drive_update (which modifies file metadata) or google_drive_delete, making the purpose immediately evident.

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 granting access to a specific user via email and role, which provides clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the brevity and clarity make the intended use obvious within the suite of Drive 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?

No annotations exist, so the description must disclose side effects. It mentions 'replace its content' which implies destructive overwriting, but does not confirm whether the entire file is replaced, whether partial updates are possible, or what happens if only name is provided. No mention of permissions or reversibility.

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

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

The description is a single concise sentence that gets directly to the point. It wastes no words, but its brevity leaves out important context addressed in other dimensions.

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

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

For a mutation tool with no annotations, output schema, or additional behavioral details, this description is insufficient. It does not specify return values, error conditions, whether content is overwritten, or the role of the account parameter. Despite the schema covering 80% of parameters, the tool's overall context is not fully described.

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 provides descriptions for 4 of 5 parameters (80% coverage), so the description doesn't need to elaborate much. The description clarifies that 'name' relates to renaming and 'content' to replacing content, adding some meaning, but it does not clarify the 'account' or 'mimeType' roles, especially since mimeType lacks a schema description.

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: renaming a file and/or replacing its content. This is a specific verb+resource combination that distinguishes it from sibling tools like upload, delete, and share, though it does not explicitly contrast them.

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

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

No guidance is provided on when to use this tool versus alternatives. It omits prerequisites, exclusions, or context such as whether it can be used for files not owned by the user or when to prefer upload over update.

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

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

With no annotations, the description carries the full burden. It mentions content optionality and 'blank Google-native file if omitted', but this is ambiguous and potentially misleading depending on mimeType. It doesn't disclose other behaviors like file permissions, account handling, or confirmation of creation.

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 sentence that front-loads the purpose and encapsulates a key behavioral nuance. There is no wasted wording or unnecessary detail.

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

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

Given no annotations, no output schema, and 5 parameters, the description is adequate but has gaps. It covers purpose and content behavior, but omits return values, parent folder/account context, and usage scenarios. Schema provides param details, but the description doesn't fully compensate for missing annotations.

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 value by clarifying the content parameter's optionality and default behavior ('blank Google-native file'). This goes beyond the schema's 'Text content to upload'.

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 creates a file in Drive, with a specific verb and resource. It distinguishes from sibling tools like google_drive_update, delete, or list. The optional content behavior adds specific scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions or alternatives, e.g., using google_drive_update for modifying existing files. It simply states what it does without contextual usage.

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

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

No annotations are provided, so the description must carry the behavioral burden. It only states 'Add a question,' without disclosing that the question is appended to an existing form, whether multiple_choice requires options, how required/defaults are handled, or any side effects. This is a significant transparency gap 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?

The description is a single, front-loaded sentence that clearly states the action and subject without any redundant words. It is an ideal model of conciseness.

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?

Although the parameter schema is rich, there are no annotations and no output schema, and the description does not mention return values, prerequisites (like needing an existing form), or behavioral details. For a tool with 7 parameters and mutation semantics, this is incomplete.

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 fully documents all 7 parameters. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score 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 uses a specific verb ('Add') and resource ('question'), and further specifies 'text or multiple-choice' and 'to a form.' This clearly distinguishes it from sibling tools like google_forms_create (form creation) and google_forms_get/responses (read 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 implies usage for adding a question to an existing form, but it provides no explicit guidance on when to prefer this tool over alternatives like google_forms_create, nor does it mention exclusions. The context is clear enough for a basic action but lacks explicit when-to-use/not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the creation action, omitting details such as authentication requirements, the role of the optional 'account' parameter, return value behavior, or any side effects. This is minimal disclosure beyond the action itself.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the core purpose using a clear verb and object, making it 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?

The tool is simple with only two parameters and full schema coverage, but there is no output schema or annotations. The description does not explain what the tool returns (e.g., form ID or URL), how the optional account parameter is used, or what steps follow creation. It is adequate for a minimal create action but leaves gaps for a fully informed 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 schema already provides descriptions for both parameters ('title' and 'account'), giving 100% coverage. The description adds nothing beyond restating 'title', so it meets the baseline for schema coverage but provides no additional semantic value.

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

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

The description clearly states the action ('Create') and the resource ('a new Google Form'), and specifies the required input (a title). It distinguishes itself from sibling tools like google_forms_add_question and google_forms_get, which serve different purposes.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description does not reference sibling tools or clarify that this should be used before adding questions or retrieving forms.

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. 'Get' implies a read-only operation, but the description does not explicitly state that no modifications occur, nor does it mention any requirements like authentication (e.g., via the 'account' parameter) or error behavior. For a tool with no annotation safety hints, this is a significant gap.

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

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

The description is a single, front-loaded sentence that is succinct and contains no filler. Every word contributes to the purpose. It is an exemplar of conciseness.

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 GET tool with two documented parameters, the description conveys the core purpose. However, with no annotations or output schema, the description is the only source of behavioral context. It does not explicitly mention read-only safety, which is important for an agent deciding whether to invoke the tool. It is minimally adequate but leaves some gaps.

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

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

The schema covers 100% of parameters with meaningful descriptions ('Form ID (from the URL)' and 'Account nickname to use'). The tool description does not add additional parameter semantics beyond what the schema already provides, so the baseline score 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 uses the specific verb 'Get' with the resource 'a Google Form's structure and questions', clearly differentiating it from sibling tools like google_forms_responses (which handles responses) and google_forms_create/add_question (which mutate forms). This is a clear, non-tautological statement of 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 usage when you need a form's structure and questions, but does not explicitly state when to use this tool versus the other form-related tools. No exclusions or alternatives are mentioned, so the guidance is only 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'List responses submitted to a form,' which is a simple read operation that is already evident from the name. It does not disclose pagination, default page size, ordering, or the format of returned data, leaving significant ambiguities.

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, direct sentence with no filler. It is front-loaded with the action and object, making it easy to parse. Every word earns its place, exemplifying conciseness.

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 or annotations, the description should explain what the response list includes, any pagination behavior, and ordering. It provides none of this context, leaving a 3-parameter tool under-specified for an agent to invoke confidently.

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

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

The schema has 100% description coverage for all three parameters (formId, account, pageSize), so the baseline is 3. The description adds no extra semantic detail beyond what the schema already provides, making it adequate but not enhanced.

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 'List responses submitted to a form' uses a specific verb (List) and resource (responses submitted to a form), clearly indicating the tool's function. It is distinguishable from sibling tools like google_forms_get, which likely retrieves form metadata. However, it does not specify what aspects of responses are included, so it is not maximally specific.

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. It does not mention prerequisites, such as requiring a form ID, or when to prefer this over google_forms_get. No context or exclusions are provided, leaving the agent to infer usage from the 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 behavioral disclosure. It does disclose that the message content includes parsed headers, body, and attachment flags, which is useful. However, it does not explicitly state that the operation is read-only, has no side effects, or require any authentication details beyond what is implied by the schema. The description adds some value but lacks deeper 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 sentence that is clear and direct, with no superfluous words. It front-loads the core purpose and includes the key details of what will be returned, achieving high conciseness and good 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?

Given the simplicity of this get tool and the 100% schema coverage, the description is mostly complete. It explains the return contents (parsed headers, body, attachment flags), which partially compensates for the lack of an output schema. However, it does not specify the exact structure of the return value, such as field names or formats, and there is no mention of potential errors or edge cases. Still, for a straightforward getter, this is adequate.

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 descriptions for both parameters (id: 'Message ID', account: 'Account nickname to use'), giving 100% schema coverage. The tool description does not add any additional meaning beyond what is already in the schema, so the 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?

The description clearly states the tool's function: fetching a single message with parsed headers, body, and attachment flags. The verb 'fetch' and resource 'single message' make the purpose explicit and distinguish it from sibling tools like google_gmail_list (which lists messages) and google_gmail_send.

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 this tool (for retrieving one message) but does not explicitly mention alternatives or exclusions. It lacks explicit guidance such as 'Use google_gmail_list to list messages' or 'Do not use for sending.' The usage context is only implicit via the name and the specification of 'single message.'

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 transparency burden. It discloses the newest-first ordering and the search option, but it does not state what the returned messages contain (e.g., metadata vs. full content), pagination behavior, or the role of the account parameter. This leaves key behavioral details unspecified.

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

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

The description is a single, front-loaded sentence that conveys the essential action and key modifiers without redundancy. It is 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?

The tool is simple with three optional parameters, but there is no output schema. The description covers the action, ordering, and search option, but it omits what the list returns (e.g., message summaries vs. full bodies) and what happens if no account is specified. This is a notable gap given the lack of output schema, yet the description still suffices for basic use.

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 only mentions the query being optional, which is already evident from the schema (no required fields). It adds no extra meaning for the account or maxResults parameters beyond what the schema already describes.

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 specifies the verb 'List', the resource 'messages from the inbox', and the ordering 'newest first', which distinguishes it from sibling tools like get, send, or modify. It also notes the optional Gmail search query, 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 gives clear context when to use this tool: to list inbox messages, optionally filtered by a search query. However, it does not explicitly mention alternatives or when not to use it (e.g., when a full message body is needed, use get), so it stops short of a 5.

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 states that labels are added or removed but does not disclose potential side effects, such as whether existing labels are preserved, whether the operation is reversible, or what the return value is. The examples map to label names but do not explain underlying behavior.

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

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

The description is a single, front-loaded sentence. It states the core action first and appends parenthetical examples for clarity. Every word earns its place, with 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 modification tool with 4 parameters and no output schema, the description adequately conveys the basic action and examples. However, it lacks details about prerequisites (e.g., message must exist), side effects, or return behavior, leaving some gaps for a tool with no annotation support.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema; the examples of mark read/unread and star/archive provide user-friendly context but largely overlap with the schema's own examples of STARRED, INBOX, TRASH, and UNREAD.

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 purpose with a specific action ('Add or remove labels') and resource ('on a message'). It provides concrete examples (mark read/unread, star, archive) and distinguishes it from sibling tools like send, list, and get.

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 label modification is needed) and gives example use cases, but it does not explicitly state when not to use it or mention alternatives. Since there is no direct sibling for label modification, this is acceptable 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 full responsibility for disclosing behavioral traits. It mentions preserving threading headers, which is useful, but it does not state that the tool sends the reply, any required permissions, whether it creates a draft or sends immediately, or potential side effects on the original message. This is a mutation tool lacking 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, well-structured sentence that is front-loaded with the action and resource. It is concise with no wasted words, effectively covering the core purpose and a key behavioral detail.

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 relatively simple with five parameters and no output schema. The description covers the main purpose and an important behavioral nuance (threading headers). It lacks some details about side effects, but given the simplicity and schema richness, it is reasonably complete for an agent to select and 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 100%, so the schema already documents all five parameters. The description does not add parameter-specific details beyond what the schema provides, but the mention of threading headers gives context for why threadId and messageId are needed. This meets the baseline for schema-covered 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 clearly states the tool's function: 'Reply to an existing message inside its thread, preserving threading headers.' This identifies the specific verb (reply) and resource (existing message in thread), and distinguishes it from the sibling google_gmail_send tool by emphasizing 'existing message' and 'preserving threading headers.'

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 intended use case (replying within an existing thread) and contrasts with sending a new message, but it does not explicitly state when not to use this tool or name alternatives. It is clear enough for an agent to infer the context, though a direct reference to google_gmail_send for new emails would strengthen guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, how accounts are resolved, what happens on success or failure, or rate limits. For a sender tool, this is a significant gap.

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

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

The description is a single, front-loaded sentence that conveys the core action without waste. It is appropriately sized for a straightforward 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?

The tool has 7 parameters, no output schema, and no annotations. The description only gives a high-level action and omits important context such as return value, account selection behavior, body format handling, and failure modes. For the tool's complexity, the description is underspecified.

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?

All seven parameters are described in the schema (100% coverage), and the description itself adds no extra parameter-level details. This is the baseline for high schema coverage; the description neither enhances nor detracts from 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 ('Send') and resource ('an email') with the context 'from the connected account,' which distinguishes it from sibling Gmail tools like google_gmail_list (listing emails) or google_gmail_reply (replying to an existing email).

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

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

The wording implies this tool is for composing and sending new emails, and the existence of google_gmail_reply hints at an alternative for replies, but the description does not explicitly state when to use this versus alternatives, nor does it provide any exclusions or prerequisites.

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

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

No annotations are present, so the description carries the full burden. It clearly communicates that rows are added below existing data (non-destructive), but omits any details about required permissions, behavior on missing sheet, or response format. The core behavior is sufficiently transparent for a simple append 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 8-word sentence that is front-loaded and contains no filler. It is appropriately sized for a simple tool.

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

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

Given the tool's simplicity and full schema coverage, the description provides adequate context for agent invocation. It clearly states the operation and target, though it lacks explicit return-value information and differentiation from write semantics, which are not critical given 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?

The input schema already describes all five parameters (100% coverage), so the description does not need to add parameter details. The description itself mentions 'rows' and 'sheet' implicitly, but adds no semantics beyond the schema.

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

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

The description uses a specific verb 'Append' with a clear resource 'rows below the existing data in a sheet', which accurately differentiates it from siblings like google_sheets_write. This is a concise statement of the tool's core 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 provides no explicit when-to-use guidance or alternative tool references. The phrase 'below the existing data' implies it is for adding rows without overwriting, but it does not explicitly state when to choose append over write or batch_update.

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 mentions 'raw' and examples of operations, but does not disclose potential side effects (e.g., data loss from deleting sheets), required permissions, whether changes are reversible, or what the return value looks like. This is a significant gap for a tool that can perform destructive batch operations.

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

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

The description is a single, front-loaded sentence that states the verb ('Send'), resource ('raw Sheets batchUpdate requests'), and examples, with zero wasted words. It is appropriately concise for a tool that references an external API.

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 and absence of an output schema, the description is adequate but thin. It explains the core purpose and gives examples, but it does not mention that the tool passes requests directly to the API, that operations are applied in order, or any caveats about quota/rate limits or error propagation. It is minimally complete for an expert user.

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%, but the param descriptions are minimal ('Spreadsheet ID.', 'Sheets API batchUpdate requests.'). The tool description adds context by listing examples of request types (add/delete sheets, formatting), but it does not explain the structure of the requests array or how to construct the batchUpdate payload beyond what the schema already says. This is baseline for a schema with full 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 clearly states the tool's function: 'Send raw Sheets batchUpdate requests' with concrete examples like 'add/delete sheets, formatting.' This distinguishes it from sibling tools like google_sheets_write/append/read, which handle simpler, higher-level 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?

Usage is implied via the word 'raw' and the examples of structural changes, suggesting it is for advanced operations not covered by other tools. However, it does not explicitly mention when to prefer this tool over alternatives like google_sheets_write or append, nor does it state any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states it creates a spreadsheet but does not disclose side effects (e.g., where it is saved), prerequisites (e.g., account required), or what the response contains. The optional sheet tabs detail is helpful but insufficient for full transparency.

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 core action ('Create a new spreadsheet') and states the optional feature in a clear, parenthetical style. Every word earns its place with no redundancy or 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?

The tool has no output schema and no annotations, so the description should explain return values and operational context. It does not specify what the tool returns (e.g., spreadsheet ID/URL) or how the account parameter interacts with default accounts. This leaves a significant gap for an agent needing to use the created spreadsheet in subsequent operations.

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 explains all three parameters. The description adds minor context by mentioning 'pre-made sheet tabs' which maps to the sheets parameter, but it does not add material meaning beyond what the schema provides. 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 uses a specific verb ('Create') and resource ('a new spreadsheet'), clearly distinguishing it from sibling tools that read/write/update existing spreadsheets. The optional pre-made sheet tabs feature adds further specificity. This is a clear, unambiguous purpose statement.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or recommend use cases. The verb 'create' implies usage for new spreadsheets, but no alternatives are contrasted or conditions 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 burden of disclosing behavior. The verb 'Get' implies a read-only operation, and the optional range behavior is mentioned, but the description does not elaborate on metadata contents, authentication, or potential side effects. It is adequate but sparse.

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 (12 words) that front-loads the core purpose. Every word contributes meaning, with no unnecessary detail 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?

With no output schema, the description should explain what 'metadata' entails or what the response format looks like, but it does not. The tool returns multiple possible data types (metadata and/or cell values), yet the description leaves the return structure ambiguous, making it incomplete for an agent.

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 full coverage (100%) for the three parameters, and the description adds no additional semantic meaning beyond what is already in the schema. The optional range is mentioned but does not enhance schema 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 uses a specific verb ('Get') and identifies a clear resource ('spreadsheet metadata') with an optional range for cell values. While this distinguishes it from sibling tools like google_sheets_read, it does so implicitly rather than through explicit comparison.

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

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

No guidance is given on when to use this tool versus alternatives such as google_sheets_read. The description only states what it does, leaving the agent to infer appropriate use cases without explicit context or exclusions.

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

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

With no annotations, the description carries the transparency burden. It discloses the return format ('rows of strings'), which is useful, but does not mention error handling, permissions, or whether values are formulas or rendered. The read-only nature is implied by the name and 'read' verb.

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, focused sentence that front-loads the key information and avoids any unnecessary words. It is highly concise and clearly 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?

Given the tool's simplicity and the rich input schema, the description is nearly complete. It states the output format and the schema details all parameters. However, the absence of usage guidelines or differentiation from similar tools prevents a perfect score.

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 fully documents all four parameters, providing 100% coverage. The description does not add parameter-level detail beyond the generic reference to 'range', so it meets the baseline for full 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 clearly states the tool reads cell values from a range and returns them as rows of strings. This distinguishes it from write/append tools, though it does not explicitly contrast with google_sheets_get.

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

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

No guidance is provided about when to use this tool versus alternatives such as google_sheets_get or other read tools. The description simply states what it does, leaving the agent to infer the correct usage 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?

The description discloses a key behavioral trait: it overwrites existing data in place. However, with no annotations provided, it does not cover other relevant behaviors like authentication requirements, whether the sheet must already exist, limits on data size, or the exact shape of the written block. The overwrite disclosure is helpful but not comprehensive.

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, direct sentence that leads with the action and key resource. The parenthetical efficiently conveys the critical overwrite behavior without unnecessary words. It is perfectly sized for the information offered.

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

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

For a write tool with no output schema and no annotations, the description is somewhat thin. It correctly states the operation and the overwrite caveat but does not explain how the dimensions of the values array map to the target range, nor does it suggest any expected return value. Given that the schema explains individual parameters, 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?

Schema description coverage is 100%, so the description adds only minimal additional meaning. It restates that the range is the top-left starting point (matching the schema) and ties range to values by saying 'rows of values starting at that cell.' This is slight enhancement, but the schema already documents each parameter accurately.

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 writes rows of values to a spreadsheet starting at a specified top-left cell. The parenthetical 'overwrites in place' distinguishes it from related operations like google_sheets_append, making its specific function 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 provides context ('starting at a range top-left cell' and 'overwrites in place') that implies it is for replacing a block of cells, but it does not explicitly mention when to avoid this tool or provide alternatives such as google_sheets_append. The overwrite hint offers some guidance, but there are no explicit when-to-use versus when-not-to-use directions.

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 present, the description must carry the full burden of behavioral disclosure. It only states the action without describing side effects, such as whether the slide is appended to the end or inserted at a specific index, or whether any permissions are required. This lack of detail is a notable gap 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?

The description is a single, front-loaded sentence of seven words. It is concise and every word earns its place, with no unnecessary elaboration.

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 has no annotations, no output schema, and only two parameters, the description is too minimal to be fully complete. It does not explain what happens after adding a slide (e.g., return value), how the slide is positioned, or any prerequisites. This leaves significant room for misinterpretation.

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 provides descriptions for both parameters (presentationId and account), giving 100% coverage. The description does not add any additional meaning to the parameters, so the baseline score 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 verb (Add) and object (a blank slide) with a target (a presentation). This distinguishes it from sibling tools like delete_slide or replace_text, 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that it requires an existing presentation, how it relates to create_presentation or delete_slide, or any prerequisites such as needing to be the owner of the presentation.

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 states the creation action but does not explain account default behavior, whether a default slide is created, or what the return value is. For a mutation tool, this is a notable gap.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every word earns its place for the simple purpose.

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 has only two parameters, no output schema, and no annotations, so complexity is low. The description covers the core purpose but omits relevant behavioral context such as account selection and expected output, leaving it only minimally 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% for both parameters (title and account). The description adds only 'with a title', which restates the title parameter and does not enrich understanding of the account parameter or parameter relationships.

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 and resource: 'Create a new Google Slides presentation.' It clearly distinguishes this from sibling tools like google_docs_create or google_slides_add_slide by specifying 'new' and 'presentation'.

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 guidance is provided about when to use this tool versus alternatives. Usage is implied by the phrase 'new presentation', but there is no mention of exclusions or references to sibling tools like add_slide or docs_create.

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 for behavioral disclosure. It only states the action and the lookup key, without disclosing whether deletion is permanent, whether it affects the presentation structure, or whether specific permissions are required.

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?

Single sentence with no redundant words or filler. It is appropriately front-loaded and compact.

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 fully documented parameters, the description is functional but lacks context about how to obtain required identifiers and the consequences of deletion. It does not mention an output or error behavior, but no output schema is expected.

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 three parameters. The description's 'by object ID' adds no additional meaning beyond the schema's 'Slide object ID to delete.' 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 clearly states a specific action ('Delete') on a specific resource ('a slide') via a specific key ('by object ID'). It distinguishes from sibling tools like google_slides_add_slide or google_slides_get.

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

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

No guidance is provided about when to use this tool, prerequisites, or alternatives. It does not mention that the slideObjectId is obtained from google_slides_get or google_slides_add_slide, nor does it caution against using it for deleting entire presentations (which would use google_drive_delete).

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 full responsibility for behavioral disclosure. It only hints at the output format ('structural JSON') but does not explain authentication requirements, whether the operation is read-only (obvious from name), or what components are included in the returned JSON. This leaves significant behavioral ambiguity.

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 conveys the essential purpose and output type in a compact manner without sacrificing clarity.

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 retrieval tool with two well-documented parameters, the description is minimally sufficient. However, the absence of an output schema and annotations means more detail about what the structural JSON actually contains (e.g., slides, layout, text) would improve completeness. The description provides a bare-bones outline but leaves the user guessing about the full 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 already provides 100% description coverage for both parameters (account and presentationId). The tool description adds no additional parameter meaning, so the baseline of 3 applies. The schema is sufficient for 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 tool retrieves a Google Slides presentation and indicates the return type as 'structural JSON'. This specific verb+resource pairing distinguishes it from sibling tools like google_slides_create or google_slides_delete_slide, and from other get operations like google_drive_get.

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 usage is reasonably implied: use this tool when you need to fetch a presentation's structural JSON. However, it does not explicitly mention alternative tools or scenarios where this tool should not be used. There is no guidance on how it compares to other Google Slides operations.

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

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

No annotations are provided, so the description must carry the full burden. It discloses that all occurrences are replaced (not just the first) and frames it as template filling, which is useful behavioral context. However, it does not mention whether replacement affects slide notes, requires any specific permissions, or what happens when the search text is not found.

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 sentence with no filler, front-loading the action and scope. It earns every word.

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 or annotations, the description is minimal. It covers the core operation but omits important contextual details such as scope limitations (only slides vs. notes), replacement behavior regarding formatting, and handling of missing matches. Adequate but with clear gaps.

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

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

Schema description coverage is 100%; each parameter (find, replace, matchCase, presentationId, account) is already documented in the schema. The description adds no additional parameter information, so 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?

Description states 'Replace all occurrences of a string across a presentation' with a specific verb ('replace'), resource ('presentation'), and scope ('all occurrences'), and adds 'template filling' to clarify intended use. This clearly distinguishes it from sibling google_docs_replace_text.

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

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

The phrase 'template filling' implies a use case, but there is no explicit guidance on when to use this tool over google_docs_replace_text or other Slides tools, nor any exclusions or prerequisites. It provides implicit context but no explicit alternatives or conditions.

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, and the description does not disclose behavioral details beyond the core action. It does not mention idempotency, whether completing is reversible, how subtasks are affected, or what response to expect. With no annotation safety net, the description carries the full burden of behavioral disclosure, and it falls short.

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 fully captures the tool's purpose in minimal words. It is front-loaded and waste-free, earning top marks for conciseness.

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 state-change tool with three parameters and high schema coverage, the description conveys the essential action. However, it lacks context about return values, error cases, or the role of optional parameters like account and tasklistId. It is minimally viable but not rich in contextual detail.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific meaning beyond the schema, but the schema already documents taskId, account, and tasklistId adequately for a simple tool. The description does not need to repeat parameter 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 'Mark a task as completed' clearly identifies the action (marking) and the resource (a task), using a specific verb. It distinguishes itself from sibling tools like google_tasks_create and google_tasks_delete, though it does not explicitly mention the task list context. Overall, the purpose is clear 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as needing an existing task or a specific task list. The description simply states the action without context. Sibling tools like google_tasks_list and google_tasks_create suggest related workflows, but no explicit usage direction 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?

No annotations are provided, and the description does not disclose behavioral traits such as the write side effects, required permissions, or error handling. It only describes the basic action without elaborating on consequences.

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

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

The description is a single, front-loaded sentence with no redundancy. Every word contributes to communicating the core purpose and optional parameters.

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 a simple create operation, and the schema covers all parameters, making the description minimally sufficient. However, it lacks usage guidance and output expectations, though these are not critical given the low complexity and rich 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 coverage is 80% and the schema already provides detailed parameter descriptions (e.g., RFC3339 for due). The description adds marginal value by explicitly noting notes and due are optional, but does not clarify the remaining 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 clearly states the tool creates a task, with optional notes and due date, which aligns with the tool name and distinguishes it from list/complete/delete siblings. However, it does not mention the task list context, slightly limiting scope specification.

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 explicit guidance on when to use this tool versus alternatives like google_tasks_complete or google_tasks_delete. Usage is only implied by the name and the obvious 'create' action.

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. 'Delete a task' is extremely sparse and does not mention irreversibility, potential cascading effects (e.g., subtasks), authentication needs, or what happens to the task in shared lists. This is a significant gap 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?

The description is a single concise sentence that is perfectly front-loaded and contains no filler. However, it is perhaps too minimal, sacrificing important context for brevity. It earns full marks for efficiency but loses a point for under-specification.

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

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

Given the tool's complexity (3 parameters, no annotations, no output schema), the description is critically under-informative. It does not explain return values, side effects, or how the tool interacts with task lists. For a mutation tool, this is a major gap, as the agent has no information about outcomes or prerequisites beyond the raw parameter list.

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%, with each parameter (taskId, account, tasklistId) having a basic description in the schema. The tool description adds no extra meaning beyond the schema, but since the schema fully documents parameters, the 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 states a clear verb and resource: 'Delete a task.' This is specific enough to convey the core function and distinguish it from task creation or completion. However, it lacks any scope or reference to the task ID, and does not explicitly distinguish from siblings like google_tasks_complete, which also modifies a task.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states the action without mentioning prerequisites (e.g., obtaining taskId from list), when to prefer delete over complete, or any context about which task list applies. This leaves the agent without decision support.

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 full burden for behavioral disclosure. It does not mention the read-only nature, return format, pagination, or authentication requirements, leaving the agent with limited understanding of side effects and outputs.

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 main action. Every word earns its place without unnecessary detail.

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

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

This is a simple tool with two optional parameters and no output schema. The description covers the core function and default behavior, but lacks details about the result structure or any limitations, making it minimally adequate.

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 already provides descriptions for both parameters with 100% coverage. The description's note about default list mirrors the schema's default annotation, so it adds little new semantic value.

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

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

The description clearly states the tool lists tasks within a task list, and mentions the default list behavior. It does not explicitly contrast with sibling tools like google_tasks_list_lists, but the verb-resource combination is specific enough.

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 usage context: listing tasks in a specific list, with an optional default list. However, it provides no guidance on when to prefer this over alternatives or any exclusions, which is a gap for a tool with many 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?

No annotations are present, so the description carries the full burden of disclosure. It only says 'List' without stating whether the operation is read-only, what the return format is, whether pagination applies, or any account-handling details. The verb 'List' implies a safe read, but the description offers no explicit 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, front-loaded sentence with no filler or redundant information. It is appropriately concise and communicates the core function efficiently.

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 simplicity of the tool and full schema coverage, the description is minimally adequate. However, it lacks context about what is returned, potential confusion with google_tasks_list, and any behavioral notes. For a simple list tool with no annotations, it 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 covers the sole parameter 'account' with a description, giving 100% coverage. The description itself adds no additional meaning to the parameter, so the schema-based 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 uses the verb 'List' and clearly identifies the resource as 'Google Tasks lists' scoped to the account. It is distinguishable from the sibling google_tasks_list, which likely lists tasks within a list, though the description doesn't explicitly call out that distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, leaving the agent to infer usage from the name alone. The sibling google_tasks_list could easily be confused, and there is no mention of prerequisites or 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 and a single-sentence description, there is zero disclosure of side effects, permission requirements, error behavior, or what happens on success. The tool appears to be a simple mutation, but the description offers no additional behavioral context beyond the obvious.

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 extremely concise—a single sentence with no unnecessary words. It is front-loaded and easy to parse, though it might be too terse, lacking important context that would be useful.

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 performs a mutation on YouTube, but the description lacks essential context such as authorization needs, playlist ownership, duplicate handling, or expected output. With no annotations or output schema, the description is insufficient for an agent to fully understand the operation's implications.

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 descriptions for all three parameters (account, videoId, playlistId), covering 100% of the semantics. The description adds no further meaning, so the 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?

The description clearly states the action: 'Add a video to a playlist.' It uses a specific verb and resource, and it is distinct from sibling tools like create_playlist or delete_playlist, leaving no ambiguity about its 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?

No guidance is provided on when to use this tool, what prerequisites are needed, or how it contrasts with alternatives. The description merely states the action without any contextual cues, leaving the agent to infer usage from the 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the obvious 'create' action and adds 'for the user,' but fails to mention that this creates a resource on the authenticated YouTube account, that privacy can be customized, that an account nickname is required, or what the response contains (e.g., playlist ID). This is a 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?

The description is a single, short sentence with no fluff or redundancy. It is appropriately sized for a straightforward creation tool, though it could have included more usage context without bloating.

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 four parameters, no annotations, and no output schema, the description is under-specified. It fails to explain that the tool requires a valid account nickname, that the playlist is created on the user's YouTube account, or that the response likely includes a playlist ID. It also doesn't hint at the privacy options beyond the default, leaving the agent without enough context for a proper invocation.

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

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

Schema description coverage is 100% for all four parameters, so the schema already documents each parameter's meaning. The description adds nothing beyond the schema; it only repeats the default privacy setting. Baseline of 3 applies because the schema does the heavy lifting.

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 'Create a private playlist for the user,' using a specific verb and resource. It distinguishes from sibling tools like list/delete playlists because the operation type is unique. However, the word 'private' is a slight under-specification since the tool supports public and unlisted playlists via the privacyStatus parameter.

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. It does not mention that this is the creation counterpart to list/delete/add-to-playlist tools, nor does it indicate any prerequisites like account selection. The agent is left without context for choosing this tool over others.

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. 'Delete' implies destructive action, but it does not disclose whether deletion is permanent, reversible, requires special permissions, or any side effects. This is a minimal statement.

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 earns its place. It is front-loaded and contains no filler or unnecessary words.

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 with a complete schema for its two parameters. The description is sufficient for a basic delete operation but lacks any caveats or context about consequences, which would be expected given no output schema and no annotations.

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 adds no extra meaning about the parameters; it only mentions 'by ID' which aligns with the schema's playlistId.

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 'Delete a playlist by ID' clearly states a specific verb and resource, and adds the detail that deletion is by ID. It distinguishes this from sibling playlist tools like create/list/add, though it is very brief.

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 usage guidance is provided. The description does not mention when to use this tool, any prerequisites, or alternatives. It simply states the action without context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It implies a read operation ('Get'), which is transparent, but it does not mention authentication requirements, rate limits, or any potential side effects. The description is adequate for a simple get tool but adds no extra 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?

One concise sentence, front-loaded with the key action and resource. No wasted words or redundant detail.

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 simplicity of the tool, the description adequately covers what it returns ('details, statistics and content details'). No output schema exists, but the description is informative enough for a get operation. It does not explain required parameters, but the schema handles that.

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

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

Schema coverage is 100% for both parameters (videoId and account), so the schema fully documents them. The description adds no additional parameter semantics, which aligns with the baseline of 3.

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

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

The description clearly states the tool retrieves details, statistics, and content details for a video, which is specific and aligns with the tool's name. It does not explicitly differentiate from siblings like google_youtube_search, but the resource (a specific video) is clear.

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

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

No guidance is provided on when to use this tool versus alternatives such as google_youtube_search or google_youtube_my_videos. The description simply states the action without 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?

No annotations are provided, so the description carries full behavioral disclosure burden. However, it only states 'list the user's playlists' without mentioning pagination, default behavior, authentication, or what data is returned. This adds little beyond the action itself.

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

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

The description is a single, clear sentence with no redundancy. It is front-loaded, appropriately sized, and wastes no words.

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

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

This simple list tool lacks an output schema and the description does not disclose return values, pagination details, or account behavior. The agent can infer only the basic action, leaving gaps about response structure and limits.

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%, with 'account' and 'maxResults' already documented. The description adds no parameter details, but the schema handles it, making this baseline adequate.

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 ('List') and resource ('the user's YouTube playlists'), distinguishing it from sibling tools like youtube_search or my_videos. The title and description align well.

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 usage for listing playlists, but provides no explicit guidance on when to use this tool versus alternatives such as youtube_search or subscriptions. No exclusions are mentioned, so it's left to inference.

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