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

No annotations are provided, so the description carries the full burden. It discloses what the tool reports (versions, paths, models, thinking levels) and implies a read-only operation via 'inspect', but it does not explicitly state that it is read-only, mention potential errors, or clarify whether it requires network access. For a status tool, this is adequate but not comprehensive.

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 with no filler. The first sentence states the core purpose and scope, and the second enumerates the specific data reported. The most critical information is front-loaded.

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 zero-parameter tool with no output schema, the description provides a clear list of what the status report contains. It does not detail the structure of the return value (e.g., JSON format), but for a simple inspection tool this is sufficient. The only missing piece is an explicit note about side effects or prerequisites, which is minor here.

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 are zero parameters, so the baseline is 4. The description correctly implies that no arguments are needed, and it adds value by describing the output content, which compensates for the lack of an output schema.

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 uses a specific verb ('Inspect') and resource ('status of all supported CLI coding agents'), and enumerates the exact agents covered (Claude Code, Antigravity, Codex, Cursor). This clearly distinguishes it from the sibling tools that handle task delegation, sessions, and diffs.

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: call this when you need to check installed versions, paths, models, or thinking levels of coding agents. It does not explicitly state when not to use it or name alternatives, but the context of the siblings makes the purpose unambiguous. A small gap is the absence of explicit routing 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 burden of behavioral disclosure. It only claims 'fast stateless,' which implies no persistence but does not mention side effects, authentication requirements, rate limits, or return format. For a tool that likely invokes an external AI service, this is a significant gap.

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 extremely short, which is concise, but it is under-specified rather than efficiently informative. The legacy alias note is arguably metadata rather than usage guidance. It is not front-loaded with actionable information; it merely states a vague capability.

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 4 parameters (1 required), no output schema, and no annotations, the description is grossly incomplete. It does not explain what the inquiry returns, how long it might take, or any prerequisites. An agent cannot reliably invoke this tool correctly with only this information.

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% (only 'prompt' has a description), and the tool description adds nothing about model, workspace_dir, or timeout_seconds. It does not compensate for the undocumented parameters or explain their roles or interactions. The agent is left to guess the meaning of these fields.

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 'Fast stateless inquiry with Google Antigravity' but does not specify a clear verb-resource pair or what kind of inquiry (e.g., question answering, diagnostics). It only references being a legacy alias for delegate_ask, which hints at purpose but does not differentiate from siblings like agy_chat or agy_plan. It is not a tautology, but it is vague and fails to convey a concrete action.

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 use this tool versus alternatives. The legacy alias note is not usage guidance. Sibling tools such as delegate_ask, agy_chat, and agy_task are not mentioned, so the agent has no basis for selecting this tool over others.

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 provided, the description carries the full burden of behavioral disclosure. It mentions preserving context and memory, but fails to disclose that the tool may execute actions requiring permissions (evident from the 'dangerously_skip_permissions' parameter), potential side effects, or what happens on failure. The description is too vague about the tool's actual behavior beyond state preservation.

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 a single sentence that front-loads the purpose and includes essential behavioral hints (preserving context). There is no fluff or redundant content. It is appropriately concise for a tool whose parameters are fully documented in the 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?

Given the tool has 7 parameters, no output schema, and no annotations, the description is insufficient. It does not explain when to use this versus siblings, does not mention that the tool may perform actions requiring permissions (implied by the 'dangerously_skip_permissions' parameter), and does not describe what the response looks like. The one-sentence description leaves critical operational context unexplained.

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 schema description coverage is 100%, so all parameters are already documented. The description adds only the notion of 'using the conversation ID,' which is redundant with the schema's parameter description. It does not provide additional format, constraints, or context for parameters, so it stays at the baseline of 3.

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 uses the specific verb 'continue' and identifies the resource as 'a multi-turn conversation with Google Antigravity.' This clearly distinguishes the tool from siblings like agy_run_task or agy_plan, which presumably start new tasks or plans. The mention of preserving context, memory, and changes further clarifies its role.

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 when you have an existing conversation (mentions 'previous turns' and 'conversation ID'), providing a clear context. However, it does not explicitly state when NOT to use this tool or name alternatives (e.g., agy_run_task for new tasks). The guidance is implied 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?

