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 the reviewer is a different model family with an adversarial posture, which is real behavioral context. It omits cost/latency implications of an external model call, any prerequisite such as resolving the model ID via list_models, and what the response looks like.

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, with the unique value (different model family) and the recommended usage front-loaded. 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?

For a 6-parameter tool with zero required fields and no output schema, the description leaves the agent guessing about input mode selection (inline content vs files) and the shape of the returned review. The core value proposition is well covered, but operational completeness is only adequate.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description adds essentially no parameter-level detail. It never clarifies that 'files' and 'content' are alternative inputs or that 'focus' narrows the critique, even though those are the choices an agent must make.

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 ('adversarial second opinion from a different model family (Gemini Pro)') and characterizes the output as flaw/edge-case/security hunting, which clearly separates it from siblings like analyze_files or deep_search. An agent can tell what this tool uniquely produces.

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

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

Explicitly prescribes contexts ('ALWAYS use this for plan critiques, design reviews, and pre-merge code review'), which is strong positive routing. It stops short of naming alternatives — e.g. when plain analyze_files suffices instead — so the agent has no explicit when-not guidance.

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

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

With no annotations, the description carries the full burden, and it discloses the most consequential trait: the files never enter the caller's context, only the answer does, which implies cost and context implications. It omits prerequisites (CLI availability/auth), latency expectations, and what happens on failure.

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 tight sentences, front-loaded with the action, then the trigger conditions, then the payoff. Nothing redundant and no repetition of schema content.

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

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

For a tool with no annotations and no output schema, the description covers purpose, triggers and the key result-shape property ('only the answer does'). Remaining gaps are modest: model/effort selection guidance and error behavior, but an agent could call it competently as written.

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 files, cwd, question, model and effort are already documented in structured form; the description adds no syntax or selection guidance for them. Baseline 3 applies. It also doesn't hint that model IDs come from list_models, a sibling that exists precisely for that.

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

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

The first sentence names a specific action and mechanism: delegate file analysis to the Antigravity CLI (Gemini), plus the explicit contrast with 'reading files yourself'. It is clear what the tool does, but it never distinguishes itself from the 'delegate' sibling, which plausibly overlaps in purpose.

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

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

Gives hard, checkable thresholds ('>200 lines' or 'more than 3 files') plus a task taxonomy (logs, database dumps, generated code, cross-file reviews, comparisons). An agent can decide on invocation without inferring anything.

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 meet it. It says nothing about whether cancellation is graceful or immediate, whether it is reversible, what happens to partial work, whether ownership/permission is required, or what the call returns.

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, which is structurally sound. It is arguably too terse for a mutation operation, but nothing in it is wasted 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 destructive-ish mutation tool with no annotations, no output schema, and an undocumented required parameter, the description leaves the agent without the information needed to call it safely or interpret 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 0% for the single parameter task_id, and the description adds no meaning: it doesn't say where the ID comes from (presumably the return of start_task), the expected format, or what happens with an unknown/already-finished 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 (cancel) and resource (a running Antigravity task), which distinguishes it cleanly from start_task and task_status in the sibling set. The only gap is that it doesn't explicitly name those siblings as the 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?

The word "running" implies a state precondition (the task must still be in flight), but there is no explicit when-to-use/when-not-to-use guidance or reference to the alternatives (task_status to check state, start_task to relaunch). Usage is inferable 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?

No annotations, so the description carries the full load. It does add real behavioral context that the name alone doesn't: work is delegated to an external CLI, it is context-saving, and the schema hints at model/effort tuning. But it says nothing about whether the call is read-only, expected latency, cost, or what happens on failure — meaningful gaps for a delegated agentic search.

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 of dense, front-loaded fragments with zero filler; the imperative selection cue sits at the end where it reads as the takeaway. 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?

There is no output schema, so the description should signal what comes back; "saves your context" only hints at a condensed report rather than stating the return shape (findings prose, citations, code excerpts). For a 4-param delegation tool with no annotations, the when-to-use story is solid but the result and cost profile are underspecified.

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

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

Schema description coverage is 100%, so the schema already documents cwd, model, query, and effort with examples and an enum. The description adds example query phrasings that clarify intent but no format, syntax, or defaulting details beyond what the schema states. 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 ("delegate") plus a concrete resource and scope: git log/diff/blame, wide greps, and historical 'when/why did X change' questions. An agent can picture the exact class of task it handles. It stops short of naming how it differs from the closest sibling (analyze_files), leaving that boundary to inference.

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?

"USE THIS instead of running many search commands yourself" gives an explicit positive selection rule with a stated rationale (context savings), and the quoted example queries model the intended input shape. No when-not-to-use case or exclusion relative to a specific sibling is given.

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

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

With no annotations, the description carries the full burden, and it does disclose a meaningful trait: agy has shell, file-read and web access inside the given cwd, which signals risk. However it omits whether the call blocks or returns a handle (siblings like start_task/task_status suggest an async pattern), what the result looks like, and any timeout or cost 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, front-loaded with the core purpose and followed by the capability disclosure. 'Raw delegation' is slightly jargon-y but no sentence 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?

No output schema and no annotations, so the description should explain the return/blocking behavior of a tool that spins up a fully tool-enabled agent. It covers capability scope but leaves the execution model and result shape unstated, which is a real gap for a tool of this complexity.

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

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

Schema description coverage is 100%, so cwd, model, effort and prompt are all documented at the schema level. The description only adds 'in the given cwd', which is redundant with the cwd parameter's own text, 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 concrete verb+resource: raw delegation to the Antigravity CLI, with scope ('heavy tasks that don't fit the other tools') and the agent's capabilities. It distinguishes itself from the narrower siblings generically rather than naming them, so it stops 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?

