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 information is checked but does not mention whether the operation is read-only, any side effects, error conditions, or the nature of the response (e.g., partial results if task still running). For a status-check tool, this is minimal behavioral disclosure.

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, concise sentence that front-loads the main purpose and lists key outputs. Every word earns its place, with no redundancy or filler.

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 one-parameter tool with no output schema, the description covers the essential purpose. However, it lacks detail about the return format, potential error scenarios, or behavior when the task is incomplete. While not critical, additional context would improve completeness.

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 fully describes the task_id parameter with 100% coverage, including its origin. The description adds no additional parameter details, but the schema already provides sufficient meaning. Since the schema covers the parameter, a baseline score 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 verb 'checks' and the resource 'asynchronous task started with async: true'. It lists specific aspects (status, running duration, execution trace, results) that distinguish it from simpler status checks. However, it does not explicitly name sibling tools or state what it is not, so it lacks explicit 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?

The description implies usage for async tasks but provides no guidance on when to use this tool versus alternatives like agy_get_status or codex_check_task. There is no mention of conditions, exclusions, or alternative tools. The agent is left to infer the appropriate 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 disclosure burden. It usefully mentions real-time streaming and token savings tracking, but it does not describe side effects, background execution behavior, or failure modes. Some behavior is recoverable from schema fields like async and workspace_dir, but the description could be more explicit.

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 focused sentence that starts with the action and then enumerates relevant use cases and key behavioral features. It is reasonably concise with no filler, though the comma-heavy list makes it slightly less scannable than a two-sentence version.

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 description helps the agent know the high-level purpose and useful behavioral details, and the schema documents all parameters. It leaves the exact return/output shape and the relative comparison with agy_execute implicit, so some contextual decisions are still on the agent.

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 100% documented parameters, so the schema does the primary lifting. The description adds context about streaming and token tracking but does not add meaning to individual parameters. Baseline score of 3 is appropriate given the full 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 uses a clear verb-resource pairing: 'continues an existing Antigravity conversation' and backs it with concrete use cases such as follow-up adjustments, revisions, test fixing, and iterative tasks. The word 'existing' differentiates it from agy_execute and similar initial-execution siblings.

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 gives an implied usage scenario: use it when a conversation already exists and needs continuation. It names the use cases but never explicitly contrasts it with agy_execute or says 'use agy_execute for a new conversation', so routing between siblings is left to the agent's inference.

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 safety/behavior details; it does disclose headless autonomous execution and live streaming/metrics, which is meaningful. However, it does not mention side effects or that the agent will directly modify files, or what happens on timeout/failure—behavioral gaps given no 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?

A single dense, front-loaded sentence that places the core action first and then lists monitoring features. It is not bloated, though the feature list could be trimmed without losing invocation-relevant 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?

Given no output schema and no annotations, the definition is serviceable but incomplete: an agent is not told what agy_execute returns (e.g., task ID, initial stream) or how to monitor/continue after an async invocation. Sibling tool names imply that workflow but the description does not state 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 baseline 3 is appropriate. The description itself adds no parameter-specific semantics; the async, mode, and workspace_dir behavior is already fully explained in 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 identifies a specific action ('spins up a headless Antigravity agent') and scope ('execute heavy coding, editing, refactoring, research, or testing tasks'), which differentiates it from status/check/continue siblings. It does not explicitly compare itself to codex_execute or say when to prefer agy_continue, so it stops short of full 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?

