What can you do with this server?

This MCP server performs read-only code analysis on a workspace directory by asking a fixed free/available model a focused question about the code. * analyze_code_cloudflare — read-only analysis using Cloudflare Workers AI GLM 4.7 Flash at low reasoning effort; intended to be tried first. * analyze_code_mimo — read-only analysis using OpenCode MiMo V2.5 Free at low reasoning effort; used when Cloudflare GLM fails or is insufficient. * analyze_code_nemotron — read-only analysis using NVIDIA Nemotron 3 Nano Omni at low reasoning effort; the last fallback. * Each tool takes only directory (absolute path under an allowed root, default C:\Develop) and prompt (1–12 000 chars), and returns the model's analysis plus header/attempt info. * It cannot modify anything: OpenCode is run with --agent plan, shell: false, and a prompt that forbids edits, state-changing commands, and hidden/credential files, node_modules, .git, and build output. * It reports failures with exit codes, NDJSON error messages, elapsed/timeout info, and stderr tails, after redacting secrets (API keys, bearer tokens, JWTs, credential objects). * The README also documents a model-discovery flow (list_free_models) and a generic analyze_code tool with auto model ordering, probing, and a budgetMs wall-clock budget — but the exposed schema only contains the three fixed-model tools above. * Configured via OPENCODE_BIN, OPENCODE_HELPER_ALLOWED_ROOTS, and OPENCODE_HELPER_ATTEMPT_TIMEOUT_MS; OpenCode uses its own stored credentials and the helper never reads or stores API keys.

Which integrations are available for this server?

Provides code analysis using Cloudflare Workers AI models (e.g., GLM-4.7-flash) via OpenCode, configured as the primary analysis provider with fallbacks to other services. Provides code analysis using NVIDIA's Nemotron models via OpenCode, used as a fallback option when earlier providers fail or are insufficient.

How do I use OpenCode Helper MCP?

1. Click on "Deploy 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., "@OpenCode Helper MCP Analyze the code in C:\Develop\my-app for bugs" 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.

OpenCode Helper MCP

Read-only MCP server for code analysis through OpenCode. Nothing hard-codes a model: the server discovers which free models OpenCode can use right now, and the client (Claude Code, Codex, …) picks one.

Tools

`list_free_models`

Returns JSON with the currently available free models (id, provider, name, free_basis, context).

Input	Default	Meaning
`probe`	`false`	Send a tiny read-only health prompt to each listed model in parallel (4 at a time, 30 s cap each). Adds `probe: { status: ok\|failed\|timeout, latency_ms, error }`.
`refresh`	`false`	Ignore the 10-minute cache and re-read the list (and re-probe).
`models`	all	Only return/probe these ids.
`provider`	all	Only return models of one provider, e.g. `opencode` or `nvidia`.

Free rule: the list comes from opencode models --verbose. A model is free when its cost.input and cost.output are both 0. If OpenCode gives no cost metadata (or --verbose fails and the plain opencode models list is used), ids ending in -free / :free, or opencode/big-pickle, count as free. Models without tool-call support (embeddings, TTS, image) and deprecated models are excluded. Only providers that OpenCode has credentials for appear in the list.

`analyze_code`

Inputs: directory, prompt, optional maxWords, budgetMs, model, models.

