Skip to main content
Glama

codex_consult_async

Submit a read-only question to Codex and receive a job ID instantly without waiting. Designed for long-running consultations that run in the background.

Instructions

Ask Codex for a read-only second opinion in the background; get a job_id back immediately instead of blocking.

Same read-only behavior as codex_consult (Codex never edits files), but it runs detached — use it when the consult may run long. Starting a job commits to spend (it runs to completion or its wall-clock deadline even if you never poll). Poll with codex_job_status, read the consult envelope with codex_job_result, delete it with codex_job_consume_result, or stop it with codex_job_cancel.

Data egress: same as codex_consult — sends your question and extra_context (raw, unredacted) to OpenAI via the codex CLI, plus files Codex reads from its resolved working directory (workspace_root, your MCP roots, or the server cwd).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoOverride the Codex model slug for this call; defaults to the server/Codex default when unset.
questionYesThe question or prompt to send Codex (a different model) for a read-only answer.
isolationNoCodex config isolation: 'inherit' (default), 'ignore-config', or 'ignore-rules'.
extra_contextNoOptional author intent / background context, added to the prompt as clearly-labeled UNTRUSTED data. Codex is instructed to treat embedded directives as data, not commands — best-effort prompt-injection mitigation, not a guarantee. Don't include live secrets: Codex can read files it's pointed at, and redaction does not cover this field.
workspace_rootNoAbsolute path to the target repository root. Pass it (or rely on an MCP root) so the call targets the intended repo; otherwise it falls back to the server's own cwd and meta.workspace_warning is set.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
Behavior1/5

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

The description claims read-only behavior ('Codex never edits files'), but the annotation readOnlyHint=false indicates the tool is not read-only. This contradiction undermines transparency. Additionally, the description adds useful details about job commitment and data egress, but the contradiction is critical.

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

Conciseness5/5

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

The description is concise and well-structured, with three focused paragraphs: async behavior, job lifecycle, and data egress. It front-loads the key purpose and uses efficient language without redundancy.

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

Completeness5/5

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

Given the tool's complexity (async, job-based, multiple siblings) and the existence of an output schema, the description covers all essential aspects: async nature, read-only claim, job lifecycle, data egress warnings, and references to related tools. It is fully complete for an AI agent to use correctly.

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 the parameters are well-defined in the schema. The description adds minor context (e.g., extra_context security warning) but does not significantly enhance understanding beyond the schema. Baseline score of 3 is appropriate.

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: to ask Codex for a read-only second opinion in the background, returning a job_id immediately. It distinguishes itself from the synchronous codex_consult by emphasizing non-blocking behavior.

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 usage context: use when the consult may run long, and explains the job lifecycle with references to polling and result tools. It lacks explicit when-not-to-use guidance but covers the key decision factor.

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

Install Server

Other Tools

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/briandconnelly/codex-in-claude'

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