Skip to main content
Glama
andreilungeanu

Codex Delegate MCP

by andreilungeanu
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Codex Delegate

Stop burning your frontier agent's limits on boilerplate.

Delegate implementation to the OpenAI Codex CLI — your agent writes the brief and reviews the diff.

npm version npm downloads MCP Registry codex-delegate-mcp MCP server node license: MIT tests

Use your best coding agent where its judgment matters most: understanding the task, shaping the plan, and reviewing the result.

Codex Delegate is the MCP bridge that lets Claude Code, Cursor, Copilot — or any MCP client — hand implementation to the OpenAI Codex CLI, then get a clean, structured result back for review.

A terminal recording of Claude Code delegating to Codex: a health check confirms the Codex CLI, auth and model catalog; an ask-mode run diagnoses why the demo repo prints "today 0", naming commitDay() bucketing by UTC while cellDay() labels by local time, with line numbers; one sentence then fans out to two Codex models at once — one editing the repo, one researching in a separate directory — and the fix lands with tests passing and the footer reading today 4, current streak 23, longest streak 23; finally Codex reviews its own diff and reports three findings

🧠 Frontier quality, kept

Your assistant does what frontier models are actually for: understands the task, writes a precise brief, reviews the finished diff. Codex holds its own as the implementer — guided and checked by a smarter orchestrator. The result reads like frontier work, because a frontier model planned it and signed off on it.

Related MCP server: Universal Coder Bridge

⚡ Done faster

Codex tears through multi-file edits while a frontier chat model would still be streaming the first file. You delegate, keep working with your assistant, and the diff shows up done.

🔋 Your limits stop being the bottleneck

Delegated work runs on the OpenAI Codex CLI and its own usage — separate from your orchestrator's chat quota, though the Codex side still bills its own way. Your Claude, Cursor, or Copilot subscription spends tokens on the brief and the review; Codex does the grinding. On API? That's the per-token grind moved off your main bill.

You and your agent understand the task, write the brief and review the diff; the MCP delegate tool hands that brief to the OpenAI Codex CLI, which implements it and edits your workspace; one compact JSON result comes back with what changed, which files, and the thread id

A delegate result: one compact JSON block with the final answer, status, thread and delegation ids, workspace, Codex CLI version, per-turn token usage, and the files the edit tools reported changing

Features

  • 📦 One result you can review — a compact JSON block: the final answer, status, the files Codex's edit tools reported changing, per-turn token counts, and the threadId to continue from. Fields that carry no signal are omitted.

  • 📋 Plan first, then build it on the same thread — plan returns schema-validated steps for you to approve, and agent implements them. ask answers questions. review runs Codex's own reviewer over uncommitted work, a base branch, or a single commit.

  • 🧵 Resume — continue a Codex thread with resumeThreadId. resumed: false tells you the context did not carry over.

  • 🧑‍🤝‍🧑 Run several, cancel cleanly — the same question across models, or independent workers on independent directories. cancel waits for the exit and warns when a process outlives the kill deadline.

  • 🤝 One-command install — Claude Code and GitHub Copilot CLI take it as a plugin, with a skill that teaches your agent how to delegate well. Cursor, VS Code, JetBrains, Windsurf and Visual Studio add the stdio server in settings.

  • 🩺 doctor — tells you exactly what's missing if setup isn't right.

Install

You need Node.js 20+ and the OpenAI Codex CLI, already logged in (codex login).

Claude Code

/plugin marketplace add andreilungeanu/codex-delegate-mcp
/plugin install codex-delegate@codex-delegate-mcp

Then just ask:

Delegate to Codex: migrate src/api from callbacks to async/await and update the tests, then walk me through what changed.

That's the whole loop — Claude writes the brief, Codex grinds through the files, Claude walks you through the diff.

Cursor

Add an MCP server in Cursor Settings → MCP (or project .cursor/mcp.json):

