Skip to main content
Glama
VasyaYovbak

smart-explore

by VasyaYovbak

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

smart-explore_smart_search

Symbol search across a directory (folded views)

~2-6k

smart-explore_smart_outline

Structural skeleton of a file or directory

~1-2k

smart-explore_smart_unfold

Full source of one named symbol from a file

~400-2.1k

smart-explore_smart_callers

Incoming call edges for one symbol

~1-3k

smart-explore_smart_callees

Outgoing call edges from one symbol

~1-3k

smart-explore_smart_related_files

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.json

The companion skills live in .agents/skills/:

  • smart-explore/SKILL.md — when & how to call the tools

  • make-plan/SKILL.md — phased implementation planner

  • do/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 launcher

For local testing, the repository includes a marketplace entry:

codex plugin marketplace add .
codex plugin add smart-explore@smart-explore-local

Start 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.sh

On Windows:

.\.opencode\install.bat

If you only want to install this MCP package directly:

cd .opencode/mcp/smart-explore
pnpm install --frozen-lockfile
pnpm run build

After install/build, the MCP server can be launched through the package binary:

pnpm run smart-explore-mcp

For npm-based environments, use the same package script:

npm run smart-explore-mcp

If 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 build

If you change anything under src/, rebuild the bundle:

pnpm run build

This regenerates scripts/mcp-server.cjs. Restart OpenCode after rebuilding.

Verifying it works

  1. Run the .opencode install script.

  2. Restart OpenCode.

  3. 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 client
  4. Ask OpenCode to use the tools:

    Run smart-explore_smart_outline on agent/main.py
  5. The 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 with mcp.smart-explore entry in opencode.json. ${CLAUDE_PLUGIN_ROOT} env var → relative project path.

  • Skills moved from claude-mem/skills/.agents/skills/ (OpenCode discovery location). Tool references in smart-explore skill updated from smart_search to smart-explore_smart_search (OpenCode prefixes MCP tools with the server name).

  • Removed Claude-Code-specific files: .claude-plugin/, .mcp.json, and the ui/ 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 tool
smart_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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

A4.1/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count1/5

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.

Completeness1/5

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

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables 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.
    4
    52
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Gives coding agents structured code understanding via tree-sitter with 23 tools and 10 languages, enabling precise queries instead of reading entire files.
    23
    28
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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.
    15
    MIT

Latest Blog Posts

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