The phrase 'heavy ... tasks' plus the async parameter's recommendation for 'real coding tasks (>45s)' and pointer to agy_check_task give clear context on when to use this tool. It does not state exclusions or direct users to codex_execute for alternative scenarios.

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 burden of behavioral disclosure. The description states what the tool checks (availability, responsiveness, status), but it doesn't disclose details such as whether the check has side effects, what the exit behavior is, whether it may hang or time out, or potential failure modes. For a no-parameter status tool, this is adequate but not rich.

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, compact sentence that clearly conveys the tool's function. No extraneous information is included, and the key aspects (availability, responsiveness, status) are all mentioned.

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 is a zero-parameter status check with no output schema, the description is nearly complete. It tells the agent what the tool does, and the lack of parameters removes potential ambiguity. A slight gap is that it doesn't mention how the status is returned or what the output format is, but for a simple health check this is acceptable.

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 provides no parameter semantics. The description doesn't need to compensate, as there is nothing to document. This is a simple status check with no inputs.

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 check availability, responsiveness, and current status of the Antigravity CLI (agy). It names a specific resource and verb (check status), which is clear and distinguishable from the sibling tools listed. However, it does not explicitly differentiate itself from siblings beyond the general 'status check' scope.

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 are no explicit usage guidelines or when-to-use instructions. The description implies the tool is for health/status checks, and the zero-parameter schema suggests it's a simple check, but it doesn't state when to prefer this over alternatives or what conditions warrant using it. As a status-check tool, its usage is fairly obvious, but no explicit guidance 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?

There are no annotations, so the description must carry behavioral meaning. It does: 'Returns ... analytics and history' signals a read-only aggregation over all delegations with no filtering or side effects. It does not explain response shape, but with zero parameters no hidden inputs or mutation risks are apparent.

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 focused sentence that states the return type (analytics/history), scope (lifetime, all delegations), and subject (context window saved). No filler or redundancy.

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 read-only aggregate tool, the description is nearly complete. It does not enumerate the exact output fields, but there is no output schema and the description gives enough shape for an agent to decide whether 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?

The schema has zero parameters, so the baseline score of 4 applies. There is no parameter ambiguity, and the description confirms the tool takes no scope/filter arguments by calling it 'lifetime' and 'across all delegations.'

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 ('Returns') and clearly identifies the resource: lifetime token savings analytics and history across all delegations. It immediately distinguishes this tool from operationally-oriented siblings like get_status or execute.

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 gives clear context for when this tool is appropriate: when an agent needs overall token savings/history data. It names no alternatives, but the tool's read-only aggregate scope makes its usage context reasonably unambiguous.

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 burden. It discloses a useful behavioral trait: the tool inspects without filling context with raw logs, implying summarized output. However, it does not clarify the exact return format, pagination or step-limit behavior, or any potential side effects, though the read-only nature is reasonably clear from 'Inspects.'

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 concise sentence that front-loads the core action and resource. It is efficient, though 'trajectory, tool calls, and actions' is slightly redundant and could be tightened without losing meaning.

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 only two parameters and no output schema, the description covers the basic purpose and a key behavioral benefit, but it does not describe the output shape or provide using-vs-alternative guidance. The max_steps schema description hints at summarization, but the tool description alone would leave an agent unsure what the return value 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 description coverage is 100%, so both conversation_id and max_steps are already documented in the schema. The description adds little parameter-specific meaning beyond framing the tool's overall purpose, which is acceptable 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 uses a specific verb ('Inspects') and names a clear resource: 'execution trajectory, tool calls, and actions from an Antigravity conversation.' It does not explicitly differentiate from sibling tools, though the phrase 'without filling context with raw logs' hints at a distinct purpose focused on summarized inspection.

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 guidance on when to use this tool versus siblings like agy_get_status, agy_execute, or agy_continue. The description implies a use case but does not state when it should be selected, when it should not, or name any alternatives.

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 only states that the tool consults models, but does not mention potential costs, latency, non-determinism, external API calls, or that responses may vary. It also does not clarify whether the tool is read-only or if it has side effects. This is a significant gap for a tool that presumably makes external calls.

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 front-loads the purpose and lists concrete use cases. It is concise and free of fluff. However, it could have been slightly more informative without losing conciseness, such as mentioning the difference from 'chatgpt_review' or providing a brief example, so it earns a 4 rather than a 5.

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 6 parameters (1 required), no output schema, and no annotations, the description is insufficient. It does not clarify the expected input format for 'prompt' or 'context', does not explain how 'temperature' interacts with 'reasoning_effort', and does not differentiate this tool from the sibling 'chatgpt_review'. An agent lacks enough context to call it correctly or know what to expect.

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 six parameters (model, prompt, context, temperature, system_prompt, reasoning_effort) are already documented in the schema. The description does not add any parameter-specific meaning beyond the schema, but the high coverage justifies a baseline score of 3. No additional context or examples are provided to enhance parameter understanding.

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 function: consulting ChatGPT/OpenAI models for high-level technical advice, architectural review, edge case analysis, or second opinions. The verb 'consults' and resource 'ChatGPT/OpenAI models' are specific, and the use cases are enumerated. However, it does not explicitly distinguish from the sibling tool 'chatgpt_review', which likely overlaps in purpose, so it loses a point for lacking 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?

