smart-explore
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., "@smart-exploreFind callers ofhandleRequestin src/routes.ts"
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.
smart-explore MCP server
Token-optimized structural code search for OpenCode, powered by tree-sitter AST parsing.
Originally built as a Claude Code plugin (claude-mem); ported to OpenCode by
re-using the existing MCP server and adapting the skill format.
What it provides
Six MCP tools, exposed under the smart-explore_ prefix:
Tool | Purpose | Token cost |
| Symbol search across a directory (folded views) | ~2-6k |
| Structural skeleton of a file or directory | ~1-2k |
| Full source of one named symbol from a file | ~400-2.1k |
| Incoming call edges for one symbol | ~1-3k |
| Outgoing call edges from one symbol | ~1-3k |
| Import/test graph around one file | ~1-2k |
These replace the typical Glob → Grep → Read discovery cycle when you want to
explore code structure rather than read full files.
smart-explore_smart_search can exclude subdirectories before scanning via
relative exclude_paths (or the alias exclude_dirs).
BM25 keeps normal English stemming for source content and uses n-gram matching
for symbol names and signatures, so identifier fragments such as cache match
cacheResult without changing the source shown in results.
Use CLI flag --show-scores or MCP argument include_scores: true to include
mode-specific BM25, RRF, or vector-distance values in search output.
smart-explore_smart_outline also accepts a directory and returns the same
file-level outline format concatenated for discovered files, with a built-in
safety cap for very large directories.
Caller/callee analysis caches parsed relations until a source file is added, removed, or its size/mtime changes. Declarations and scopes come from Tree-sitter; call sites still use a lightweight regex. Named imports, namespace-qualified calls, and same-file symbols are resolved before unique project-wide names. Dynamic dispatch, computed properties, and ambiguous duplicate names remain unresolved rather than being attributed arbitrarily.
Related MCP server: git-project-xray-mcp
Layout
.opencode/mcp/smart-explore/
├── scripts/
│ ├── bootstrap-mcp.cjs ← dependency installer
│ └── mcp-server.cjs ← bundled server (entry point)
├── src/ ← TypeScript source (parser, search, server)
├── node_modules/ ← tree-sitter native bindings (gitignored)
├── package.json
└── tsconfig.jsonThe companion skills live in .agents/skills/:
smart-explore/SKILL.md— when & how to call the toolsmake-plan/SKILL.md— phased implementation plannerdo/SKILL.md— orchestration protocol for executing plans with subagents
Codex plugin
This repository is also a Codex plugin. It bundles the MCP server, the
smart-explore CLI, and a CLI-first skill that routes exploration requests to
the cheapest operation. The CLI is preferred, while the MCP server starts in
the background so it can bootstrap the CLI runtime and install its PATH shim.
The plugin files are:
.codex-plugin/plugin.json ← plugin manifest
.mcp.json ← bundled stdio MCP server
skills/smart-explore/ ← Codex skill and CLI instructions
scripts/codex-launch.cjs ← dependency bootstrap and launcherFor local testing, the repository includes a marketplace entry:
codex plugin marketplace add .
codex plugin add smart-explore@smart-explore-localStart a new Codex session after installation. On MCP startup, the launcher
installs the pinned dependencies and creates a smart-explore PATH shim in a
writable user bin directory. The skill then invokes smart-explore directly.
How it's wired in
.opencode/opencode.json:
"mcp": {
"smart-explore": {
"type": "local",
"command": ["pnpm", "run", "smart-explore-mcp"],
"enabled": true
}
}OpenCode spawns the server as a stdio subprocess. The MCP protocol handshake
registers the tools; the LLM sees them as smart-explore_smart_search,
etc. (server name + _ + tool name).
Setup
Run the root .opencode installer before starting OpenCode:
./.opencode/install.shOn Windows:
.\.opencode\install.batIf you only want to install this MCP package directly:
cd .opencode/mcp/smart-explore
pnpm install --frozen-lockfile
pnpm run buildAfter install/build, the MCP server can be launched through the package binary:
pnpm run smart-explore-mcpFor npm-based environments, use the same package script:
npm run smart-explore-mcpIf the package is installed globally or published to a registry, its bin entry
also exposes the executable as smart-explore-mcp.
node_modules/ is still required at runtime (~666 MB — tree-sitter grammars
are native bindings that can't be bundled by esbuild), so the install step must
be run on each fresh clone.
This package uses pnpm because the current tree-sitter grammar set has
incompatible optional peer ranges under newer npm versions.
If you want to install it manually without the root script:
cd .opencode/mcp/smart-explore
pnpm install --frozen-lockfile
pnpm run buildIf you change anything under src/, rebuild the bundle:
pnpm run buildThis regenerates scripts/mcp-server.cjs. Restart OpenCode after rebuilding.
Verifying it works
Run the
.opencodeinstall script.Restart OpenCode.
Check the log for:
service=mcp key=smart-explore mcp stderr: [mcp-server] smart-explore vX.Y.Z ready service=mcp key=smart-explore toolCount=3 create() successfully created clientAsk OpenCode to use the tools:
Run smart-explore_smart_outline on agent/main.pyThe TUI should show a folded structural view in the tool-result panel.
Troubleshooting
MCP server bundle missing in log
The committed bundle is missing. Rebuild it with npm run build inside
.opencode/mcp/smart-explore/.
node_modules missing in log
Run ./.opencode/install.sh or node scripts/bootstrap-mcp.cjs inside
.opencode/mcp/smart-explore/.
Tools don't appear in OpenCode
Check mcp.smart-explore.enabled: true in opencode.json and restart.
Tools fail with "Cannot find module 'tree-sitter-X'"
The install may be incomplete or built for the wrong architecture. Re-run npm ci
inside .opencode/mcp/smart-explore/.
Supported languages
JavaScript / TypeScript / TSX / JSX / Python / Go / Rust / Ruby / Java / C / C++.
Files with unrecognized extensions fall back to plain-text grep-style search
(smart-explore_smart_search still works; smart-explore_smart_outline does not).
Custom grammars can be added via .claude-mem.json at project root — see the
smart-explore skill for the syntax.
Differences from the original Claude Code plugin
.mcp.json(Claude Code config) replaced withmcp.smart-exploreentry inopencode.json.${CLAUDE_PLUGIN_ROOT}env var → relative project path.Skills moved from
claude-mem/skills/→.agents/skills/(OpenCode discovery location). Tool references insmart-exploreskill updated fromsmart_searchtosmart-explore_smart_search(OpenCode prefixes MCP tools with the server name).Removed Claude-Code-specific files:
.claude-plugin/,.mcp.json, and theui/viewer (used by claude-mem's memory snapshot browser, not the search MCP).Server source code (
src/,scripts/build.js, parser logic) is unchanged.
Available Tools
1 toolsmart_explore_cli_statusA
Check whether the bundled smart-explore CLI is installed and runnable. Use the CLI for all code exploration; this is only a health check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It goes beyond the name by specifying that the check verifies 'installed and runnable' and by explicitly labeling the tool as 'only a health check', signaling a non-destructive read-only operation. It does not detail output format or failure behavior, but for a zero-parameter status probe this is adequate.
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 two sentences with no filler. It front-loads the exact action and then adds a single useful usage/context sentence, earning every word.
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?
For a simple zero-input, zero-output-schema health check, the description is nearly complete: it states the exact condition checked and the scope of the tool. The only missing piece is the precise response representation, but 'Check whether' strongly implies a boolean/status result, which is sufficient for an agent to proceed.
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?
The tool accepts 0 parameters, so the baseline is 4. The description does not need to explain any parameters, and it correctly avoids introducing nonexistent ones.
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 starts with 'Check whether the bundled smart-explore CLI is installed and runnable', which is a specific verb and resource. It also clarifies scope with 'this is only a health check', distinguishing it from actual code exploration, so an agent can easily understand its role.
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?
The description explicitly gives usage direction: 'Use the CLI for all code exploration; this is only a health check.' This tells the agent when to invoke this tool versus the alternative of using the CLI for exploration, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
There is only one tool, so there is no possibility of confusion between tools. Its name and description clearly indicate it is a health check for the CLI.
The single tool name uses a consistent snake_case style and is descriptive. With only one tool, there are no conflicting naming conventions to penalize.
A single status-check tool is an extreme mismatch for a server named smart-explore, which implies code exploration as its purpose. This is a trivial health-check-only surface.
The server exposes no actual exploration tools; it only checks CLI availability. Agents cannot perform any part of the server's stated core function.
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
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to understand and navigate codebases through structural analysis. Provides code mapping, symbol search, and impact analysis using ast-grep for accurate parsing of Python, JavaScript, TypeScript, and Go projects.452MIT
- AlicenseAqualityCmaintenanceProvides AI assistants with progressive code intelligence to explore repository structure, find symbols, and assess the impact of changes using ast-grep.3MIT
- AlicenseAqualityDmaintenanceGives coding agents structured code understanding via tree-sitter with 23 tools and 10 languages, enabling precise queries instead of reading entire files.2328MIT
- AlicenseNot gradedqualityDmaintenanceEnables code analysis of JavaScript, TypeScript, TSX, Python, and Rust files using Tree-sitter, providing symbol listing, definition/reference lookup, AST queries, LSP-style features, and SQLite indexing for efficient cross-file searches.15MIT
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/VasyaYovbak/smart-explore-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server