No annotations are provided, so the description must fully disclose behavior. It only says 'Inspect', which hints at read-only operation but does not explicitly state that no modifications are made, nor does it mention any side effects, required permissions, or output format. The description is minimal and does not provide sufficient behavioral disclosure for a tool with zero annotation coverage.

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 exceptionally concise: one sentence with a leading alias note. It front-loads the most important routing information (alias) and then states the action. Every word is purposeful, with no fluff or redundancy. It is an exemplar of efficient, structured writing.

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 one optional parameter and no output schema or annotations, the description provides the core purpose but omits details like return value format, how to specify the workspace directory, and any prerequisites. However, because it is an alias for delegate_diff, the agent can refer to that sibling for full behavior. It is adequate but not fully complete, leaving the agent to infer details from the sibling or context.

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 input schema has one parameter (workspace_dir) with no description (0% coverage). The description does not explicitly mention the parameter, but the phrase 'in the target workspace' implies that workspace_dir specifies the target workspace. This is an implicit connection, but it does not add clear semantics such as expected format (e.g., path) or whether it is required. The description fails to compensate for the schema's lack of parameter documentation.

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 clearly states the tool's purpose: 'Inspect git status and diff patch in the target workspace.' It uses a specific verb ('Inspect') and identifies the resource ('git status and diff patch'), and it explicitly notes it is a legacy alias for delegate_diff, which differentiates it from sibling tools. The purpose is unambiguous and distinct.

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 opens with '[Legacy Alias -> delegate_diff]', which directly tells the agent that the canonical tool is delegate_diff and this is a legacy alias. This implies the agent should prefer delegate_diff, but it does not explicitly state when to use this tool vs. alternatives beyond the alias. It provides clear context for routing, though it lacks explicit conditional 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states 'List all AI models' with no mention of side effects, permissions, output format, or potential variability (e.g., whether results are sorted, include deprecated models). For a read operation the risk is low, but the description gives no additional behavioral context beyond the literal 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?

The description is a single sentence that front-loads the action and scope. It includes examples to make the purpose concrete without extra verbosity. Every word 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 parameterless listing tool with no output schema, the description provides a clear purpose and examples of expected output. It could explicitly state the return format (e.g., an array of model names), but the examples strongly imply this. Given the tool's simplicity, this is 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?

The tool has zero parameters, and the schema is an empty object (100% coverage). The description doesn't need to explain any parameters, so the baseline of 4 is appropriate.

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 clearly states the action ('List'), the resource ('all AI models'), and the scope ('available to the Antigravity CLI runtime'). It also provides concrete examples of models, which removes ambiguity. This is distinct from all sibling tools, none of which focus on model listing.

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 does not explicitly state when to use this tool versus alternatives. However, the siblings are all different operations (delegation, tasks, diffs, sessions, etc.), so there is no obvious overlap. Still, no when-to-use or when-not-to-use guidance is provided.

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 provided, the description carries the full burden. It discloses the critical non-modifying behavior and read-only inspection. It does not cover other aspects like output format or resource usage, but for a planning tool the safety guarantee is the primary trait and is well-stated.

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 that immediately states the mode, the action, and the key constraint. No filler or redundant details; every word 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?

Given 7 parameters and no output schema, the description is incomplete. It does not mention what the plan output looks like (e.g., text format, file path) or any prerequisites. While the schema covers parameter details, the lack of return-value guidance leaves the agent guessing about 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 100%, so all parameters are already documented. The description adds no additional meaning to the parameters, such as how they interact or examples. It sticks to the high-level purpose, which is adequate but not value-added beyond the schema.

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 clearly states the action ('invoke Antigravity in planning mode'), the resource (codebase inspection), and the output (a plan). The phrase 'without modifying any files' distinguishes it from execution tools like agy_task, making its purpose 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?

The description implies when to use it (when a plan is needed before implementation) and its non-destructive nature, but it does not explicitly name alternatives or state when not to use it. The planning-mode phrasing and the no-file-modification guarantee provide clear context, though explicit exclusions are absent.

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 full burden. It only says 'Reset the active conversation', which implies clearing state, but does not disclose side effects (e.g., whether it deletes history, is irreversible, requires active connection) or explain the clear_all_sessions parameter's effect. This is minimal and inadequate for a mutation 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?