'For heavy tasks that don't fit the other tools' gives an implied selection rule, but it never says when to prefer delegate over start_task/task_status or what 'doesn't fit' actually means. An agent must infer the boundary 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 the full burden. It usefully discloses the key behavioral trait that prior context lives server-side and need not be resent, but says nothing about whether the follow-up mutates the session, how cwd/model/effort interact with an existing session, 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?

Two tight sentences with the core mechanic front-loaded and the practical implication (no need to resend context) second. Nothing is wasted 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 five-parameter tool with no annotations and no output schema, the description covers the central mechanic but leaves the session-mutation behavior and return value unexplained. An agent knows when to call it but not how overriding model/effort or cwd affects an existing session.

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, which sets the baseline at 3. The description only reinforces the session_id parameter and adds no guidance on whether model/effort/cwd can or should be overridden in a follow-up.

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 (continue a prior Antigravity session by session_id) and frames the tool as the follow-up counterpart to an initial delegation, which lets an agent separate it from delegate/start_task. It stops short of naming the sibling to use for the first call, so the differentiation is implied 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?

"USE THIS for follow-up questions about a prior delegation" gives a clear triggering condition and implicitly excludes first-time delegation. There is no explicit statement of prerequisites (that a session_id from a prior call must already exist) or of what to do instead when there is no prior session.

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. "Live" and "authenticated" are the only behavioral hints; it does not say whether this is a safe read, whether results are cached, what the authentication prerequisite entails, or whether calling it has side effects or rate 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 front-loaded sentence with no filler; the resource and provenance are established immediately. It is minimal but not 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?

This is a simple read tool with one optional boolean and no output schema, so the description is close to sufficient. However, the meaning of `refresh` and a hint at the return shape (list of model identifiers) are missing, leaving a real gap for an agent deciding how to call it.

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

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

Schema coverage is 0% and the single parameter `refresh` is never mentioned in the description, so an agent cannot tell whether it forces a cache bypass, re-authentication, or re-fetch. The description fails to compensate for the undocumented 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?

States a specific verb ("List") and resource ("live model directory") plus the source system ("Antigravity CLI"), which is unambiguous against siblings like deep_search or web_lookup. It does not need sibling routing since no other tool lists models, but it also does not explicitly say so.

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 indication of when an agent should call this versus another discovery path, and no guidance on when the `refresh` flag matters. "authenticated" hints at a prerequisite but the description never states what that requires or how to satisfy 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?

With no annotations, the description carries the full burden. It usefully discloses the asynchronous, long-running nature and the lifecycle (poll/stop), but says nothing about whether a task identifier is returned, cost/latency implications, permission needs, or the effect of omitting model/effort.

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

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

Two short, front-loaded sentences with no wasted words; the purpose comes before the sibling routing. It is efficient rather than padded, though the brevity is part of why other dimensions suffer.

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 no-annotation, no-output-schema, 0%-param-coverage async mutation tool needs more than two sentences. Missing what gets started, what comes back, and how the four parameters affect execution leaves an agent under-equipped to call it correctly.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate, and it mentions none of them. The meaning of prompt, cwd, model, and effort (including the enum's cost/quality tradeoff) is left entirely 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+resource ('Start a long-running task') and names the two lifecycle siblings (task_status, cancel_task), which distinguishes it from them. It doesn't clarify what kind of task or how it differs from delegate or deep_search, so it stops short of full sibling differentiation.

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

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

Explicitly routes the agent to task_status for polling and cancel_task for stopping, which is real usage guidance. However, it gives no condition for choosing start_task over delegate or deep_search, and no prerequisites or 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 behavioral burden. It implies read-only but says nothing about whether the call blocks, what state values can be returned, whether the result field is absent while the task is still running, or what happens with an unknown/expired task_id.

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 sentence with no filler, and the core action is front-loaded. However, its brevity is under-specification rather than efficiency, given the behavioral gaps.

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 required parameter, the definition is too thin. The description should at minimum explain the task state/result relationship, polling expectations, and the source of task_id.

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 task_id has 0% schema description coverage, and the description does not compensate by stating that it is the identifier returned by start_task or its expected format. The one param that matters most for correct invocation is 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 description pairs a specific verb ("Read") with a specific resource ("task state and final result"), so an agent knows it is a status/result retrieval operation. It never explicitly names how it differs from start_task or cancel_task, so differentiation is left to the tool name.

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 call this versus start_task or cancel_task, and no mention of the typical pattern (call start_task, then poll this with the returned id). The usage is only inferable from the name and description.

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

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

With no annotations, the description must carry behavioral weight; it usefully discloses that the work is delegated to an external CLI agent with web access, implying nondeterminism and network dependency. It says nothing about latency, cost, failure modes, or whether the agent can execute code rather than just read, which matters for a delegated-agent 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?

Two dense sentences: the first establishes the mechanism and scope, the second front-loads the selection condition with an explicit "USE THIS". No filler or repetition.

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

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

For a four-parameter, single-required-field tool with a fully described schema, the description covers what the tool does and when to reach for it. The only gap is the shape of the response (free-text answer vs. structured citations), which is unstated and there is no output schema to cover 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%, so every parameter (query, cwd, model, effort) is already documented in the schema. The description adds no interpretation of these fields, 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 names a specific action (delegate a web/documentation lookup) and the concrete mechanism (Antigravity CLI / Gemini with web access), plus example use cases like library docs, API references, and current versions. It stops short of explicitly distinguishing itself from siblings such as deep_search or delegate, so an agent must infer which lookup path applies.

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?

"USE THIS when you need information you don't have or that may be newer than your training data" gives a clear trigger condition tied to knowledge gaps or recency. There is no statement of when *not* to use it and no named alternative among the sibling tools, so routing against deep_search remains ambiguous.

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