antigravity_delegate

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

With no annotations, the description carries the full burden and does well: async execution, task-ID return, edits confined to an independent clone of committed HEAD, no merge or push, and a warning that external output is untrusted. It omits permission requirements, timeout/expiry behavior, and what happens if the clone diverges, 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?

Five terse clauses, front-loaded with the action and return value, then the isolation guarantee and the security caveat. No filler sentences; every statement carries operational weight.

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 mutation-adjacent tool with no annotations and no output schema, the description supplies the critical async/clone/untrusted-output context but leaves the majority of parameters (mode, base, model, timeoutMs, contextFiles) unexplained. Adequate for invoking it, incomplete for tuning or predicting behavior.

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

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

Eight parameters with only 25% schema description coverage, and the description adds no per-parameter meaning at all. Schema-undocumented params like base, mode, model, timeoutMs, and contextFiles (including its 64-item cap) get no explanation or example from the description, so the coverage gap is not compensated.

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 concrete action (start an async delegate task) and states its key output (task ID), plus the workspace model: it edits an independent clone of committed HEAD with no merge/push. That distinguishes it from read-only siblings like ask/review. The phrase 'Start delegate' is slightly awkward, but the resource and effect are unambiguous.

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

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

'Poll status then result' implies the follow-up workflow using the antigravity_status and antigravity_result siblings, giving implied routing. However, it never explicitly names those tools, nor states when to prefer antigravity_ask or antigravity_review instead of delegating a mutation.

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