The description implies appropriate usage by listing contexts like 'high-level technical advice, architectural review, edge case analysis, or second opinions'. However, it does not explicitly state when to use this tool instead of alternatives like 'chatgpt_review', nor does it mention any exclusions or prerequisites. The guidance is present but implicit, relying on the agent to infer applicability.

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 disclose all behavioral aspects. It states the tool performs an 'adversarial code review' but doesn't mention whether it's read-only, any side effects, authentication requirements, or rate limits. It also doesn't describe the return format or potential side effects on external systems.

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 is clear and to the point. It front-loads the action and resource, though it could be slightly more specific about the 'specialized focus' without adding length.

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 there is no output schema and no annotations, the description fails to explain what the tool returns, how to interpret the review, or any prerequisites. The tool has four parameters including an enum, but the description doesn't elaborate on the review process, output format, or typical use cases. It is insufficient for an agent to understand the full 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?

Schema coverage is 100%, so the schema already documents all four parameters. The description adds nothing beyond what the schema provides, such as clarifying the meaning of 'focus' or how 'instructions' interact with the review. Baseline 3 is appropriate since the schema carries the burden.

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 identifies the tool as requesting an adversarial code review from ChatGPT, specifying the input types (git diff, file content, or code snippet). It differentiates from the sibling chatgpt_consult, which is likely a general consultation tool, though it doesn't explicitly contrast 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 no guidance on when to use this tool versus alternatives like chatgpt_consult or the codex_* family. The mention of 'specialized focus' is vague and doesn't clarify the intended context or conditions for selection.

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 the behavioral disclosure. It describes what the tool returns (status, duration, trace, results) and implies a read-only operation via the verb 'checks', but does not explicitly state non-destructiveness, potential side effects, or any limitations. This is adequate for a simple check 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 a single, well-structured sentence that immediately conveys the action and scope. No unnecessary words or repetition; it is front-loaded with the verb 'Checks' and remains concise.

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 parameter and no output schema, the description is complete. It covers the purpose, the target task type, and the high-level information returned. It does not specify the exact response format, but that is not essential given the simplicity of the 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 input schema fully describes the task_id parameter, including its origin from execute or continue calls when async is true. The description adds no additional parameter detail, so the baseline of 3 applies given 100% 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 checks the status, running duration, execution trace, and results of an asynchronous task, and specifies it applies to Codex or Antigravity. It is specific and distinct from execution tools, but does not explicitly differentiate from the sibling codex_get_status, which likely serves a similar or overlapping 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention that it should be used after execute/continue calls, nor does it contrast with codex_get_status or other siblings. An agent is left to infer usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'continues' and 'adjustments, corrections, or iterative bugfixing', implying modifications, but it does not explicitly state that it will execute code, modify files, or have destructive potential. It omits permissions, rate limits, reversibility, and any side effects, leaving the agent uninformed about the impact of calling this 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 sentence that front-loads the core action and resource. It contains no filler, no redundant clauses, and is efficient in conveying the primary 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?