{
  "mcpServers": {
    "codex-delegate": {
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

Then ask Cursor to delegate implementation to Codex the same way.

GitHub Copilot CLI

copilot plugin install andreilungeanu/codex-delegate-mcp

More clients

Install in VS Code Install in VS Code Insiders

{
  "servers": {
    "codex-delegate": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

Or run Chat: Install Plugin From Source with this repository's URL.

Under Settings → Tools → AI Assistant → Model Context Protocol (MCP), add a server with command npx and arguments -y codex-delegate-mcp.

{
  "mcpServers": {
    "codex-delegate": {
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

Heads-up: Cascade caps you at 100 tools across all servers.

{
  "servers": {
    "codex-delegate": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

Requires 17.14+. Note the top-level key is servers, not mcpServers.

OpenCode does not use mcpServers. Local servers go under mcp, with type: "local" and command as one array:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "codex-delegate": {
      "type": "local",
      "command": ["npx", "-y", "codex-delegate-mcp"],
      "enabled": true
    }
  }
}
{
  "mcpServers": {
    "codex-delegate": {
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

In the IDE: … on the agent panel → MCP Servers → Manage MCP Servers → View raw config. Antigravity 2.0, IDE, and CLI share the Gemini config file. You may need to approve the server's tools on first run.

Same shape as OpenCode: type: "local" and command as one array.

{
  "mcp": {
    "codex-delegate": {
      "type": "local",
      "command": ["npx", "-y", "codex-delegate-mcp"],
      "enabled": true
    }
  }
}

In the VS Code extension: Settings → MCP → Add Server → Local (stdio). On Windows, if npx is not found, use command cmd with arguments /c, npx, -y, codex-delegate-mcp.

{
  "context_servers": {
    "codex-delegate": {
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"],
      "env": {}
    }
  }
}

Zed's native agent uses this. External ACP agents in Zed read their own MCP config unless you forward Zed's servers.

Kiro and any other MCP client

Add the following server to the client's MCP config:

{
  "mcpServers": {
    "codex-delegate": {
      "command": "npx",
      "args": ["-y", "codex-delegate-mcp"]
    }
  }
}

MIT © Andrei Lungeanu

Configuration · Security · Privacy · Terms · Changelog

Available Tools

3 tools
cancelA
DestructiveIdempotent

Cancel active runs. delegationId selects one (announced in progress before spawn — the only handle if a run wedges at startup), threadId all on its thread, neither all. Waits for settlement; if a process tree survives the kill deadline, it still returns and the delegate result warns. Status: cancelled, nothing-active, or not-found (no active run with this ID).

ParametersJSON Schema
NameRequiredDescriptionDefault
threadIdNo
delegationIdNo

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds meaningful behavioral context: it waits for settlement, returns even if a process tree survives the kill deadline, and warns via the delegate result. It also enumerates the three possible statuses. This goes beyond the annotations without contradicting them.

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 dense sentences with no filler. The most important selection semantics are front-loaded, and the status outcomes are compactly listed at the end. Every clause earns its place.

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 cancellation tool with no output schema, the description covers selection semantics, wait behavior, failure behavior, and status outcomes. It does not describe the exact shape of the return value, but the status list and warning note give an agent enough to interpret the result. The sibling tools are simple enough that no further context is needed.

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%, so the description must carry the parameter semantics, and it does: delegationId selects one run, threadId selects all on a thread, and neither selects all. It also explains the special significance of delegationId as the only handle for a wedged startup. This fully compensates for the empty 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 opens with a specific verb and resource ('Cancel active runs') and immediately distinguishes the two selection modes (delegationId vs threadId) and the all-runs fallback. It also names the sibling context by explaining when delegationId is the only handle, which clearly separates it from delegate and doctor.

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

Usage Guidelines5/5

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

It explicitly states when to use delegationId (announced in progress before spawn, the only handle if a run wedges at startup), when to use threadId (all runs on its thread), and when to use neither (all active runs). This is direct when-to-use guidance with no ambiguity.

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

delegateA
Destructive

Delegate a coding task to OpenAI Codex. Never run codex from the shell — use this tool. Check status before trusting result — a run that spawns then fails returns normally. Keep model, reasoningEffort and fast at their defaults unless the user asks. See the delegate skill.

ParametersJSON Schema
NameRequiredDescriptionDefault
fastNoCodex Fast mode; higher credit use.
modeNoagent implements; plan returns a structured plan; ask answers; review runs native review.agent
specYesBrief with goal, scope, fixed decisions quoted exactly, and acceptance criteria; reference files instead of pasting code.
modelNoCodex model id: gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.5, gpt-5.4, gpt-5.4-mini.gpt-5.6-luna
timeoutMsNoWhole-run cap in ms (default 1h). Mid-turn silence is allowed; startup has a separate 60s first-output deadline.
webSearchNoCodex's built-in web search.
workspaceYesCodex's working directory; not confinement. Must already exist — never create one for the call.
reviewTargetNoRequired in review; forbidden otherwise: uncommitted, base branch, or commit.
resumeThreadIdNoThread to continue. Reuse its workspace. Forbidden with review.
reasoningEffortNominimal is rejected by every published model; none is accepted though the catalog omits it.xhigh

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the destructive, non-read-only nature of the tool. The description adds the non-obvious failure behavior: 'a run that spawns then fails returns normally,' plus the warning to check status before trusting the result.

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 four short sentences, each carrying distinct information: purpose, invocation rule, failure caveat, and default policy. The critical safety warning is front-loaded before the pointer to the delegate skill.

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 10-parameter tool with no output schema, the description covers the key invocation rules, failure behavior, and default policy, while the schema documents every parameter. It does not describe the return/status format or relate to cancel/doctor, but those are minor gaps given the strong schema and annotations.

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 100% description coverage and already explains each parameter in detail, including spec, workspace, reviewTarget, and reasoningEffort. The description adds only the default-keeping policy for model, reasoningEffort, and fast, which is useful but not essential for understanding the 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 states a specific verb and resource: 'Delegate a coding task to OpenAI Codex.' It also removes ambiguity by explicitly prohibiting shell invocation, and the action is clearly distinct from the sibling tools cancel and doctor.

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

Usage Guidelines5/5

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

It gives an explicit when-not and alternative: 'Never run codex from the shell — use this tool.' It also directs the agent to check status before trusting results and to keep model, reasoningEffort, and fast at defaults unless the user asks.

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

doctorA
Read-onlyIdempotent

Diagnose plugin/CLI/login, recursion, and workspace (default: server cwd). deep adds no-quota help and model-catalog checks.

ParametersJSON Schema
NameRequiredDescriptionDefault
deepNo
workspaceNo

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add context beyond safety. It adds useful behavior: workspace defaults to server cwd and deep enables no-quota help plus model-catalog checks. It does not describe the output format or clarify ambiguous terms like 'recursion', but the safety profile is already covered.

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?

Two sentences with no filler: the first front-loads the diagnostic targets and workspace default, the second covers the 'deep' flag concisely. The phrasing is slightly cryptic, especially 'no-quota help', which prevents a 5.

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?

With no output schema, the description should clarify what a diagnosis produces or returns, but it does not. Both parameters and the safe read-only behavior are addressed, yet ambiguous terms such as 'recursion' and 'no-quota help' and the lack of any mention of the tool's output leave meaningful gaps.

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 description coverage is 0%, so the description must compensate for documenting the parameters. It explains 'deep' as adding no-quota help and model-catalog checks, and it gives the workspace default as server cwd. It stops short of specifying workspace format or the exact meaning of 'no-quota help', but both parameters receive meaningful semantic context.

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 opens with a specific verb 'Diagnose' and names concrete targets: plugin/CLI/login, recursion, and workspace. It also distinguishes the 'deep' mode by what it adds. It does not explicitly connect to the annotation title's 'Codex delegation setup' or differentiate from sibling tools, so it is not a 5.

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 verb 'Diagnose' and the list of target areas imply when the tool should be used, and 'deep adds no-quota help and model-catalog checks' gives a condition for enabling extra checks. However, it does not explicitly say when to use doctor versus the sibling tools delegate/cancel.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev2.2.1
    • Changeddelegate1 field changed
      • changedInput schema / properties / reasoningEffort / description
        Previous value: -"gpt-5.6-* reject minimal; older models reject none."New value: +"minimal is rejected by every published model; none is accepted though the catalog omits it."
  2. 1 tool updatev2.0.0
    • Changeddelegate6 fields changed
      • changedInput schema / properties / model / default
        Previous value: -"gpt-5.6-terra"New value: +"gpt-5.6-luna"
      • changedInput schema / properties / model / description
        Previous value: -"Codex model id: gpt-5.6-terra, gpt-5.6-sol, gpt-5.6-luna, gpt-5.5, gpt-5.4, gpt-5.4-mini and more."New value: +"Codex model id: gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.5, gpt-5.4, gpt-5.4-mini."
      • changedInput schema / properties / reasoningEffort / default
        Previous value: -"high"New value: +"xhigh"
      • changedInput schema / properties / reasoningEffort / enum
        Previous value: -[
-  "none",
-  "minimal",
-  "low",
-  "medium",
-  "high",
-  "xhigh",
-  "max"
-]New value: +[
+  "none",
+  "minimal",
+  "low",
+  "medium",
+  "high",
+  "xhigh",
+  "max",
+  "ultra"
+]
      • changedInput schema / properties / workspace / description
        Previous value: -"Codex's working directory; not confinement. Must already exist — never create one for the call. Defaults to the server cwd, often not the project root under npx/plugin. Required on resume: resume has no --cd."New value: +"Codex's working directory; not confinement. Must already exist — never create one for the call."
      • changedInput schema / required
        Previous value: -[
-  "spec"
-]New value: +[
+  "spec",
+  "workspace"
+]
  3. 3 tool updatesv1.21.1
    • Changedcancel2 fields changed
      • removedInput schema / properties / delegationId / description
        Removed value: -"Cancel this one delegation, by the id announced in its progress stream"
      • removedInput schema / properties / threadId / description
        Removed value: -"Cancel every delegation running on this Codex thread"
    • Changeddelegate11 fields changed
      • changedInput schema / properties / fast / description
        Previous value: -"Codex Fast mode (service_tier=fast) — higher credit use"New value: +"Codex Fast mode; higher credit use."
      • addedInput schema / properties / mode / description
        Added value: +"agent implements; plan returns a structured plan; ask answers; review runs native review."
      • changedInput schema / properties / model / description
        Previous value: -"Codex model id"New value: +"Codex model id: gpt-5.6-terra, gpt-5.6-sol, gpt-5.6-luna, gpt-5.5, gpt-5.4, gpt-5.4-mini and more."
      • removedInput schema / properties / network
        Removed value: -{
-  "default": true,
-  "description": "Web search, and network from Codex's shell in agent mode. false seals the run",
-  "type": "boolean"
-}
      • changedInput schema / properties / reasoningEffort / description
        Previous value: -"Reasoning effort. gpt-5.6-* reject minimal; older models reject none"New value: +"gpt-5.6-* reject minimal; older models reject none."
      • changedInput schema / properties / resumeThreadId / description
        Previous value: -"Resume an existing Codex thread instead of starting a new one"New value: +"Thread to continue. Reuse its workspace. Forbidden with review."
      • changedInput schema / properties / reviewTarget / description
        Previous value: -"Required in review mode: uncommitted, base branch, or commit sha"New value: +"Required in review; forbidden otherwise: uncommitted, base branch, or commit."
      • changedInput schema / properties / spec / description
        Previous value: -"Task brief: goal, scope, decisions already made (quote the user's exact values), acceptance criteria. Point at files to read rather than pasting code."New value: +"Brief with goal, scope, fixed decisions quoted exactly, and acceptance criteria; reference files instead of pasting code."
      • changedInput schema / properties / timeoutMs / description
        Previous value: -"Hard-cap timeout in milliseconds (default 1h). A long silent command is not a timeout; only the 60s spawn-to-first-output deadline is."New value: +"Whole-run cap in ms (default 1h). Mid-turn silence is allowed; startup has a separate 60s first-output deadline."
      • addedInput schema / properties / webSearch
        Added value: +{
+  "default": true,
+  "description": "Codex's built-in web search.",
+  "type": "boolean"
+}
      • changedInput schema / properties / workspace / description
        Previous value: -"Working directory for Codex. Optional; defaults to the server process cwd, which for npx and plugin launches is not necessarily your project root — pass it explicitly. Smallest directory holding the task's files; none → project root. Must already exist — never create one for the call. Required when resuming: codex exec resume has no --cd."New value: +"Codex's working directory; not confinement. Must already exist — never create one for the call. Defaults to the server cwd, often not the project root under npx/plugin. Required on resume: resume has no --cd."
    • Changeddoctor1 field changed
      • removedInput schema / properties / deep / description
        Removed value: -"When true, probe codex exec/review/resume --help surfaces"
  4. 3 tool updatesv1.18.1
    • Changedcancel1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": true,
-  "properties": {
-    "status": {
-      "enum": [
-        "cancelled",
-        "nothing-active",
-        "not-running",
-        "not-found"
-      ],
-      "type": "string"
-    }
-  },
-  "required": [
-    "status"
-  ],
-  "type": "object"
-}New value: +null
    • Changeddelegate3 fields changed
      • changedInput schema / properties / reasoningEffort / enum
        Previous value: -[
-  "none",
-  "minimal",
-  "low",
-  "medium",
-  "high",
-  "xhigh"
-]New value: +[
+  "none",
+  "minimal",
+  "low",
+  "medium",
+  "high",
+  "xhigh",
+  "max"
+]
      • changedInput schema / properties / workspace / description
        Previous value: -"Working directory for Codex (defaults to cwd)"New value: +"Working directory for Codex. Optional; defaults to the server process cwd, which for npx and plugin launches is not necessarily your project root — pass it explicitly. Smallest directory holding the task's files; none → project root. Must already exist — never create one for the call. Required when resuming: codex exec resume has no --cd."
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": true,
-  "properties": {
-    "cliVersion": {
-      "type": "string"
-    },
-    "delegationId": {
-      "type": "string"
-    },
-    "exitCode": {
-      "type": "integer"
-    },
-    "filesReportedByEditTools": {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "plan": {
-      "additionalProperties": false,
-      "properties": {
-        "overview": {
-          "type": "string"
-        },
-        "steps": {
-          "items": {
-            "additionalProperties": false,
-            "properties": {
-              "detail": {
-                "type": "string"
-              },
-              "title": {
-                "type": "string"
-              }
-            },
-            "required": [
-              "title",
-              "detail"
-            ],
-            "type": "object"
-          },
-          "type": "array"
-        }
-      },
-      "required": [
-        "overview",
-        "steps"
-      ],
-      "type": "object"
-    },
-    "reason": {
-      "enum": [
-        "cancelled",
-        "startup-timeout",
-        "hard-cap",
-        "agent-error",
-        "died-mid-turn",
-        "exit-nonzero"
-      ],
-      "type": "string"
-    },
-    "result": {
-      "type": "string"
-    },
-    "resultSource": {
-      "const": "stream-fallback",
-      "type": "string"
-    },
-    "resumed": {
-      "type": "boolean"
-    },
-    "status": {
-      "enum": [
-        "completed",
-        "failed",
-        "interrupted"
-      ],
-      "type": "string"
-    },
-    "threadId": {
-      "type": "string"
-    },
-    "usage": {
-      "additionalProperties": false,
-      "properties": {
-        "cacheWriteInputTokens": {
-          "type": "number"
-        },
-        "cachedInputTokens": {
-          "type": "number"
-        },
-        "inputTokens": {
-          "type": "number"
-        },
-        "outputTokens": {
-          "type": "number"
-        },
-        "reasoningOutputTokens": {
-          "type": "number"
-        }
-      },
-      "type": "object"
-    },
-    "warnings": {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "workspace": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result",
-    "status",
-    "workspace"
-  ],
-  "type": "object"
-}New value: +null
    • Changeddoctor1 field changed
      • changedOutput schema / (root)
        Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": true,
-  "properties": {
-    "codex": {
-      "additionalProperties": true,
-      "properties": {
-        "found": {
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "found"
-      ],
-      "type": "object"
-    },
-    "plugin": {
-      "additionalProperties": true,
-      "properties": {
-        "version": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "version"
-      ],
-      "type": "object"
-    },
-    "runtime": {
-      "additionalProperties": true,
-      "properties": {
-        "node": {
-          "type": "string"
-        },
-        "platform": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "node",
-        "platform"
-      ],
-      "type": "object"
-    },
-    "warnings": {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    }
-  },
-  "required": [
-    "plugin",
-    "codex",
-    "runtime",
-    "warnings"
-  ],
-  "type": "object"
-}New value: +null
  5. 2 tool updatesv1.14.1
    • Changedcancel3 fields changed
      • addedInput schema / properties / delegationId
        Added value: +{
+  "description": "Cancel this one delegation, by the id announced in its progress stream",
+  "type": "string"
+}
      • changedInput schema / properties / threadId / description
        Previous value: -"Cancel only when this thread is active"New value: +"Cancel every delegation running on this Codex thread"
      • changedOutput schema / properties / status / enum
        Previous value: -[
-  "cancelled",
-  "nothing-active",
-  "not-owned"
-]New value: +[
+  "cancelled",
+  "nothing-active",
+  "not-running",
+  "not-found"
+]
    • Changeddelegate1 field changed
      • addedOutput schema / properties / delegationId
        Added value: +{
+  "type": "string"
+}
  6. 3 tool updatesv1.11.0
    • First observedcancel
    • First observeddelegate
    • First observeddoctor
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly separate action: delegate starts work, cancel stops active runs, and doctor diagnoses the environment. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

All three tool names are single, lowercase imperative verbs (delegate, cancel, doctor), following a consistent and predictable style. No mixed naming conventions or confusing prefixes.

Tool Count5/5

Three tools is well-scoped for a focused delegation and control server; each covers a distinct phase of the workflow. Nothing feels redundant, and the small count matches the narrow purpose.

Completeness4/5

The core lifecycle is covered: start work, cancel work, and diagnose setup issues. There is no explicit standalone status/list-tools operation, but delegate results and cancel statuses provide the necessary state information for the described workflow.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Universal Coder Bridge

    sorensadrgit-art
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP+HTTP control plane for routing work to multiple coding-agent CLIs through a normalized contract, enabling multi-agent coding pipelines with planning, implementation, review, and revision.
    MIT

  • harness-bridge

    rbutera
    A
    license
    A
    quality
    A
    maintenance
    Bridges Claude Code and OpenAI Codex through MCP, allowing cross-harness querying, code review, explanation, and implementation delegation.
    6
    89
    1
    MIT

Latest Blog Posts

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/andreilungeanu/codex-delegate-mcp'

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