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

Adds real context beyond the annotations: 'cooperative' signals the cancellation may not take effect immediately, 'already indexed files remain' bounds the destructiveness, and 'writes local job state only' scopes the write. This complements destructiveHint=false and readOnlyHint=false well, though it doesn't say how progress/completion of the cancellation is observed.

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

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

Three short sentences, front-loaded with the action, and every clause carries distinct information (mechanism, data safety, write scope). 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?

An output schema exists so return values need no explanation, and the description covers non-destructiveness and resumability for a mutation tool. The remaining gap is operational: no pointer to team_drive_job_status for confirming the job actually stopped.

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 required parameter job_id is never mentioned; schema coverage is 0% and the property carries no description. It is a self-evidently named identifier with type and length constraints visible in the schema, which keeps this at minimum-viable, but the description misses an easy win by not saying where a job_id comes from (e.g., team_drive_list or team_drive_job_status).

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: 'Request cooperative cancellation of an indexing job.' The phrase 'resume by refreshing' implicitly points at the team_drive_refresh sibling, but the tool is never contrasted explicitly with team_drive_job_status or team_drive_status, which an agent also has available for job tracking.

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

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

The description implies the usage flow (cancel, then refresh to resume) rather than stating when to choose this over team_drive_job_status or team_drive_status. There is no explicit when-not guidance or statement of prerequisites.

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

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

Adds real context beyond annotations: it writes to a local JSONL artifact (consistent with readOnlyHint=false) while not modifying the source (consistent with destructiveHint=false), and frames the output as deterministic. It does not mention idempotency behavior despite idempotentHint=false, which is a minor 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?

Three dense sentences with the core action front-loaded. The 'Check coverage and parser warnings first' clause is slightly terse but earns its place as a workflow hint.

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?

An output schema exists so return values need no explanation, and the description covers the source-safety and versioning constraints. It stops short of clarifying where the artifact lands or how repeated exports behave, which would round out a file-writing tool.

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

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

Schema coverage is 67% and both required params (file_id, expected_version) are documented in the schema. The description reinforces the versioning constraint via 'explicitly versioned file' but adds no syntax or format detail for the `format` constant. 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+resource: exports indexed segments of an explicitly versioned file into a local JSONL artifact. This distinguishes it from read/inspect by emphasizing 'all segments' and the versioned, deterministic nature. It does not name a sibling, so not 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?

"Check coverage and parser warnings first" implies using inspect/status before exporting, but the description does not name those tools or state when-not to use this one. Usage is implied rather than 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?

Annotations already declare the operation read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a meaningful behavioral caveat about official status and notes paging/offset/version inspection, but it does not explain return format or operational limits, so a 3 is appropriate.

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

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

Two sentences with no obvious filler; the official-status caveat is compact and useful. The first sentence is dense with jargon but still front-loads the core inspection 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?

With an output schema and strong read-only annotations, the description does not need to document return values. It still omits sibling routing and limit semantics, leaving the agent without full context for choosing and configuring the call.

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

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

Schema coverage is 67%: file_id and cursor are documented, while limit is not. The description's 'page through' wording loosely connects to pagination but does not explain limit semantics or add substantial meaning beyond the schema.

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

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

The description specifies actions such as verifying the current source hash and paging through indexed structure groups with segment offsets, format limitations, and version. However, it never directly names the team-drive resource or clearly distinguishes this inspection from siblings like team_drive_status or team_drive_read, so the purpose remains somewhat opaque.

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 guidance is the caveat that a recent modification time does not establish official status. There is no explicit when-to-use guidance, prerequisites, or comparison to alternatives, leaving the agent to infer that this tool is for official-status verification rather than status, read, or search calls.

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?

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered; the description adds a genuinely useful interpretive caveat that a completed scan can still contain failed or unsupported files. That non-obvious behavior (success status != clean result) is real added value beyond structured fields.

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

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

Two short sentences, front-loaded with the core action and followed by the one caveat that matters. Zero 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?

An output schema exists so return values need not be explained, and the description covers what data the tool surfaces plus the failure caveat. Minor gap: nothing about how to get a job_id or any pagination limits.

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

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

One optional parameter with 0% schema description coverage; the schema only gives type and maxLength. The description partially compensates by framing the parameter as 'specified' vs 'current', implying omission returns the current job, but gives no guidance on where to obtain a job_id.

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 resource (indexing job progress, coverage, failures), which is clearly distinct from siblings like team_drive_cancel or team_drive_list. It doesn't explicitly name a sibling or contrast, so not 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?

'Read current or specified indexing job progress' implies the job_id is optional and you get the current job when omitted, which is useful implied usage. But there is no explicit when-to-use/when-not guidance versus team_drive_status or team_drive_refresh.

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?

Annotations already declare read-only, idempotent, closed-world, so safety is covered. The description adds genuinely non-obvious behavior: the inventory includes unsupported and failed files, and complete results require paging through all pages rather than stopping at the first response. It does not mention any auth or rate-limit characteristics, but that is a minor gap given the annotation coverage.

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 what is enumerated and what it contains, followed by usage guidance. Dense but every clause carries information; 'scope manifest' and 'evidence use' are slightly domain-jargon-heavy but still interpretable.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a paginated enumeration tool the description doesn't tell the agent when to stop paging or how ordering behaves, and says nothing about the undocumented limit parameter, leaving a few practical gaps.

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

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

Schema coverage is 67%: cursor and prefix are documented in-schema, limit is not. The description says 'page through' but adds no detail on limit semantics, prefix scoping, or cursor handling beyond what the schema already states. Baseline 3 is appropriate.

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

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

