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

The description discloses the concrete side effect (the process tree is terminated) and, importantly, the partial-effect boundary: previously completed file changes remain for review. That is exactly the kind of context the annotations (readOnlyHint=false, destructiveHint=false) do not convey, and it is consistent with destructiveHint=false since no persisted work is lost.

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 its scope front-loaded and the preservation guarantee second. Nothing is redundant or 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 single-parameter mutation tool with no output schema, the description covers the essential behavior and its partial effects. It omits edge-case handling, such as what happens if the task id is unknown or the task has already completed, which is a minor 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?

Schema description coverage is 0% and the sole parameter, task_id, is never mentioned in the description. It does not say where the id comes from (e.g., gemini_list_agents or gemini_agent_status) or what format it takes, so the description leaves the only input undocumented.

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 ('Cancel') applied to a specific resource ('a queued or running task') with scope ('stop its active process tree'), which cleanly separates it from siblings like gemini_wait_agent, gemini_agent_status, and gemini_interrupt_agent. An agent can tell what this does without opening the schema.

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

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

The phrase 'queued or running task' implies the usage condition, but the description never states when to prefer this over the closely related gemini_interrupt_agent or what to do for tasks that already finished. Usage is inferable 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 establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely new context: tasks survive MCP reconnection, errors are structured with failure_reason, retryable, and error_id, and partial output is explicitly flagged as incomplete with recovery guidance. It stops short of describing status field values or how long completed tasks remain queryable.

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?

Dense and front-loaded — the read action and its payload come first, behavioral notes after. The final clause about recording the agent report and independently checking files is terse to the point of being slightly cryptic, but no sentence 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?

With no output schema and no annotation detail on returns, the description must describe what comes back, and it does: status, progress events, changed files, exit codes, structured error fields, and final report. The main remaining gap is the set of possible status values and how 'completed' differs from 'failed' 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?

One required parameter with 0% schema description coverage, so the description carries the burden. It conveys that the lookup is keyed to a durable task, which makes task_id largely self-explanatory, but it never states the id's origin (returned by gemini_spawn_agent / gemini_agent_submit) or the failure mode for an unknown 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 a well-scoped resource (durable task status), then enumerates the payload: progress events, changed files, exit codes, failure/final report. An agent can tell it is a status-reader rather than a spawner or interrupter, though it never names a sibling (e.g. gemini_wait_agent or gemini_list_agents) to sharpen the boundary.

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: you call it to poll a task by id, and the closing line hints at post-completion verification. There is no explicit statement of when to poll this versus gemini_wait_agent (blocking wait) or gemini_list_agents (discovery), so the agent must infer the routing.

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 only say destructive/openWorld/non-idempotent; the description adds substantial context beyond them — thinking-level selection per kind, default JSON-mode reads scoped to workspace, native_tools running with local user privileges and *not* tracking native effects, and command grants being exact executable + fixed args requiring review. That is exactly the privilege and side-effect disclosure an agent needs for a destructive, open-world 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?

Dense but front-loaded: purpose first, then permission constraints, then the return/polling contract. Every sentence carries behavioral information; the only friction is that the permission clauses are compressed into a single long sentence that is harder to scan than the rest.

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 behavior and privilege model are well covered for a destructive, no-output-schema tool, and the return contract (task ID + polling) is stated. However, for a six-parameter tool with a deep nested browser/checks/assertions block and a required workspace, the description leaves key inputs and their effects undocumented.

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 carry the load; it does explain kind (via thinking levels), permissions.write, native_tools, and the commands structure (id/executable/args semantics). But workspace, task, max_turns, idempotency_key, and the entire nested browser/checks/assertions structure are left 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?

Opens with a specific verb+resource: "Delegate an autonomous frontend/general/writing task," matching the kind enum exactly. It distinguishes the three task kinds via thinking levels, though it never contrasts itself with close siblings like gemini_spawn_agent or gemini_followup_task.

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

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

Gives clear conditional guidance: writes require write=true, native_tools=true requires write=true, and commands must be reviewed before granting. Also routes the agent to polling ("poll status for progress and results") rather than treating the call as synchronous. It falls short of naming alternatives such as gemini_wait_agent or gemini_agent_status.

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 annotations already declaring destructive=true and non-idempotent, the description adds useful behavioral detail: idle agents start a new run, running agents receive steering at the next boundary, and workspace/capabilities remain fixed. It still doesn't explain what 'destructive' means in practice or what permissions are required, but the annotations lower that burden.

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 core action, followed by conditional runtime behavior and scope constraints. Every sentence adds value with no wasted text.

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, open-world mutation tool with no output schema and zero schema descriptions, the description covers the central follow-up semantics but omits parameter details and the practical consequences of destruction. An agent can understand the intent but not the required invocation details.

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 must compensate, but it never defines 'target' or 'message'. The phrase 'same Gemini agent' hints that target identifies an agent and message is an instruction, but neither parameter's format, constraints, or semantics are clarified.

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

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

