How do I use local-agent-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., "@local-agent-mcp use Codex to generate a README for the current project" 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.

local-agent-mcp

by 3230390742

Overview Schema Related Servers Score Discussions

TypeScript

Local

local-agent-mcp

A local MCP Agent Hub: a stdio Model Context Protocol server that lets Claude Code drive your locally installed, already-logged-in Codex CLI and OpenCode CLI as sub-agents.

Claude Code stays the orchestrator. This server exposes four tools — run Codex, run OpenCode, compare both, and a health check — while enforcing a strict directory allowlist, read-only-by-default execution, output/concurrency limits, and secret redaction.

1. Architecture

┌──────────────┐   MCP tool calls    ┌────────────────────────┐   spawn (shell:false)   ┌───────────────┐
│              │  (stdio JSON-RPC)   │    local-agent-mcp      │  ────────────────────►  │  Codex CLI    │
│ Claude Code  │ ──────────────────► │   (this MCP server)     │                          │ (codex exec)  │
│ (MCP client) │ ◄────────────────── │                         │  ────────────────────►  │  OpenCode CLI │
│              │   JSON results      │  • Zod validation       │                          │ (opencode run)│
└──────────────┘                     │  • path allowlist       │                          └───────────────┘
                                     │  • concurrency + locks  │
                                     │  • redaction            │
                                     │  • JSONL/JSON parsing    │
                                     └────────────────────────┘
                                          │ stderr (logs only)
                                          ▼
                                     never pollutes stdout

Request flow for a run:

tool call → Zod parse → length checks → realpath(cwd) + allowlist check
          → write gate (if writing) → acquire concurrency slot (+ write lock)
          → spawn CLI (shell:false, arg array) → capture (capped) → parse events
          → redact → structured JSON result → release slot

Component responsibilities:

Module	Responsibility
`src/index.ts`	MCP server bootstrap, stdio transport, tool registration
`src/config.ts`	Read & validate environment configuration
`src/security.ts`	Path allowlist, realpath/symlink checks, write gating, input limits
`src/concurrency.ts`	Global concurrency semaphore + per-directory write lock
`src/process-runner.ts`	`spawn` wrapper: shell:false, timeout (SIGTERM→SIGKILL), output cap
`src/executable-resolver.ts`	Resolve `codex`/`opencode` to a shell-free spawnable target (Windows `.cmd` fix)
`src/redaction.ts`	Mask tokens / API keys / auth headers
`src/parsers/codex-parser.ts`	Parse Codex JSONL events
`src/parsers/opencode-parser.ts`	Parse OpenCode JSON events
`src/tools/*.ts`	The four MCP tool implementations

Related MCP server: codex-cli-mcp-tool

2. Prerequisites

Requirement	Notes
Node.js ≥ 18.17	ES Modules + modern `spawn`. Tested on Node 24.
Claude Code	The MCP client. Install per Anthropic docs.
Codex CLI	Installed and logged in (`codex login`). Verify: `codex --version`.
OpenCode CLI	Installed and authenticated (`opencode auth`). Verify: `opencode --version`.
Git	Optional but recommended; reported by `agent_health`.

This server does not log in for you. Codex and OpenCode must already be authenticated with your own credentials on the machine.

3. Install dependencies

npm install

4. Check that Codex and OpenCode are logged in

Codex:

codex --version           # should print a version
codex login               # if not already logged in

OpenCode:

opencode --version        # should print a version
opencode auth list        # inspect configured providers
opencode auth login       # if not already authenticated

Once this server is registered you can also call the agent_health tool from Claude Code, which reports install status and versions for both CLIs.

5. Environment variables

Variable	Default	Meaning
`AGENT_ALLOWED_ROOTS`	(empty)	Required. Comma-separated absolute directories agents may access. Empty = nothing allowed.
`AGENT_ALLOW_WRITE`	`false`	When `true`, permits `codex_run` `workspace_write` and `opencode_run` `auto_approve`.
`AGENT_MAX_OUTPUT_BYTES`	`5000000`	Max combined stdout+stderr bytes captured per run. Excess is truncated.
`AGENT_MAX_CONCURRENCY`	`3`	Max simultaneous agent runs.
`AGENT_DEBUG`	`false`	When `true`, full prompts are written to the stderr debug log.

See .env.example.

6. Build

npm run build      # compiles TypeScript to ./dist

Other scripts:

npm run dev        # run from source with tsx (no build step)
npm start          # run the compiled server (node dist/index.js)
npm test           # run the vitest suite
npm run typecheck  # type-check only, no emit
npm run lint       # eslint

