codex-offload-mcp

by jgt87

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: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: starting tasks (codex_start, codex_execute_plan), checking status (codex_status), collecting results (codex_result), canceling (codex_cancel), replying (codex_reply), listing models (codex_models), and listing jobs (codex_list). No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'codex_' prefix followed by a clear verb or verb_noun pattern (start, execute_plan, status, result, cancel, reply, models, list), maintaining perfect naming consistency.
Tool Count5/5
8 tools is well-scoped for managing background Codex jobs: covering task initiation (two variants for different workflows), monitoring, result collection, cancellation, follow-up, model discovery, and job listing. No superfluous or missing tools.
Completeness5/5
The tool surface covers the full lifecycle of background job offloading: start (with plan variant), status, result, cancel, reply, list, and model queries. No obvious gaps for the intended domain.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that results are ordered newest first and include current state, but does not mention pagination, rate limits, or that it is a read-only operation. While not misleading, it leaves gaps in behavioral understanding.
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 extremely concise — two sentences that front-load the purpose and usage context. Every word adds value, with no repetition or fluff.
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 simple list tool with two optional parameters, the description covers the primary function and common use cases. It could mention the output format (e.g., array of job objects) since there is no output schema, but the current level is adequate for basic understanding.
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 baseline is 3. The description adds no additional meaning beyond the schema's descriptions for limit and state — the parameters are straightforward and self-explanatory.
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 lists jobs newest first with their current state, and provides specific use cases like finding a lost jobId or checking if anything is still running. This distinguishes it from sibling tools like codex_status or codex_cancel.
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 explicitly says when to use the tool ('find a jobId you lost track of, or to check whether anything is still running'), giving contextual guidance. However, it does not explicitly mention alternatives or when not to use it, but the use cases imply differentiation.
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?
Discloses key side effect: file edits stay on disk and cancelling does not rollback. This adds value beyond the basic cancel action, especially since no annotations are provided.
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?
Two sentences, no wasted words. First sentence states the action, second adds critical behavioral detail. Efficient and well-structured.
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?
For a simple 1-parameter tool with no output schema, the description is fully sufficient. It explains what happens (stop job and child processes) and important caveats (no rollback).
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% and the parameter jobId is described as 'Id returned by codex_start.' The description adds no extra meaning beyond the schema, meeting the baseline.
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 'Stop a running job and its child processes,' using a specific verb and resource. It distinguishes from sibling tools like codex_start (starts) and codex_status (checks status) by focusing on cancellation.
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?
No explicit guidance on when to use vs alternatives. The description implies it's for stopping jobs but doesn't contrast with other tools or state when not to use it.
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. It discloses key behavioral traits: it returns a new jobId, advises to keep working while it runs (avoid re-checking), and states that it reuses the original working directory and sandbox. It also notes that Codex retains context from the original job. The description does not explicitly state if the operation is destructive or safe, but the nature of sending a follow-up implies a non-destructive mutation.
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 with four sentences. It is front-loaded with the core purpose, then adds critical details (retains context, return value, reuse of directory). Every sentence adds value without redundancy or fluff.
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 has 4 parameters and no output schema, the description adequately explains the tool's behavior and return value (new jobId). It covers the key use case and workflow. Minor omissions like error handling are forgivable, as this is a follow-up tool that builds on existing jobs.
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 100%, so baseline is 3. The description adds valuable context beyond the schema: for 'reasoningEffort', it provides strategic guidance on when to raise or lower the effort; for 'jobId', it clarifies that it can be a previous codex_reply job. The general explanation of the tool enriches understanding of parameter purpose.
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 'Send a follow-up' and the resource 'finished job's Codex thread'. It provides concrete examples of usage ('corrections, review comments, 'you missed X', 'now do Y as well') and distinguishes itself from the sibling tool 'codex_start' by emphasizing the benefit of retaining context. The purpose is specific and unambiguous.
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 explicitly states that this tool is 'far better than starting a fresh job that would begin cold', giving a clear when-to-use recommendation. It implies when not to use (when a fresh start is needed) and contrasts with 'codex_start'. However, it does not mention other sibling tools like 'codex_execute_plan' or 'codex_result', but the primary alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is non-blocking, cheap to call, and reports current status without waiting. It also details what information is returned. This is sufficient transparency for a status-check tool.
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 three sentences long, front-loaded with purpose, followed by details and behavioral notes. Every sentence adds value, and there is no redundancy or unnecessary text.
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?
The description adequately covers the tool's behavior and returned information for a simple status check. It might lack details on error handling or exact return format, but given the low parameter count and no output schema, it is nearly complete.
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 baseline is 3. The description does not add meaning beyond the schema; it only restates the purpose. No additional parameter semantics are provided.
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: 'Report whether a job is still running and what it has done so far'. It specifies the resource (a Codex job) and the verb (report/check), includes examples of returned information (commands run, files edited, latest messages), and distinguishes it from siblings like codex_result and codex_cancel.
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: it is 'Cheap to call' and 'Does not block', suggesting it is for lightweight polling. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
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, the description handles the burden well. It explains that Codex follows faithfully, stops on blockers, and cannot see the conversation. It mentions returning a jobId immediately and working in background. However, it could explicitly mention that the tool modifies files based on sandbox settings, though that is covered in parameter descriptions.
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 paragraph that front-loads the core purpose and then provides detailed usage guidance. While not overly verbose, it could be slightly more concise (e.g., 'the execute half of plan→execute' is a bit redundant). Still, every sentence contributes meaning.
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 no output schema, the description mentions returning a jobId but doesn't fully specify the return format or structure. However, for a tool with 9 parameters and complex behavior, it covers the essential aspects: execution model, blocking behavior, plan requirements, and post-execution flow via codex_result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context beyond the schema: for 'plan' it stresses self-containment and structure, for 'reasoningEffort' it gives nuanced guidance on when to lower it, and for 'sandbox' it explains defaults and warnings. This extra information helps the agent choose appropriate values.
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 identifies this as the execution half of a plan-execute split, with specific verb 'hand' and resource 'plan'. It distinguishes itself from codex_start by emphasizing the pre-planned nature and from other siblings like codex_status and codex_result by stating it returns a jobId immediately and is for background execution.
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?
The description explicitly states when to use this tool: 'Reach for this when the hard part was deciding what to do and the rest is faithful typing across files.' It provides guidance on when not to use it implicitly, mentions alternatives like codex_reply for blockers, and gives tips on reasoningEffort and plan self-containment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: returns report and actualChanges, trust actualChanges over report, non-blocking progress return, and job completion requirement. Highly transparent.
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?
Single, well-structured paragraph front-loaded with the purpose. Every sentence provides useful information without redundancy. Length is appropriate for the tool's complexity.
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 tool with 2 parameters and no output schema, the description adequately explains the return content (report with specifics, actualChanges). Still, a more detailed template of the report could improve completeness, but current level is sufficient.
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 covers both parameters with descriptions. The description adds value by linking jobId to codex_start and explaining that includeActivity returns the full trace, enriching the schema information.
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?
Description clearly states the tool collects a finished Codex job's output, specifying the structured report and actualChanges. It distinguishes itself from sibling tools like codex_status and codex_cancel by focusing on final output collection.
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?
Provides clear guidance on when to use (after job finishes) and what to expect (progress if still running). Includes a practical tip to trust actualChanges over the report. Lacks explicit comparison to alternative tools but is generally sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the source (Codex's own model index) and that it reports how the index was obtained, making staleness or missing data visible.
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?
Well-structured with the main purpose front-loaded, and every sentence adds value 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 zero parameters and no output schema, the description is remarkably complete, covering usage, data source, and potential issues (stale index).
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 no parameters, so baseline is 4. The description adds no parameter-specific details but fully compensates by explaining the tool's purpose and output.
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 shows available Codex models and their reasoning efforts, distinguishing it from sibling tools like codex_start by focusing on listing rather than execution.
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?
Explicitly advises when to use: when pinning model or reasoningEffort on codex_start, and warns that invalid values fail the job, not the call, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It fully discloses that Codex edits files on disk in cwd, that jobs run in the background, and warns against tight polling loops. It explains automatic model/reasoning-effort selection, default behaviors for structured, documentation, and autoRoute, and the implications of each sandbox setting.
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 lengthy (over 400 words) but every sentence serves a purpose. It is front-loaded with the core action and use cases, then systematically covers behavioral details and parameter guidance. While slightly verbose, the density of information justifies the length.
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 9 parameters, no output schema, and no annotations, the description covers all necessary behavioral and contextual details: what is returned (jobId), how to interact with sibling tools (status, result), file system effects, parameter defaults, and when to override each. It is thorough and leaves no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description significantly enriches each parameter beyond the schema. It explains when to set structured=false (long prose), why documentation defaults true, how reasoningEffort maps to task complexity, and the meaning of sandbox levels. This adds substantial value for an agent.
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: handing a coding task to Codex CLI and receiving a jobId immediately for background execution. It specifies the verb ('hand a coding task'), resource ('Codex CLI'), and distinguishes from sibling tools by emphasizing that it returns a jobId, not an answer. The two use cases (slow tasks and output-heavy tasks) further clarify its role.
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?
The description provides explicit when-to-use criteria (self-contained slow or output-heavy tasks) and when-not-to-use (quick questions, trivial triage/classification). It even suggests an alternative: 'send those to a local model instead.' This is comprehensive and actionable.
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:

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

Score Badge

Copy to your README.md:

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

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/jgt87/codex-offload-mcp'

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