The description states a specific action ('Continue work') on a specific resource ('the same Gemini agent and retained context'). It distinguishes follow-up continuation from spawning a new agent, though it doesn't explicitly contrast with siblings like gemini_send_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?

It implies usage by describing the continuation scenario and how idle vs. running agents behave. However, it does not name alternatives or state when not to use this tool versus gemini_spawn_agent or gemini_send_message.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable context beyond that: it enumerates the specific live checks performed (executable, authentication, model listing, generation) and notes that unknown states are returned as null. It stops short of describing latency, auth requirements, or cost, but for a read-only probe this is informative.

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

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

The description is two short sentences with no wasted words, and the core purpose is front-loaded. The second sentence ('Unknown states are null') is a useful clarification but is terse to the point of being slightly cryptic. Still, the overall structure is efficient.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers what the probe checks and one aspect of return behavior (null for unknowns). However, it does not describe the shape of the result (e.g., whether it returns an object with fields for each check or a single status), which would help an agent interpret the response. Adequate but with a clear 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 no parameter semantics to explain. The description appropriately does not waste space on nonexistent inputs, and the schema is empty. Baseline 4 is appropriate for a zero-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?

The description names a specific action ('Explicit live provider probe') and enumerates what it checks: executable presence, authentication, model listing, and generation readiness. This distinguishes it from the sibling tools, which all perform agent operations rather than health checks. The only weakness is the compressed jargon 'READY generation,' which is less immediately clear than the rest.

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 alternatives, nor any mention of prerequisites or typical scenarios (e.g., before spawning agents, when diagnosing failures). The name 'gemini_health' implies a health check, but the description itself does not state when an agent should call it.

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=false and destructiveHint=false; the description adds genuinely useful context beyond them by saying context is retained and existing file changes persist. It stops short of describing in-flight behavior (e.g., whether a running tool call is aborted mid-execution or whether interruption is immediate).

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 action front-loaded and the consequential side-effects immediately after. Every clause earns its place.

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

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

With annotations present and no output schema, the description covers the safety and state consequences adequately. The unresolved identification of 'target' is the notable remaining gap for a single-parameter tool where that parameter is required.

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 'target' has 0% schema description coverage and no enum, and the description says nothing about it — whether it is an agent ID, name, or handle, or what format is accepted. With low coverage the description is expected to compensate, and it does not.

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

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

States a specific verb+resource ('Interrupt a Gemini agent') and the effect ('stop active work'), so the intent is unambiguous. It does not, however, differentiate itself from the sibling gemini_agent_cancel, which plausibly does something similar, leaving the agent to 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?

Usage is only implied: the note that the agent 'remains available for follow-up with retained context' hints that this is a soft stop rather than a teardown, which is the main selection cue. There is no explicit when-to-use/when-not or named alternative such as gemini_agent_cancel or gemini_wait_agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: retention across MCP reconnection and availability of earlier tasks and results, which an agent cannot derive from 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 sentences, front-loaded with the verb and resource, followed by the one behavioral fact that matters. Nothing is repeated from the annotations or schema.

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 parameters and no output schema, the description carries the return-shape burden and does so by listing the fields. Could be slightly stronger by noting ordering, pagination, or how it relates to per-agent status lookups.

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?

Zero parameters, so the baseline is 4. The description correctly implies a no-filter, full-listing call with no additional input needed.

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 retained Gemini agents') and enumerates the returned fields (names, stable IDs, status, messages, revisions, reports). It does not explicitly differentiate itself from the closely related sibling gemini_agent_status, which is the only missing piece.

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?

Implied usage comes from 'remain available for follow-up', suggesting this is the discovery step before messaging or follow-up. However, there is no explicit statement of when to call this versus gemini_agent_status or gemini_wait_agent, leaving the agent to infer.

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

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

The annotations already declare readOnly=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuine behavioral value by promising that specific token classes will not be altered during polishing, which is a constraint annotations cannot express. It stops short of describing the return value or latency, so it is additive but not rich.

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

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

