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

With no annotations, the description carries the full behavioral burden but supplies almost nothing: no mention of required permissions, which calendar the event lands on (no calendarId parameter is present), whether attendees are emailed invitations, or whether reminders/notifications fire. 'Optional attendees' is the only behavioral hint, and it is thin for a write 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?

A single front-loaded sentence with no filler; it is appropriately sized for the amount of information it conveys, even if that information is sparse.

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 mutating calendar tool with zero annotation coverage and no output schema, so the description should disclose side effects (invitations, notifications) and target-calendar behavior. It omits all of that, leaving the agent to guess at consequences of the write.

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 seven parameters already have documented meanings; baseline 3 applies. The description only echoes the attendees parameter and adds no formatting or time zone interpretation notes beyond what the schema states.

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

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

States a specific verb and resource ('Create a new Google Calendar event') and adds scope detail about optional attendees. It does not explicitly distinguish itself from the sibling calendar_update_event, though the name makes the create-vs-update split fairly obvious.

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 about when to use this versus calendar_update_event, what prerequisites exist (auth, target calendar), or when not to use it. The agent must infer everything from the name.

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

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

With no annotations provided, the description carries the full behavioral burden and falls short: it does not say the deletion is permanent/irreversible, whether it requires specific OAuth scopes, what happens to recurring event instances, or what the response contains. For a destructive mutation, these omissions matter.

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

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

A single, front-loaded sentence with no waste. It is arguably too terse for a destructive operation, but structurally it is efficient and clear.

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

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

For a destructive, irreversible mutation with zero annotation coverage and no output schema, the definition should mention irreversibility and required permissions. The one-line description leaves material gaps an agent would want before invoking it.

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

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

Schema description coverage is 100% for the single eventId parameter, so the schema already tells the agent what to pass. The description adds no format hints (where to obtain the event ID, calendar ID assumptions), 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?

States a specific verb ('Delete') and resource ('Google Calendar event'), which distinguishes it from calendar_create_event and calendar_update_event in the sibling list. It does not explicitly name those siblings, but the verb itself is unambiguous.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites (e.g., event must exist, calendar access scopes), and no note about confirming with the user before deleting. The agent must infer all 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses little. It does not state that this is a read-only operation, how results are ordered, whether recurring events are expanded, what the default time range is when timeMin is omitted, or whether results are paginated beyond maxResults.

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

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

A single front-loaded sentence with no filler. It is efficiently sized, though the brevity comes at the cost of the missing context noted elsewhere rather than being optimally informative.

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

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

For a tool with four optional parameters, no annotations, and no output schema, the description is too thin. An agent still cannot tell what a result object looks like, whether nextPageToken exists, or what range 'upcoming' covers, all of which the description should have supplied given the absence of structured 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 every parameter (timeMin, timeMax, calendarId, maxResults) is already documented with format hints and defaults. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (events from Google Calendar) with a scope qualifier ('upcoming'). It is distinguishable from calendar_create_event, calendar_update_event, and calendar_delete_event by the verb alone, though the description never explicitly contrasts 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 on when to use this versus the other calendar siblings, and no mention of the default time window implied by 'upcoming'. The agent must infer from the schema that timeMin/timeMax are optional and that omitting them yields some default range.

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 identifies the operation as an update but does not explain whether it is a partial or full replacement, whether omitted fields are preserved, what permissions are required, whether changes are reversible, or what the response contains.

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 wasted text. It is concise, though for a six-parameter mutation tool it offers no structural framing beyond the core 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?

This is a mutation tool with no annotations and no output schema, yet the description omits update semantics, permission requirements, and safety context. The rich parameter schema helps, but the description does not cover enough for an agent to invoke this tool 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%, and the schema already documents each of the six parameters. The description adds no parameter-level meaning beyond identifying the target as an existing event, 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 states a specific verb ('Update') and resource ('existing Google Calendar event'). The word 'existing' distinguishes it from calendar_create_event, but no sibling tool is named explicitly, so it falls short of a 5.

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

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

There is no explicit guidance on when to use this tool versus calendar_create_event, calendar_delete_event, or calendar_list_events. The only usage cue is the implied condition that an event already exists.

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 usefully discloses that cancellation is a request, applies only to queued or active jobs, and prevents further regeneration, but it omits permissions, idempotency, and what response or job state to expect.

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

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

Two short sentences, front-loaded with the action and eligibility scope. The second sentence adds a relevant behavioral detail without waste.

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

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

For a mutation tool with no annotations and no output schema, the description is missing important context: required permissions, whether cancellation is immediate or asynchronous, idempotency, and expected result. It covers only the core action and one side effect.

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 sole parameter, jobId, has 0% schema description coverage and is not explained in the description. Its name and uuid format make it inferable, but the description adds no meaning about where to obtain it or how it identifies the job.

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

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

The description gives a specific verb ('Request cancellation') and resource ('video job'), and scopes it to queued or active jobs. This clearly distinguishes it from siblings like get_video_job, list_video_jobs, and regenerate_video.

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

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

It implies the usage condition by saying 'queued or active video job,' but it does not explicitly say when to use this versus related tools such as recover_video_job or regenerate_video. No exclusions or alternatives are named.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that a persistent 'record' is created and that it holds 'defined steps', but says nothing about permissions, whether the record is reusable by trigger_flow, whether creation is idempotent, or what the response contains. The distinction from UI workflows is valuable context but leaves major behavioral gaps for a write 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 with the primary action first and the crucial scope limitation second. No filler or redundancy.

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

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

Three simple parameters with one required and full schema coverage, plus no output schema, mean the description does not need to explain parameters. It still omits what happens after creation and how the created record is consumed, which an agent would need in order to use the tool 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 schema already documents name, steps and description. The description only echoes 'defined steps' and adds no format or constraint detail 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 gives a specific verb and resource ('Create a legacy bridge workflow record') and explicitly distinguishes the output from a 'Google Flow UI workflow', which separates it from flow_browser_generate_video and related siblings. It stops short of naming how it relates to list_flows or trigger_flow, so it is clear but not fully differentiated across all siblings.

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

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

The negative guidance ('this does not create a Google Flow UI workflow') is genuinely useful for steering an agent away from the wrong tool. However, it never states when an agent should choose this tool, what the workflow is used for, or which sibling to use instead for UI-style flows.

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

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

