antigravity_review

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

With no annotations, the description carries the full burden and discloses several non-obvious traits: the operation is asynchronous and returns a task ID, it is not truly read-only (nonempty diff needs allowSnapshotWrites consent), and external output is untrusted. It omits auth/permission requirements and failure behavior, which keeps it 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?

Four dense, front-loaded fragments with no filler and the async/return behavior stated first. The telegraphic phrasing trades some readability for compactness, but nothing is wasted.

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

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

For an 8-parameter, annotation-free tool with no output schema, the description covers the async workflow, the consent gating, and the untrusted-output warning, which is the important behavioral context. It is still incomplete on several parameter meanings and on what the eventual result contains.

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

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

Schema coverage is only 25% across 8 parameters, so the description must compensate but largely does not. It clarifies the consent condition tied to allowSnapshotWrites (which the schema already partly documents) and implies mode=base, but base, model, prompt, timeoutMs, contextFiles, and cwd remain undocumented in both places.

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?

"Start review asynchronously; returns task ID" gives a specific verb, resource, and outcome, and the reference to polling status and result differentiates it from the status/result/cancel siblings. It is clear what the tool does, though it does not explicitly contrast itself with antigravity_ask or antigravity_delegate.

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?

"Poll status then result" implies the follow-up workflow and the consent condition hints at a usage prerequisite, but there is no explicit statement of when to choose this over antigravity_ask or antigravity_delegate. Usage is implied rather than stated.

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