The tool has 8 parameters, no output schema, and no annotations. The description is only one sentence and does not explain what happens when called, what the response looks like, how to handle asynchronous behavior, or the nature of the execution (e.g., whether it runs commands). An agent cannot fully understand the tool's behavior or its results from this description alone.

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 description adds no parameter-specific guidance. It does not mention thread_id, instructions, or any other parameter. With a schema description coverage of 63%, some parameters may lack sufficient clarity, and the tool description does not compensate. Agents cannot derive additional meaning about how to fill parameters correctly from the description.

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 ('Continues') and resource ('existing Codex session thread'), and clarifies the purpose as 'follow-up adjustments, corrections, or iterative bugfixing'. This clearly differentiates it from starting a new session and from other agents (e.g., agy_continue) by explicitly naming 'Codex'.

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 you have an existing session thread and want to continue it. The purpose is explicit, but it does not name alternatives or explicitly exclude use for new sessions. The context is clear enough that an agent would know to use this after a prior codex_execute or codex_continue, but there are no explicit exclusions, so it falls short of a 5.

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 autonomous execution and live streaming/token tracking, but it does not disclose potential side effects such as modifying files, executing arbitrary commands, or the implications of the sandbox setting (e.g., danger-full-access). It also doesn't explain whether the subagent can make irreversible changes or what happens on failure. This is a significant gap for a tool that can modify a workspace.

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 conveys the primary function without redundancy. It is front-loaded with the action ('Spins up an OpenAI Codex subagent') and lists task types succinctly. No wasted words, though it could potentially mention a key usage caveat without becoming verbose.

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 8 parameters, no output schema, and no annotations, so the description must compensate for missing context. It fails to explain what the tool returns (e.g., progress updates, token savings data, or final output), how 'live streaming' manifests in practice, or the significance of the sandbox options. It also omits the mandatory workspace_dir requirement in Claude Desktop (present in schema but not description). An agent would not have enough information to call this correctly without reading the schema in full, making the description insufficient for 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?

Schema description coverage is 100%, so each parameter already has its own description in the schema. The tool description adds no extra parameter-level detail beyond what the schema provides. For instance, it doesn't clarify how 'instructions' should be formatted or what 'workspace_dir' should point to, though the schema already covers those. Since coverage is high, a baseline of 3 is appropriate, and the description does not enhance 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 description clearly states a specific action: spinning up an OpenAI Codex subagent to execute coding, refactoring, testing, and file editing tasks. It names the resource and the types of tasks, distinguishing it from generic 'process' or 'execute' tools. The mention of 'Codex' and 'subagent' differentiates it from siblings like agy_execute or codex_continue.

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 itself provides no explicit when-to-use guidance or exclusions relative to sibling tools. However, the input schema's async parameter includes a recommendation for Claude Desktop and mentions checking status with codex_check_task or agy_check_task, which gives some indirect usage context. Still, the description does not directly state when this tool should be preferred over alternatives, so 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?

With no annotations, the description carries the transparency burden. It clearly frames the tool as a status-checking/read-only operation rather than a mutation, and names both installation/operability and authentication status. It doesn't spell out exact success/failure output, but the behavior is sufficiently disclosed for a simple status probe.

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 filler or repetition. Every clause contributes a distinct fact: installed, operational, and authentication status.

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, low-complexity status tool, the description covers the essential invocation context. It could be stronger by listing likely output values or statuses, especially since there is no output schema, but an agent has enough to use the tool as a read-only status check.

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 zero parameters and 100% schema coverage, so there are no parameter semantics the description needs to add. A score above baseline is not warranted because the description does not need to clarify arguments; it simply has none.

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 verb/resource: it checks whether the OpenAI Codex CLI is installed, operational, and authenticated. This clearly differentiates it from siblings like codex_execute, codex_check_task, and agy_get_status.

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 context is implied through 'status,' 'installed,' and 'current authentication status,' suggesting a preflight/readiness check. However, it does not explicitly say when to call it versus siblings like codex_check_task or agy_get_status, nor does it state that it should precede codex_execute.

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