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

Annotations already include destructiveHint=true and readOnlyHint=false. The description enhances this by detailing sandbox levels (read-only, workspace-write, full-auto), timeout behavior, and the impact of the files parameter on I/O and timeout. No contradictions with annotations.

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 well-organized: a one-sentence purpose, a bulleted capabilities list, a 'When to use a different tool' paragraph, and compact tips. Every sentence adds value, and the structure aids quick comprehension.

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 10 parameters, no output schema, and complex capabilities, the description covers purpose, usage guidelines, tips, and behavioral context. It could be more explicit about the response format, but overall it provides sufficient context for 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 baseline is 3. However, the description adds significant practical context: line ranges for files, sandbox semantics, timeout defaults, reasoning effort mapping, and sessionId usage. This goes well beyond the schema descriptions.

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 'Execute a prompt via Codex CLI' and lists specific capabilities like code generation and refactoring. It distinguishes from siblings through the 'When to use a different tool' section and by emphasizing that this tool is for interacting with an AI coding agent with full project context.

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 a 'When to use a different tool' section that advises against using the files parameter for simple text analysis, and offers tips on setting workingDirectory, sandbox level, and session management. While it doesn't explicitly contrast with sibling tools, the guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns only metadata (no prompts/responses) and focuses on active sessions, providing useful behavioral context beyond annotations.

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, front-loaded with the primary action, no redundant words. 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?

For a parameter-free tool with no output schema, the description fully covers purpose, return content, and usage context. Additional details on output format are unnecessary.

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?

With zero parameters and 100% schema coverage, the description naturally contains no param details. Baseline score of 4 is appropriate; no further info needed.

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 lists active Codex sessions and specifies exactly what metadata is returned (IDs and timing). It distinguishes itself from siblings like codex by explaining its role in orchestration.

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?

Explicitly advises when to use: 'Use to check available sessions before resuming with the codex tool's sessionId parameter.' No ambiguity.

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?

Beyond the readOnly/destructive annotations, the description discloses significant behavioral traits: it is slower than normal calls, boots servers from ~/.codex/config.toml, produces no thread/session record in default mode, and starts an ephemeral thread in diagnostics mode. It also explains output interpretation ('unknown' is not a failure, 'degraded' warning semantics, builtIn vs configuredButUnreported). No contradiction with annotations.

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?

Although the description is long, it is exceptionally well-structured with a clear purpose statement, a behavioral caveat section, a two-mode breakdown, and an output interpretation guide. Every sentence adds necessary detail for a tool with no output schema. It is front-loaded with the most important information and uses scannable formatting.

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 complexity, the lack of an output schema, and the need to explain side effects, timing, and result semantics, the description is remarkably complete. It covers what the tool returns (initialized/unknown/failed), when failures can be detected, how to interpret warnings, and what side effects occur. No gaps remain for a competent agent to use 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema for the diagnostics parameter, explaining that it 'starts an ephemeral thread to collect startup notifications' and is the only way to get explicit failure states. It also clarifies the default behavior (inventory only) which ties to the parameter's absence. Timeout and workingDirectory are left to the schema, but the added diagnostics context raises it above baseline.

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 opens with a specific verb and resource: 'Report what Codex's own app-server says about each MCP server it knows about: auth type, tool inventory, and whether the server initialized.' It clearly distinguishes itself from sibling tools by explicitly stating 'Unlike the other tools, this one deliberately does NOT suppress Codex's MCP servers,' making its unique purpose obvious.

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?

It provides clear when-to-use context and even explains why alternatives would not work ('suppressing them would disable the thing being measured'). It also gives explicit guidance on choosing between default and diagnostics mode, stating diagnostics is 'the only way to get explicit failure states and error text.' This is strong usage guidance with exclusions and mode selection criteria.

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?

Adds context beyond annotations by specifying the verification and reporting actions, without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no waste, front-loading the purpose and key behavior.

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?

Adequately describes the tool for a health check with no parameters or output schema, though exact return format is not specified.

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?

No parameters exist; description adds value by stating the tool's function, meeting the baseline for 0-param tools.

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 verifies Codex CLI installation and authentication and reports versions and capabilities, distinguishing it from siblings like search or query.

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

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

No explicit guidance on when to use this tool versus alternatives, but the purpose is implied through the health check nature.

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

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