The description is a single, front-loaded sentence with the alias note, which is concise. However, it is under-specified rather than efficiently concise – it omits essential details about behavior and parameters, so it is not appropriately sized for the tool's complexity.

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 one optional parameter and no output schema, but the description fails to explain the parameter's semantics, return value, or any prerequisites. For a reset operation, it should at least mention that it clears conversation context and what clear_all_sessions does. The description is incomplete for safe and correct usage.

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 schema has one parameter clear_all_sessions with zero description coverage. The description does not mention or explain this parameter at all. An agent cannot infer what 'clear all sessions' means from the description, leaving a critical gap for correct invocation.

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 ('Reset'), a specific resource ('active conversation with Google Antigravity'), and clarifies it is a legacy alias to delegate_reset. This clearly distinguishes it from siblings like agy_ask or agy_chat, which are about interaction rather than resetting.

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 this is a legacy alias for delegate_reset, hinting that the modern alternative is delegate_reset, but it does not explicitly state when to use this vs. delegate_reset or other siblings. It provides no explicit exclusions or conditions, leaving the choice somewhat inferred.

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 provided, the description carries the full burden of behavioral disclosure. It does disclose that the agent 'operates autonomously with full tool access (file editing, terminal commands, web search, subagents)', which implies potential file modifications and side effects. However, it doesn't explicitly warn about destructive actions, irreversibility, or that the workspace may be altered, and it doesn't mention timeouts or permission implications beyond the schema. This is adequate but not comprehensive.

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 concise, only two sentences, and front-loads the core purpose. It avoids redundancy and is easy to scan. However, it could be slightly more informative without being verbose, but the structure is effective for a quick read.

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 9 parameters, no output schema, and no annotations, the description is too sparse to be fully contextual. It doesn't explain what the tool returns (e.g., success/failure, diff, summary), doesn't clarify the distinction between 'accept-edits' and 'plan' modes, and provides no guidance on when to use this vs. agy_ask or agy_plan. The description covers only the high-level delegation concept, leaving critical operational details to the schema.

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 parameters (mode, model, effort, prompt, add_dirs, workspace_dir, conversation_id, timeout_seconds, dangerously_skip_permissions) have their own descriptions. The tool description adds no extra meaning to any parameter—it doesn't elaborate on how to choose mode, what models are available, or how to use add_dirs. With high schema coverage, the baseline of 3 is appropriate.

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 clearly states the tool's purpose: to delegate a software engineering task (bug fix, refactoring, feature implementation) to Antigravity. The verb 'Delegate' and specific resource types make it unambiguous. However, it doesn't explicitly contrast with sibling tools like agy_plan or agy_ask, so some differentiation is implied but not 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?

The description provides no guidance on when to use this tool versus alternatives such as agy_plan, agy_ask, or delegate_task. It doesn't mention that planning should use agy_plan or that simple questions should use agy_ask. There is no when-not guidance, leaving the agent to infer usage context from the schema and sibling names.

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 of disclosing behavior. It only says 'Manage Antigravity sessions,' which does not reveal whether actions are read-only, destructive (e.g., 'clear' likely resets or deletes), or how switching works. No side effects, permissions, or state changes are mentioned, leaving the agent blind to the tool's operational implications.

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 a single sentence, which is concise, but it is under-specified to the point of being unhelpful. The alias note is front-loaded, which is good, but the rest is too sparse. It does not earn its place because it lacks actionable information. Conciseness without substance is not effective.

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 only two parameters, but with no output schema, no annotations, and a description that only says 'manage sessions,' the agent cannot infer return values, side effects, or error behavior. It is missing all behavioral context, making it impossible to call correctly without external knowledge of the legacy alias target.

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 the parameters. It mentions neither 'action' nor 'session_id'. The schema defines an enum for action and a free-form session_id, but the description adds no context about what values are valid, how they interact, or what each action does. This is a critical 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 says 'Manage Antigravity sessions,' which identifies a resource (Antigravity sessions) and a generic verb ('Manage'). It does not specify the concrete actions (list, switch, clear) that the schema provides, making the purpose vague. It is not a tautology, but it lacks the specificity needed to distinguish it from other session-management tools like delegate_sessions.

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 opens with '[Legacy Alias -> delegate_sessions]', which hints that delegate_sessions is the preferred tool, but it does not explicitly state when to use this tool versus alternatives. No guidance is given on selecting among the sibling tools (e.g., when to use agy_sessions vs. agy_task or delegate_ask). The alias note provides a mild routing hint but falls short of explicit usage conditions.

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 are absent, so the description carries the full burden of behavioral disclosure. It only says 'delegate a coding task,' which implies action but doesn't disclose side effects, permissions, reversibility, or potential impact. No context about timeouts, destructive changes, or return behavior is provided.

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 a single sentence with no wasted words, but it is severely under-specified. It is concise in length but not appropriately sized because it omits essential guidance. The legacy alias note is useful, but the overall content is insufficient for a tool with 10 parameters.

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 10 parameters, no output schema, and no annotations, the description should provide substantial context. It does not explain return values, parameter usage, or any behavioral expectations. The tool is completely opaque aside from the basic action.

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 10% (only 'prompt' has a description). The description adds no meaning to parameters like mode, model, one_off, add_dirs, thinking, session_id, include_diff, workspace_dir, or timeout_seconds. It fails to compensate for the low schema coverage, leaving agents to guess at parameter semantics.

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 clearly states the tool delegates a coding task to Google Antigravity, identifying the verb (delegate), resource (coding task), and target. It also notes it's a legacy alias for delegate_task(agent='agy'), which distinguishes it from siblings like agy_ask or agy_plan.

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 legacy alias note implicitly tells agents to prefer delegate_task instead, but it doesn't explicitly state when to use this tool versus alternatives or provide exclusions. There is no mention of when it would be appropriate to invoke this alias directly.

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 burden. It discloses that the tool 'get' version/path and 'verifying runtime health', implying it is a read-only operation, but it does not explicitly state it is safe or non-destructive. It also does not mention what it returns (e.g., format, structure) or error behavior. For a simple tool, this is acceptable but not fully transparent. It does not contradict any annotations (none exist), so no contradiction flag.

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 a single, well-structured sentence that is front-loaded with the action ('Get the version and binary path') and then adds the secondary purpose. There is zero waste; every word contributes. It is concise yet complete for its simple scope.

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 has no parameters, no output schema, and no annotations, the description is adequate. It tells the agent what the tool does and hints at the return value (version and binary path). It does not specify the exact format or error handling, but for a version check this is not critical. The description is complete enough for an agent to decide whether to call it and interpret the basic 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?

