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 useful traits: async execution, a returned task ID, isolation in a fresh scratch directory, limited context, and untrusted external output. It stops short of permissions, timeouts, or whether the source directory can be mutated (relevant given allowSnapshotWrites).

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?

Terse, front-loaded fragments with no filler; the async/return fact leads and the safety note closes. Efficient for the amount of information conveyed.

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 tool with low schema coverage and no annotations or output schema, the description is too thin: it omits most parameter meanings, any timing/timeout expectations, and how the eventual result is retrieved beyond a bare pointer to polling.

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 only 25% across 8 parameters, so the description should compensate. It hints at contextFiles ('selected context only') and cwd isolation ('fresh scratch directory'), but leaves base, mode, model, and timeoutMs unexplained, so most parameters remain 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 clear verb+resource ('Start ask asynchronously') and adds scope detail ('fresh scratch directory; selected context only') and a return value ('returns task ID'). However, it does not distinguish this from close siblings like antigravity_delegate or antigravity_review, leaving the agent to infer which one to pick.

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 a follow-up workflow using the sibling antigravity_status/antigravity_result tools, which is helpful. But it never states when to choose this tool versus delegate/review, nor any preconditions or exclusions.

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, so the safety profile is partly covered. The description adds that in-memory results are released while the workspace is preserved, which is genuinely useful behavioral context, but it is garbled and omits state/idempotency details. No annotation contradiction.

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?

Very short and front-loaded, which is good, but the second sentence is ambiguous and poorly worded ('Forget releases in-memory results, preserves workspace'), so not every sentence cleanly 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 mutating, single-parameter tool with no output schema, the description leaves the agent without taskId semantics, the resulting task state, or idempotency behavior. It is under-specified relative to the tool's 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?

There is one required parameter (taskId) with 0% schema description coverage, and the description says nothing about what taskId is or where it comes from. The description fails to 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?

States a specific verb+resource ('cancel a task') scoped to 'this MCP server session', which is clear enough to distinguish from most siblings. The sideline reference to 'Forget' muddies it slightly, but the core purpose is legible.

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 explicit when-to-use or when-not-to-use guidance, and no condition that selects this over antigravity_forget or antigravity_status. The second sentence hints at a relationship with forget but never states when one should be preferred.

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 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.

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

With no annotations, the description carries the full disclosure burden, and it delivers two meaningful traits: probeAuth performs a real call that 'may incur usage' (a cost/side-effect warning), and the explicit anti-pattern 'Never infer auth from config directories'. It still omits whether the inspection itself is read-only or what it returns, so it is not fully complete.

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 with zero filler; the primary purpose is front-loaded, followed by the parameter cost caveat and the methodology warning in priority order.

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 one-parameter diagnostic tool with no output schema, the description covers what it does and the main behavioral risk. It could add whether the command is non-destructive and roughly what it reports, but nothing critical to correct invocation 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 must explain the single parameter, and it does: probeAuth 'sends a small real prompt and may incur usage'. That conveys the semantics and the cost implication the bare boolean type could not. Minor gap: no mention of the default when omitted.

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 (Inspect) and resource (installed agent CLI/version/help), which is a diagnostic intent clearly distinct from the ask/delegate/review/status siblings. It does not explicitly name an alternative, so it falls short of the 5 bar.

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 implied (run this to inspect the installed CLI) but there is no explicit when-to-use/when-not framing or named sibling for comparison. The probeAuth caveat gives conditional guidance for that parameter, not for choosing the tool.

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, and the description adds real context beyond them: what is released (in-memory results) versus what survives (workspace). This tells the agent the operation mutates session state without destroying persisted work, which is exactly the kind of detail annotations cannot convey. It still omits reversibility of the forget action.

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 with the core action front-loaded and the effect detail second; there is no filler. The phrasing is slightly clipped and the second sentence could be tighter, 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 a one-parameter session-mutation tool with no output schema, the description covers the main effect but omits how to obtain taskId, whether forgetting is reversible, and what happens on an unknown id. Minimum viable but with clear 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 description coverage is 0% for the single taskId parameter, and the description never explains where taskId comes from or what form it takes (presumably returned by antigravity_delegate/antigravity_ask). A single undocumented parameter leaves the agent guessing about how to supply the required argument.

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 pair (forget a task) scoped to the MCP server session, which is concrete and actionable. It does not distinguish itself from the closest sibling, antigravity_cancel, so an agent cannot tell from the description alone which of the two is appropriate.

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 when-to-use or when-not-to-use guidance, and no mention of alternatives such as antigravity_cancel. The only usage signal is implicit in the effect statement 'releases in-memory results, preserves workspace,' which hints at intent but does not route the 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 destructiveHint=false, setting a low bar. The phrase "preserves workspace" adds a modest behavioral claim beyond the annotations, but the surrounding sentence is incoherent and it is unclear what state is touched or returned.

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?

Brief, but the size comes from under-specification rather than economy. The first sentence is not front-loaded with a clear action and the second sentence's meaning is ambiguous, so neither sentence 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 no output schema and no annotations covering return values, the description should explain what a "result" actually is, yet it does not. For a session-scoped tool sitting among seven siblings, this leaves an agent unable to know when or how to invoke 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?

There is one parameter (taskId) with 0% schema description coverage, so the description must compensate and it does not explain what a taskId is, where to obtain it, or whether the task must have been started in the current session. The parameter is effectively 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?

"result a task in this MCP server session" is grammatically broken and never states a clear verb+resource (retrieve? submit? finalize?). An agent cannot confidently tell whether this fetches a task's output or produces a result, and it is not clearly distinguished from siblings like antigravity_status or antigravity_forget.

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 second sentence gestures at a distinction from a forget-style operation ("Forget releases in-memory results"), but it is garbled enough that no reliable when-to-use rule can be extracted. No explicit conditions, prerequisites, or named alternatives are 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 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.

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

Annotations declare readOnlyHint=true and destructiveHint=false, yet the description states that it "[f]orgets/releases in-memory results" — a state mutation — which conflicts with a read-only profile. The definition also never says what is returned (task status payload, terminal vs pending states, etc.), so an agent cannot rely on it for 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?

It is short, but the second sentence appears to be unrelated/leftover text about forgetting and releasing results, which wastes space and confuses rather than front-loading the core action. Two sentences exist but one of them does not earn 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 one required parameter, no output schema, and annotations that are contradicted by the text, the description leaves the agent without the information needed to call the tool correctly or interpret it. It should at minimum state what status is returned and how taskId is obtained.

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?

taskId has 0% schema description coverage and no inline description, so the description must compensate; it only implies the parameter identifies "a task" in the session without stating the format, where the ID comes from, or how workspace scope interacts with it.

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 phrase "status a task in this MCP server session" gestures at a verb (status) and resource (task) but never says concretely whether it fetches, sets, or reports task status, and it is not distinguished from the sibling antigravity_result. The second sentence then describes forgetting/releasing behavior, which muddies the purpose further.

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 when-to-use or when-not-to-use guidance, and no alternative sibling is named. The clause "preserves workspace" vaguely gestures at a contrast with antigravity_forget, but the agent is not told the condition under which this tool should be selected over result, review, or cancel.

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