Annotations already indicate readOnly and openWorld hints. Description adds context: no file reading, no repo exploration, no session state. It confirms non-destructive behavior and provides clarity on what the tool cannot do, which is valuable beyond the annotations.

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?

Description is well-structured: brief overview, explicit exclusions, use cases, and tips. Every sentence adds value. No wasted words.

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 6 parameters and no output schema, the description fully covers the tool's behavior, parameter usage, and limitations. It is complete enough for an agent to use correctly without confusion.

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?

All parameters are described in schema, but the description adds extra guidance: context must be inline text (not file paths), reasoningEffort levels mapped to depth, maxResponseLength as soft limit. This adds significant value beyond the schema descriptions.

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?

Description clearly states the tool is a lightweight query for analysis on existing text, distinguishing it from code execution (codex), search, and other siblings. It specifies what it does not do (file reading, repo exploration, session state).

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?

Explicitly provides use cases (reviewing, critiquing, comparing) and when not to use (for code execution or file operations, use codex). Also includes tips on how to pass text and control reasoning effort.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no behavioral context beyond what annotations provide; it does not explain what destructive actions might occur or what side effects the review has (e.g., modifying git state). It adequately describes the input scope but not the behavioral traits.

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: two paragraphs and a bullet list with no filler. It front-loads the core purpose and practical usage, making it easy for an AI agent to parse efficiently.

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?

While the description covers purpose and usage, it lacks information about the output format. Since there is no output schema, the description could explain the review return structure (e.g., JSON with issues, severity, line numbers). Additionally, it gives no details on limitations or error handling.

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 a clear description. The description adds general tips (e.g., 'Set workingDirectory to the target git repository') but does not provide additional semantic detail beyond what the schema offers.

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 runs 'Codex CLI's native diff-aware review' and specifies it is for reviewing uncommitted changes, base branch diffs, or a single commit. It distinguishes from sibling tools like 'codex' by targeting MCP clients that cannot run shell commands.

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 states when to use this tool ('for MCP clients that cannot run shell commands but need native Codex review') and provides alternatives: 'Use the codex tool with sandbox "read-only" for free-form review prompts.' It also gives tips on setting workingDirectory and choosing mode.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds behavioral details such as default timeout (2 minutes), ability to increase for complex queries, and control of verbosity via maxResponseLength. It does not describe rate limits or API costs, but given the annotations, this is sufficient.

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 well-structured with a clear purpose statement followed by bullet-point tips. It is front-loaded with the main function. One sentence could be removed (e.g., 'Results include source URLs for verification' is stated twice), but overall it is 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?

Given the tool's complexity (web search with synthesis) and the richness of annotations, the description covers key aspects: response includes URLs, timeout behavior, and length control. No output schema exists, but the description explains return format sufficiently. Missing details like error handling are not critical for basic 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 coverage is 100%, so the schema already documents all parameters. The description adds value by explaining when to adjust timeout and maxResponseLength, and how they affect behavior (e.g., complex queries may require multiple fetches). This goes beyond the schema's type/limit descriptions.

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 'Web search via Codex CLI' and 'Searches the web and synthesizes a comprehensive answer with source URLs', providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'query' or 'review', which may have overlapping purposes.

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 lists concrete use cases (current information, documentation lookups, API references, research) and provides actionable tips (ask specific questions, use maxResponseLength, adjust timeout). It lacks explicit when-not-to-use or alternative tool references, but the context is clear enough for an AI agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it generates a JSON response, but does not elaborate on behavior like error handling or idempotency. With annotations doing heavy lifting, the description is adequate but not exceptional.

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, front-loaded with the core action followed by use cases. No redundant or missing words.

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 6 parameters (2 required) and no output schema, the description covers the essential function and use cases. It could hint at return value more explicitly, but 'Generate a JSON response' suffices.

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% with detailed parameter descriptions. The tool description does not add additional meaning beyond what the schema already provides, meeting the baseline expectation.

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 it generates JSON based on a provided schema, naming specific use cases like data extraction and classification. It distinguishes from sibling tools (codex, search) by emphasizing structured output.

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 says 'Use for data extraction, classification, or any task needing machine-parseable output,' providing clear when-to-use guidance. However, it lacks explicit when-not-to-use or alternatives among siblings, but the context is strong.

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