A single front-loaded sentence with no wasted clauses; the preservation contract is packed into one list. It is efficient, though arguably undersized for a tool with four optional parameters that need explaining.

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?

There is no output schema and no explanation of how four optional parameters shape the result, so an agent cannot tell what it will get back or how to steer the polishing. For a five-parameter text-transformation tool, the definition leaves too much to guesswork.

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% across five parameters, and the description says nothing about 'style', 'language', 'instruction' or 'max_attempts'. Only the required 'text' parameter is loosely implied by 'expression'. With the schema fully silent, the description needed to compensate and does not.

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

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

The description pairs a specific verb ('polish') with a resource ('expression') and adds a concrete preservation contract: facts, numbers, names, URLs, paths, commands and identifiers. That contract distinguishes it meaningfully from gemini_rewrite, but the sibling is never named, so differentiation is implicit rather than explicit.

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 states when to use this tool rather than gemini_rewrite, nor when it is inappropriate. The preserve-list hints at the intended scope, but an agent is left to infer the trigger conditions from the name alone.

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

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

The readOnlyHint and destructiveHint=false annotations already establish that this is a safe review operation. The description adds useful context that the output is structured editorial feedback and not the factual authority, but it does not explain the return shape, variability, or why idempotentHint=false.

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 comparison purpose and then the authority caveat. There is no wasted text.

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

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

The tool has six parameters, no parameter descriptions, no output schema, and no sibling routing guidance. The description states the high-level purpose and return type in prose, but it is not complete enough to guide parameter use or selection versus adjacent gemini_* 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?

The description mentions original and revised prose, which maps loosely to the two required parameters. But with 0% schema description coverage across six parameters, it provides no meaning for style, language, instruction, or max_attempts, so it does not compensate for the schema gap.

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

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

The description states a specific action and resource: compare original and revised prose for fact drift and omissions. It is clearly distinct from rewrite/polish siblings, but it does not explicitly name an alternative or state sibling boundaries.

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 comparison-for-fact-drift purpose implies when to use the tool, and 'Codex remains the factual authority' hints at a boundary on reliance. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative such as gemini_polish or gemini_rewrite.

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, non-destructive, openWorld, non-idempotent. The description adds meaningful context — that factual and literal technical content are preserved and results should not be repeatedly polished — but says nothing about the surprising zh-CN language default, style behavior, or single-pass execution.

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 compact sentences with the purpose front-loaded and zero filler. It is well-structured; the low parameter coverage is a completeness issue rather than a verbosity one.

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?

A 5-parameter tool with 0% schema description coverage and no output schema needs the description to explain the controls, especially the non-obvious zh-CN language default and the instruction/attempt parameters. The description addresses none of these.

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% across 5 parameters, so the description must carry the load and does not. It never mentions style, language (default zh-CN), instruction, or max_attempts, leaving four parameters undocumented in both schema and prose.

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 (restructure) and resource (prose) plus the key invariant: facts and literal technical content are preserved. This distinguishes it conceptually from a generic polish pass, though it never names gemini_polish, which is the closest sibling.

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 the negative instruction 'Do not repeatedly polish the result,' which hints at a difference from gemini_polish without explaining when to choose this tool over it. No prerequisites, no exclusion conditions, no explicit routing to alternatives.

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

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

With annotations declaring destructiveHint=true and openWorldHint=true, the description adds substantial behavioral context about how messages are handled in JSON versus native mode, including stale action discarding and steering timing. Some phrases like 'native changes remain' are vague, but overall it provides more than structured fields alone.

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 purpose is front-loaded, but the middle sentences are dense with agent-mode jargon and some phrasing is confusing. Several clauses could be tightened without losing meaning, though the information is relevant.

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, open-world messaging tool with no output schema and 0% schema coverage, the description gives useful behavioral detail but omits explicit routing relative to siblings and leaves parameter meanings under-specified. It covers some behavioral complexity but not enough 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 0%, so the description must explain both parameters. It only vaguely characterizes target as 'named or identified Gemini agent' and says nothing about message format or constraints, leaving the parameters largely undocumented.

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 first sentence states a clear verb and resource: send a message to a named or identified Gemini agent. It is specific enough to know what the tool does, but it does not distinguish itself from similarly named siblings such as gemini_agent_submit or gemini_followup_task.

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

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

The description implies usage conditions through agent states — waiting agents resume, completed agents retain messages — but it never explicitly says when to choose this over alternative messaging tools or interrupt/cancel tools. Guidance is indirect and leaves the agent to infer the right context.

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

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