The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters. The baseline for 0 parameters is 4, and the description adds no unnecessary param details. It effectively communicates the tool's scope without mentioning parameters, which is appropriate.

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 ('Get') and a precise resource ('version and binary path of the installed Google Antigravity (agy) CLI'), and adds a secondary purpose ('verifying runtime health'). This clearly distinguishes it from sibling tools like agy_task or agy_chat, which perform different operations. The purpose is unambiguous and informative.

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: it is for checking the CLI's version and binary path, and for verifying runtime health. This gives context on when to use it (e.g., diagnostics or environment checks). However, it does not explicitly name alternatives or state when not to use it, though the simplicity of the tool makes alternatives obvious. There is no exclusion guidance, but the implied use case is clear.

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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only and does not create or alter conversation session state, which is critical safety information. However, it does not describe the output format or any potential side effects beyond the read-only guarantee, so a full 5 is not warranted.

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 a single, efficient sentence that front-loads the most important information (read-only, fast, purpose) and contains no redundant phrases. Every word 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?

Given the tool's straightforward read-only nature and full schema documentation, the description adequately covers purpose and key behavior. The only gap is the absence of any mention of the return value or response interpretation, which could be helpful since there is no output schema, but this is a minor omission for a query-style tool.

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 schema has 100% parameter description coverage, so all six parameters are already documented. The description adds no parameter-specific details beyond the schema, meeting the baseline for high schema coverage without extra value.

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 clearly states the tool executes a fast, read-only question, diagnostic, or code review via a CLI agent, and explicitly notes it does not alter conversation session state. This specific verb-resource-scope combination distinguishes it from task-execution siblings like delegate_task, even without naming them.

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 provides clear context for when to use it (read-only questions, diagnostics, reviews) but does not explicitly state when not to use it or name alternative tools. It implies a boundary against mutating tasks, but an agent would have to infer that from the read-only wording rather than receiving explicit routing 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states 'non-destructively', signaling a read-only operation, which is a key safety property. However, it does not detail any potential side effects, permission requirements, or failure modes, leaving some gaps.

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 a single, well-structured sentence. It is front-loaded with the core action and immediately lists the specific inspection targets. No filler or redundant information, making it highly 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?

Although there is no output schema, the description explicitly lists the outputs (git status, modified files, insertions/deletions, unified diff patch), giving the agent a clear expectation. It does not cover error cases or edge scenarios, but for a simple inspection tool this is reasonably complete. The optional workspace parameter is documented in the schema.

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 schema provides 100% coverage for the only parameter (workspace_dir) with a clear description. The tool description does not add extra semantic meaning beyond the schema, but it does imply the parameter through 'target workspace'. This meets the baseline for adequate parameter documentation.

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 clearly states the action ('Inspect') and the resource (git status, modified files, insertions/deletions, unified diff patch). It distinguishes itself from the sibling 'agy_diff' by including git status and modified files, but does not explicitly contrast with it. The purpose is specific and 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?