No annotations are provided, so the description carries the full behavioral burden. The phrasing 'Mark ... deleted' usefully implies a soft-delete rather than a hard delete, but it does not disclose permissions, reversibility, side effects, or idempotency.

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 definition is a single front-loaded sentence with no wasted text. It is appropriately compact for a one-parameter mutation tool, though it is terse to the point of leaving behavioral context unstated.

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

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

For a low-complexity tool with one fully documented parameter and no output schema, the description gives enough information to invoke the operation. However, as a no-annotation mutation tool, it should disclose more about permissions, reversibility, and side effects to be fully complete.

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

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

Schema description coverage is 100%, so the workflowId parameter is already documented as the workflow ID to delete. The description adds 'by ID' but no additional meaning beyond the schema, which meets the baseline for fully 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 gives a specific verb and resource: it marks a legacy bridge workflow record as deleted by ID. That is clear enough to distinguish it from list_flows, trigger_flow, create_flow, and status-related siblings, though it does not explicitly name a sibling alternative.

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

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

There is no guidance on when to use this tool versus alternatives, nor when not to use it. It also omits prerequisites such as whether the workflow must be inactive or whether the operation is reversible.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation to an existing document but does not disclose permissions needed, whether content is inserted at the end, formatting behavior, return values, or whether existing content is preserved.

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 wasted words. It immediately conveys the action and target resource.

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 and the schema fully documents both required parameters. However, with no annotations and no output schema, the description could say more about mutation behavior, permissions, or response expectations, leaving some gaps for an agent invoking a write operation.

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

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

Schema description coverage is 100%, so both parameters ('documentId' and 'content') are already documented in the schema. The description adds no syntax, format, or semantic detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Append') and resource ('text to an existing Google Docs document'), making the operation clear. It does not explicitly differentiate itself from siblings like docs_create or docs_read, but the distinction is largely inferable.

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 only usage signal is 'existing' document, which implies appending rather than creating. There is no explicit guidance on when to use this tool versus docs_create, docs_read, or drive-related tools, and no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full behavioral burden, yet it omits what the call returns (document ID/URL — critical since no output schema exists), whether auth/scopes are required, where in Drive the doc is created, and sharing/default-visibility 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?

One front-loaded sentence with no redundancy and no filler. It is efficient, though its brevity is the cause of the coverage gaps noted elsewhere rather than a virtue here.

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 creation tool with no annotations and no output schema, an agent still needs to know the returned handle (doc ID), permission requirements, and default location/visibility. None of that is present, so the definition is incomplete for reliable invocation.

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

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

Schema coverage is 100%, so both parameters are already documented. The description only echoes that content is optional, adding nothing about format/limits or how content interacts with the title — baseline 3.

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

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

States a specific verb ('Create') and resource ('Google Docs document'), which clearly separates it from docs_read and docs_append. It does not explicitly name those siblings, so it falls short of a 5.

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

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

The description never says when to use this versus alternatives such as docs_append, drive_upload, or other document creation paths, and lists no prerequisites or exclusions. Usage is only inferable from the verb.

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 alone must carry the safety profile: 'Read' and 'text content' imply a non-destructive operation and signal that formatting/structure is not returned, which is useful. However, it doesn't address permission or auth requirements, return value shape, behavior on missing/inaccessible documents, or size limits.

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

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

One sentence with no waste, front-loaded with the verb and the resource. Nothing could be cut without losing meaning.

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

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

For a simple single-parameter read tool with a fully documented schema and no output schema requirement, this is close to sufficient: the agent knows what it does and what it needs. The remaining lack is behavioral detail (permissions, empty-doc behavior, what 'text content' excludes).

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 single required parameter (documentId), so the schema already carries the parameter meaning. The description adds nothing beyond it, which is the baseline-3 case rather than a strength.

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

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

States a specific verb ('Read') and a specific resource ('text content of a Google Docs document'), clearly separable from the sibling mutation tools docs_create and docs_append. It stops short of explicitly naming the read-alternative siblings, but the operation is unambiguous.

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

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

No guidance on when to use this versus the sibling tools; an agent must infer that this is the read path while docs_create/docs_append are the write paths. There are no prerequisites, no exclusions, and no mention of what to do when the document is large or empty.

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

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

No annotations exist, so the description carries the full burden. It does disclose useful behavioral context — that downloads require an 'authorized' source, that output is confined to FLOW_OUTPUT_DIR, and that validation is not this tool's job — but it says nothing about overwrite behavior, failure modes, or what the tool returns on success.

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

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

Two short sentences, zero filler, with the legacy/deprecation warning and the intended audience ('manual') front-loaded before the caveat. Nothing could be cut without losing information.

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

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

For a three-parameter download tool with no annotations and no output schema, the description covers the important framing: it is a legacy path, requires authorization, and writes only under FLOW_OUTPUT_DIR. It stops short of describing return value or failure/overwrite semantics, which an agent would still need to discover.

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 three parameters are already documented in structured data and baseline is 3. The description reinforces that videoUrl may be a URL or a Drive ID and that outputPath is sandboxed to FLOW_OUTPUT_DIR, but adds no syntax or format detail the schema lacks.

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

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

States a specific verb and resource ('Legacy manual download from an authorized Google asset URL or Drive ID') and flags it as legacy, which separates it from the generate/orchestration siblings. It does not explicitly distinguish itself from the generic drive_download sibling, so an agent could still hesitate between the two.

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?

'Legacy manual download' plus 'Completed orchestration jobs already download and validate their own asset' gives a clear when-not-to-use signal: don't call this if a job already produced the asset. It never names the preferred alternative tool, so the agent must infer rather than be routed.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not state that this is a write operation requiring Drive write scope, what happens on duplicate names, or that the created folder's ID is the useful return value. Only the bare 'create' semantics are conveyed.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably too sparse to be genuinely helpful rather than merely non-wasteful.

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

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

For a mutation tool with no annotations and no output schema, the description should at least mention that it returns the new folder identifier and any permission expectations. As written, an agent knows what it does but not what it will get back or what can go wrong.

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

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

Schema description coverage is 100%, and the schema already explains 'name' and 'parentId' (including the root default). The description adds no additional meaning beyond that, 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?

States a specific verb ('Create') and resource ('folder') plus the system ('Google Drive'), which is unambiguous and does not collide with any sibling (drive_list, drive_upload, drive_trash handle other operations). No explicit sibling differentiation is offered, but none is needed here since no other folder-creation tool exists.

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 versus drive_upload or drive_trash, and no preconditions (e.g., parent folder must exist, auth requirements). Usage is only inferable from the verb itself.

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

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