Recommended: call list_free_models first (probe: true when unsure), then pass the chosen model and optionally an ordered fallback list in models.
Only ids in the current free list are accepted; others are rejected with the list of valid ids.
Without model/models the helper auto-orders: opencode/deepseek-v4.1-flash-free, opencode/glm-5.3-flash-free, opencode/mimo-v2.6-flash-free (each only if currently listed), then other free models (recently probed-OK first, fastest first, opencode/* before others). Models that failed or timed out in a recent probe are skipped. At most 4 automatic attempts.
Each model is called at most once. budgetMs (30 000–600 000, default 300 000) is the total wall-clock budget; each attempt gets up to 120 s while 30 s per remaining attempt is reserved, a single attempt may use the whole budget, and time left by a fast failure goes to the next attempt.
--variant low is passed only for models that offer a low variant.

The result starts with a header:

## CodeHelper
- Model: opencode/glm-5.3-flash-free (23874 ms)
- Selection: auto (opencode/deepseek-v4.1-flash-free → opencode/glm-5.3-flash-free → …)
- Attempts:
  1. opencode/deepseek-v4.1-flash-free — failed 812 ms (cap 120000 ms): OpenCode exited with code 1 after 812 ms.
      Error: <NDJSON error message>
      stderr (tail): <last ~1500 chars>
  2. opencode/glm-5.3-flash-free — ok 23874 ms (cap 120000 ms)

Related MCP server: BoundedRelay

Errors

Failures report the exit code, the error message from OpenCode's NDJSON output when present, and the last ~1500 characters of stderr. Timeouts report the elapsed milliseconds. Everything is passed through secret redaction first (bearer/Authorization values, sk-/nvapi-/gsk_/ghp_-style keys, api_key=…/token: … pairs, JWTs, long key-like strings, and any auth.json-style credential object). Model metadata such as headers/options is never stored or returned.

Safety

OpenCode runs as opencode run --dir <dir> --model <id> [--variant low] --agent plan --format json <prompt> with shell: false; the prompt forbids edits, state-changing commands, hidden/credential files and node_modules/.git/build output.
Target folders must resolve canonically (junctions and symlinks resolved) under C:\Develop; set OPENCODE_HELPER_ALLOWED_ROOTS to a semicolon-separated list to change that.
Child stdout (1 MiB, 8 MiB for model listing) and stderr (64 KiB) are bounded; timeouts and overflows kill only the known child process tree (taskkill /t /f on Windows).

Configuration

Env var	Meaning
`OPENCODE_BIN`	Path to `opencode` (default: `opencode` on PATH).
`OPENCODE_HELPER_ALLOWED_ROOTS`	Allowed workspace roots (default `C:\Develop`).
`OPENCODE_HELPER_ATTEMPT_TIMEOUT_MS`	Fallback per-attempt timeout when no budget is given (default 120 000; `OPENCODE_HELPER_TIMEOUT_MS` is still read for compatibility).

Run locally

npm install
npm start

Tests

npm test

Add to Codex

codex mcp add opencodeHelper -- node C:\Develop\openCodeHelperMcp\src\index.js

Open a new Codex task (or restart Claude Code) after updating the server. OpenCode uses its own stored credentials; the helper never stores or reads API keys.

Available Tools

3 tools

analyze_code_cloudflareAnalyze code with Cloudflare GLMA

Read-only code analysis using the fixed Cloudflare Workers AI GLM 4.7 Flash model at low reasoning effort. Use this first.

Name	Required	Description	Default
`prompt`	Yes	The focused code-analysis question.
`directory`	Yes	Absolute workspace path under an allowed root.

TDQS

A4.2/5.0

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, and it succeeds in an important way: 'Read-only' discloses the safety profile, while 'fixed model' and 'low reasoning effort' set expectations about determinism and output quality. It does not describe output format or potential rate limits, but for a read-only analysis tool this is reasonable.

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 short sentences, zero filler. The core behavior is front-loaded and the usage directive is immediate. 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?

For a two-parameter read-only tool, the description gives model identity, safety profile, reasoning effort, and default usage priority. It is slightly thin on what the response looks like, but with 100% schema coverage and no output complexity this is acceptable.

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 parameter meanings are already fully documented in the schema. The description adds no further param detail, so the baseline 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 this is a read-only code analysis tool and identifies the exact model (Cloudflare Workers AI GLM 4.7 Flash). The phrase 'Read-only code analysis' gives a specific verb and resource, and the tool is differentiated from its siblings by being the recommended Cloudflare/GLM option.

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?

'Use this first' provides explicit selection guidance, telling the agent this is the default among sibling analysis tools. It does not explain when to prefer analyze_code_mimo or analyze_code_nemotron, but the priority is clearly established.

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

analyze_code_mimoAnalyze code with MiMo FreeA

Read-only code analysis using the fixed OpenCode MiMo V2.5 Free model at low reasoning effort. Use this after Cloudflare GLM fails or is insufficient.

Name	Required	Description	Default
`prompt`	Yes	The focused code-analysis question.
`directory`	Yes	Absolute workspace path under an allowed root.

TDQS

A4.2/5.0

Behavior4/5

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

Anontations are absent, and description carries the full burden. It discloses the important read-only nature of the operation and the low reasoning effort, a useful performance trait. It does not go into return maps or rate limits, but it does offer meaningful behavioral context beyond the bare schema.

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 word I count is minimal, each sentence earns its place: the first defines the capability, the second defines the usage condition. The description is appropriately small, well-ordered, and holds no 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?

With only two well-sdhema'd parameters and no output schema, the description does not need to explain internals. However, some behavioral aspects such as return semantics or output format are not touched, which are minor for a read-analy analysis tool.

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?

He schema already has 100% coverage for both required parameters: 'prompt' has a focused question description and 'directory' a path description. The description adds no new semantic detail, so a 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?

The description communicates a specific verb (analyze), a focused resource (code), and a specific model (fixed OpenCode MiMo V2.5 Free) with clarity and concision. By mentioning 'read-only' and naming Cloudflare GLM, it distinguishes itself from its primary sibling and provides a clear differentiation.

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?

It tells the agent exactly when to use it — after Cloudflare GLM fails or is insufficient — thereby providing a critical routing context. It does not explicitly mention the Nemotron sibling or exclude that alternative, which is a minor omission; hence the 4 rather than 5.

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

analyze_code_nemotronAnalyze code with NVIDIA NemotronA

Read-only code analysis using the fixed NVIDIA Nemotron 3 Nano Omni model at low reasoning effort. Use this after MiMo fails or is insufficient.

Name	Required	Description	Default
`prompt`	Yes	The focused code-analysis question.
`directory`	Yes	Absolute workspace path under an allowed root.

TDQS

A3.7/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 disclosure burden. It does convey 'read-only,' the fixed model, and low reasoning effort, which are meaningful behavioral details. It still lacks information about the tool's return format, error behavior, or failure modes, so transparency is incomplete.

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 two tightly written sentences with no filler. The core 'read-only code analysis' behavior is front-loaded, and the usage routing note follows efficiently.

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?

For a small 2-parameter read-only tool, the description provides adequate context for purpose and routing. The absence of an output schema and the lack of any description of what the result looks like means the behavioral contract is not fully complete. Still, the read-only nature and model selection details mitigate many concerns.

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 input schema already fully documents the two parameters. The tool description adds no parameter-level detail, which is acceptable at the baseline of 3 but no more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs read-only code analysis using a specific model, which goes beyond just restating the name. However, it does not explicitly distinguish itself from the Cloudflare sibling beyond the shared 'analyze_code' prefix, so differentiation is incomplete.

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?

It explicitly says 'Use this after MiMo fails or is insufficient,' giving a clear when-to-use condition and naming one alternative. It does not mention the Cloudflare sibling, so the routing guidance is partial but still useful.

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.

3 tool updatesv0.1.0Aug 24, 2026
- First observedanalyze_code_cloudflare
- First observedanalyze_code_mimo
- First observedanalyze_code_nemotron

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.8/5.0

Scored 2026-08-24 15:46 across 3 tools

Disambiguation2/5

The three tools share the same core operation—analyzing code at low reasoning effort—and differ only by backend model. Their descriptions include model names and a fallback order, but there is no distinct purpose-based choice; an agent can only distinguish them by which fallback step it happens to need.

Naming Consistency5/5

All tools follow the consistent pattern analyze_code_<model>, with matchings-style and no mixing of verbs or argument formats. The naming is predictable and readable.

Tool Count4/5

Three tools is not necessarily bloated, and the fallback approach justifies multiple endpooints. However, this functionality could just as easily be a single tool with model parameter, so the count is slightly inflated by the redundancy.

Completeness3/5

The server covers its narrow read-only code analysis goal by providing three fallback models. But beyond analyzing a snippet/no input, there is no capability for fetching code, changing analysis params, handling analysis output, or performing any related helper task, which leaves the surface limited.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121
https://mcp.claude-world.com/mcp
Shellway AOAuth
com.getshellway
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Command Line Developer Tools
1
https://mcp.getshellway.com/mcp
Apex (smartapex.uk) AI Component Card Store A
io.github.mickeyappol-create
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
AI & Machine Learning Developer Tools Agent Orchestration
242
https://smartapex.uk/api/mcp
SBOMApp - SBOM Generator & Vulnerability Scanner
io.github.mcpsbom
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Developer Tools Security Testing & QA Tools
2
https://mcp.sbomapp.com/mcp

Related MCP Servers

Codex to OpenCode MCP Server
Coding Agents Autonomous Agents Developer Tools
TAO-MINGYU
A
license
A
quality
C
maintenance
Enables Codex to delegate coding tasks to an OpenCode CLI locally, returning structured results such as exit codes, session summaries, tool calls, and git diffs.
Updated 2 months ago (2026-08-24 13:55 UTC)
2
MIT
BoundedRelay
Agent Orchestration Autonomous Agents Coding Agents
mohammad19974
A
license
Not graded
quality
B
maintenance
Enables Claude Code to delegate bounded, read-only analysis and isolated patch proposals to the locally installed Codex CLI over MCP, with sanitized live status, revision-aware polling, and reviewable results.
Updated a month ago (2026-10-01 23:12 UTC)
1
MIT
@cognium/mcp-serverofficial
Code Analysis Penetration Testing Developer Tools
cogniumhq
A
license
Not graded
quality
D
maintenance
Enables MCP clients such as Cursor, Claude Desktop, and Claude Code to run deterministic static-analysis tools for scanning projects, listing entry points and reachable sinks, tracing taint paths, explaining findings, and checking sanitizers without API keys or network access.
Updated 12 days ago (2026-10-19 03:47 UTC)
MIT
Cognitally
Observability Monitoring Developer Tools
kamanager2012
A
license
Not graded
quality
B
maintenance
Enables AI coding agents such as Claude Code, Cursor, Codex, and OpenCode to query local token usage, costs, quotas, projects, and models through six strictly read-only tools. All data stays on the local machine, drawn from passively parsed session logs rather than uploaded telemetry.
Updated a month ago (2026-10-04 12:26 UTC)
MIT

OpenCode Helper MCP

Tools

list_free_models

analyze_code

Errors

Safety

Configuration

Run locally

Tests

Add to Codex

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Codex to OpenCode MCP Server

BoundedRelay

@cognium/mcp-serverofficial

Cognitally

`list_free_models`

`analyze_code`