The description implies when to use the tool (to inspect repository changes) but does not provide explicit guidance on when to prefer this over 'agy_diff' or other siblings. No exclusions or alternatives are mentioned. The usage context is inferable but not stated directly.

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 must fully disclose behavior. It states that the operation resets the session and clears context, which is the core effect. However, it does not mention potential side effects (e.g., whether ongoing tasks are interrupted, if the reset is idempotent, or if any data is permanently lost beyond conversation state). This is a moderate disclosure, sufficient but not exhaustive.

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 with no redundancy. The first sentence states the primary action and scope; the second explains the consequence. The information is front-loaded and every word serves a purpose.

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 simple tool with one optional parameter and no output schema, the description is largely complete. It explains what is reset and the resulting state. It does not describe the return value, but for a reset action this is minor. The tool's scope (specific vs. all) is explicit, and the connection context is stated. Adequate for an agent 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?

The schema description for the 'agent' parameter already covers the semantics completely (specific agent vs. all agents). Since schema coverage is 100%, the tool description adds no additional value beyond what the schema provides. The baseline of 3 applies here.

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 clearly states the action ('Reset the active conversation session'), the target (specific agent backend or all agents on this connection), and the effect (fresh conversation, clean context). It distinguishes itself from siblings like delegate_task and delegate_ask by focusing on reset behavior, leaving no ambiguity about what the tool does.

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 explicitly defines when to use it: when a session reset is needed, either for one agent or all agents. It doesn't explicitly mention alternatives like delegate_sessions (likely for listing) or agy_reset (similar but for a different backend), but the scope is clear. The absence of explicit exclusions is a minor gap given the sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output format with [ACTIVE] markers but does not disclose the side effects of 'switch' or 'clear' actions, whether they are destructive, or any prerequisites. The description adds minimal behavioral context beyond what the schema already states.

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 sentences with zero waste. It front-loads the primary actions (list, inspect, switch) and immediately clarifies the scope ('across backends'). Every word 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, the description should at least hint at the return format, which it does by mentioning [ACTIVE] markers. However, it does not cover error handling, prerequisites for switching, or the implications of 'clear'. For a management tool with 3 parameters, this is adequate but not exhaustive. It lacks details that could prevent incorrect usage.

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 the schema fully documents all parameters. The description adds contextual value by noting 'across backends' and 'multi-turn sessions', but it does not provide additional parameter-specific semantics beyond the schema. Baseline 3 is appropriate given the high schema coverage.

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 clearly states the tool's purpose: to list, inspect, or switch multi-turn agent sessions. It adds 'across backends' which distinguishes it from sibling tools like agy_sessions that might be specific to one backend. The verb+resource combination is specific and 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?

The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. It doesn't mention that this is the preferred tool for cross-backend session management or when to choose a sibling like delegate_task or agy_sessions. No exclusions or when-not conditions 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?

No annotations are provided, so the description must disclose behavioral traits. It only mentions context preservation and zero-token overhead, but fails to explicitly state that the tool can modify files, run terminal commands, or have other side effects. The mutating nature is implied by 'coding task' but not clearly disclosed. This is a significant gap for a tool that delegates autonomous coding.

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 concise sentences with no filler. The purpose is front-loaded, and the second sentence adds a key feature (context preservation). Every word 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 tool with 11 parameters, no output schema, and no annotations, the description is inadequate. It does not explain return behavior, potential risks, or when to use it. It omits practical guidance on timeouts, agent selection, or session management. The schema covers parameters, but the description fails to provide the high-level context needed for safe and effective use.

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 parameters are well-documented in the schema. The description adds overall context about conversation continuity, which relates to session_id and one_off, but does not provide parameter-specific insights beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 clearly states a specific action ('Delegate') with a resource ('coding task, bug fix, architectural refactor, or test implementation') and a specific target ('local autonomous CLI coding agent'). It names the supported agents (Claude Code, Antigravity, Codex, Cursor), making the purpose unambiguous even without looking at 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?

No guidance is given on when to use this tool versus siblings like delegate_ask or agy_task. The description mentions context preservation but does not explain when to choose this over a simpler ask or when not to use it. The schema's mode enum hints at usage, but the description itself offers no decision criteria.

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