With no annotations provided, the description carries the full disclosure burden, yet it says nothing about authorization requirements, what happens if the local file already exists (overwrite? error?), size limits, or whether the call blocks during transfer. Only the bare mutation-transfer intent is conveyed.

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

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

A single front-loaded sentence with no filler; every word earns its place. It is efficient but so terse that it borders on under-specification rather than tightness.

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 file-transfer tool with no annotations and no output schema, the description should cover overwrite behavior, auth needs, and what is returned on success. None of that is present, leaving real operational gaps an agent would need.

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

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

Schema description coverage is 100%, so both fileId and localPath are already documented in the schema, establishing the baseline of 3. The description adds no meaning beyond the schema — notably it does not clarify the ambiguous 'file or directory' semantics for localPath.

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

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

States a specific verb (download) and resource (a Google Drive file) plus the destination, which clearly separates it from drive_list, drive_upload, drive_trash, and drive_create_folder. It does not explicitly distinguish itself from the similarly named download_flow_video, but the Drive-vs-Flow framing is implicit in the name and description.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites (file must exist, must have read access), and no guidance on how to choose a localPath. The agent is left to infer everything about invocation 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 full burden. 'List' implies a safe read, but nothing is said about pagination or result caps, ordering, behavior on an invalid or inaccessible folderId, or permission requirements — all material for a directory-listing call.

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

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

A single front-loaded sentence with no filler. The resource and the filter set both land immediately, which is exactly the right shape for a simple list 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?

With three optional params, no annotations, and no output schema, the definition is minimally sufficient to invoke, but it never describes what a result looks like (file fields, IDs needed for follow-up drive_download/drive_trash calls) or how large result sets are handled.

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 query, fileType (with examples), and folderId (default root). The description only restates the same three filter axes in generic terms; it adds no matching semantics (substring vs. exact vs. Drive query syntax) beyond the schema.

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

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

States a specific verb (List) and resource (files in Google Drive) plus the filter axes, which cleanly separates it from drive_upload, drive_download, drive_trash, and drive_create_folder. It doesn't explicitly name or contrast with a sibling, but the operation is 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?

Usage is only implied: calling with no arguments lists root, and each filter narrows results. There is no statement of when to prefer this over other approaches, no note on prerequisites (auth/scope), and no exclusions, but no competing 'list files' sibling exists to route away from.

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

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

No annotations are provided, so the description carries the full burden and it does little: it doesn't state that trashing is recoverable, whether it fails on already-trashed files, what permissions the caller needs, or what the response contains. For a mutation on user data with zero annotation coverage, that's 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?

One front-loaded sentence with no filler or redundancy. It is arguably over-terse for what it leaves out, but there is nothing wasteful to trim.

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 (1 param, no output schema, no nested objects), so the description is barely adequate. Missing reversibility, permission, and error-condition details keep it from being complete for a destructive-adjacent 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?

With a single required parameter at 100% schema description coverage, the schema already explains fileId fully. The description only alludes to 'a file', adding no format, ID-source, or validation detail beyond the schema, 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?

States a specific verb (move...to trash) and resource (file in Google Drive), so the action is unambiguous. It doesn't need to distinguish from siblings like drive_upload or drive_create_folder, but it also never positions itself against a hard-delete alternative because none exists in the sibling list.

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 intent is implied by 'to trash' versus a permanent delete, but the description never says when to choose this over other drive operations or what preconditions apply. An agent gets the general context (trash a file) with no explicit exclusions or alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention authentication requirements, whether uploads overwrite existing files, what permissions are needed, or any side effects. 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 wasted words. It is appropriately concise, though it could include a bit more 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?

Given the tool is a mutation operation with no annotations and no output schema, the description should provide more behavioral context such as return values, error conditions, or side effects. It is too minimal for the complexity of an upload operation.

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

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

Schema description coverage is 100%, so all parameters are well-documented in the schema. The description adds no additional meaning beyond the schema itself, which is acceptable when schema coverage is high.

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

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

The description states a specific verb (Upload) and resource (local file to Google Drive), clearly identifying the action. It does not explicitly differentiate from sibling tools like drive_download or drive_create_folder, but the purpose is still 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, no prerequisites, and no exclusions. It merely states what the tool does without any contextual usage information.

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. 'Browser automation' hints that a live authenticated session is needed, but it never states prerequisites (login, check_session), whether actions are destructive or reversible, or how failures surface — all critical for a tool that drives a UI and can export or run flows.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of substance rather than from disciplined pruning.

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

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

For a no-annotation, no-output-schema dispatcher with a nested free-form parameters object and heavy sibling overlap, the description is far too thin. It should state session prerequisites, per-action side effects, and how it relates to the dedicated create_flow/trigger_flow/flow_browser_generate_video 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 coverage is 100%, so the three parameters are already documented in the schema, giving a baseline of 3. The description adds nothing about what keys belong in the free-form 'parameters' object per action — arguably the biggest ambiguity in this schema — and it omits 'navigate' from its action list.

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

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

The description names a verb-and-resource ('Execute a Google Flow action through browser automation') and enumerates four of the five enum actions. But it never distinguishes this generic dispatcher from siblings like create_flow, trigger_flow, or flow_browser_generate_video, which appear to overlap on the same actions. The parenthetical also silently drops the 'navigate' action that the enum allows.

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 the many sibling flow_* and flow_browser_* tools. The agent must infer that this is a catch-all dispatcher, and nothing says when the dedicated per-action tools are preferable.

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

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

No annotations exist, so the description carries the full burden, and it does add real value by stating a manually authenticated persistent browser session is required and that password/MFA automation is never performed. It omits other behaviors an agent needs: that jobs are async by default (waitForCompletion=false), whether submission is idempotent via idempotencyKey, and what happens on session expiry.

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

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

Two efficient sentences with no waste, but the size reflects under-specification rather than discipline: an agent needs information that simply isn't there, so brevity does not earn full marks.

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?

Eight parameters, no annotations, no output schema, and no param-level detail — the description should at minimum disambiguate the job-submission semantics, the async/wait behavior, and the idempotency contract. Only the authentication constraint is covered.

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

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

