jcodemunch
jcodemunch via mcporter
Query jcodemunch-mcp indexed codebases using bunx mcporter call and bunx mcporter list. This avoids loading the full MCP server into the agent's context while still accessing all of jcodemunch's code intelligence.
Prerequisites
jcodemunch-mcp must be running (either as a configured MCP server or reachable via stdio). Repos must be indexed before querying — use index_folder or index_repo to index first.
How to call
All calls go through mcporter's stdio transport:
# List available tools
bunx mcporter list --stdio "uvx jcodemunch-mcp"
# Call a tool (function-call syntax)
bunx mcporter call --stdio "uvx jcodemunch-mcp" 'list_repos()'
# Call with arguments
bunx mcporter call --stdio "uvx jcodemunch-mcp" 'search_symbols(repo: "jsed", query: "parse")'
# JSON output for structured processing
bunx mcporter call --stdio "uvx jcodemunch-mcp" 'list_repos()' --output json
The --stdio "uvx jcodemunch-mcp" flag tells mcporter to launch jcodemunch as a stdio subprocess.
Tool reference
Orientation (start here on an unfamiliar repo)
| Tool | Purpose | Example |
|---|---|---|
list_repos() |
List all indexed repos | 'list_repos()' |
suggest_queries(repo) |
Entry-point files, top keywords, example queries | 'suggest_queries(repo: "jsed")' |
get_repo_outline(repo) |
High-level: dirs, file counts, languages, symbol counts | 'get_repo_outline(repo: "jsed")' |
get_file_tree(repo) |
File tree, optionally filtered by path prefix | 'get_file_tree(repo: "jsed", path_prefix: "src/utils")' |
Symbol search & inspection
| Tool | Purpose | Example |
|---|---|---|
search_symbols(repo, query) |
Search across repo by name, signature, summary | 'search_symbols(repo: "jsed", query: "parse", max_results: 5)' |
get_file_outline(repo, file_path) |
All symbols in a file with signatures | 'get_file_outline(repo: "jsed", file_path: "src/main.ts")' |
get_symbol_source(repo, symbol_id) |
Full source of a symbol | 'get_symbol_source(repo: "jsed", symbol_id: "src/main.ts::parseToken")' |
get_context_bundle(repo, symbol_id) |
Source + imports, deduped. Use output_format: "markdown" for paste-ready |
'get_context_bundle(repo: "jsed", symbol_id: "src/main.ts::parseToken", output_format: "markdown")' |
get_related_symbols(repo, symbol_id) |
Heuristic clustering: co-location, shared importers, name overlap | 'get_related_symbols(repo: "jsed", symbol_id: "src/main.ts::parseToken")' |
Text search
| Tool | Purpose | Example |
|---|---|---|
search_text(repo, query) |
Full-text search across file contents, supports regex | 'search_text(repo: "jsed", query: "TODO", context_lines: 2)' |
Dependency & impact analysis
| Tool | Purpose | Example |
|---|---|---|
get_dependency_graph(repo, file) |
File-level import graph, up to 3 hops | 'get_dependency_graph(repo: "jsed", file: "src/main.ts", direction: "both")' |
find_importers(repo, file_path) |
What files import a given file | 'find_importers(repo: "jsed", file_path: "src/utils/helpers.ts")' |
find_references(repo, identifier) |
Where is an identifier used | 'find_references(repo: "jsed", identifier: "parseToken")' |
check_references(repo, identifier) |
Is an identifier referenced anywhere (dead-code detection) | 'check_references(repo: "jsed", identifier: "oldFunction")' |
get_blast_radius(repo, symbol) |
All files affected by changing a symbol | 'get_blast_radius(repo: "jsed", symbol: "parseToken")' |
get_class_hierarchy(repo, class_name) |
Inheritance tree (ancestors + descendants) | 'get_class_hierarchy(repo: "jsed", class_name: "BaseParser")' |
Indexing
| Tool | Purpose | Example |
|---|---|---|
index_folder(path) |
Index a local folder | 'index_folder(path: "/Users/danb/projects/myrepo")' |
index_repo(url) |
Index a GitHub repo | 'index_repo(url: "owner/repo")' |
index_file(path) |
Re-index a single file (faster than full re-index) | 'index_file(path: "/Users/danb/projects/myrepo/src/changed.ts")' |
Diffing
| Tool | Purpose | Example |
|---|---|---|
get_symbol_diff(repo_a, repo_b) |
Diff symbol sets between two indexed snapshots | 'get_symbol_diff(repo_a: "jsed-main", repo_b: "jsed-feature")' |
search_symbols detail levels
The detail_level parameter controls result verbosity:
compact— id/name/kind/file/line only (~15 tokens each). Best for broad discovery.standard(default) — includes signatures and summaries.full— inlines source code and docstrings. Equivalent to search + get_symbol_source in one call.
Use token_budget instead of max_results when you want to pack as many results as possible into a fixed context window.
Workflow patterns
"What is this repo?"
list_repos()— find the repo identifiersuggest_queries(repo)— get entry points and example queriesget_repo_outline(repo)— directory structure and language breakdown
"Where is X used?"
find_references(repo, identifier: "X")— import-level referencessearch_text(repo, query: "X")— full-text occurrences (catches string refs, comments)
"What would break if I change X?"
get_blast_radius(repo, symbol: "X")— confirmed + potential affected filesget_dependency_graph(repo, file: "...", direction: "importers")— who depends on this file
"Show me everything about function X"
get_context_bundle(repo, symbol_id: "...", output_format: "markdown")— source + imports, paste-ready
Repo identifiers
Repos are identified by their display name (e.g., "jsed", "@oneput") or their full identifier (e.g., "local/jsed-2fd72aec"). Use list_repos() to discover available identifiers.
Batch operations
Several tools support batch mode for efficiency:
get_file_outline— passfile_paths: [...]instead offile_pathget_symbol_source— passsymbol_ids: [...]instead ofsymbol_idfind_importers— passfile_paths: [...]instead offile_pathfind_references— passidentifiers: [...]instead ofidentifiercheck_references— passidentifiers: [...]instead ofidentifier
More from danielbush/skills
nullables
Guide for implementing James Shore's Nullables pattern and A-Frame architecture for testing without mocks. Use when implementing or refactoring code to follow patterns of: (1) Separating logic, infrastructure, and application layers, (2) Creating testable infrastructure with create/createNull factory methods, (3) Writing narrow, sociable, state-based tests without mocks, (4) Implementing value objects, (5) Building infrastructure wrappers that use embedded stubs, or (6) Designing dependency injection through static factory methods.
15nullables-test
Write illustrative tests for code that follows the Nullables pattern. Verifies the class under test is ready (all HARDWIRED_INFRA replaced by INJECTED_INFRA, every dependency has .createNull), then writes narrow, sociable, state-based tests using .createNull(). Tests should illustrate the system's concepts and architecture, not just achieve coverage. Use after applying the nullables-refactor skill, or when writing tests for code that already uses DUAL_FACTORY.
13nullables-refactor
Analyze a file and produce a refactoring plan to apply the Nullables pattern. Classifies code by side-effect boundary (PURE, IN_MEMORY, OUTSIDE_WORLD), identifies HARDWIRED_INFRA, recommends INFRASTRUCTURE_WRAPPER or NULLABLE_CLASS conversion, checks DUAL_FACTORY and CREATE_BOUNDARY_RULE compliance, and decides on DELAYED_INSTANTIATION. Use when asked to refactor a file or module to follow the nullables pattern.
13effect-ts
>
7nullable-architecture
Use when refactoring code or writing tests in the Nullables style: choose between `new`, `.create()`, and `.createNull()`, introduce infrastructure wrappers at the environment boundary, add behavior simulation and output tracking, and write narrow, sociable, example-driven, state-based tests without mocks or spies.
5logic-sandwich
Use when refactoring a top-level orchestrator or mediator method so it gathers state at the edges, computes a pure intent in the middle, and applies effects at the bottom. Especially useful in deep-modules codebases where top-level modules should stay readable and orchestration-focused.
1