opencode-mcp
Allows asking natural-language questions about a GitHub repository and receiving answers grounded in the code.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@opencode-mcpWhere is the main entry point in facebook/react?"
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-mcp
MCP server (stdio) exposing an ask_codebase tool: ask a natural-language question about a GitHub repository, get an answer grounded in the real code. READ-ONLY by design.
Built in TypeScript on the official MCP TypeScript SDK, and on opencode running headless as the analysis engine.
How it works
The server fetches the repo itself — clone if absent, fetch + hard resync otherwise. Fully deterministic: a nonexistent repo fails in seconds with the git error relayed verbatim, zero LLM tokens spent.
opencode runs headless with
cwd= the repo directory. Noopencode serve, no--attach. The repo's ownAGENTS.md(if any) is loaded as project context. Sessions are opencode-native and scoped per project directory, socontinue_session=truedeterministically means "the latest session of this repo" — cross-repo cross-talk is impossible by construction.
Fetch policy
A clone/fetch runs only when:
the repo is not in the manifest, or
its checkout is missing on disk (periodic cleanup), or
an explicitly requested branch differs from the checked-out one, or
the last fetch is older than
OPENCODE_REPO_TTL_DAYS(default 3).
Otherwise the existing checkout is used as-is, so the code stays stable across follow-up calls.
Manifest
Known checkouts are tracked in .opencode_mcp_manifest.json (atomic writes, one entry per owner/repo):
{
"owner/repo": {
"dir": "/abs/path",
"branch": "main",
"fetched_at": "2026-07-15T03:21:00Z"
}
}Read-only enforcement
Two layers:
A read-only preamble injected into every prompt by this server.
Your opencode agent config — define an "explore"-style agent with
edit: denyand setOPENCODE_AGENTto force it on every run.
Do not put read-only rules in your global AGENTS.md: it would poison your normal interactive opencode sessions.
Long calls
The hard timeout defaults to 10 minutes and an MCP progress notification is emitted every 15 s (clone/fetch included). Per the MCP spec, clients that reset their request timeout on progress keep the call alive; when the client sends no progressToken, the heartbeat is a no-op. Align the client's own per-call timeout (timeout: in the mcp_servers entry) above the hard one.
Related MCP server: GitHub Repo Explainer MCP
Requirements
Node.js ≥ 20
giton the PATHopencode CLI (absolute path recommended via
OPENCODE_BIN)
Install
From npm:
npm install -g @mvagnon/opencode-mcp # installs the `opencode-mcp` commandOr run it without installing:
npx -y @mvagnon/opencode-mcpFrom source:
npm install
npm run build # server binary: dist/index.js (stdio transport)Configuration
Declare environment variables in the env: block of the client's mcp_servers entry. Hermes does not pass your full shell env to stdio servers — only PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR.
Variable | Default | Purpose |
|
| opencode binary (absolute path recommended) |
| (none) | opencode agent forced on every run (e.g. |
|
| Where checkouts live |
|
| Directory of |
|
| Re-fetch a repo after this many days |
|
| Hard timeout for the opencode run, in seconds |
Example client entry (Hermes):
mcp_servers:
opencode:
command: npx
args: ["-y", "@mvagnon/opencode-mcp"]
timeout: 660 # keep above ASK_CODEBASE_TIMEOUT
env:
OPENCODE_BIN: /usr/local/bin/opencode
OPENCODE_AGENT: exploreFor a from-source checkout, use command: node with args: ["/abs/path/to/opencode-mcp/dist/index.js"] instead.
The ask_codebase tool
Argument | Type | Description |
|
| The natural-language question (e.g. "where is API request auth validated?") |
|
| Exact GitHub slug |
|
| Optional branch to pin; omit for the default branch |
|
| Resume the latest discussion of this repo (default |
Use it for architecture questions, where a feature lives, request flow, conventions, design rationale, etc.
Development
npm run lint # eslint
npm run typecheck # tsc --noEmit
npm run build # emit dist/
npm test # node:test unit tests (pure logic)
npm run dev # tsc --watchSource layout: see AGENTS.md.
Releasing
Releases are fully automated with release-please and npm trusted publishing (OIDC — no npm token stored in the repo):
Land changes on
mainusing Conventional Commits (feat:,fix:,feat!:…) — they drive the version bump and the changelog.release-please maintains a release PR that accumulates changes, bumps
package.json, and updatesCHANGELOG.md.Merging the release PR creates the GitHub release and tag; the
publishjob then publishes to npm via OIDC.
One-time setup (already done once the package exists):
npm cannot create a package via OIDC, so the first version must be published manually (
npm login && npm publish).Then on npmjs.com → package → Settings → Trusted Publisher: GitHub Actions, repository
mvagnon/opencode-mcp, workflowrelease.yml.
Available Tools
1 toolask_codebaseAsk codebaseARead-only
Ask a natural-language question about a GitHub repository and get an answer grounded in the real code. READ-ONLY: never writes, edits, builds, or executes anything. The harness fetches the repo itself (clone or refresh, max every few days) — a nonexistent repo fails fast with the exact git error. Stateful PER REPOSITORY: continue_session=true resumes the latest discussion of that owner/repo (follow-up questions keep their context); false (default) starts a fresh one. Optional branch pins a specific branch. Use it for architecture questions, where a feature lives, request flow, conventions, design rationale, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | REQUIRED exact GitHub slug "owner/repo" (e.g. "vercel/next.js"). Deterministic — no nicknames, no fuzzy descriptions, no URLs. The harness fetches it itself and fails fast with the exact git error if it does not exist or is unreachable. | |
| branch | No | Optional branch to pin (e.g. "canary"). Omit for the repo's default branch. An explicit branch different from the current checkout triggers a re-fetch. | |
| question | Yes | The natural-language question (e.g. "where is API request auth validated?"). | |
| continue_session | No | If true, resume the latest discussion of this repo (same context; the checkout is only refreshed by the TTL policy, so code usually stays stable). If false (default), start a fresh discussion. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnlyHint and openWorldHint annotations: it explicitly states 'READ-ONLY: never writes, edits, builds, or executes anything', explains the harness's repo fetching and caching behavior, fails-fast with git errors, and details session statefulness with continue_session. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the core purpose. Every sentence delivers unique value: purpose, safety, fetch behavior, statefulness, and usage examples. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior, safety, statefulness, fetch mechanics, and use cases. The input schema thoroughly documents all four parameters, and the description complements it without needing an output schema. It is complete for an AI agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enriches parameter understanding beyond the schema by explaining deterministic repo slugs, session semantics associated with continue_session, and branch behavior (e.g., re-fetch on explicit branch). This adds meaningful context rather than merely repeating schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states that the tool answers natural-language questions about a GitHub repository with answers grounded in real code. The verb 'Ask' and resource 'codebase' are specific and there are no sibling tools requiring differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists use cases: 'architecture questions, where a feature lives, request flow, conventions, design rationale, etc.' This gives clear context on when to use the tool, even though no alternatives exist to contrast.
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.
1 tool update
v1.0.0- First observed
ask_codebase
TDQS
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined as read-only codebase Q&A.
The single tool name 'ask_codebase' follows a clear verb_noun pattern, which is consistent and descriptive.
One tool feels thin for a general-purpose MCP server, but it is appropriately focused for a specialized read-only Q&A assistant. The count is borderline but acceptable.
The tool covers the entire stated domain of asking questions about a codebase, with session state, branch selection, and error handling. No obvious gaps for its intended purpose.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Ask any GitHub repository a question. Get source-backed answers.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables AI models to access GitHub repository contents as context, with features to fetch entire repositories, specific file contents, and repository structures for use in AI interactions.31182MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to access live GitHub repository data without cloning, supporting repo summarization, file explanation, recent changes, and dependency analysis.MIT
- FlicenseNot gradedqualityDmaintenanceProvides read-only access to company GitHub repositories, enabling code search, file retrieval, documentation search, and repo browsing via natural language.-
- AlicenseNot gradedqualityDmaintenanceEnables interacting with GitHub repositories for pull requests, code, and reviews through natural language.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mvagnon/opencode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server