Schema coverage is only 63%, and three parameters (priority, idempotencyKey, waitForCompletion) have no schema description at all. The description says nothing about any parameter, so it does not compensate for the gaps — notably the meaning of priority and the idempotency semantics are left undefined.

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 labels the tool a 'compatibility alias for a bounded, persistent Flow video job' but supplies no verb and never says what invoking it actually does (submit a job? resume one? open a session?). With siblings like flow_browser_generate_video, trigger_flow, and create_flow, an agent cannot tell which resource operation this maps to.

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?

'Compatibility alias' hints it exists for legacy callers, but there is no explicit statement of when to prefer this over flow_browser_generate_video or create_flow, and no prerequisites or exclusions beyond the auth note.

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

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

No annotations are provided, so the description carries the full burden; it does disclose the key non-destructive trait that the current page is not navigated away from. It does not disclose what happens on an invalid or expired session (error vs. boolean result), nor any authentication prerequisites for making the check 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?

Two short sentences, front-loaded with the purpose and followed by the one behavioral detail that matters. Nothing is redundant or padded.

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

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

With no annotations and no output schema, the description is the only source of truth about the result, yet 'returns the session state' is vague about shape (boolean, status enum, or object with expiry). For a zero-parameter boolean-style check this is workable but leaves the agent guessing what a return value actually looks like.

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 takes zero parameters, so there is no parameter semantics to clarify; the baseline of 4 applies. The description does not waste words re-explaining an empty schema.

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

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

States a specific verb ('check') and a specific resource ('Google browser session') with the exact condition being tested (valid and active). It is clearly distinguishable from siblings like flow_browser_login or flow_browser_action, though it does not name any sibling to route against explicitly.

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

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

The clause 'without navigating away from the current page' implies a pre-flight check that is safe to call before other browser operations, which is useful context. However, it never states when to call this versus flow_browser_login (e.g., 'call this before flow_browser_action to decide whether login is needed').

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 usefully discloses that session data is preserved for the next launch, which is meaningful behavioral context. However, it says nothing about whether in-flight automation tasks are terminated, whether it errors when no session exists, or whether repeated calls are safe.

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

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

Two short sentences, front-loaded with the action and followed by the key side effect. Every sentence earns its place and nothing is 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 zero-parameter close operation with no output schema, this covers the core action and the data-retention behavior. It is still missing edge-case behavior that the description must carry in the absence of annotations, such as no-active-session handling or effect on running automation.

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 takes zero parameters, so there is no parameter semantics to explain and nothing the description could meaningfully add. Baseline 4 applies, with nothing done wrong.

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

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

States a specific verb (close) and resource (browser automation session), clearly enough to tell it apart from siblings like flow_browser_check_session or flow_browser_login. It does not explicitly name or contrast those siblings, which keeps it below a 5.

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

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

Usage is implied: close the session when automation is finished, with data retained for the next launch. There is no explicit guidance on when not to call it or which sibling to use instead, and no mention of what happens if no session is active.

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 usefully discloses that this uses a persistent job orchestrator and requires a manually authenticated Google browser session, but it does not explain job lifecycle, waitForCompletion behavior, or return characteristics.

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

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

The description is two short sentences, front-loads the compatibility-alias role, and contains no filler. It is efficiently structured for scanning.

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 eight-parameter video-generation tool with no annotations and no output schema, the description is too thin. It mentions orchestration and authentication but omits job behavior, result handling, parameter semantics, and when this alias should be preferred over the primary generate_video 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 only 63%, and the description adds no parameter-level meaning at all. Some schema fields such as priority, idempotencyKey, and waitForCompletion lack descriptions, and the prose does not compensate for those 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 identifies this as a compatibility alias for generate_video and distinguishes it by noting the persistent job orchestrator. The resource is clear from the tool name and the named sibling, though the description never explicitly says it generates a video.

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

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

It implies use as a compatibility path for generate_video and states an authentication prerequisite, but it does not clearly say when to choose this over generate_video or when to avoid it. The agent must infer the selection criteria from the alias relationship.

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

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

With no annotations, the description carries the full burden and does disclose a genuinely important behavioral trait: credentials, TOTP secrets, cookies, and one-time codes are never accepted, typed, stored, or logged, so the agent knows not to attempt to pass secrets. It omits other operational traits such as whether the call blocks until login completes, whether it times out, or whether the resulting session persists for later browser tools.

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

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

Two short sentences, each earning its place: the first states the action, the second states the security constraint that shapes agent behavior. Nothing redundant or padded.

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

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

No output schema exists, so the description must convey what happens on return, and it doesn't — whether the call waits for manual login, returns immediately, or fails if no browser is available. Given the sibling set includes check_session and browser_action, a sentence on sequencing would materially improve 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 tool takes zero parameters and the description correctly introduces none; there is nothing about the input that needs clarification. Baseline 4 applies for a 0-parameter tool.

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

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

States a concrete verb and resource — opening the persistent browser profile at Google sign-in — which is far more specific than a mere restatement of the name. It does not explicitly contrast itself with flow_browser_check_session or flow_browser_autopilot, so an agent must infer the 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?

'Complete login manually' implies this is a human-in-the-loop entry point and not something to automate, but the description never says when to call it versus flow_browser_check_session, nor what to do afterwards (re-check session, retry, etc.). Usage is implied rather than stated.

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

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

With no annotations provided, the description carries the burden and does so: it declares the operation read-only and scopes it to static reference content, so there is no ambiguity about mutation or side effects. It does not say whether the call is instantaneous/cached or whether it touches the Flow session, which would fully close the 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?

Two sentences, front-loaded with the identity of the tool and followed by the single actionable usage rule. The content enumeration is dense but every item is a real capability category a caller might ask about.

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?

Enumerating the sheet's contents largely substitutes for the absent output schema, so an agent knows what it will get back. The only unstated detail is the shape of the response (structured data vs. a formatted text sheet), which matters slightly given no output schema exists.

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 takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly makes no parameter claims that the empty schema would contradict.

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

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