Adds real context beyond the annotations: fixed command grants carry local user privileges, native_tools requires write=true and is not an OS sandbox, native effects are untracked, and the final report must be independently verified. That is exactly the kind of risk disclosure a destructive, open-world tool needs. Not a 5 only because the durability/communication lifecycle (wait, interrupt, status) is left to siblings.

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?

Dense and front-loaded: identity/return value first, then idempotency, then the permission caveats. Nearly every sentence earns its place; the 'like Codex spawn_agent' comparison is the only 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?

There is no output schema, and the description does return the durable id, which is the key output. But for a tool with deeply nested permission objects (browser command_id, checks, assertions, commands array) and a destructive hint, the description does not tell the agent what the permission sub-objects do or what happens on failure. The phantom 'capabilities' parameter further weakens 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?

Schema description coverage is 0%, so the description must compensate. It clarifies task_name, message, workspace, idempotency_key, permissions.native_tools and the write prerequisite, which is useful. But it references a 'capabilities' parameter that does not exist in the schema, and leaves kind enum values, max_turns, permissions.commands and the whole permissions.browser checks structure unexplained.

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 ('Spawn a Gemini subagent') and adds the durable return id, which makes the effect concrete. The 'like Codex spawn_agent' analogy and the unqualified 'capabilities' term slightly muddy an otherwise clear statement, and it never names the sibling it contrasts with (gemini_send_message / gemini_followup_task).

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

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

Gives conditional usage advice for idempotency_key ('supply a stable idempotency_key to safely resubmit after an uncertain disconnect') and states the default kind. However, it never says when to spawn a new agent versus messaging or following up on an existing one, so the routing decision against siblings is left implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: it is a bounded wait, makes no provider requests or retries, and can stream MCP progress notifications while waiting. It does not state what the wait returns on timeout or completion, which keeps it from 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?

The description is dense and front-loaded: the observation scope comes first, then the incremental-event recipe, then the mode split, then the wait guarantees. It is appropriately sized for its complexity, though the second sentence is slightly overloaded.

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 async wait tool with five parameters and no output schema, the description covers modes, revision-based pagination, and wait guarantees, but leaves out targets and timeout semantics as well as any sense of the returned structure beyond 'messages and results'. It is adequate but incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It partially does: it explains after_revision, compact=true, and the two until modes. It does not explain targets or timeout_ms, leaving two of five parameters undocumented anywhere.

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 scope: observing agent execution, tool activity, timing, messages and results. This is clear enough to distinguish it from spawn/write/cancel siblings, but it never names an explicit alternative (e.g. gemini_agent_status) to sharpen the boundary.

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 guidance is strong within the tool: until=update vs until=attention is explained, and after_revision+compact is described for incremental events. However, there is no guidance on when to use this tool rather than gemini_agent_status or gemini_list_agents, which is the main sibling-selection gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and "write prose" does not contradict it (it generates text, it does not mutate data). The description adds genuinely useful behavior: output is derived from facts that must be independently verified before use. It does not mention that calls are non-idempotent (idempotentHint=false), so repeated calls may yield different prose, nor does it describe the response shape.

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

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

Three short, front-loaded sentences with no filler; the core purpose and the batching rule come first. The closing sentence is cryptic ("Codex" is an unexplained external reference) and spends a line on workflow advice rather than tool 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 5-parameter generative tool with no output schema and no parameter descriptions, the definition is too thin: an agent cannot know what style/language/instruction do or why max_attempts is pinned to 1. Only the purpose and a batching hint are conveyed.

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

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

All 5 parameters have 0% schema description coverage, so the description carries the full burden and largely fails: style, language (defaulting to zh-CN), instruction, and max_attempts (const 1) are never mentioned. "From authoritative facts" only loosely hints that `content` should be facts rather than prose, leaving the four optional parameters completely opaque.

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?

"Write prose from authoritative facts" gives a specific verb (write prose) plus a source constraint (authoritative facts), which separates it from gemini_polish and gemini_rewrite in spirit. However, it never explicitly names those siblings or states what a "writing unit" is, so differentiation is inferred 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?

"One call per writing unit" is a real usage constraint, and "Codex must check facts before final use" implies a verification workflow. But there is no explicit when-to-use/when-not guidance relative to gemini_polish, gemini_rewrite, or gemini_review, so the agent must guess which writing tool to pick.

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