What can you do with this server?

The OpenCode Advisor MCP server provides a single tool (ask_opencode_advisor) to request a read-only second-opinion code review of Git changes from a local OpenCode advisor agent. What you can do: * Request a code review of current Git changes (diff and/or status) * Ask a specific question (question) to focus the advisor on particular concerns (e.g., risks, missing tests, privacy issues) * Provide a high-level goal (goal) to give the advisor context about what the changes aim to achieve * Scope the review to a specific working directory (cwd) or particular file paths (paths) * Compare against a specific base ref (base_ref) to control which Git diff is reviewed * Include or exclude the Git diff (include_diff) or status (include_status) from the review context * Limit diff size (max_diff_chars) to control how much diff content is sent to the advisor * Receive structured JSON responses with stable error codes (e.g., invalid_cwd, git_failed, timeout) for predictable error handling The advisor operates in read-only mode — the bundled template is designed to block writes and deny .env reads.

Which integrations are available for this server?

Allows Codex (OpenAI's coding assistant) to request a review of Git changes from an OpenCode advisor, focusing on risks, tests, privacy, and release readiness.

How do I use OpenCode Advisor 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., "@OpenCode Advisor MCP Review the current git diff for potential bugs and security issues." 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 Advisor MCP

by henrydontbbai

Overview Schema Related Servers Score Discussions

JavaScript

Local

OpenCode Advisor MCP

OpenCode Advisor MCP gives Codex three local MCP tools:

ask_opencode_advisor for a read-only reviewer pass
ask_opencode_planner for a read-only planning pass
get_opencode_task for queued or running work

The MCP server has exactly two built-in roles: reviewer and planner. It does not reuse normal OpenCode, Codex, or Cockpit provider settings. The bundled agents can reason only over the request plus supplied Git status/diff context and, for the planner, the supplied plan; they have no file or shell tools.

Install And Configure

The current supported install path is the verified tarball attached to the GitHub v0.3.0 Release. This release process did not publish to npm, and no npm-registry install path is supported for v0.3.0.

Invoke-WebRequest https://github.com/henrydontbbai/opencode-advisor-mcp/releases/download/v0.3.0/opencode-advisor-mcp-0.3.0.tgz -OutFile opencode-advisor-mcp-0.3.0.tgz
Invoke-WebRequest https://github.com/henrydontbbai/opencode-advisor-mcp/releases/download/v0.3.0/SHA256SUMS.txt -OutFile SHA256SUMS.txt
$expected = "47a4697ad28e99fd85ba2951ac21289a566378948743526f2b1cde5cbd905fa1"
$manifest = (Get-Content .\SHA256SUMS.txt -Raw).Trim()
if ($manifest -ne "$expected  opencode-advisor-mcp-0.3.0.tgz") { throw "Release manifest mismatch" }
$actual = (Get-FileHash .\opencode-advisor-mcp-0.3.0.tgz -Algorithm SHA256).Hash.ToLowerInvariant()
if ($actual -ne $expected) { throw "Release checksum mismatch" }
npm install -g .\opencode-advisor-mcp-0.3.0.tgz
opencode-advisor-setup

For another local packed tarball, install that exact file:

npm install -g <path-to-opencode-advisor-mcp.tgz>
opencode-advisor-setup

For source development or as a fallback, install dependencies and run setup from the checkout:

npm ci
npm run setup

opencode-advisor-setup requires an interactive terminal. It asks for a third-party provider ID, display name, API base URL, transport (responses or chat_completions), model list, reviewer model and optional reasoning variant, planner model and optional reasoning variant, and API key. The key is hidden at entry and is never accepted from command arguments, MCP TOML, or a pipe. Setup does not inspect normal OpenCode, Codex, or Cockpit configuration, credentials, or account-login state; no OpenCode account login is required.

The setup command creates an independent profile under %USERPROFILE%\.codex\opencode-advisor on Windows or $HOME/.codex/opencode-advisor on POSIX. Windows credentials use CurrentUser DPAPI. POSIX uses a filesystem-permission fallback: private 0700 profile directories and a 0600 Base64-encoded credential envelope, rather than DPAPI-equivalent encryption. The profile contains the bundled codex-advisor and codex-planning-partner agent templates plus a non-secret provider manifest.

The credential is bound to the exact manifest fingerprint, and the generated OpenCode overlay must also match that manifest. An incomplete profile written during setup, stale overlay, or binding mismatch is fail-closed: MCP calls return setup guidance without queuing work. If setup ends before it writes profile artifacts, a previously valid profile remains usable. Rerun opencode-advisor-setup instead of editing profile artifacts by hand.

Related MCP server: codex-claude-bridge

MCP Configuration

For a source checkout, use Node and the absolute server path. The only required environment setting is OPENCODE_ADVISOR_ALLOWED_ROOTS:

[mcp_servers.opencode_advisor]
command = "node"
args = ["C:\\absolute\\path\\to\\opencode-advisor-mcp\\src\\server.mjs"]
startup_timeout_sec = 30
tool_timeout_sec = 420

[mcp_servers.opencode_advisor.env]
OPENCODE_ADVISOR_ALLOWED_ROOTS = "C:\\workspace\\allowed-repositories"

For a GitHub Release or local tarball installed globally, use command = "opencode-advisor-mcp"; examples/codex-mcp.toml shows that installed-package form.

Do not put provider URLs, model IDs, API keys, tokens, or OPENCODE_CONFIG_CONTENT in the MCP configuration. See docs/CONFIGURATION.md for non-secret runtime settings.

Provider Compatibility

The setup transport is explicit:

responses generates an @ai-sdk/openai provider. OpenCode owns the Responses streaming SSE exchange, including output-text events such as response.output_text.delta / response.output_text.done, error events (error, response.failed), and function-call events.
chat_completions generates an @ai-sdk/openai-compatible provider and uses standard /v1/chat/completions stream chunks followed by [DONE].

Each role can optionally select an OpenCode model variant. The choices are independent even when reviewer and planner use the same model; a common setup is reviewer high and planner max. Leave a variant empty to use the model default. For a responses provider/model that supports the selected variant, the generated OpenCode model variant reaches the Responses request as reasoning.effort. high and max are examples, not values guaranteed by every provider or model.

The built-in agents deny all tool execution. A streamed function call is covered only as a fail-closed condition: it is not executed, does not complete a tool round-trip, and the built-in-agent fixture expects a timeout rather than a reviewer or planner result. Raw provider tool events are not MCP output; only structured assistant text can become a reviewer or planner result. The provider key belongs only to the independent Advisor profile.

Verify

From a source checkout:

npm run smoke
npm test
npm run test:doctor
$env:OPENCODE_ADVISOR_ALLOWED_ROOTS = "<allowed-root>"
npm run doctor

opencode-advisor-doctor checks the independent profile, both roles, structured JSON output, and sanitized MCP response shape. A missing or unreadable profile remains an opencode_failed MCP result with setup guidance; it never creates a queued task.

Use opencode-advisor-doctor --json (or npm run --silent doctor -- --json from source) for a machine-readable report. JSON mode preserves the same checks and exit status as the default text report and does not add provider settings or credentials.

Security Boundaries

Reviewer and planner child processes run with --pure and an explicit provider/model.
OpenCode receives isolated XDG and OpenCode configuration paths plus a generated OPENCODE_CONFIG_CONTENT overlay.
OPENCODE_DISABLE_PROJECT_CONFIG=1 prevents the reviewed repository's OpenCode configuration from being merged.
Inherited OpenCode, XDG, provider-key, token, secret, and password environment variables are removed before OpenCode starts.
Queue files, runner logs, doctor reports, and MCP responses do not include provider URLs, model selections, role variants, or API keys.
A custom OPENCODE_ADVISOR_OPENCODE_CMD on Windows must name an existing, operator-trusted absolute .exe; command strings with arguments and .cmd / .bat wrappers are rejected.
Keep OPENCODE_ADVISOR_ALLOWED_ROOTS narrow and use this only for repositories you are authorized to disclose to the configured provider.

Further details:

Available Tools

3 tools

ask_opencode_advisorAsk OpenCode AdvisorC

Ask the local read-only OpenCode codex-advisor agent to review current git changes.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`goal`	No
`paths`	No
`base_ref`	No
`question`	No
`include_diff`	No
`include_status`	No
`max_diff_chars`	No

TDQS

C2.9/5.0

Behavior2/5

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

The description mentions 'read-only', implying no destructive side effects, but provides no further behavioral details such as output format, required dependencies (e.g., git repo), or error conditions. With no annotations, this is insufficient for a tool with 8 parameters.

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 sentence, which is concise and to the point. However, it could benefit from additional structure (e.g., listing what the advisor does) without becoming overly verbose.

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?

Given 8 parameters, no output schema, and no annotations, the description is far too minimal. It does not explain the review process, expected output, or parameter interactions, making it hard for an agent to use correctly without prior knowledge.

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%, yet the description adds no explanation for any of the 8 parameters. The parameter names give some hints, but the description does not clarify their types, constraints, or when to use each, leaving ambiguity.

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 asks a read-only advisor to review current git changes. It distinguishes from siblings like ask_opencode_planner and get_opencode_task, which focus on planning and task retrieval respectively.

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?

No explicit guidance is given on when to use this tool versus alternatives. The description lacks any 'when to use' or 'when not to use' context, leaving the agent to infer based on the name and description alone.

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

ask_opencode_plannerAsk OpenCode PlannerC

Ask the local read-only OpenCode planning partner to improve a plan without taking over implementation.

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`goal`	No
`paths`	No
`base_ref`	No
`question`	No
`constraints`	No
`current_plan`	No
`include_diff`	No
`include_status`	No
`max_diff_chars`	No

TDQS

C2.4/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits; it states 'read-only' and 'without taking over implementation', which hints at safety, but does not detail side effects, required permissions, or operational constraints for a tool with 10 parameters.

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 single-sentence description is very concise and front-loaded with the key purpose, but it may be too terse given the tool's complexity.

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?

Given the high parameter count (10), lack of output schema, and no annotations, the description is far too brief to provide sufficient context for correct invocation and understanding of the tool's behavior.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about any of the 10 parameters (cwd, goal, paths, etc.), failing to add meaning beyond their names and types.

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 is for asking a planning partner to improve a plan, distinguishing it from siblings (advisor, task) by specifying it's a planning partner that is read-only and doesn't implement.

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 implies usage for improving plans without implementation, but provides no explicit when-to-use, when-not-to-use, or alternatives compared to sibling tools.

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

get_opencode_taskGet OpenCode TaskB

Check whether a queued or running OpenCode planner/reviewer task has finished.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

TDQS

B3.1/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 full burden. It states the tool checks completion but does not disclose behavior on non-existent tasks, errors, or return format. Minimal behavioral disclosure.

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

Conciseness3/5

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

A single 14-word sentence is front-loaded but too brief. It leaves out parameter explanation that could fit without being verbose.

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?

No output schema and no description of return values. For a tool that polls status, the description should hint at expected response or how to interpret 'finished.' Incomplete for its complexity.

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

Parameters1/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 what task_id is or how to obtain it. The description adds no meaning beyond the schema's raw type definition.

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 'Check' and the resource 'whether a queued or running OpenCode planner/reviewer task has finished,' distinguishing it from sibling tools like ask_opencode_advisor and ask_opencode_planner, which are for 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 Guidelines4/5

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

The description implies usage after submitting a task via sibling tools, but does not explicitly state when not to use or provide alternatives. It is clear enough for a simple polling tool.

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.

3 tool updatesv0.3.0Jul 13, 2026
- Changedask_opencode_advisor2 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedInput schema / properties / max_diff_chars / maximum
```
Added value: +9007199254740991
```
- Addedask_opencode_planner
- Addedget_opencode_task
1 tool updatev0.2.0Jul 4, 2026
- First observedask_opencode_advisor

Install Server

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

TDQS

B3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: ask_opencode_advisor reviews git changes, ask_opencode_planner improves plans, and get_opencode_task checks task status. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: ask_opencode_advisor, ask_opencode_planner, get_opencode_task.

Tool Count3/5

With only 3 tools, the server is minimal but acceptable for a focused local agent interaction. However, it borders on too few for a complete agent workflow.

Completeness3/5

The server provides tools to ask agents and check task status, but lacks tools to retrieve results, cancel tasks, or configure agents, creating potential dead ends.

Maintenance

ActivitySlowing

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

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

Claude Code Review MCP
Code Analysis Developer Tools Code Execution
praneybehl
A
license
A
quality
F
maintenance
An MCP server that provides code review functionality using OpenAI, Google, and Anthropic models, serving as a "second opinion" tool that works with any MCP client.
Updated a year ago (2025-05-16 05:22 UTC)
1
42
33
MIT
codex-claude-bridge
Developer Tools Code Analysis Testing & QA Tools
AmirShayegh
A
license
Not graded
quality
A
maintenance
MCP server that enables Claude Code to send code and plans for review by OpenAI Codex, returning structured feedback inline.
Updated 2 months ago (2026-07-09 23:23 UTC)
65
23
MIT
mcp-agent-review
Code Analysis AI & Machine Learning
lzx1413
A
license
Not graded
quality
C
maintenance
An MCP server that provides agentic code review powered by OpenAI-compatible models, designed for use with Claude Code.
Updated 4 months ago (2026-04-29 01:52 UTC)
1
MIT
codex-cli-architect-mcp
Code Analysis Developer Tools AI & Machine Learning
itto-ki
A
license
A
quality
D
maintenance
An MCP server that provides technical consultation, code review, and code explanation by integrating with OpenAI's Codex CLI, enabling AI-powered coding assistance in a sandboxed, read-only environment.
Updated a year ago (2025-08-10 07:19 UTC)
3
64
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/henrydontbbai/opencode-advisor-mcp'

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