How do I use codex-subagents-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@codex-subagents-mcp Use the review agent to analyze my latest commit." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

codex-subagents-mcp

by leonardsellem

Overview Schema Related Servers Score Discussions

JavaScript

Local

codex-subagents-mcp

Node >=18 License: MIT GitHub stars

Status: Archived. This repo is no longer maintained.
I’m restarting this project from scratch with a new approach in: https://github.com/leonardsellem/codex-specialized-subagents

File‑based sub‑agents for Codex CLI. One MCP tool. Zero fluff.

Auditable: agents are files reviewed in PRs
CI‑friendly: validate_agents, list_agents
Safer ops: temp workdirs, quiet stdout, git worktree isolation

Claude‑style sub‑agents for Codex CLI via a tiny MCP server. Each call spins up a clean context in a temp workdir, injects a persona via AGENTS.md, and runs codex exec --profile <agent> to preserve isolated state.

Quickstart

Prereqs: Node.js >= 18, npm, Codex CLI installed and on PATH.
Install deps and build:

npm install
npm run build

Start server (manual run):

npm start

Tools exposed by this server:

Primary: delegate
Support: list_agents, validate_agents

Agents directory discovery (in order): --agents-dir arg, CODEX_SUBAGENTS_DIR env, then defaults ./agents, ./.codex-subagents/agents, dist/../agents.

60‑second Quickstart (copy‑paste)

# 1) Install + build
npm i && npm run build

# 2) Point Codex at the built server (absolute paths recommended)
# ~/.codex/config.toml
[mcp_servers.subagents]
command = "/usr/bin/env"
args    = ["node", "/ABS/PATH/TO/dist/codex-subagents.mcp.js", "--agents-dir", "/ABS/PATH/TO/agents"]

# Example profiles you can reference from agent frontmatter
[profiles.review]
model = "gpt-5"
approval_policy = "on-request"
sandbox_mode    = "read-only"

[profiles.debugger]
model = "o3"
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# 3) In Codex, verify tools and agents
tools.call name=list_agents
tools.call name=validate_agents

# 4) Delegate one task to an agent
subagents.delegate(agent="review", task="Summarize and review the last commit")

Tip: See docs/SECURITY.md for trust boundaries and docs/OPERATIONS.md for E2E and logging.

Related MCP server: codex-as-mcp

Wiring with Codex CLI

Build the server and point Codex at the absolute path to the compiled entrypoint. Pass the agents directory explicitly so the server doesn't scan until after the handshake. The server also falls back to an agents/ folder adjacent to the installed binary (e.g. dist/../agents) if --agents-dir and CODEX_SUBAGENTS_DIR are not provided:

# ~/.codex/config.toml
[mcp_servers.subagents]
command = "/absolute/path/to/node"
args    = ["/absolute/path/to/dist/codex-subagents.mcp.js", "--agents-dir", "/absolute/path/to/agents"]

[profiles.review]
model = "gpt-5"
approval_policy = "on-request"
sandbox_mode    = "read-only"

[profiles.debugger]
model = "o3"
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[profiles.security]
model = "gpt-5"
approval_policy = "never"
sandbox_mode    = "workspace-write"

Usage (in Codex):

“Review my last commit. Use the review sub-agent.”
“Reproduce and fix the failing tests in api/ using the debugger sub-agent.”
“Audit for secrets and unsafe shell calls; propose fixes with rationale using the security sub-agent.”

AGENTS hint to drop into your repo’s `AGENTS.md`

Route all work through the orchestrator:

subagents.delegate(agent="orchestrator", task="<goal>")

Example security review routed via orchestrator:

subagents.delegate(agent="orchestrator", task="Audit the repo for secrets and unsafe shell calls")

Prefer tool calls over in-thread analysis to keep the main context clean.

Note: MCP servers run outside Codex’s sandbox. Keep surfaces narrow and audited. This server exposes a single tool: delegate.

