Skip to main content
Glama
Sign In
codex-mcp-server

codex-mcp-server

by etheaven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

review

Run Codex code analysis on git changes—uncommitted work, a branch against a base, or a single commit—and return prioritized findings with file:line references. Read-only.

Instructions

Run a Codex code review (codex review) on git changes: uncommitted work, a branch against a base, or a single commit. Returns prioritized findings with file:line references. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "review"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoReview the current branch against this base branch
modelNoOptional model ID, passed straight to Codex CLI (-m). Omit to use the default from ~/.codex/config.toml (recommended). Do not guess IDs: call the list-models tool to see the models this Codex install offers.
titleNoOptional title shown in the review summary
commitNoReview the changes introduced by this commit SHA
promptNoCustom review instructions. Codex CLI only accepts this when uncommitted/base/commit are NOT set.
timeoutNoMaximum execution time in milliseconds. Default: CODEX_MCP_TIMEOUT_MS env var, else 600000 (10 min).
workingDirNoGit repository to review. Defaults to CODEX_MCP_CWD / the client working directory.
uncommittedNoReview staged, unstaged and untracked changes in the working directory
reasoningEffortNoOptional reasoning effort (model_reasoning_effort). Common values: low, medium, high, xhigh, max; some models also take none, minimal or ultra. Support varies per model: list-models shows the levels each model accepts. Omit to use the model/config default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations at all, the description carries the full burden, and it does disclose the read-only nature and the return shape (prioritized findings with file:line references). It says nothing about the external Codex CLI dependency, expected latency (the schema hints at a 10-minute default timeout), or failure modes when the CLI is missing or unauthenticated — material gaps for a tool that shells out to another process.

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?

Three short sentences: capability, output shape, safety profile. The mode enumeration is front-loaded and the read-only guarantee is a single closing word with zero 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 nine-parameter, no-output-schema tool, the description covers what it does, its modes, and its return format. It is slightly thin on mutual exclusivity between base/commit/uncommitted and on the cost of an external CLI invocation, but nothing essential to calling it correctly is missing.

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 coverage is 100%, so every one of the nine parameters is already documented, and the description only implicitly links its three modes to uncommitted/base/commit. It adds no semantics beyond the schema — no guidance on combining parameters, on how prompt interacts with the mode flags, or on workingDir defaults — which is the expected baseline when the schema does the work.

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?

"Run a Codex code review (codex review) on git changes" names a specific verb and resource, and the three modes (uncommitted, branch-vs-base, single commit) pin down the scope precisely. It does not explicitly contrast itself with siblings like ask-codex or batch-codex, so an agent must infer the boundary from the word "review".

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 enumerates the three legitimate review scenarios, which map cleanly onto the uncommitted/base/commit parameters, so an agent knows which mode to pick. It stops short of exclusions — nothing says when to prefer ask-codex or batch-codex instead, or what happens if conflicting mode parameters are supplied.

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

Deploy Server

Other Tools