States a specific verb+resource ("Read-only capability sheet for Google Flow") and enumerates the exact contents: modes, aspect ratios, durations, models, output counts, watermark-removal engine, and delivery locations. This clearly separates it from siblings like list_flows (enumerates instances) and video_system_health (operational 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?

"Consult it whenever a caller asks what Flow can do or which sizes/ratios are available" gives a concrete trigger condition. It lacks explicit exclusions naming the sibling to use instead (e.g., use list_flows for existing flows), 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?

No annotations exist, so the description carries the full burden. It does not disclose whether an active browser session/login is required (despite siblings like flow_browser_check_session and flow_browser_login existing), whether the page must be navigated first, or what the tool returns (a file path vs. image bytes). Only the debugging motivation is conveyed.

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

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

One short sentence with the action front-loaded and no filler. It is efficient, though the brevity comes at the cost of the missing behavioral detail noted elsewhere.

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 browser-session-dependent tool with no annotations and no output schema, the description omits prerequisites (active session, current page state) and the return value. Given the surrounding browser/flow tooling, an agent cannot tell from this text what it needs set up beforehand.

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?

There is a single optional parameter at 100% schema description coverage, including its default (./screenshots/), so the schema already does the work. The description adds no further meaning such as file-name format or overwrite behavior, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource ('Take a screenshot of the current browser page'), which is unambiguous and distinct from siblings like flow_browser_action or download_flow_video. It does not explicitly contrast itself with any sibling, which keeps it from a 5.

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

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

The parenthetical '(useful for debugging)' hints at a use case but gives no explicit when-to-use/when-not guidance and names no alternatives. The agent must infer that this is for visual inspection of the browser state.

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 and does substantial work: it discloses that the call creates a durable (async) job, that the prompt is passed verbatim (no rewriting), that output is post-processed with watermark removal, and that delivery is local. It omits authentication/session requirements and does not say how the job's results are retrieved.

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

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

Two sentences, front-loaded with the action and resource, no filler. The trailing 'watermark removal and local delivery' clause is slightly promotional but carries genuine behavioral information.

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

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

For an 8-parameter generation tool with no output schema and no annotations, the description explains what is produced but not what is returned (a job handle) or that it must be polled via get_flow_status before assets appear locally. That lifecycle gap is the main missing piece.

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 would be 3, but the description adds real semantics beyond the schema: it clarifies the prompt goes to Flow verbatim as the visual instruction (i.e. no model-side augmentation), which meaningfully affects how an agent should write the prompt.

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

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

The description names a specific verb and resource: 'Create a durable Google Flow IMAGE job' with 'still renders'. Capitalized IMAGE and 'still' separate it from the video-oriented siblings like generate_video and flow_browser_generate_video, though it never names that alternative outright.

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 only implied by the word IMAGE and by the aspect-ratio framing; there is no explicit 'use this for static images instead of generate_video' statement, no prerequisites (e.g. flow_browser_login/session) and no when-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?

No annotations are provided, so the description carries the full burden; it does disclose that jobs are durable and async by default, which is genuinely useful. However, it omits what the tool returns (job id), what permissions or Flow session state are required (despite flow_browser_login existing as a sibling), and what happens on failure. Several behavioral gaps remain for a task-submitting write 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?

Two sentences, zero filler, with the action and the async behavior both front-loaded before any nuance. Nothing here could be removed without losing information.

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

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

With 12 parameters, no annotations, and no output schema, the description needs to say more than it does. Most critically, it never mentions how to follow up on an async job (get_video_job, get_video_status, cancel_video_job all exist as siblings) or that output lands under outputs/<job-id>/. That omission leaves a real workflow gap for the 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?

Schema description coverage is 100%, so the schema already explains model, duration, negativePrompt, referenceImagePaths, and the deprecated outputPath. The description adds only the conceptual framing that the prompt is treated as a director brief, which enriches the meaning of the primary parameter. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("Create a durable Google Flow video job") plus the pipeline it triggers: director brief interpretation and prompt compilation. That is clearly distinct from list/status/delete siblings, but it never names how it differs from refine_video, regenerate_video, or flow_browser_generate_video, which an agent could plausibly confuse it with.

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 "processed asynchronously by default" implies when the immediate-return mode applies, and the schema's waitForCompletion default reinforces it, but the description never states when to pick this tool over refine_video, regenerate_video, or generate_image. Usage is only implied, not routed.

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 not state whether the operation is read-only, what status values may be returned, whether authentication is required, or how errors are handled. Only the word 'Get' and context of 'legacy bridge workflow record' hint at read 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 with no redundant or wasteful phrasing. Every word contributes to identifying the resource and 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?

With one required parameter, no output schema, and no annotations, the description provides the minimum viable context. It does not explain what a 'status' response includes or what 'legacy bridge' implies for behavior, leaving gaps that an agent might need to infer.

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

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

Schema description coverage is 100%, and the single parameter is fully documented in the schema as 'The execution/trigger ID from a previous trigger_flow call'. The description does not add 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 states a specific verb ('Get') and resource ('status of a legacy bridge workflow record'), making the tool's core function clear. It distinguishes itself from trigger_flow by focusing on status retrieval rather than launching a workflow.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like trigger_flow or list_flows. It implies usage after triggering a flow, but does not state prerequisites, exclusions, or which sibling to prefer in ambiguous cases.

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

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

No annotations, so the description carries the burden. It does disclose the full payload shape (state, timeline, output, QC), implying a non-mutating read, but says nothing about what happens when the job is missing/expired, whether 'durable' implies retention guarantees, 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?

One front-loaded sentence with zero filler; the verb and resource lead and the payload list follows. Nothing redundant.

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-param read tool with no output schema, listing the return fields is the right compensating move, and the schema fully documents the ID. The missing piece is disambiguation from the several sibling video-job 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?

Single parameter with 100% schema description coverage ('Video job ID returned by generate_video'), so the schema already does the work. The description adds no format or sourcing detail beyond what is in the schema; 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?

Specific verb + resource ('Get a durable video job') followed by an enumeration of what the payload contains (state, progress timeline, prompt compilation, output, QC result). However, it never distinguishes itself from the sibling get_video_status, which an agent could reasonably pick instead.

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

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

No guidance on when to use this versus get_video_status, list_video_jobs, or recover_video_job. The only implicit cue is the schema line saying jobId comes from generate_video, which is not in the description itself.

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

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

With no annotations, the description carries full behavioral burden. It discloses the two-tier lookup order (durable local jobs then legacy bridge), but omits critical traits like read-only safety, idempotency, what it returns, and error handling for missing jobs.

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

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

Two efficient sentences, with the compatibility alias fact front-loaded. No wasted words, though the second sentence is slightly implementation-focused at the expense of agent-relevant 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 status tool with no output schema, the description should explain what the agent gets back (e.g., job status, progress, success/failure). It provides the lookup strategy but leaves return values and error cases unspecified, creating a gap.

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

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

Schema coverage is 100% and the single parameter is already documented as coming from generate_video. The description adds no additional meaning about the requestId format or usage beyond what the schema provides, so the baseline score 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 states it is a compatibility alias for get_video_job and describes the lookup order, but it never explicitly says it retrieves video job status. The verb 'checks' is vague, and the core action is only implied by the tool name and alias relationship.

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

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

No explicit when-to-use guidance is given. It mentions being a compatibility alias and the internal lookup order, but does not say when to prefer this over get_video_job or under what conditions (e.g., legacy clients) it should be called.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' correctly signals a non-mutating operation, but it is silent on whether fetching marks the message as read in Gmail, what content format is returned (plain/HTML/headers/attachments), or any auth requirement — all traits an agent would want before calling.

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

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

One sentence, front-loaded with the verb and resource, zero filler. Nothing to trim and nothing essential buried.

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

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

For a one-parameter read tool with a fully documented schema and no output schema, the definition is nearly sufficient. The remaining gap is return-shape expectation: 'full content' hints at a body but doesn't say which fields come back, which matters somewhat absent 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?

Schema coverage is 100% and the single parameter is fully documented, including its provenance ('from gmail_search results'). The description's 'by its message ID' adds nothing beyond the schema, so the 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?

Specific verb+resource: 'Read the full content of an email', which clearly separates it from gmail_search (which finds messages) and gmail_send/gmail_reply (which write). The 'full content' vs. search-results distinction is useful, but it never names the sibling it complements, so differentiation is implied rather than stated.

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

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

'by its message ID' implies the prerequisite — you must already have an ID, presumably from gmail_search — but the description never states when to use this instead of, say, listing or searching. The usage pattern is inferable from the single required parameter, not from explicit 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 supplied, so the description carries the whole behavioral burden, and it discloses almost nothing: it does not say whether the reply is sent immediately or saved, whether it threads correctly, whether reply-all is supported, what permissions are needed, or what the call returns. For a mutation tool with zero annotation coverage this is a substantial 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?

A single front-loaded sentence with no filler or redundancy. It is efficiently sized, though the brevity reflects under-specification rather than disciplined trimming.

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 genuinely simple – two required string parameters, full schema coverage, no nested objects – so the description is close to sufficient for correct invocation. What is missing is post-call behavior (return value, threading effect), which is not covered by an output schema or 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 both parameters (messageId, body, including HTML support) are already documented and the baseline of 3 applies. The description adds no syntax or format detail, and the 'thread' wording versus the messageId parameter leaves a small ambiguity about whether a thread ID would also work.

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 pairs a specific verb ('Reply') with a specific resource ('an existing email thread'), which cleanly distinguishes it from siblings like gmail_send, gmail_read, and gmail_search by name alone. It doesn't explicitly name those alternatives, but the action is unambiguous.

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

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

There is no guidance on when to use this versus gmail_send for a new message, nor any stated prerequisites (must the thread exist, must the user be a participant, what happens if messageId belongs to a draft or a different account). The agent must infer the trigger conditions entirely.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about this being a read-only, non-mutating operation, whether results are paginated, how maxResults caps the return set, or what a result record contains. For a search tool with zero structured behavioral metadata, this is a meaningful 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?

A single short, front-loaded sentence with no filler. It is arguably too terse rather than bloated, but there is no wasted language.

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

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

For a two-parameter read tool with full schema coverage and no output schema, the basics are covered, but the definition omits the read-only nature, result shape, pagination, and how it relates to gmail_read — information an agent needs to pick and call 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% and the query parameter already carries an example with from/subject/after operators, so the schema does the heavy lifting. The description's reference to 'advanced query syntax (same as Gmail search bar)' adds a modest pointer but nothing about supported operators, quoting, or maxResults behavior.

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

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

The description gives a specific verb and resource ('Search Gmail') and points to the Gmail query language, so the purpose is immediately legible. It stops short of differentiating this from the sibling tool gmail_read, which also reads mail, leaving the agent to infer that one is query-based and the other is message-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?

There is no statement of when to use this instead of gmail_read, nor any prerequisite or exclusion. The only hint ('same as Gmail search bar') concerns syntax, not 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 the full behavioral burden and does not discharge it: it never says sending is an irreversible external side effect, whether the message lands in Sent, whether HTML in the body is rendered, or whether an authenticated Gmail session is a prerequisite (the presence of flow_browser_check_session siblings makes that a live question). Only 'via Gmail' gestures at the transport.

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 front-loaded sentence with zero waste: the action and transport come first, the optional-field note second. Nothing is repeated from the schema and no filler is present.

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 five-parameter send tool whose schema is fully annotated, the essentials are nearly covered. What remains missing is material for a side-effecting external action: confirmation/safety expectations, authentication prerequisites, and any indication of what a successful send returns now that there is no 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?

Schema description coverage is 100%, so all five parameters are already documented, including that CC/BCC take comma-separated lists and the body supports HTML. The description's mention of optional CC and BCC adds the useful nuance that only three fields are mandatory, but goes no further than the schema. 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 gives a specific verb and resource ('Send an email via Gmail'), which is enough to separate it from gmail_search, gmail_read and the Drive/Sheets/Docs siblings. It does not, however, distinguish it from gmail_reply, the other sibling that produces outgoing mail, so an agent must infer that reply is for threading onto an existing message.

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?

Nothing states when to use this instead of gmail_reply or when not to use it. The only usage signal is 'optional CC and BCC', which is a field note rather than guidance, so an agent has to reason about the alternative from the sibling names 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 exist, so the description carries the full burden. It does not disclose whether this is read-only (though 'List' implies it), whether results are paginated, ordered, or capped, or whether auth/session state is required — all relevant since sibling flow_browser_* tools depend on a login session. Only the scope/negative-differentiation fact is added.

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

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

Two short sentences, front-loaded with purpose, and the second sentence exists solely to prevent a concrete misidentification. Nothing is wasted.

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

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

For a zero-parameter list tool this covers purpose and scope disambiguation, but with no annotations and no output schema the agent still has no idea what fields records carry, how many come back, or whether results are paginated. A sentence on return shape or result size would close the remaining 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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. Notably, it also does not falsely imply any filtering inputs, which keeps expectations aligned with the empty schema.

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

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

States a specific verb+resource ("List legacy bridge workflow records") and immediately distinguishes it from the Google Flow/Veo siblings, which is the main confusion risk given names like list_videos and list_video_jobs. It stops short of saying what a 'legacy bridge workflow record' contains, but the intent 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?

The negative guidance ("not Google Flow/Veo projects") implicitly steers the agent away from using this for Flow/Veo listing, which is useful. But there is no positive when-to-use statement and no named alternative for the Flow/Veo case, leaving the agent to infer that list_videos or list_video_jobs is the right sibling.

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, so the description carries the full burden. It usefully discloses that results come from durable local job history rather than a remote source, but says nothing about ordering, whether completed/failed/cancelled jobs are included, retention window, or read-only nature. The disclosure of persistence location is real added value, but the behavioral picture is incomplete.

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

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

Two short sentences, front-loaded with the core action and followed by the disambiguating constraint. No filler and nothing buried.

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 annotations, no output schema, and an undocumented parameter, the description does the minimum: it establishes what the tool returns conceptually (local durable job records) but not the shape, ordering, or scope of that list. Adequate to identify the tool, thin for calling 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?

The single parameter 'limit' has 0% schema description coverage — the schema only supplies type, default, and min/max, not meaning. The description never mentions the parameter, so an agent must infer whether it caps returned rows or filters by job count, and gets no guidance on using values near the maximum of 100.

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

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

Specific verb + resource ('List recent durable video jobs') with an added scope qualifier ('local job history'). It distinguishes itself from remote Drive search, though it does not differentiate from the closest siblings list_videos or get_video_job.

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 clause 'not a remote Drive search' gives one exclusion, but the more likely confusion — choosing between this, list_videos, and get_video_job — is not addressed. Usage is implied rather than stated as a when/when-not rule.

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 says nothing about whether results are paginated, ordered, filtered by ownership, whether it requires Drive auth/scopes, or what happens when folderId is omitted beyond the schema's 'default: all Drive'. For a zero-annotation tool this is a substantial 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?

A single tight sentence with the resource front-loaded and no filler. It is efficient but arguably under-specified rather than deliberately 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 one-parameter read tool with a fully documented schema and no output schema, this is minimally adequate. The missing pieces are the differentiation from list_video_jobs and any note on result ordering or pagination, which an agent would need 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 coverage is 100% — folderId is documented as the Drive folder ID with a default of all Drive — so the schema already does the explanatory work. The description adds no further meaning about folderId (e.g., whether it recurses into subfolders), 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?

States a specific verb and resource (list generated videos) plus a source system (Google Drive), which is clearer than the title alone. However, it does not distinguish itself from the close sibling list_video_jobs, which also enumerates videos but presumably from a job queue rather than Drive — an agent could easily pick the wrong one.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of any alternative. With siblings like list_video_jobs, get_video_status, and drive_list present, the description leaves the routing decision entirely to inference.

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

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

With no annotations, the description carries the full behavioral burden and discloses important non-obvious behavior: it reattaches to the open Flow tab, retrieves an already-paid clip, removes the watermark, completes the job, and avoids new credit spend. It does not cover authentication/session prerequisites beyond the open tab, failure modes, idempotency, or what is returned after recovery.

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

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

The description is short, front-loaded with the recovery purpose, and every sentence contributes useful information. It efficiently covers the triggering condition, the internal actions, and the no-credit guarantee.

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 schema fully documents the only parameter and its allowed states, and the description explains the core recovery behavior. However, because there is no output schema and no annotations, the description should do more to explain what the tool returns or what happens on partial failure; 'completes the job' is not enough for an agent to understand the result.

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 single jobId parameter is already fully documented in the schema, including the relevant job states. The description adds no additional parameter semantics beyond what the schema provides, 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 names a specific operation and resource: recovering a video job whose generation finished but download failed or was interrupted. It also distinguishes the action from a new generation by stating that it never submits a new generation and spends no additional credits.

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

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

It gives a clear triggering condition: use this when a Flow generation has finished but the download failed or was interrupted. The schema further constrains jobId to DOWNLOAD_FAILED, RECOVERY_REQUIRED, GENERATED, or RETRIEVING states. It does not explicitly name regenerate_video or other siblings as alternatives, so the routing guidance is strong 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one useful trait — unrelated approved details are preserved — but says nothing about whether this is an asynchronous job submission, whether the response is a job ID requiring get_video_job/get_video_status polling, or what happens to the original job.

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 well-formed sentence with the key information front-loaded and no filler. It is efficient, though its brevity comes at the cost of the behavioral detail noted above.

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 job-creating mutation operation with no annotations, no output schema, and zero parameter documentation. An agent cannot tell from the description whether the call returns immediately with a job handle, how to monitor progress, or what the priority field does — meaningful gaps for this complexity level.

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

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

Schema description coverage is 0%, so the description must compensate. It maps loosely to jobId ('prior job') and directive ('creative directive'), but never explains the 3–4000 character constraint, the UUID format, or what the priority enum (LOW/NORMAL/HIGH) affects. Priority is entirely unexplained in both schema and 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?

States a specific verb and resource: 'Create a new version from a prior job using a targeted creative directive.' The clause 'while preserving unrelated approved details' implicitly distinguishes it from regenerate_video (full regeneration) and generate_video (from scratch), though it never names those siblings directly.

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 only implied: the agent can infer this is for targeted edits that keep other approved details intact. There is no explicit 'use this instead of regenerate_video when...' guidance and no stated prerequisites (e.g., the prior job must be completed).

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the call is asynchronous, whether it returns a new job ID, whether it consumes credits, or what happens if the prior job has no approved brief — all critical for a job-creating mutation.

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

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

A single front-loaded sentence with no padding. It is efficiently written, though its brevity reflects under-specification rather than disciplined editing.

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 job-creating tool with no annotations, no output schema, and zero parameter documentation, the description is far too thin. An agent cannot tell what it gets back (a job ID?), whether the call blocks, or what the 'approved brief' prerequisite means operationally.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not. It never mentions jobId or the priority enum; the only weak signal is the phrase 'prior job', which loosely implies an ID is required.

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 verb ('Create a new version') and resource ('a prior job') are stated, but 'new version' is ambiguous — it does not clarify whether this re-renders with the same brief or accepts new parameters, and it never distinguishes itself from close siblings like refine_video, generate_video, or recover_video_job.

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

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

There is no explicit when-to-use guidance and no named alternative. The phrase 'from its approved creative brief' hints at a precondition, but the agent is left to infer when to pick this over refine_video or generate_video.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies additive/non-destructive behavior. It does not disclose permission requirements, whether appending extends the range or requires the sheet to exist, how existing formatting or formulas are treated, or what the response contains. For a write operation with zero annotation coverage, this is a meaningful 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?

A single front-loaded sentence with no filler or redundancy. Every word (verb, direction, resource) contributes to identifying the tool.

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

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

The tool is structurally simple (3 required scalar/array params, no nesting, no output schema), and the description identifies the action adequately. However, with no annotations, it should have covered at least whether the append is destructive to existing data and what the agent needs before calling.

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 all three parameters documented in the schema (range format, 2D values array, spreadsheet ID). The description adds nothing beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (append) and resource (Google Sheets spreadsheet) with a clear scope qualifier ('rows to the end'). It implicitly distinguishes itself from sheets_write by emphasizing append-at-end semantics, but never names or contrasts with any sibling explicitly.

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

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

There is no guidance on when to use this instead of sheets_write or sheets_create, no mention of prerequisites (auth, sharing, whether the sheet/range must already exist), and no exclusions. The only usage signal is the word 'append' itself, which the agent must interpret on its own.

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

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

With no annotations, the description carries the full burden: it implies a mutating create but says nothing about required auth/scopes, default sharing state, or what is returned. Most critically, it never mentions that a spreadsheet ID is produced, which the agent needs to chain into sheets_write/sheets_append.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the terseness leaves the tool under-explained rather than over-explained.

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

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

For a simple two-parameter creation tool with fully described parameters, the description is minimally adequate. However, with no output schema and no annotations, it should disclose the returned identifier and any side effects to be complete for a mutating 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 both 'title' and 'sheetNames' are already documented in the schema. The description adds nothing 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 states a specific verb (Create) and resource (a new Google Sheets spreadsheet), which is unambiguous on its own. It does not explicitly contrast with siblings like sheets_read/sheets_write/sheets_append, but the naming and the 'new' qualifier make the distinction inferable.

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

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

There is no guidance on when to use this versus sheets_write or sheets_append, nor any prerequisites (e.g., that the spreadsheet must be created before writing to it). The agent must infer the workflow entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation but does not mention permissions, authentication needs, error behavior, or what data form is returned.

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

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

One concise, front-loaded sentence with no wasted words. However, it is arguably too minimal rather than fully structured for an agent-facing definition.

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

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

For a tool with no annotations and no output schema, the description should do more to explain return values or operational context. It identifies the action but leaves key behavioral and output details unstated.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional parameter meaning, which fits the baseline of 3 when schema coverage is high.

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

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

States a clear verb and resource: read data from a Google Sheets spreadsheet. It lets an agent distinguish read from sibling write/append/create tools, though it does not explicitly name alternatives.

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

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

Provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage is only implied by the name and verb.

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 behavioral burden. It usefully discloses the destructive overwrite behavior, which is key for avoiding data loss, but omits permission/auth requirements, rate limits, and return behavior for what is an unannotated 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 tight sentence with the destructive caveat front-loaded in parentheses. Every element earns its place, no filler.

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

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

For an unannotated mutation tool with no output schema, the overwrite disclosure covers the most important risk, but completeness is undermined by missing auth/permission context and response behavior.

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

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

Schema description coverage is 100%, so range (A1 notation), values (2D array), and spreadsheetId are fully documented in the schema. The description adds nothing beyond what the schema already conveys, which meets the baseline.

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

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

States a specific verb (write) and resource (Google Sheets spreadsheet) plus a scope qualifier (overwrites existing data in range). This implicitly distinguishes it from sheets_append, though it never names the sibling explicitly.

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

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

The '(overwrites existing data in range)' parenthetical hints that a non-destructive add operation exists elsewhere, implying sheets_append is the alternative, but no explicit when-to-use versus when-not guidance or prerequisites are stated.

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

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

With zero annotations, the description carries the full burden, and it discloses almost no behavioral traits. It doesn't say that triggering is a side-effecting, non-idempotent action, whether re-triggering the same name runs it twice, what auth is required, or what 'legacy bridge' implies operationally. The word 'legacy' hints at deprecation but is never cashed out.

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

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

Two sentences, both front-loaded and both earning their place: the first defines the action, the second prevents confusion with a large sibling family. No filler.

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

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

No annotations and no output schema, so the description should explain what a trigger returns — a workflow run id, a status object, or nothing until waitForCompletion — and it does not. For a side-effecting tool with a free-form inputs object, this leaves the agent unable to predict the response and plan follow-up calls like get_flow_status.

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

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

Schema description coverage is 100% and all three parameters are documented in the schema, so baseline 3 applies. The description echoes the schema ('by name with optional input parameters') without explaining the shape or valid keys of the free-form nested `inputs` object, which is the one genuinely ambiguous 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?

Specific verb ('Trigger') plus resource ('legacy bridge workflow record') and a name-based scope. The explicit 'This is not a Google Flow/Veo generation' distinguishes it from the many flow_*/generate_* siblings, though it doesn't clarify how it differs from create_flow or list_flows.

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 negative disambiguation against Veo/Flow video generation is genuinely useful given sibling names like generate_video and flow_browser_generate_video. But there is no positive guidance on when to prefer this over create_flow, list_flows, or get_flow_status, and no stated preconditions.

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

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

With no annotations, the description carries the full behavioral burden. It adds useful context by stating that credentials are not exposed during the check, but it does not clarify whether the operation is read-only, whether it requires authentication, or what side effects, if any, it may have.

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 lists the checked areas efficiently and adds the credential-safety note without waste.

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

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

For a zero-parameter diagnostic tool, the description covers what is checked and mentions credential safety. However, with no annotations and no output schema, it should say more about the expected response or whether the check is strictly read-only and needs authentication.

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 takes zero parameters, so there are no parameter semantics to explain. The schema is empty and description coverage is 100%, making baseline 4 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, 'Check,' and names three concrete resources: local video-job persistence, queue availability, and browser-session availability. It distinguishes the tool as a system health check rather than a job status or browser-session-only check, though it does not explicitly differentiate itself from sibling tools like flow_browser_check_session.

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 states what is checked but gives no guidance on when to use this tool versus alternatives such as flow_browser_check_session, get_video_status, or list_video_jobs. Usage is only implied by the diagnostic wording.

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