Who This Is For / Not For

For: teams already on Codex CLI who want auditable specialist agents and CI gating.
Not for: folks seeking a general agent framework or multi‑tool orchestrator.

Terminology: Agents vs Profiles

agent (what you pass to subagents.delegate): the name of an agent loaded from your registry directory. The name is the file basename, e.g., agents/review.md → agent review.
profile (Codex CLI): an execution profile you define in ~/.codex/config.toml under [profiles.<name>]. Agents typically specify which profile to use via frontmatter (profile: <name>), but agent names and profile names don’t have to match.

There are no hardcoded built‑in agent names. The server loads agents from disk (agents/*.md|*.json) or accepts an ad‑hoc agent when both persona and profile are provided inline.

Tool: `delegate`

Parameters:
- agent: string — the agent name from your registry (basename of agents/<name>.md|json)
- task: string (required)
- cwd?: string (defaults to current working directory)
- mirror_repo?: boolean (default false). If true and cwd provided, mirrors the repo into the temp workdir for maximal isolation.
- profile? and persona?: optional ad-hoc definition when agent is not found in registry. Provide both.
Behavior:
1. Creates a temp workdir; writes AGENTS.md with the agent persona.
2. Optionally mirrors the repo into the temp dir via cp -R fast path.
  - Safer alternative (recommended for large repos): git worktree add <tempdir> <branch-or-HEAD> (documented in docs/INTEGRATION.md).
3. Spawns codex exec --profile <agent-profile> "<task>" with cwd set to the temp dir if mirrored, else your provided cwd.
4. Returns JSON: { ok, code, stdout, stderr, working_dir }.

Custom agents

Add agents without code changes:

File-based registry (recommended)

Create an agents directory and point the server to it via either:
- Config args: add "--agents-dir", "/path/to/agents" in ~/.codex/config.toml under the MCP server args
- Env var: CODEX_SUBAGENTS_DIR=/path/to/agents
- Defaults (auto-detected): ./agents or ./.codex-subagents/agents
Define agents as files using the basename as the agent name:

Example agents/perf.md:

---
profile: debugger
approval_policy: on-request   # one of: never | on-request | on-failure | untrusted
sandbox_mode: workspace-write # one of: read-only | workspace-write | danger-full-access
---
You are a pragmatic performance analyst. Identify hotspots, measure, propose minimal fixes with benchmarks.

Or JSON agents/migrations.json:

{
  "profile": "debugger",
  "approval_policy": "on-request",
  "sandbox_mode": "workspace-write",
  "persona": "You plan and validate safe DB migrations with rollbacks.",
  "personaFile": null
}

Ad-hoc agent via tool params

Call delegate with a new name and supply both profile and persona:

subagents.delegate(
  agent="perf",
  task="Analyze render jank",
  profile="debugger",
  approval_policy="on-request",
  sandbox_mode="workspace-write",
  persona="You are a perf specialist..."
)

List available agents:

tools.call name=list_agents

Validation: approval_policy and sandbox_mode are validated against the allowed values above. They are advisory metadata and should match the Codex profile you run under. Enforce actual behavior via profiles in ~/.codex/config.toml.

Validate agent files:

tools.call name=validate_agents
# or
tools.call name=validate_agents arguments={"dir":"/abs/path/to/agents"}

Returns per-file errors/warnings and a summary. Invalid values are flagged; missing profile in Markdown is a warning (loader defaults to default).

Build, Lint, Test

npm install
npm run build
npm run lint
npm test

Note: Do not edit dist/ manually; it is build output.

E2E Demo

Automated end-to-end check using the real Codex CLI:

npm run e2e

It will:

Build the project.
Write a temporary ~/.codex/config.toml pointing to the built server.
Run /mcp to verify the server is connected.
Pick the first agent on disk and call subagents.delegate.

The script requires OPENAI_API_KEY and a working Codex CLI binary.

Safety & Operations

Concern	This repo does
Prevent handshake break	No stdout logs; debug only to stderr (`DEBUG_MCP=1`)
Reduce blast radius	Temp workdir + optional `git worktree` isolation
Gate risky personas	`validate_agents` + profiles/approvals alignment
Network surface	Single tool (`delegate`); Codex handles model I/O
Auditability	Agents live as files; reviewable in PRs

Troubleshooting MCP timeouts

Warning: Stdout must be newline‑delimited JSON only. Any logs on stdout will break the MCP handshake. Use DEBUG_MCP=1 to emit diagnostics to stderr.

“codex not found”: Install Codex CLI and ensure it is on PATH. Re-run npm run e2e.
Timeout on startup: confirm the config points at the absolute dist/codex-subagents.mcp.js path and passes --agents-dir.
Logs on stdout break the handshake. Set DEBUG_MCP=1 to log timing to stderr only.
The server speaks newline-delimited JSON; older configs expecting HTTP headers will stall.
Large repos: prefer git worktree over mirror_repo=true (see docs/INTEGRATION.md).
Slow start: agent files are loaded lazily after initialization.

Agent Recipes (starter personas)

These come as file‑based agents under agents/. Each link includes a one‑line goal and suggested metadata (frontmatter).

agents/review.md: Code review and refactor checklist. Frontmatter: profile: review (suggested: approval_policy: on-request, sandbox_mode: read-only).
agents/debugger.md: Reproduce failures and propose minimal fixes. Frontmatter: profile: debugger (suggested: approval_policy: on-request, sandbox_mode: workspace-write).
agents/security.md: Threat modeling and concrete mitigations. Frontmatter: profile: security (suggested: approval_policy: never, sandbox_mode: workspace-write).
agents/perf.md: Identify hotspots; measure and optimize. Frontmatter: profile: default (suggested: approval_policy: on-request, sandbox_mode: workspace-write).
agents/docs.md: Improve and restructure docs. Frontmatter: profile: default (suggested: approval_policy: on-request, sandbox_mode: read-only).
agents/a11y.md: Accessibility reviews and fixes. Frontmatter: profile: default (suggested: approval_policy: on-request, sandbox_mode: read-only).

Invite PRs that add new agents—see “Contribute an agent”.

Contribute an agent (fast path)

Fork and create agents/<name>.md with frontmatter:
```
profile: debugger
approval_policy: on-request
sandbox_mode: workspace-write
```
Then describe the persona in free text.
Run tools.call name=validate_agents.
Open a PR using the “Agent request / contribution” template.

We track requested personas in GitHub Discussions (open a new topic under Show & Tell if none exists yet).

Comparisons

vs. building your own MCP server: this repo keeps a single tool and file‑based agents to minimize attack surface.
vs. complex orchestrators: this intentionally avoids graphs/routers—Codex CLI profiles + file personas keep it simple.

If this project helps, a star helps others discover it.

Docs

docs/INTEGRATION.md: deeper wiring, profiles, AGENTS.md guidance.
docs/SECURITY.md: isolation, trust boundaries, sandbox guidance.
docs/OPERATIONS.md: logs, env vars, upgrades.

License

MIT

Available Tools

4 tools

delegateC

Run a named sub-agent as a clean Codex exec with its own persona/profile.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`task`	Yes
`agent`	Yes
`persona`	No
`profile`	No
`mirror_repo`	No
`sandbox_mode`	No
`approval_policy`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full responsibility for behavioral disclosure. It mentions 'clean Codex exec' and 'own persona/profile', which hint at isolation and customization, but it does not disclose any side effects, return behavior, or whether the operation modifies the workspace. Given the presence of sandbox_mode and approval_policy parameters, the absence of safety/permission context is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler words. It gets to the point immediately. However, it may be overly concise given the tool's complexity, but for what it covers, 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.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, no annotations, and no output schema, this description is incomplete. It does not explain how results are returned, whether the operation is synchronous, or what the sandbox_mode and approval_policy values imply. The description only covers the basic idea of delegation, leaving the agent to guess about critical aspects of invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. However, it only hints at 'persona/profile' and implies a 'task', but provides no meaning for cwd, mirror_repo, sandbox_mode, approval_policy, or how these interact. The description fails to explain the key configuration parameters that an AI agent would need to invoke the tool correctly.

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 with a specific verb ('Run') and resource ('a named sub-agent'), and adds meaningful context about executing as a clean Codex exec with its own persona/profile. This distinguishes it from sibling tools like delegate_batch (which implies batch processing) and list_agents/validate_agents (which are management operations).

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. It does not mention that delegate_batch should be used for batch operations, nor does it state any prerequisites or exclusions. The only implied usage is from the tool name and sibling names, which is not explicit.

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

delegate_batchB

Run multiple sub-agents in parallel

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`task`	Yes
`agent`	Yes
`persona`	No
`profile`	No
`mirror_repo`	No
`sandbox_mode`	No
`approval_policy`	No

TDQS

B3.4/5.0

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 reveals that multiple sub-agents run in parallel, but omits any details about side effects, permission requirements, concurrency limits, error handling, or the operational impact of the sub-agents themselves. Given the parameters for sandbox_mode and approval_policy, this is a significant transparency gap.

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: 'Run multiple sub-agents in parallel.' It is front-loaded with the action verb and resource, contains no extraneous words, and every word adds meaning. This is ideal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 parameters, two enums, no annotations, and no output schema, making it a complex tool. Yet the description provides only the core action. It omits critical operational context such as how tasks are distributed, what the return value is, what permissions are needed, and how the sandbox_mode and approval_policy affect execution. This is grossly insufficient for an AI agent to reliably invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the 8 parameters. The phrase 'multiple sub-agents' hints at batch behavior but provides no information about required fields like 'agent' and 'task' or optional ones like 'persona' and 'profile'. The description fails to compensate 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's function with a specific verb 'Run' followed by the resource 'multiple sub-agents' and the scope 'in parallel'. This fully distinguishes it from the sibling tool 'delegate', which likely runs a single agent, and from list/validate tools. It immediately conveys what the tool 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 description gives clear context for when to use the tool: when you need to run multiple sub-agents concurrently. It does not explicitly mention alternatives or exclusions, but the name 'delegate_batch' and the phrase 'multiple sub-agents' imply it is the batch variant of 'delegate'. This is clear context without exclusions.

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

list_agentsA

List available sub-agents from built-ins and custom agents dir.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the data sources (built-ins, custom agents dir) and indicates a read-only listing operation, but does not explicitly state side-effect-free behavior, return format, or any ordering/filtering details.

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, front-loaded with the action, concise, and contains no filler. Every word adds value.

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 zero-parameter, no-output-schema tool, the description covers what it does and where data comes from. It does not explicitly describe the return value structure, but that is largely implied. Sibling tools exist but are not mentioned, which slightly reduces completeness.

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?

There are zero parameters, so the schema provides no meaningful details. The baseline for 0 params is 4, and the description adds no unnecessary parameter information, which is appropriate here.

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 'List' with a clear resource 'available sub-agents' and a scope 'from built-ins and custom agents dir'. This distinguishes it from siblings like delegate and validate_agents, which have different purposes.

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 discovering available agents but does not explicitly state when to use this tool versus alternatives such as delegate or validate_agents. No exclusions or alternative recommendations are given.

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

validate_agentsB

Validate agent files and report errors/warnings per file.

ParametersJSON Schema

Name	Required	Description	Default
`dir`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the output format (errors/warnings per file) but does not mention side effects, safety (read-only vs. mutating), or permission requirements. This is adequate but leaves 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 a single, clear sentence with no wasted words. It efficiently conveys the tool's function and output in a well-structured manner.

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 low complexity (one optional parameter, no output schema), and the description covers the main purpose and output. However, the lack of parameter explanation and absence of annotations means the description is not fully complete, though it is sufficient for basic understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explicitly explain the 'dir' parameter. While 'agent files' gives a clue that 'dir' may be a directory containing agent files, it does not state its role, default behavior, or whether it is required, leaving the parameter under-specified.

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 'validate' with a clear resource 'agent files' and specifies output 'report errors/warnings per file'. It is distinct from sibling tools like delegate and list_agents, which involve different actions.

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

Usage Guidelines2/5

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

The description states only what the tool does, not when to use it or when to prefer alternatives. No exclusions, prerequisites, or context comparing to sibling tools are provided, so usage guidance is entirely absent.

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.

4 tool updatesv0.1.0Aug 14, 2026
- First observeddelegate
- First observeddelegate_batch
- First observedlist_agents
- First observedvalidate_agents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: delegate runs one sub-agent, delegate_batch runs many, list_agents shows available agents, and validate_agents checks agent files. There is no meaningful overlap; even delegate and delegate_batch are distinguishable by scope.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: delegate, delegate_batch, list_agents, validate_agents. The pattern is uniform and predictable, making the set easy to navigate.

Tool Count5/5

Four tools is well-scoped for managing and running sub-agents. Each tool addresses a distinct part of the workflow (single run, batch run, discovery, validation), leaving no unnecessary bulk or sparseness.

Completeness4/5

The core delegation lifecycle is covered: listing available agents, validating configuration, running individually, and running in batches. Minor gaps exist such as no explicit tool to fetch agent details or stop/abort runs, but these do not block the primary use case.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
AgentPlaybooks A
ai.agentplaybooks
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Autonomous Agents Knowledge & Memory
4914
AI Skill Store A
io.github.garasegae
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
AI & Machine Learning Agent Orchestration Developer Tools
1824
OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1

Related MCP Servers

Polyagent MCP
Coding Agents Developer Tools Autonomous Agents
execveat
A
license
Not graded
quality
D
maintenance
Enables any MCP-compatible client to use existing Claude Code agents from .claude/agents/ directories. Spawns agents in separate CLI sessions for better context optimization and performance across Codex, Gemini CLI, and other AI coding assistants.
Updated a year ago (2025-10-05 20:34 UTC)
3
MIT
codex-as-mcp
Coding Agents Autonomous Agents
kky42
F
license
A
quality
A
maintenance
Delegates work from MCP clients (like Claude Code) to the Codex CLI, allowing spawning of autonomous Codex subagents for tasks.
Updated 2 months ago (2026-06-29 11:24 UTC)
2
173
-
codex-specialized-subagents
Agent Orchestration Developer Tools
leonardsellem
A
license
Not graded
quality
F
maintenance
Artifact-first sub-agent delegation for Codex CLI, enabling multi-step parallel work with durable logging via specialized sub-agents.
Updated 8 months ago (2025-12-31 16:48 UTC)
67
MIT
external-agent-mcp
Code Analysis Coding Agents Command Line
parkavenue9639
F
license
A
quality
C
maintenance
Bridges Codex to external CLI coding agents for read-only code analysis and deterministic quality fixes.
Updated a month ago (2026-07-26 06:32 UTC)
9
-

Appeared in Searches

A server for finding information about Codex

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/leonardsellem/codex-subagents-mcp'

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

codex-subagents-mcp

Quickstart

60‑second Quickstart (copy‑paste)

Wiring with Codex CLI

AGENTS hint to drop into your repo’s AGENTS.md

Who This Is For / Not For

Terminology: Agents vs Profiles

Tool: delegate

Custom agents

Build, Lint, Test

E2E Demo

Safety & Operations

Troubleshooting MCP timeouts

Agent Recipes (starter personas)

Contribute an agent (fast path)

Comparisons

Docs

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

AGENTS hint to drop into your repo’s `AGENTS.md`

Tool: `delegate`