7. Register with Claude Code (`claude mcp add`)

After building, register the compiled server. Provide the allowlist and any other config via --env flags.

macOS / Linux:

claude mcp add local-agent-hub \
  --env AGENT_ALLOWED_ROOTS=/Users/me/projects,/home/me/work \
  --env AGENT_ALLOW_WRITE=false \
  --env AGENT_MAX_CONCURRENCY=3 \
  -- node /absolute/path/to/local-agent-mcp/dist/index.js

Windows (PowerShell):

claude mcp add local-agent-hub `
  --env AGENT_ALLOWED_ROOTS="C:\Users\me\projects,C:\work" `
  --env AGENT_ALLOW_WRITE=false `
  --env AGENT_MAX_CONCURRENCY=3 `
  -- node "C:\path\to\local-agent-mcp\dist\index.js"

Everything after -- is the command Claude Code will spawn. Use an absolute path to dist/index.js.

Verify:

claude mcp list

8. `.mcp.json` configuration example

To share the server via a project-scoped config, add it to .mcp.json (see .mcp.json.example):

{
  "mcpServers": {
    "local-agent-hub": {
      "command": "node",
      "args": ["./dist/index.js"],
      "env": {
        "AGENT_ALLOWED_ROOTS": "C:\\Users\\me\\projects,C:\\work",
        "AGENT_ALLOW_WRITE": "false",
        "AGENT_MAX_OUTPUT_BYTES": "5000000",
        "AGENT_MAX_CONCURRENCY": "3",
        "AGENT_DEBUG": "false"
      }
    }
  }
}

On Windows, JSON requires escaped backslashes (\\) in paths. On macOS/Linux use ordinary forward-slash paths.

9. Calling the tools from Claude Code

Once registered, just ask Claude Code in natural language; it will select the tool and fill parameters. The tools are:

agent_health — environment/version/config snapshot.
codex_run — run Codex non-interactively.
opencode_run — run OpenCode non-interactively.
agent_compare — run both (read-only) and return both results.

Example prompts:

"Use agent_health to check whether Codex and OpenCode are installed."

"With codex_run, analyze the code in /Users/me/projects/api (read-only) and summarize the request-handling flow."

"Use agent_compare on C:\work\service to ask both agents how they'd add input validation, then tell me where they agree."

Tool parameters

codex_run

Param	Type	Default	Notes
`prompt`	string (req)	—	Instructions for Codex.
`cwd`	string (req)	—	Absolute path inside an allowed root.
`mode`	`read_only` \| `workspace_write`	`read_only`	Maps to Codex `--sandbox read-only` / `workspace-write`.
`model`	string	—	Optional model override (`-m`).
`timeout_seconds`	number (10–3600)	300	Kill after timeout (SIGTERM→SIGKILL).
`output_mode`	`final` \| `events`	`final`	`events` also returns raw parsed events.

opencode_run

Param	Type	Default	Notes
`prompt`	string (req)	—	Instructions for OpenCode.
`cwd`	string (req)	—	Absolute path inside an allowed root.
`model`	string	—	`provider/model`.
`agent`	string	—	Named OpenCode agent.
`session_id`	string	—	Continue an existing `ses_...` session.
`auto_approve`	boolean	`false`	Maps to `--auto`; write action, requires `AGENT_ALLOW_WRITE=true`.
`timeout_seconds`	number (10–3600)	300
`output_mode`	`final` \| `events`	`final`

agent_compare

Param	Type	Default	Notes
`prompt`	string (req)	—	Sent to both agents.
`cwd`	string (req)	—	Absolute path inside an allowed root.
`codex_model`	string	—	Codex model override.
`opencode_model`	string	—	OpenCode model override.
`timeout_seconds`	number (10–3600)	300	Per agent.
`parallel`	boolean	`true`	Run both at once or sequentially.

agent_compare is always read-only and never judges a winner — it returns both results verbatim for Claude Code to synthesize.

10. Path differences: Windows / macOS / Linux

Absolute paths are required. Relative paths are rejected.
Windows: use drive-letter paths, e.g. C:\Users\me\projects. In JSON (.mcp.json) escape backslashes: C:\\Users\\me\\projects. Path comparison is case-insensitive on Windows.
macOS/Linux: use POSIX paths, e.g. /Users/me/projects or /home/me/work. Comparison is case-sensitive.
Symlinks are fully resolved with fs.realpath before the allowlist check, on every platform. On macOS note that /tmp and /var are symlinks; the resolved (/private/...) path is what gets checked.
Windows executable resolution: npm installs codex/opencode as .cmd shims. Node's spawn with shell:false cannot launch .cmd files (a security fix, CVE-2024-27980). This server resolves the underlying native .exe or node <entry>.js and spawns that directly — so shell:false is always preserved and no shell parsing ever happens.