States a specific verb and resource: paging through the indexed file inventory, and clarifies the scope by noting it includes unsupported and failed files. It distinguishes from inspection/read siblings implicitly by being a bulk enumeration, but doesn't explicitly contrast with team_drive_search, which is the closest overlapping 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?

Gives downstream guidance ('use all pages for a scope manifest; verify versions before evidence use') which implies bulk enumeration over spot lookup, but never names team_drive_search or any other sibling as the alternative for targeted retrieval. When-not-to-use this tool is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantive behavior: read is version-guarded via expected_version, pagination is cursor-based, and the caveat 'missing rows are not zero' warns about absent vs zero values. It does not say what happens when expected_version mismatches (error vs stale read), which is the main remaining 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?

Four dense sentences, front-loaded with the core action, then selector mapping, then continuation semantics. No filler, but the telegraphic style ('missing rows are not zero') costs a little readability for the information it carries.

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?

An output schema exists so return values need not be explained, and the description covers the two things that most affect correct invocation: selector-per-file-type and cursor/version continuity. Version-mismatch behavior and the limit parameter remain undefined, which is a modest but real gap for a versioned-read tool.

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

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

Schema coverage is 50% and the description compensates well for the selector object by mapping keys to file types (rows for CSV/TSV, sheet+rows for XLSX, page for PDF, slide for PPTX) and explaining that start indexes selected segments rather than absolute rows. However it refers to 'rows' where the schema exposes row_start/row_end, leaving the exact pairing ambiguous, and says nothing about limit.

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: reads a bounded segment page of a team-drive file, returning original locators and source version while verifying the current file. It is distinguishable from export/inspect by its paged-segment framing, though the phrasing ('original locators') is jargon-heavy and never names the resource type 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?

Gives continuation rules ('Continue with next_cursor and identical selector/expected_version') which is real procedural guidance, but never says when to choose this over team_drive_inspect, team_drive_export or team_drive_search. An agent must infer the boundary 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?

Annotations declare it is not read-only, not idempotent and not destructive; the description adds real context beyond that by saying it queues an asynchronous job, that source files remain read-only, and that completion must be polled via job_status. It does not say what happens if called repeatedly on the same drive (relevant given idempotentHint=false), so it falls short of a 5.

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, then the parameter caveat, then the safety and follow-up note. No sentence is 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?

An output schema exists, so return values need not be explained, and the async job/polling model is covered. The remaining gap is what a reindex job actually affects locally and what the caller should do with the job handle besides polling, but nothing critical to invoking it correctly is missing.

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

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

Schema coverage is 0%, so the description carries the burden for the single `force` parameter, and it does explain the specific conditions under which force should be set. It stops short of describing the default incremental behavior in mechanical terms (skipping unchanged files), so the semantics are clear but not complete.

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

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

The description opens with a specific verb and resource ('Queue a local inventory and incremental reindex job') and explicitly routes the agent to the sibling team_drive_job_status for polling, which is the most likely confusion point among the read-only 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?

It gives explicit conditions for the only parameter ('Use force only to retry unchanged failures or deliberately rebuild the index'), which is genuine when-to-use guidance. It does not state when to prefer this over sibling operations like team_drive_inspect or team_drive_list, leaving that 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description earns credit by disclosing a non-obvious trait: results are 'not authoritative or exhaustive business data', which changes how the agent should treat hits. Minor gap on result set size/pagination 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?

Two sentences, no filler, and the core capability is front-loaded before the trust caveat. Every sentence carries distinct 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 an output schema present, return values need no explanation, and cursor/prefix semantics live in the schema. For a 4-param search tool the description covers purpose, match semantics and the verify-before-answering rule; only result-volume and paging expectations are unaddressed.

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

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

Schema coverage is 50%: cursor and prefix are already documented in the schema, while query and limit are not. The description partially compensates by explaining what query matches (names, indexed keywords, short Chinese terms, configured aliases), but says nothing about limit or paging 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?

States a specific verb and resource ('Find candidate files') and scopes it to names plus indexed keyword content. It implicitly separates itself from team_drive_list/inspect by calling results 'candidate' files, but never names a sibling explicitly.

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

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

The closing clause 'inspect/read before answering' tells the agent this tool is a first-pass filter that must be followed by team_drive_inspect or team_drive_read. Clear context, but no explicit condition for choosing search over team_drive_list, and no guidance on when to use prefix vs query.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and a closed world, so the safety profile is covered. Beyond that, the description adds a genuinely useful caveat that counts reflect the last inventory rather than live business totals, warning the agent against treating results as real-time. It could go further by saying what refreshes that inventory.

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 substantive capability list front-loaded and the staleness caveat following as a qualifier. Nothing in it restates the name or title redundantly.

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 an output schema present, the description needn't document return values, and with no parameters the input side is trivially complete. What remains slightly thin is how the reported inventory gets refreshed, which matters given the sibling team_drive_refresh.

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 disambiguate; baseline 4 applies. The description correctly spends no space on inputs and focuses on what the call yields.

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 (check) and enumerates the concrete things returned: index coverage, current jobs, supported formats, configured limits. That is far more informative than the title's tautology. It does not, however, distinguish itself from team_drive_job_status, which plausibly covers the 'current jobs' portion, leaving overlap unresolved.

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 list of reported items implies a health/diagnostics use case, but there is no explicit statement of when to call this versus team_drive_job_status or when to follow up with team_drive_refresh. Usage must be inferred from the reported fields rather than stated.

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