mcp-codex-dev

by FYZAFH

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: exec for raw CLI execution, health for environment checks, review for code reviews, session_discard and session_list for session management, and tdd for TDD-based implementation. There is no overlap or ambiguity in functionality, making tool selection straightforward for an agent.
Naming Consistency4/5
Most tools follow a consistent verb-based naming pattern (exec, health, review, tdd), but session_discard and session_list deviate with a noun_verb structure. This minor inconsistency is still readable and does not severely impact usability, though it breaks the overall pattern slightly.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose of interacting with Codex CLI. Each tool serves a specific, necessary function (execution, health checks, reviews, session management, TDD), and none feel redundant or out of place, making the count appropriate.
Completeness4/5
The tool set covers core workflows for Codex CLI interaction, including execution, health, reviews, and session management. However, there are minor gaps, such as no explicit tool for creating or updating sessions beyond resume capabilities, which agents might need to work around using exec or other tools.
Average 3.5/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'checks' which implies a read-only diagnostic operation, but doesn't specify if it modifies anything (e.g., via 'ensureTrackingDir'), what permissions are needed, or how results are returned. For a tool with parameters that could affect system state, this is a significant gap in 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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a diagnostic tool, making it easy to parse and understand quickly.
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 (3 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the checks entail, what output to expect, or behavioral traits like side effects from 'ensureTrackingDir'. For a diagnostic tool, more context is needed to guide effective use.
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 schema description coverage is 100%, meaning all parameters are well-documented in the input schema. The description adds no additional meaning beyond implying general checks, so it meets the baseline for adequate but not enhanced parameter semantics.
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 ('Run environment and configuration checks') and resources ('Codex CLI, config, Git, filesystem'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'exec' or 'review', which might also involve system operations, so it doesn't reach the highest score.
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 'exec' or 'review', nor does it mention any prerequisites or exclusions. It simply states what the tool does without context for its application, leaving the agent to infer usage scenarios.
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 'Supports session resume,' which adds useful context about session management. However, it lacks details on critical behaviors like error handling, permissions needed, rate limits, or what 'raw execution' entails (e.g., potential side effects). This is inadequate for a tool that likely performs system-level operations.
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 highly concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second adds key behavioral context ('Supports session resume'). Every word earns its place, making it efficient and clear.
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 (invoking CLI commands, session management) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'raw execution' means in terms of safety, what the output looks like, or how errors are handled. This leaves significant gaps for an AI agent to use the tool effectively.
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 100%, so the input schema fully documents the three parameters (instruction, sessionId, workingDirectory). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate as the schema handles the heavy lifting.
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: 'Invoke Codex CLI with a plain instruction.' It specifies the verb ('invoke') and resource ('Codex CLI'), and distinguishes it from siblings by mentioning 'No template, no context wrapping — just raw execution.' However, it doesn't explicitly differentiate from all siblings like 'review' or 'tdd', keeping it from a perfect 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 provides some usage context by stating 'No template, no context wrapping — just raw execution,' which implies when to use this tool (for direct CLI commands) versus alternatives that might involve templates. However, it doesn't explicitly name alternatives or specify when-not-to-use scenarios, leaving gaps in guidance.
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 mentions filtering capabilities but doesn't describe key behaviors such as pagination, rate limits, authentication requirements, or what 'tracked' means in practice. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic filtering.
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, efficient sentence that front-loads the core purpose ('List tracked Codex sessions') and adds essential detail ('Can filter by type and status'). There is no wasted verbiage, and every word contributes directly to understanding the tool's functionality.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and filtering options but lacks details on behavioral aspects like return format, error handling, or session tracking scope. Without annotations or output schema, the description should do more to compensate, but it meets a minimum viable threshold.
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 100%, with clear descriptions for all parameters (e.g., 'Session type filter'). The description adds minimal value by mentioning 'filter by type and status,' which aligns with the schema but doesn't provide additional context like default behaviors or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 verb ('List') and resource ('tracked Codex sessions'), making the purpose immediately understandable. It distinguishes this as a listing/filtering tool rather than a creation or modification tool. However, it doesn't explicitly differentiate from potential sibling tools like 'exec' or 'review' that might also involve sessions.
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 the phrase 'Can filter by type and status,' suggesting this tool is for retrieving sessions with optional filtering. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'session_discard' or 'tdd,' nor does it mention prerequisites or exclusions. The guidance is functional but lacks comparative context.
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 describes key behaviors: it invokes an external CLI (Codex), uses a specific template, returns structured results, supports session continuation, and has different review modes. However, it doesn't mention critical aspects like whether this is a read-only or mutating operation, authentication requirements, rate limits, error handling, or what the 'structured review results' look like. For a complex 11-parameter tool with no annotations, this leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized (three sentences) and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second covers input/output and session continuation, the third explains the 'full' mode nuance. There's minimal waste, though the third sentence is somewhat dense and could be slightly clearer.
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 complexity (11 parameters, no annotations, no output schema), the description is incomplete. It covers the purpose, basic usage, and session behavior, but lacks details on output format (what 'structured review results' entail), error conditions, side effects, and how it differs from sibling tools. For a code review tool with many parameters and no structured output definition, more context is needed to be fully helpful to an agent.
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 schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds some context by mentioning 'git range' (mapping to baseSha/headSha), 'description info' (mapping to instruction/whatWasImplemented), and sessionId usage. However, it doesn't provide additional semantic meaning beyond what's in the schema descriptions (e.g., explaining relationships between parameters or usage nuances). With high schema coverage, the baseline is 3.
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: 'Invoke Codex CLI for code review. Uses built-in code-reviewer template.' It specifies the action (invoke Codex CLI), the resource (code review), and the method (built-in template). However, it doesn't explicitly distinguish this tool from its sibling 'tdd' (which might also involve code-related operations), so it doesn't reach the highest score.
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 for usage: 'Pass git range and description info' and 'Supports continuing previous review sessions via sessionId.' It also explains different modes ('full', 'spec', 'quality') and how to resume sessions. However, it doesn't explicitly state when NOT to use this tool or name alternatives among siblings (e.g., when to use 'tdd' instead), so it's not a perfect 5.
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 describes key behaviors: 'Injects TDD methodology template that enforces writing tests before production code' and 'Supports session resume for iterative TDD cycles.' However, it doesn't mention important aspects like whether this tool modifies files (destructive), requires specific permissions, has rate limits, or what the return format looks like. The description adds some behavioral context but leaves significant gaps for a tool that presumably writes code and tests.
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 three sentences that each add value. The first sentence states the core purpose, the second explains the TDD enforcement mechanism, and the third mentions session resumption capability. There's no wasted text, and the information is front-loaded with the main purpose stated first. It could be slightly more structured by explicitly separating purpose from features.
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 this is a complex code implementation tool with 6 parameters and no annotations or output schema, the description provides basic context about TDD methodology and session management but lacks important details. It doesn't explain what the tool returns, how errors are handled, what file modifications occur, or prerequisites for use. For a tool that presumably creates and modifies code files, more behavioral transparency would be expected.
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 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'session resume' which relates to the 'sessionId' parameter, but doesn't provide additional semantics about parameter interactions or usage patterns. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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: 'Invoke Codex CLI to implement code using strict Test-Driven Development (Red-Green-Refactor).' It specifies the exact methodology (TDD with Red-Green-Refactor cycle) and distinguishes it from siblings like 'exec' (general execution) or 'review' (code review). The description goes beyond the tool name 'tdd' by explaining what TDD means in this context.
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 context ('Supports session resume for iterative TDD cycles') but doesn't explicitly state when to use this tool versus alternatives like 'exec' for general code execution or 'session_list' for session management. It mentions session resumption but doesn't provide clear guidance on when to start a new session versus resume an existing one, or when TDD is preferred over other development approaches.
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 behavioral disclosure. It effectively describes key behavioral traits: the tool discards sessions, has a default refusal mechanism for active sessions, and allows overriding with force=true. This covers destructive intent and conditional behavior, though it lacks details on permissions or error handling.
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 the core purpose and follows with a crucial behavioral detail in a single, efficient sentence. Every word earns its place, avoiding redundancy and maintaining clarity.
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 as a destructive operation with no annotations or output schema, the description is reasonably complete. It covers the main action and a key behavioral constraint, but could benefit from mentioning prerequisites or potential side effects to be fully comprehensive.
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 100%, so the schema already documents all parameters. The description adds some context by explaining the interaction between sessionIds and force, but does not provide additional meaning beyond what the schema specifies for parameters like workingDirectory.
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 verb ('discard') and resource ('Codex sessions'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools like 'session_list' by indicating a destructive operation rather than a read operation.
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 by mentioning the default behavior of refusing to discard active sessions unless force=true. However, it does not explicitly state when not to use it or name alternatives, such as whether 'session_list' should be consulted first.
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:

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

Score Badge

Copy to your README.md:

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

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/FYZAFH/mcp-codex-dev'

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