11. Security notes

stdout is protocol-only. All logs go to stderr; nothing else is ever written to stdout.
Directory allowlist. Every cwd is realpath-resolved and must live inside an AGENT_ALLOWED_ROOTS entry (also realpath-resolved). This blocks ../ traversal and symlink escapes.
Read-only by default. Writes require AGENT_ALLOW_WRITE=true. Even then, agent_compare stays read-only.
No shell, ever. Processes are spawned with shell:false and arguments as a discrete array — no string concatenation, so command injection via prompt/model/paths is not possible.
No arbitrary executables. Only the fixed codex/opencode binaries are ever launched; user input never chooses the program.
No dangerous bypasses. The server never passes Codex's --dangerously-bypass-approvals-and-sandbox or danger-full-access, and exposes no arbitrary-shell tool.
Concurrency + write lock. A global semaphore caps simultaneous runs; at most one write task may touch a given directory at a time.
Output cap. Combined stdout+stderr is capped (AGENT_MAX_OUTPUT_BYTES).
Timeouts. Runs are killed after timeout_seconds (SIGTERM, then SIGKILL after a 5s grace period).
Input limits. prompt, cwd, model, agent, session_id have length caps.
Redaction. Bearer tokens, API keys (sk-…, ghp_…, AWS keys), JWTs, and key=value secrets are masked in logs and error messages.
Prompt privacy. Full prompts are not logged unless AGENT_DEBUG=true.

The server trusts the local, already-authenticated Codex/OpenCode credentials. Anyone able to call this MCP server can run those CLIs within the allowlist, so only expose it to trusted clients (Claude Code on your own machine).

12. Troubleshooting

Symptom	Cause / Fix
`agent_health` shows `codexInstalled:false`	`codex` not on PATH for the server process. Confirm `codex --version` in the same shell; reinstall if needed.
`codex_not_found` / `opencode_not_found`	Same as above for the run tools. On Windows, ensure the npm global bin dir is on PATH.
`no_allowed_roots`	`AGENT_ALLOWED_ROOTS` is empty. Set it to absolute directories.
`cwd_not_absolute`	You passed a relative path. Use an absolute one.
`cwd_outside_allowed`	The (realpath-resolved) cwd is not inside any allowed root — including symlink targets.
`cwd_not_found`	The directory does not exist or is not accessible.
`write_not_allowed`	You requested `workspace_write`/`auto_approve` but `AGENT_ALLOW_WRITE` is not `true`.
`write_lock_conflict`	Another write task is already running for that directory. Retry after it finishes.
`timeout`	The run exceeded `timeout_seconds`. Raise it (max 3600) or narrow the task.
Result `truncated:true`	Output exceeded `AGENT_MAX_OUTPUT_BYTES`. Raise it or reduce output.
Codex returns a usage-limit error	That's from Codex/your account, surfaced verbatim in `errors`.
Nothing happens / client can't connect	Ensure you built (`npm run build`) and pointed the client at the absolute `dist/index.js`. Check the server's stderr.
Want to see prompts in logs	Set `AGENT_DEBUG=true` (logs to stderr only).

13. Uninstall / remove the MCP server

Remove it from Claude Code:

claude mcp remove local-agent-hub

Or delete the mcpServers.local-agent-hub entry from your .mcp.json.

Then optionally delete this project directory. Removing this server does not affect your Codex or OpenCode installations or their logins.

Public demo evidence

public-demo/demo-manifest.json is generated from one real local, read-only Codex and OpenCode run against the fixed fixtures/public-demo scenario. The companion publication-receipt.json binds the manifest's SHA-256 digest to the complete publication audit.

The two model outputs are shown without ranking and are not benchmark scores. They are review evidence for the same small input-validation fixture.

Privacy boundary

When deployed, the portfolio imports these two reviewed JSON files as a static replay. It cannot call Codex or OpenCode, spawn a CLI, accept a prompt, proxy a request, or access local Agent credentials. Real execution remains on the local machine.

The publication audit rejects write-enabled policy, absolute paths, local usernames, credential-shaped values, auth headers, session/thread identifiers, raw stderr, unreviewed prompts, failed Agent runs, and incomplete verification.

