codex-app-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation4/5
Most tools have clearly distinct purposes (status, doctor, fs, events, etc.), but there is some overlap among job/lane/turn/goal management which could confuse agents about which to use for background work. Descriptions differentiate them, but boundaries are less crisp.
Naming Consistency4/5
All tools follow a consistent codex_app_ prefix and mostly use noun-like names (status, doctor, fs, job), but a few use verbs (discover, mcp_call) and rpc_read is an adjective-noun combo. The pattern is predictable overall.
Tool Count3/5
With 20 tools, this server is on the heavy side (16-25). The scope is broad enough that each tool may be justified, but the count will likely overwhelm agents and increase selection difficulty.
Completeness5/5
The tool surface is remarkably comprehensive, covering diagnostics, filesystem, events, jobs, scheduling, RPC, commands, threads, turns, goals, review, and process control. There are no obvious dead ends or missing core operations for the stated purpose of managing a Codex app-server.
Average 3/5 across 20 of 20 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions 'governed' and 'allowlisted roots' but fails to disclose critical details such as authorization requirements, destructive behavior (remove, force overwrites), watch lifecycle semantics, or response formats. This is a significant gap for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise and readable, though its brevity sacrifices useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters, 9 action variants, no output schema, and no annotations. The description provides only a broad overview and lacks essential context about return values, action-specific requirements, filename/path constraints, binary handling, and error behavior. It is far from complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining parameter meanings. It names operation types (read, write, copy) but does not clarify relationships between path, text, sourcePath, destinationPath, watchId, or other parameters. The agent cannot infer semantics beyond the bare schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs governed filesystem operations (read/write/list/copy/remove/watch) on the app-server filesystem v2 under allowlisted roots. It distinguishes itself from sibling tools by naming the filesystem and operation scope, though it lacks a single verb+resource phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about governance and allowlisted roots but does not specify when to use this tool versus alternatives. No explicit exclusions or sibling comparisons are provided, leaving usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It names operations like 'prepare' and 'run' but does not disclose whether these mutate state, require auth, or have side effects on the filesystem. The phrases 'isolated' and 'background a turn' give weak hints, but the tool's mutational footprint and operational behavior remain opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense but concise sentence that leads with action verbs and names the core resource. It is efficient and not padded, though the slash-separated list of operations makes it slightly hard to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 26 parameters, 7 action variants, and no output schema or annotations. A single-sentence overview cannot possibly cover behavior, return values, workflow steps, or parameter relationships, leaving the agent without critical context for safely using operations like start vs run or poll.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for 26 parameters, and the description does not explain any of them. It only loosely mirrors the action enum via words like 'run' and 'poll', but parameters such as lane, jobId, delivery, approvalPolicy, baseRef, and outputSchema are entirely unexplained. The description fails to compensate for the extremely low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates specific operations (prepare, list, diff, run/background, poll, review) and ties them to isolated codex/* git worktrees and the app-server, making the core purpose clear. It does not explicitly contrast with sibling tools like codex_app_turn or codex_app_review, but the worktree/lane resource is distinctive enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools such as codex_app_turn, codex_app_review, or codex_app_job. The description implies coverage of lane/worktree lifecycle operations but provides no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is 'experimental unsandboxed' and requires a special environment variable, which is useful context. However, with no annotations, it fails to mention the potentially destructive nature of actions like kill or write, or any other side effects. This is insufficient for a process-control tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of moderate length. It packs essential context (experimental, unsandboxed, access requirement) without wasting words, though it is terse to the point of being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no annotations, and no output schema, this one-sentence description is severely incomplete. It does not explain the actions, handle semantics, stream behavior, timeout handling, or any return values, making it inadequate for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention any of the 13 parameters, including the required 'action' and 'processHandle'. It provides no meaning beyond the schema, so the agent gets no help understanding what each parameter does or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Control experimental unsandboxed app-server process/* sessions,' which identifies the resource (process sessions) and a general action (control). It also includes important context about being experimental and unsandboxed, but the verb is broad and it does not differentiate from sibling tools like codex_app_runtime or codex_app_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a prerequisite (requires CODEX_APP_MCP_ALLOW_FULL_ACCESS=1) but provides no guidance on when to use this tool versus alternatives. There are no exclusions or alternative tool references, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It says 'generate and inspect' but doesn't clarify side effects, safety, or what 'generate' entails (e.g., whether it writes files or just outputs to stdout). This omission leaves the agent uncertain about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, its brevity contributes to the lack of parameter and usage detail, though it is well-structured for what it contains.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 2 enums, no output schema, and no annotations, this description is drastically incomplete. It fails to explain the actions (summary, methods, method, refresh) and how the parameters control behavior, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the six parameters. It doesn't explain the action enum values, nor the purpose of kind, force, limit, query, or method, leaving the agent to guess how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates and inspects the versioned JSON schema from the Codex app-server binary. It distinguishes itself from sibling tools by focusing on protocol schema, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling codex_app_* tools. The description doesn't mention use cases, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It mentions 'persistent' but omits side effects, permission requirements, or consequences of actions like archive, delete, or inject. Mutating actions are not flagged as such.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded with verbs, but the comma-separated list format is somewhat unstructure. Still, it earns its place as a summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a large action surface (20+ enum values) and 31 parameters, yet the description covers only a subset of actions and zero parameter details. No output schema exists to clarify return values. The description is grossly inadequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 31 parameters with 0% description coverage. The description only lists action verbs and does not explain any parameters (threadId, cwd, items, config, etc.). It fails to compensate for the schema's lack of descriptions, leaving parameters entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource (persistent Codex threads) and lists several key actions, which distinguishes it from sibling tools like codex_app_turn. However, it omits many actions present in the enum (e.g., delete, inject, shell, terminals_list), so it is not fully exhaustive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not state context, prerequisites, or exclusions, leaving the agent to infer usage purely from the action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavior. It only says 'Start/probe' without explaining side effects, permissions, or consequences of starting a connection. It does not mention what the return value looks like or whether 'start' is destructive or reversible, which is a significant gap for a tool that can seemingly mutate state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core action and resource efficiently, though it lacks structured details that might improve clarity. It is appropriately concise for the simple schema but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It fails to explain what 'probe' returns, what 'start' actually does, or any behavioral context. The single line is insufficient for an agent to safely and effectively use the tool, especially given the need to distinguish it from many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional boolean parameter 'includeStderr' with 0% description coverage, and the tool description does not mention this parameter at all. Since schema coverage is low, the description should compensate, but it offers zero guidance on what 'includeStderr' controls or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Start/probe') and a specific resource ('version-pinned Codex app-server connection'), which distinguishes it from siblings focused on other aspects like doctor, discover, or protocol. However, the dual verb 'start/probe' is slightly ambiguous about whether the primary function is initiating or checking status, preventing a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus any of the many codex_app_* siblings. There are no exclusions, prerequisites, or alternative tool mentions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It doesn't state whether the tool is read-only, what 'live' implies, whether external calls are made, or any side effects. The bare noun list leaves the agent without important safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the discoverable resources. It is efficiently written with no redundant filler, though the enumeration is somewhat long. It earns its place by covering most of the action values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is far from complete. It provides no information on return formats, pagination, error behavior, or the meaning of the additional parameters, making it insufficient for a complex discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter documentation. It provides no explanation of 'cwds', 'force', 'limit', 'cursor', 'detail', or 'action' semantics beyond listing some enum values in prose. It fails to clarify the meaning or usage of the other five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Discover' and enumerates the target resources (models, features, MCP servers, apps, etc.), which conveys the tool's purpose. However, it doesn't explicitly distinguish this from sibling tools like 'codex_app_status' or 'codex_app_rpc_read', and it omits the 'config_requirements' action from the schema, so it's not a perfect differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tools. The description simply states what it does, offering no context about appropriate use cases, prerequisites, or when to choose an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'cursor-paginated' (indicating pagination) and the three actions, but does not disclose potential side effects (e.g., whether 'respond' is a mutating operation), authorization requirements, or what happens on error. This is insufficient for a tool with multiple action types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, readable sentence that efficiently lists the three operations and a key behavior (cursor-paginated). It is not overloaded with fluff, but it could be structured more clearly to separate the actions and their associated parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, 3 actions, nested objects, no output schema, and no annotations, the one-sentence description is severely under-specified. It gives any indication of return values, prerequisites, or how to use the 'respond' action meaningfully. The context is far from complete for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 11 parameters. For example, the 'action' enum is implied by the verbs 'poll', 'list', and 'respond', but there is no mapping to the rest parameters like 'answers', 'decision', 'execpolicyAmendment', etc. The description adds zero semantic value to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Poll cursor-paginated thread events, list pending approvals/input, or respond to a deferred app-server request.' It clearly distinguishes the tool from siblings by enumerating three distinct actions tied to events and approvals. This is far more specific than a vague 'manage events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool can do but gives no guidance on when to choose it over sibling tools like codex_app_thread or codex_app_review. There are no explicit alternatives or conditions for use; it merely implies functionality without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions that commands are argv arrays and that danger-full-access is an explicit governed option, but it does not explain side effects, permission requirements, or what 'control' entails (e.g., write/resize/terminate actions). This is insufficient for a tool with write and terminate capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It conveys core details efficiently, though the brevity leaves many important aspects unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool with 17 parameters, 4 distinct actions, nested objects, no output schema, and no annotations. The description covers only a small fraction of what an agent needs to know: it omits action semantics, lifecycle behavior, I/O handling, timeouts, error handling, and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially clarifies the 'command' parameter by noting it uses argv arrays and hints at the sandbox enum via 'danger-full-access', but 15 other parameters (cwd, env, tty, size, processId, etc.) remain completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs and controls app-server command/exec sessions, using a specific verb and resource. It distinguishes from siblings like codex_app_process by focusing on command/exec sessions rather than general process management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as codex_app_process, codex_app_rpc, or codex_app_fs. It does not mention exclusions, prerequisites, or scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full transparency weight. It discloses that jobs use a SQLite ledger and expose persisted identifiers, which is useful, but it omits critical behavioral details such as side effects of cancel/resume, asynchronous execution behavior, error handling, or durability guarantees beyond the ledger mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, with two short sentences that front-load the primary actions and resource. It avoids fluff and gets to the point quickly, though a bit more detail could be packed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with 7 parameters, no annotations, no output schema, and several sibling tools, this description is far from complete. It does not clarify how to choose between actions, what values are valid for request, the meaning of state, or what output to expect, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It echoes the action enum with verbs like 'start' and 'cancel' but provides no explanation of jobId, kind, state, request, limit, or includeHistory, nor how these parameters interact with actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Start, inspect, resume, or cancel') and a defined resource ('durable background goal/turn jobs'). It distinguishes itself from sibling tools by emphasizing durability and persisted thread/turn identifiers, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'durable background goal/turn jobs' implies when this tool is appropriate, and the lifecycle verbs suggest common use cases. However, it does not explicitly explain when to use this versus sibling tools like codex_app_goal or codex_app_turn, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of explaining side effects and safety. The text does not disclose whether these actions are destructive, require specific permissions, or how interruption affects thread state. This is a significant gap for a tool that can mutate execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. It immediately communicates the core actions and target resource, making it easy to parse quickly. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 13 parameters and no output schema, yet the description provides almost no contextual information about turn lifecycle, expected inputs, return values, or error handling. It is inadequate for an agent to select and invoke the tool correctly without additional documentation. The complexity demands significantly more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal value for the parameters. It does clarify the 'action' parameter's allowed values, but the remaining 11 parameters (cwd, mode, model, effort, images, prompt, turnId, sandbox, outputSchema, approvalPolicy, approvalReviewer) are left unexplained. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary actions (start, steer, interrupt) on a specific resource (a turn on a loaded Codex thread). It distinguishes from siblings like codex_app_thread by focusing on turn-level control rather than thread management. The verb set 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as codex_app_thread or codex_app_process. The description does not include any context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only discloses that mutations require the unsafe RPC operator gate. It does not mention side effects, reverting changes, authorization needs, or the destructive potential of specific operations like memory.reset or plugin.uninstall, offering minimal behavioral transparency for such a broad tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's scope and immediately adds an important operational note (the mutation gate). No unnecessary words or repetition, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a large operation list (80+ enums), no output schema, and no annotations, so the description must compensate. A one-sentence high-level overview covering many resource categories is insufficient for such complexity; it lacks per-operation details, return value expectations, and safety guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'params', 'timeoutSeconds', or 'requireSupported' fields. The only connection to parameters is the vague phrase 'Typed access to ... operations,' which indirectly refers to the operation enum but adds no concrete meaning to the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Typed access to account, config, apps/plugins/skills, environment, search, memory, realtime, and remote-control app-server operations,' which clearly identifies the tool's resource scope. However, the verb 'access' is generic and doesn't explicitly differentiate it from sibling tools like codex_app_rpc or codex_app_command, so it loses the sibling-distinguishing point for a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage constraint: 'Mutations require the unsafe RPC operator gate,' which tells the agent when mutations are permitted. However, it does not explicitly compare with sibling tools or state when not to use this tool, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the tool is disabled until allowlists are configured, which is essential operational knowledge. However, it does not disclose other behavioral aspects such as authentication requirements, error handling, or side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, both front-loaded with critical information. The first sentence states the core action, and the second provides an important operational constraint. Every word earns its place, with no fluff or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, nested objects, no output schema, and no annotations. The description only covers the tool's general purpose and one restriction, leaving out essential context such as expected argument structure, return values, and error scenarios. This is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (server, tool, arguments, threadId, _meta). The agent is left without any guidance on how to fill the required fields, making parameter usage completely opaque. The description does not compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with a specific verb ('Call') and resource ('an explicitly allowlisted downstream MCP/SaaS tool through app-server'). It clearly differentiates from sibling tools by focusing on downstream tool invocation. The phrase 'explicitly allowlisted' adds necessary context about the tool's scope, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Disabled until server and tool allowlists are configured'), which is useful guidance for when the tool can be used. However, it does not explain when to choose this tool over sibling alternatives, nor does it mention any fallback or excluded use cases. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the tool is read-only and serves as an escape hatch, implying it may permit RPC methods not in the allowlist. But it doesn't specify behavior for invalid or non-read-only methods, nor does it mention authentication, errors, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the core concept. However, it is so brief that it sacrifices useful detail, though conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only a one-sentence description, the tool lacks sufficient information for an agent to invoke it correctly. Key aspects like supported methods, parameter structure, return format, and error conditions are absent. This is inadequate for a tool that appears to be an RPC endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention 'method' or 'params' at all. While the parameter names are somewhat self-explanatory, the description fails to explain how to construct the 'params' object or how the method string relates to the RPC API. This is a significant gap given the low schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an 'escape hatch for a strict read-only RPC allowlist,' clearly indicating it handles read-only RPC calls outside the normal allowlist. It distinguishes from the sibling codex_app_rpc via the 'read-only' qualifier, though it lacks a direct verb like 'call' or 'invoke.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'escape hatch' implies use when the standard allowlist does not cover a needed read-only method, and 'version-forward-compatible' suggests handling newer methods. However, it provides no explicit when-to-use/when-not-to-use guidance, nor does it reference alternatives like codex_app_rpc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that goals are persisted, autonomous, and run until terminal status, which is useful. However, it doesn't discuss side effects, resource usage, or prerequisites, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no fluff. It's appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 34 parameters, 5 enums, no annotations, and no output schema, this description is far too sparse. It doesn't cover actions, requirements, or return behavior, making it inadequate for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 34 parameters. It provides no meaning beyond the bare types and enums in the schema, so the agent cannot infer parameter usage or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb ("Start or manage") and resource ("persisted autonomous goal"), and adds context about the runtime generating continuation turns. However, it doesn't strongly differentiate from sibling tools like codex_app_process or codex_app_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for persisted autonomous goals that need continuation turns, but it doesn't explicitly state when to use this tool over alternatives or mention exclusions. There's no guidance on choosing this vs. sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions execution modes 'inline or detached' but does not explain what these mean, nor does it disclose whether the review is read-only, what side effects might occur, or what the output will be. This is insufficient for a 39-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Run the native app-server reviewer') and packs essential information about execution modes and targets without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (39 parameters) and the absence of output schema or annotations, the description is far from complete. It does not explain what the reviewer does, what inputs are required beyond the targets, or what the result looks like. The description is too brief to contextualize the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 39 parameters with 0% description coverage. The description adds only indirect hints about parameters like baseBranch, commit, and instructions by naming them as targets. It does not add meaningful semantic detail for the vast majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run the native app-server reviewer' against specific targets. It uses a specific verb and resource, and the mention of 'inline or detached' and the various targets distinguishes it from sibling tools like codex_app_status or codex_app_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'against uncommitted changes, a base branch, a commit, or custom instructions.' This implies the tool is appropriate for review scenarios. However, it does not explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the allowlist mechanism and the environment variable requirement for stateful methods. It adds valuable security/behavioral context beyond the schema, though it omits error behavior or side-effect specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and immediately highlight the key security constraints. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a general-purpose raw RPC with no output schema and open-ended parameters. The description covers the security model but lacks return value expectations, error conditions, and how it relates to the sibling codex_app_rpc_read. It is minimally sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'method', 'params', or 'timeoutSeconds' parameters. It implicitly ties 'method' to read/stateful categories but provides no concrete values, formats, or syntax, leaving users under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'raw app-server RPC' and differentiates read vs stateful methods, which distinguishes it from siblings like codex_app_rpc_read. However, the actual action (invoking an RPC method) is implied rather than explicitly stated as a verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context on when to use the tool: read methods are allowed by default, while stateful methods need extra configuration. But it does not explicitly name alternatives or say 'use codex_app_rpc_read for safe read-only operations,' leaving the guidance implicit rather than a clear exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the operator gate requirement for restart, which is a meaningful behavioral constraint. However, it does not describe potential side effects of restart (e.g., connection drop) or details about the metrics output, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by a critical prerequisite. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects), and the description covers the core actions. However, without an output schema, it does not explain what the metrics return or what happens after restart, leaving some context incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the two enum values: 'Read gateway counters' maps to 'metrics' and 'explicitly restart' maps to 'restart.' This adds meaning beyond the raw enum list, though it doesn't explicitly name the parameter 'action.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual functionality: 'Read gateway counters or explicitly restart the owned app-server connection.' This provides a specific verb+resource and distinguishes it from sibling tools like codex_app_status or codex_app_rpc_read by its focus on runtime counters and connection restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to read counters or restart the connection. It provides one explicit precondition: 'Restart requires the unsafe RPC operator gate.' However, it does not offer alternative tool guidance or exclusions, so the guidance is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 labels the operation as 'read-only', which is important safety information, but it does not mention side effects, prerequisites, permissions, or what the output looks like. Some value is added, but more context would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and lists the diagnostic categories clearly. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless diagnostic tool, the scope is well defined by naming the four diagnostic categories. The main gap is the absence of any mention of the output format or return behavior, which would help the agent know what to expect after invocation. However, given the low complexity and empty schema, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the input schema is empty, so there are no parameter semantics to explain. The description correctly does not attempt to describe parameters. Baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Run') and specifies the exact resource: read-only diagnostics for app-server, account, config-requirements, and Windows sandbox-readiness. It also distinguishes itself from related tools by explicitly stating 'without invoking codex doctor', making its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when read-only diagnostics are needed and codex doctor should be avoided—but it does not explicitly state alternative tools or provide a clear when-not-to-use scenario. The context is present but only implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses important traits: durability, timezone-awareness, RRULE-based recurrence, idempotency, misfire policy, and retries. This goes beyond a simple 'schedule jobs' statement, though it still omits details about action-side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense, front-loaded sentence that conveys essential capabilities without fluff. Every phrase adds value, and it is 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 12 parameters, an 8-value action enum, a nested request object, and no output schema. The description does not explain action-specific behaviors, return values, or error scenarios. Given the high complexity and lack of annotation support, the description is insufficient for an agent to confidently invoke the correct action and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and there are 12 parameters. The description meaningfully maps to several key parameters (rrule, timezone, idempotencyKey, misfirePolicy, retryCount, retryBackoffSeconds, request), but it does not clarify important parameters like action values, scheduleId, name, limit, or startAt. It partially compensates for missing schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create and operate') and resource ('durable timezone-aware RRULE schedules'), and it distinguishes this tool from sibling job/goal/turn tools by emphasizing scheduling semantics. It precisely communicates the core purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool—for durable, timezone-aware, recurring schedules with idempotency and retries—which implies scheduling use cases versus one-off job execution. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![codex-mcp MCP server](https://glama.ai/mcp/servers/zai-one/codex-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zai-one/codex-mcp)

Score Badge

Copy to your README.md:

[![codex-mcp MCP server](https://glama.ai/mcp/servers/zai-one/codex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zai-one/codex-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zai-one/codex-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server