claude-code-codex-agents

by tsunamayo7

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but 'execute' and 'trace_execute' are nearly identical aside from output detail, and 'session_list' and 'status' both report session info. Descriptions clarify the differences, so agents should generally select correctly.
Naming Consistency4/5
The majority of tools follow a verb_noun pattern (e.g., execute, review, explain, spawn_codex_agent), but 'session_list', 'session_continue', and 'status' deviate to noun_verb or bare noun. This is a minor inconsistency in an otherwise predictable naming scheme.
Tool Count4/5
15 tools is at the upper boundary of appropriate for a Codex CLI wrapper. The set covers task execution, code analysis, session management, and background agent lifecycle, but a few tools like 'trace_execute' and 'status' feel somewhat redundant with 'execute' and 'session_list', making the set slightly over-sized.
Completeness4/5
The toolkit covers the core workflows: single, parallel, and traced execution; code review, explanation, generation, and discussion; session listing and continuation; and background agent lifecycle. A notable gap is the lack of a cancellation mechanism for running tasks, but the overall surface is fairly complete for the domain.
Average 3.7/5 across 15 of 15 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
This repository is licensed under MIT License.
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 fully disclose behavior. It mentions 'background' and 'Claude Code-style lifecycle' but does not explain important traits like how the worker is managed, how to interact with it, or what happens on timeout. This leaves significant ambiguity for an agent.
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 that front-loads the action, containing no extraneous words. However, it is under-specified, so while structure is good, the content is minimal.
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 complexity (7 parameters, output schema) and lack of annotations, the description is too sparse. It does not clarify the lifecycle, return behavior, or parameter usage, making it insufficient for an agent to invoke 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% (no parameter descriptions in the schema), and the description does not explain any of the 7 parameters (prompt, cwd, model, sandbox, timeout, agent_type, description). It fails to compensate for the lack of schema information.
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 the verb 'Start' with a specific resource ('background Codex worker'), making the core function clear. It distinguishes itself from sibling tools like execute by specifying 'background' and 'Claude Code-style lifecycle', 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like execute or parallel_execute, nor does it mention any exclusions or prerequisites. The only hint is 'background', which implies async use, but there is no explicit 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, the description carries the full burden of disclosure. It states the core waiting behavior but does not mention timeout semantics (e.g., default 30s), whether it blocks indefinitely, what happens on timeout or error, or whether it returns the agent's final output.
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, focused sentence with no redundant words. It is easy to parse and directly conveys the tool's primary action.
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?
Despite having an output schema, the description lacks essential context such as timeout behavior, interaction with other agent management tools, and when to prefer waiting versus polling status. The tool is simple, but the description is too sparse to fully guide correct usage.
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 mention agent_id or timeout at all. The agent must infer parameter purposes from names alone, which is insufficient given the absence of schema descriptions.
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 specific verb ('Wait') and resource ('background Codex agent') with a clear completion condition ('finish its current turn'). It distinguishes the tool from siblings like spawn, send, list, and close by focusing on the waiting aspect.
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 provides no explicit when-to-use guidance or exclusions. It does not mention how this differs from status or other session monitoring tools, nor does it state prerequisites or common usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, side effects, or prerequisites. For a status tool, one might infer it is non-mutating, but this is not stated. The description carries no burden beyond basic purpose, which is insufficient without annotation support.
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, compact sentence that directly states the tool's function with no redundant words. It is front-loaded and appropriately sized for a simple status-check tool, earning a high score for conciseness.
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?
For a simple no-parameter tool with an output schema, the description is minimally viable but leaves gaps. It does not explain when to use it relative to session_list or whether any side effects exist. The absence of usage guidelines and behavioral transparency reduces completeness, though the output schema may cover return values.
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 has zero parameters, and the input schema is empty. The description adds no parameter-level information because none is needed. Baseline for 0-parameter tools is 4, and the description meets this baseline without needing to compensate for schema gaps.
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 'Codex CLIの状態とセッション情報を確認' clearly states the tool's purpose: to check Codex CLI status and session information. It uses a specific verb ('確認' / check) and resource ('状態' and 'セッション情報'), but does not explicitly differentiate from sibling tools like session_list, which may overlap in functionality.
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 provides no guidance on when to use this tool versus alternatives such as session_list or session_continue. It is a bare statement of purpose without context, exclusions, or explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool delegates to Codex CLI and returns a structured report, without explaining potential filesystem modifications, the meaning of sandbox modes, or safety implications. The sandbox parameter hints at risk but is not elaborated.
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 front-loaded with a single clear purpose sentence followed by a compact, well-organized Args list. Every line provides useful information with no wasted words.
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?
Given the tool's potentially dangerous ability to execute tasks and the presence of several sibling tools, the description lacks usage context and safety notes. However, an output schema exists and the parameter list is complete, making the description minimally viable for basic invocation.
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 schema has no property descriptions (0% coverage), but the description's Args section provides meaningful one-line explanations for all five parameters, including the allowed sandbox values and the default behavior of cwd. This compensates well for the missing schema descriptions, though the explanations are terse.
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 'Codex CLI(GPT-5.4)にタスクを委譲' (delegate tasks to Codex CLI) and notes that it returns a structured report, giving a clear verb and resource. However, it does not differentiate this tool from sibling tools like parallel_execute or spawn_codex_agent.
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?
There is no guidance on when to use execute versus alternatives such as parallel_execute, trace_execute, or the codex agent tools. The description only lists parameters and provides no context for tool selection.
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 for behavioral disclosure. It does reveal the non-obvious behavior that the last known result is kept, which is helpful. However, it omits important traits for a mutating/destructive operation: whether the agent is terminated, idempotency, what happens if the agent is not idle, and any side effects or permission requirements.
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 that states both the action and the key behavioral outcome. It contains no filler, redundancy, or irrelevant detail, making it highly efficient.
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?
Given the tool's low complexity (one parameter), the presence of an output schema, and a clear one-sentence description, the core functionality is reasonably covered. However, it lacks usage guidance and behavioral caveats that would make it fully self-contained for an agent deciding whether and when to invoke it.
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 the undocumented agent_id parameter. It does not explain the format, how to obtain it, or whether it refers to a session ID or process ID. The parameter name is self-explanatory at a basic level, but no additional semantic value is provided beyond the raw 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 a specific verb ('Close') and resource ('idle Codex agent'), and adds a meaningful outcome ('keep its last known result'). This clearly distinguishes it from sibling tools like spawn_codex_agent, wait_codex_agent, and list_codex_agents, which handle other lifecycle stages.
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 'idle Codex agent' implies it should be used when an agent has finished some work and no longer needs to execute, and 'keep its last known result' signals that results are preserved. However, it does not explicitly state when to use this versus waiting (wait_codex_agent) or listing (list_codex_agents), nor does it mention any exclusions.
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 behavioral disclosure. It mentions that the tool requests from 'Codex CLI(GPT-5.4)', implying an external call, but it does not disclose whether the operation is read-only, whether code is transmitted externally, what side effects might occur, or the response format. This is insufficient for an agent to anticipate the tool's behavior beyond a simple explanation request.
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, focused sentence followed by a terse bullet list of arguments. It is front-loaded with the purpose, and every line provides necessary information without redundancy. The structure is clean and easy to parse, achieving maximum clarity with minimal words.
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?
For a simple tool with three parameters and an output schema, the description covers the core purpose and parameter meanings. However, it lacks any guidance on usage context, and given the absence of annotations, it does not disclose behavioral aspects like side-effect safety or external service invocation details. The description is adequate but leaves clear gaps in usage and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (schema coverage 0%), but the description's Args section explicitly defines each parameter: code as 'the code to explain', language as 'programming language', and detail_level as 'detail level (brief/medium/detailed)'. It adds meaning to all three parameters and even enumerates valid value options for detail_level, which the schema does not provide. This fully compensates for the schema's lack of semantics.
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 opens with a clear statement: 'Codex CLI(GPT-5.4)にコードの解説・分析を依頼' (request code explanation/analysis from Codex CLI). This names a specific action (request explanation/analysis) and a resource (Codex CLI), clearly distinguishing it from sibling tools like execute, generate, or review. The purpose is unambiguous and matches the tool name.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions like 'use when you need to understand existing code' or note that execution tools should be used for running code. The only context is the tool's own purpose, with no exclusions or alternative comparisons.
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 behavioral traits. It reveals that it includes a full JSONL event timeline and is the same execution as 'execute', but it does not mention potential side effects, permission requirements, or performance implications. The execution nature implies code execution, but the safety profile remains unknown.
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 compact, starting with the primary purpose, then the differentiation, then a clean Args list. Every sentence adds information; only minor redundancy in the arg glosses.
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 description, combined with an output schema (which documents return values), covers the core functionality and arguments. It lacks clarifications on error behavior, permissions, or exactly when the trace output is beneficial, leaving some gaps for an agent. The presence of the output schema reduces the need to describe return values, but behavioral context is still thin.
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?
The input schema has no parameter descriptions (0% coverage), so the description's brief glosses (e.g., '実行するタスクの説明' for prompt) add basic meaning. However, some glosses are tautological (e.g., 'サンドボックスモード' for sandbox), providing limited extra value. It covers all parameters but without depth.
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 opens with 'Codex実行の全イベントトレースを返す' (returns all event traces of Codex execution), explicitly naming the resource and action. It further clarifies 'executeと同じ実行だが、全JSONLイベントのタイムラインも含む' which distinguishes it from the sibling 'execute' by adding the trace timeline. This clearly states what it does.
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 phrase 'デバッグ・分析用の詳細モード' explicitly identifies debugging/analysis as the intended use case, giving clear context for when to choose this over the standard 'execute'. It does not explicitly exclude alternatives or list when-not-to-use, but the stated purpose is sufficient for most agents.
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 carries the full burden. It only states the action but does not disclose whether the call blocks, returns immediately, or what happens if the agent is not found. The timeout parameter hints at waiting behavior but is never explained in the description.
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 sentence that front-loads the action and resource with no filler words. It is optimally concise for a tool meant to continue an existing agent.
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 has 3 parameters and an output schema, but the description is minimal. It lacks details on timeout semantics, error behavior, or how it relates to sibling tools like session_continue. For a simple tool, it is marginally adequate but leaves gaps around behavior and edge cases.
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?
The description indirectly adds meaning to 'agent_id' (existing agent) and 'message' (new instruction), but it does not explicitly describe any parameters. With 0% schema coverage, the 'timeout' parameter is entirely absent from the description, so it only partially compensates for the schema's silence.
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 the specific verb 'continue' and resource 'existing background Codex agent', clearly distinguishing it from siblings like spawn_codex_agent (create) and wait_codex_agent (wait). It is unambiguous about the tool's function.
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 phrase 'existing background Codex agent' implies it is for already-spawned background agents, differentiating it from spawn_codex_agent. However, it does not explicitly mention alternatives or when-not-to-use conditions, so some guidance is left implicit.
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 carries the full burden of behavioral disclosure. It only says the tool requests a review and is part of an 'Adversarial Review Loop', but does not mention side effects (e.g., external API calls, cost, latency) or whether it mutates state. This is a significant gap for an operation that invokes a CLI.
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 concise: one line for purpose, one line for context, and a clean Args list. It is immediately readable and well-structured. Every sentence earns its place without unnecessary elaboration.
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 description covers purpose and parameters well, and an output schema exists (so return values need not be explained). However, it lacks context about the 'Adversarial Review Loop' workflow, any prerequisites, or behavioral specifics. Given the complexity of invoking an external CLI, the description is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an explicit Args list explaining each parameter: code (review target), language (programming language), and focus (comma-separated review areas). Since the schema itself has 0% description coverage, this fully compensates and adds meaning beyond the basic type/default information.
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: 'Codex CLI(GPT-5.4)にコードレビューを依頼' (request a code review from Codex CLI). This is a specific verb+resource combination, and it is distinct from sibling tools like 'explain' and 'generate'. The additional phrase 'Adversarial Review Loopの実行部分' provides context without obscuring the main action.
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 through its explicit purpose ('request code review') but does not state when to use this tool versus alternatives. There is no mention of exclusions or alternative tools such as 'explain' or 'discuss'. The reference to 'Adversarial Review Loop' hints at a specific workflow but offers no concrete guidance on conditions for use.
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 that the tool is interactive and seeks alternate viewpoints, but it does not mention whether it creates or requires a session, whether it has side effects, or how long the interaction lasts. This leaves important behavioral aspects unstated.
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 concise and front-loaded, stating the primary purpose in the first sentence. The Args section is cleanly structured and easy to parse. Every sentence contributes useful information without redundancy.
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 description is simple, but with no annotations and no explicit note about whether the tool uses or affects sessions (given sibling tools like session_list and session_continue), the completeness is average. The existence of an output schema helps, but the description itself does not explain return values or prerequisites, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful Japanese explanations for both parameters: 'topic' as the topic to discuss and 'context' as additional context such as current design or issues. This fully compensates for the 0% schema description coverage and adds real semantic value beyond the raw string type.
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 states a specific verb ('discuss') and resource ('Codex CLI'), and clarifies the purpose: interactively deepen ideas and get alternative perspectives. This distinguishes it from sibling tools like 'execute' or 'generate' by emphasizing a conversational, idea-oriented function.
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 interactive idea exploration ('対話的にアイデアを深掘り'), but does not explicitly state when to prefer this over siblings like 'review' or 'explain', nor does it give exclusions. It offers only implicit context rather than clear usage boundaries.
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. It discloses a meaningful behavioral trait: if output_file is empty, the tool returns code; otherwise it likely writes to a file. However, it does not mention side effects, permissions, or safety implications beyond this, leaving some uncertainty about the tool's 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 short and efficient, starting with a one-line purpose statement followed by a clear parameter list. Every sentence serves a purpose with no extraneous information.
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?
The description adequately covers the tool's purpose and all parameters, and it explains the behavior of the output_file parameter. Given that an output schema exists, the lack of explicit return value documentation is acceptable. However, it omits information about error handling, required environments, or typical use cases, which would make it more 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?
Schema coverage is 0%, but the description compensates by explaining each parameter: description (code spec, Japanese OK), language (programming language), cwd (working directory), and output_file (output path; empty returns code). This adds meaningful context beyond the schema's type and default fields, though it could be more detailed about allowed values or formats.
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 'Request code generation from Codex CLI (GPT-5.4)', which is a specific verb+resource combination. This distinguishes it from sibling tools like execute or review, as the focus is on generating code rather than running or explaining it.
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 tool's purpose implies it should be used when code generation is needed, but there is no explicit guidance on when to use it versus alternatives like execute or discuss. The description does not mention exclusions or alternatives, so it relies on the verb and context for implied usage.
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 of disclosure. It adds some behavioral context by stating each task is individually traced and results are returned in a structured report. However, it does not disclose sandbox behavior, failure handling, resource implications, or security aspects, which are important for a tool that executes tasks in subprocesses.
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 brief and front-loaded with the core purpose, followed by a cleanly formatted Args section. Every sentence provides useful information without redundancy or filler. It is well-structured and easy to parse.
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?
Given the tool's complexity (parallel subprocess execution, five parameters, no annotations), the description covers the essential aspects: purpose, parameter meanings, and output format (structured report). An output schema exists, so return values need not be detailed. However, it could be more complete with a brief note on when to use it relative to sibling tools, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage (only types and defaults), while the description provides meaningful explanations for every parameter: tasks (newline-separated list), model (model to use), sandbox (mode), cwd (working directory), and timeout (overall timeout seconds). This fully compensates for the lack of schema documentation.
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 executes multiple tasks in parallel via subprocesses and returns all results together. This provides a specific verb (execute), resource (multiple tasks), and distinguishing feature (parallel subprocess execution) that sets it apart from sibling tools like 'execute' or 'trace_execute'.
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 when parallel execution of multiple tasks is needed, but it does not explicitly state when to prefer this tool over alternatives such as 'execute' or 'trace_execute'. No exclusions or alternative guidance are provided, so while the context is clear, the tool lacks explicit usage direction.
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 must carry the burden. It states the tool displays a history list and allows confirming thread_id, which establishes it as a read-only operation. However, it does not disclose additional behavioral details such as ordering, pagination, or any required permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise Japanese sentences that front-load the main purpose and then provide the key use case. Every sentence contributes valuable information without waste.
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?
Given the tool's simplicity, zero parameters, and the presence of an output schema, the description is nearly complete. It states the core functionality and links to the relevant sibling tool session_continue. It could mention return value specifics, but the output schema likely covers that, so the description suffices.
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 has zero parameters, so there are no parameter semantics to document. The schema trivially covers 100% of parameters, and the description adds no parameter-specific information. Baseline of 4 applies for zero-parameter tools.
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 uses specific verb '表示' and resource 'Codexセッション（スレッド）の履歴一覧', clearly distinguishing it from sibling tools like session_continue. It also states the practical purpose of confirming thread_id, making the tool's function unambiguous.
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 explicitly mentions session_continue, implying this tool is the precursor for obtaining thread_id before continuing a session. It provides clear context for when to use it, though it does not explicitly exclude alternatives like list_codex_agents.
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 of disclosing behavior. The verb 'list' clearly indicates a read-only operation with no side effects, and it adds specificity with 'tracked background' agents. It does not over-explain, but for a simple list tool, this is adequately transparent.
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 that states exactly what the tool does without any unnecessary words. Every word earns its place, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the description fully covers what the tool does and its scope ('all tracked background Codex agents'). The presence of an output schema means return values need not be described, and no additional context is needed for correct invocation.
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 has zero parameters, and the schema coverage is 100% (since there are none). The rubric sets a baseline of 4 for zero-parameter tools, and the description appropriately does not add param information where none is needed.
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 the specific verb 'list' and clearly identifies the resource as 'tracked background Codex agents,' which distinguishes it from sibling tools like spawn_codex_agent or close_codex_agent. It also specifies the scope with 'all,' leaving no ambiguity about what the tool returns.
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 implies a clear use case: to retrieve all tracked background Codex agents. While it does not explicitly mention alternatives or exclusions, the context is evident and sufficient for a simple listing operation, especially given the distinct sibling tools.
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 burden of explaining behavior. It discloses the key trait of auto-selecting the latest session when thread_id is omitted, and describes the take-over-and-continue behavior. It lacks details on side effects or error handling, but for a continuation tool, this is reasonably transparent.
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 succinct and well-structured: a one-line purpose, a follow-up behavioral note, and a clearly formatted Args list. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (return values are covered) and 5 parameters with full descriptions, the description is complete. It covers the purpose, key behavior, and all parameter semantics, making it self-sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by listing and explaining all five parameters in the Args block (prompt, thread_id, model, sandbox, timeout). Each parameter gets a concise but meaningful description, adding semantics beyond the schema's type/default information.
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: '前回のCodexセッション（スレッド）を引き継いで継続実行' (continue by taking over the previous Codex session/thread). This specific verb+resource combination distinguishes it from siblings like session_list (listing) and execute (starting new).
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 by explaining that omitting thread_id automatically takes over the latest session, which guides when to use the tool. However, it does not explicitly state when not to use it or name alternatives, though the sibling tools imply the contrast.
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:

[![claude-code-codex-agents MCP server](https://glama.ai/mcp/servers/tsunamayo7/claude-code-codex-agents/badges/card.svg)](https://glama.ai/mcp/servers/tsunamayo7/claude-code-codex-agents)

Score Badge

Copy to your README.md:

[![claude-code-codex-agents MCP server](https://glama.ai/mcp/servers/tsunamayo7/claude-code-codex-agents/badges/score.svg)](https://glama.ai/mcp/servers/tsunamayo7/claude-code-codex-agents)

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/tsunamayo7/claude-code-codex-agents'

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