Verification

Run the complete local quality gate:

npm run check

To verify only the committed replay bundle:

npm run demo:audit

demo:audit validates the schema, privacy boundary, read-only policy, complete test totals, receipt checks, and manifest hash without requiring either Agent login. CI runs this offline audit and never invokes demo:record.

License

MIT

Available Tools

4 tools

agent_compareCompare Codex and OpenCodeA

Run Codex and OpenCode against the same prompt in READ-ONLY mode and return both results verbatim. Does not judge which is better; the caller synthesizes the conclusion. One agent failing does not suppress the other.

ParametersJSON Schema

Name	Required	Description
`cwd`	Yes	Absolute path to an allowed working directory.
`prompt`	Yes	Prompt for both agents.
`parallel`	No	Run both agents in parallel (default) or sequentially.
`codex_model`	No	Codex model override.
`opencode_model`	No	OpenCode model override.
`timeout_seconds`	No	Per-agent timeout in seconds (10-3600).

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions READ-ONLY mode and independent failure, but does not describe output format or potential side effects. Adequate but not comprehensive.

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 sentences, all essential. No fluff. Efficiently covers purpose and behavioral notes.

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?

Missing output schema, so description should clarify return format. It says 'return both results verbatim' but does not specify structure. Also lacks detail on directory constraints. Adequate but incomplete.

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 description adds no new parameter meanings beyond what schema already provides. Baseline 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?

Clearly states it runs both Codex and OpenCode against the same prompt in READ-ONLY mode and returns results verbatim. Distinguishes from sibling tools like codex_run and opencode_run.

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?

Explicitly says the caller synthesizes the conclusion and that one agent failing does not suppress the other. Provides good usage context, though could explicitly mention when not to use.

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

agent_healthAgent Health CheckA

Report the local agent environment: Node version, Git availability, Codex/OpenCode install status and versions, allowed working directories, whether writes are permitted, and current concurrency usage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/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. It thoroughly lists what is reported, including 'whether writes are permitted' and 'current concurrency usage,' which implies a safe read operation. It could mention that it has no side effects, but the description is sufficiently transparent for the given complexity.

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, front-loaded sentence that efficiently conveys the tool's purpose. Every word contributes meaning, with no 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 fully covers what the tool does. It lists all key aspects of the agent environment, providing complete contextual information for an agent to decide when to call it.

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?

The tool has zero parameters, and the schema coverage is 100%. The description adds meaning by detailing what the output includes, making it more valuable than the empty schema alone.

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 specific verbs and nouns: 'Report the local agent environment:' followed by a detailed list of items (Node version, Git availability, etc.). This clearly distinguishes it from siblings like codex_run and opencode_run, which perform execution tasks.

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 health checks but does not explicitly state when to use this tool vs alternatives or provide exclusions. An agent can infer but lacks explicit guidance.

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

codex_runRun Codex CLIA

Run the locally installed, logged-in Codex CLI non-interactively in a sandboxed working directory. Defaults to read-only. Use workspace_write only when writes are enabled server-side. Returns the final agent message plus command/file-change/error summaries.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	Yes	Absolute path to an allowed working directory.
`mode`	No	read_only (default) or workspace_write.	read_only
`model`	No	Optional model override.
`prompt`	Yes	Instructions for Codex.
`output_mode`	No	final summary or full raw events.	final
`timeout_seconds`	No	Timeout in seconds (10-3600).

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: local installation requirement, non-interactive mode, sandbox, default read-only, and return structure (final message plus summaries). Warns about enabling writes via workspace_write.

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 succinct sentences, each providing distinct value: purpose, usage guideline, and return description. No redundancy or unnecessary detail.

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 6 parameters and no output schema, the description covers the tool's purpose, key behavioral constraints, and output summary. Could briefly elaborate on 'events' output mode for full completeness.

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 has 100% parameter description coverage, so baseline is 3. The description adds context for the mode parameter (when to use workspace_write) and hints at return format, but does not significantly enhance understanding of other parameters.

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?

Clearly identifies the tool as running Codex CLI non-interactively in a sandbox, with a default read-only mode. However, it does not explicitly differentiate from sibling tools like opencode_run, limiting clarity slightly.

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 explicit guidance: 'Use workspace_write only when writes are enabled server-side.' This helps the agent decide when to use each mode. Missing contrast with opencode_run or other alternatives.

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

opencode_runRun OpenCode CLIA

Run the locally installed, logged-in OpenCode CLI non-interactively in a sandboxed working directory. auto_approve enables side-effecting actions and requires server-side write permission. Supports session continuation and agent/model selection.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	Yes	Absolute path to an allowed working directory.
`agent`	No	Named OpenCode agent.
`model`	No	provider/model override.
`prompt`	Yes	Instructions for OpenCode.
`session_id`	No	Existing session id (ses_...) to continue.
`output_mode`	No	final summary or full raw events.	final
`auto_approve`	No	Auto-approve actions (write). Requires AGENT_ALLOW_WRITE.
`timeout_seconds`	No	Timeout in seconds (10-3600).

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses sandboxed directory, non-interactive execution, side-effecting actions with auto_approve, and session continuation. However, it omits details like idempotency or error handling, which would be useful for risky operations.

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 redundancy. The main action is front-loaded, followed by essential details. Every word 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?

With 8 parameters (2 required) and no output schema, the description covers the core behavioral contracts and parameter meanings. It could mention what the tool returns (e.g., output of CLI) but is otherwise adequate for invocation.

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 100%, but the description adds value beyond schema by explaining that auto_approve enables side effects and requires server-side permission. It also contextualizes session_id as 'session continuation'. This reduces ambiguity for the 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 uses specific verb-resource pairing ('Run the ... OpenCode CLI') with context ('non-interactively in a sandboxed working directory'). It clearly differentiates from siblings like 'agent_health' (health check) and 'codex_run' (likely another CLI runner) by specifying the exact CLI and mode.

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 explains when to use auto_approve and mentions session continuation, but does not explicitly state when to prefer this tool over siblings or when not to use it. Still, the context is clear for an experienced user.

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 updatesv1.0.0Jul 28, 2026
- First observedagent_compare
- First observedagent_health
- First observedcodex_run
- First observedopencode_run

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 distinct purpose: agent_health reports environment, codex_run runs Codex, opencode_run runs OpenCode, agent_compares both. No overlap or ambiguity.

Naming Consistency4/5

All tools use snake_case with descriptive names, but there's a mix: agent_health is noun-based while codex_run, opencode_run, and agent_compare are verb-focused. Still predictable and clear.

Tool Count5/5

4 tools is well-scoped for the domain of running and comparing local AI agents. Each tool earns its place without redundancy or bloat.

Completeness4/5

Covers health check, execution of both agents, and comparison. Minor gaps like lacking a tool to stop running agents or manage sessions, but core workflows are covered.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2
docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2

Related MCP Servers

codex-dobby-mcp
Developer Tools Coding Agents
Averyy
A
license
A
quality
C
maintenance
A local MCP server that lets Claude delegate scoped work to Codex with structured results and guardrails, supporting planning, code review, build, reverse engineering, and long-running background tasks.
Updated 2 months ago (2026-07-10 18:06 UTC)
11
MIT
codex-cli-mcp-tool
Code Execution Coding Agents
Mr-Tomahawk
A
license
Not graded
quality
F
maintenance
An MCP server that allows Claude Code to interact with the OpenAI Codex CLI.
Updated a year ago (2025-08-19 07:26 UTC)
29
21
MIT
codex-offload-mcp
Coding Agents Autonomous Agents Code Execution
jgt87
A
license
A
quality
B
maintenance
An MCP server for running Claude Code and the Codex CLI as a pair: Claude drives, and hands self-contained tasks to Codex as background jobs.
Updated a month ago (2026-07-28 20:48 UTC)
8
MIT
Codex Native Bridge
Agent Orchestration Coding Agents Autonomous Agents
PatrickStar-sketch
A
license
A
quality
B
maintenance
An MCP server that lets Claude Code delegate durable background tasks, reasoning profiles, thread resumption, and native image generation to your local Codex CLI.
Updated a month ago (2026-08-10 04:49 UTC)
10
1
MIT

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/3230390742/local-agent-mcp'

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

local-agent-mcp

1. Architecture

2. Prerequisites

3. Install dependencies

4. Check that Codex and OpenCode are logged in

5. Environment variables

6. Build

7. Register with Claude Code (claude mcp add)

8. .mcp.json configuration example

9. Calling the tools from Claude Code

Tool parameters

10. Path differences: Windows / macOS / Linux

11. Security notes

12. Troubleshooting

13. Uninstall / remove the MCP server

Public demo evidence

Privacy boundary

Verification

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

7. Register with Claude Code (`claude mcp add`)

8. `.mcp.json` configuration example