Provides symbol extraction for C/C++ source code via tree-sitter AST parsing.
Extracts symbols and resolves dependencies for JavaScript projects, including support for jsconfig.json path mapping.
Supports symbol extraction and convention-based dependency resolution for Kotlin source code.
Extracts symbols and resolves dependencies for PHP projects following PSR-4 conventions and directory mapping.
Offers comprehensive code intelligence for Python, including symbol extraction, import parsing, and absolute/relative dependency resolution.
Supports symbol extraction for Ruby source files using tree-sitter AST parsing.
Enables symbol extraction and dependency tracing for Rust projects using standard crate and module conventions.
Provides symbol extraction for Scala source code as part of its polyglot intelligence capabilities.
Extracts symbols from script blocks and resolves dependencies within Svelte components.
Utilizes TOML configuration files like pyproject.toml for automatic project root detection and analysis environment setup.
Enables deep code intelligence for TypeScript, including symbol extraction and dependency resolution with tsconfig.json path alias support.
symbols
A fast, polyglot source code intelligence CLI. Extract symbols, parse imports, trace dependencies, and analyze impact — all from the command line.
No language server required. No build step for your projects. Just point it at your code.
Table of contents
Why this exists
symbols is for the moments when you need to understand a codebase quickly without opening 30 files first.
Common pain points it targets:
You are about to change a file and need to know blast radius immediately.
You are onboarding to an unfamiliar repo and need a map, not a scavenger hunt.
You are reviewing a PR and want concrete dependency and ownership signals.
You are using AI coding tools and need reliable, structured project context on demand.
Instead of manually reconstructing context from editor tabs, grep output, and memory, symbols gives you the structural view in one step.
How it saves context
symbols saves context in two practical ways:
It externalizes code structure into fast, repeatable queries (
list,deps,dependents,impact,graph,search) so you do not have to rebuild mental maps every session.It exposes the same model through MCP (
syms mcp) so agents and tools can fetch fresh project facts directly, rather than relying on stale chat history or guessed file relationships.
Net effect:
less re-reading
fewer "what will this break?" surprises
faster onboarding and safer refactors
more useful AI assistance because context is retrieved, not improvised
lower cost from fewer exploratory engineering cycles and reduced AI token spend on repo re-discovery
What it does
syms list server.py # functions, classes, constants, variables
syms imports server.py # parsed import statements
syms deps server.py # files this file imports from
syms dependents server.py # files that import this file
syms impact server.py # full impact analysis (direct + transitive)
syms graph . # project-wide dependency summary
syms search User # find symbols by name across a project
syms mcp # run as MCP server for AI toolsInstall
git clone https://github.com/Jordan-Horner/symbols.git
cd symbols
go build -o syms .
sudo mv syms /usr/local/bin/Requirements: Go 1.26+
Language support
Symbol extraction uses tree-sitter for full AST parsing (function signatures with parameters, classes, types, constants). Import parsing and dependency resolution use regex.
Language | Symbols | Import parsing | Dependency resolution |
Python | tree-sitter (functions, classes, constants, variables) | regex | Relative + absolute imports |
TypeScript | tree-sitter | regex |
|
JavaScript | tree-sitter | regex | Same as TypeScript (also reads |
Svelte | tree-sitter (script block) | regex | Same as TypeScript |
Go | tree-sitter | regex |
|
Java | tree-sitter | regex | Dot-to-slash, |
Kotlin | tree-sitter | regex | Same as Java + |
Rust | tree-sitter | regex |
|
C# | tree-sitter | regex | Namespace-to-path, class name fallback |
PHP | tree-sitter | regex | PSR-4 conventions, |
C/C++ | tree-sitter | — | — |
Ruby | tree-sitter | — | — |
Scala | tree-sitter | — | — |
Bash | tree-sitter | — | — |
Usage
Symbol extraction
# Single file
syms list app.py
# Multiple files
syms list src/main.go src/handlers.go
# Recursive directory scan
syms list -r src/
# JSON output (for piping to other tools)
syms list --json app.py
# Pretty JSON output (human-readable)
syms list --json --pretty app.py
# Optional: include precise symbol ranges
syms list --json --ranges app.py
# Count symbols per file
syms list --count src/
# Filter by symbol kind (repeatable or comma-separated)
syms list --filter class src/
syms list --filter class,function src/
syms list --filter class --filter function src/Output:
### `app.py` — 245 lines
constant VERSION # line 1
constant API_URL # line 3
variable app # line 5
class Application # line 12
def __init__(self, config) # line 15
async def start(self) # line 34
def shutdown(self) # line 78Import parsing
syms imports server.pyOutput:
### `server.py`
from flask import Flask, jsonify # line 1
from .models import User, Post # line 2
import os # line 3Dependency queries
# Direct dependencies
syms deps src/handlers.go
# Transitive (everything it depends on, recursively)
syms deps -t src/handlers.go
# Who imports this file?
syms dependents src/models.py
# Transitive dependents
syms dependents -t src/models.pyImpact analysis
syms impact src/core/utils.pyOutput:
### `src/core/utils.py` — impact analysis
Direct dependents: 8
Transitive dependents: 23
Direct:
src/api/handlers.py
src/core/auth.py
src/core/db.py
...
Indirect (transitive):
src/api/routes.py
src/main.py
tests/test_auth.py
...Project graph summary
syms graph .Output:
Project dependency graph
Files: 187
Import edges: 562
Unresolved imports: 43
Most depended-on files:
src/utils.py (36 dependents)
src/config.py (33 dependents)
src/models.py (23 dependents)
Heaviest importers:
src/app.py (28 imports)
src/main.py (24 imports)
Circular dependencies (1):
src/config.py <-> src/runner.pyJSON output
All commands support --json for machine-readable output:
syms impact --json src/utils.py | jq '.direct_dependents'
syms graph --json . | jq '.hot_spots[:5]'
# Optional: pretty-print JSON for humans
syms graph --json --pretty .
# Full edge map (file → its dependencies)
syms graph --json . | jq '.edges'
# What does a specific file depend on?
syms graph --json . | jq '.edges["src/app.py"]'Shorthand
The list subcommand is the default — you can omit it:
# These are equivalent:
syms list app.py
syms app.py
# Flags work too:
syms -r src/ --jsonSymbol search
# Find symbols by name (fuzzy: exact > prefix > contains)
syms search User
# JSON output
syms search --json handle
# Search in a specific project
syms search --root /path/to/project Config
# Search only specific symbol kinds
syms search --filter class User
# Optional: include precise symbol ranges in search results
syms search --json --ranges UserOutput:
Found 3 symbols matching "User":
class User models.py:1
class UserProfile models.py:5
function get_user(id) api/handlers.py:12MCP server
Run syms as an MCP server for AI tool integration (e.g. Claude Code):
syms mcpExposes all functionality as MCP tools over stdio (JSON-RPC 2.0):
Tool | Description |
| Extract symbols from files |
| Parse import statements |
| File dependencies |
| Reverse dependencies |
| Impact analysis |
| Search symbols by name |
| Project dependency graph |
syms_list and syms_search accept optional kinds: string[] arguments to filter symbol kinds.
syms_list and syms_search also accept optional include_ranges: boolean for start/end line+column metadata.
Tool results are returned in structuredContent (not JSON text blobs in content[].text).
Claude Code configuration (~/.claude.json):
{
"mcpServers": {
"syms": {
"type": "stdio",
"command": "syms",
"args": ["mcp"]
}
}
}How it works
Symbol extraction uses tree-sitter for full AST parsing. Each language has a compiled grammar (linked statically into the binary) that produces a syntax tree. The tool walks the tree to extract top-level declarations with names, kinds, line numbers, and function parameters. For Python, module-level assignments are also extracted as constants (UPPER_CASE) or variables.
Import parsing uses regex patterns tuned to each language's import syntax. This is fast and reliable for standard import forms without needing AST parsing.
Dependency resolution maps import specifiers to actual files on disk using language-specific conventions:
Python: module dot-path to file path, relative import resolution
Go:
go.modmodule name stripping, package-to-directory mappingJava/Kotlin: dot-to-slash convention, standard source root prefixes (
src/main/java/)Rust:
crate/self/superpath resolution,mod.rsconventionC#: namespace-to-path with progressive prefix stripping
PHP: PSR-4 backslash-to-slash mapping,
require/includepath resolution
Directory scanning uses early pruning of .git, node_modules, dist, build, vendor, target, and other common non-source directories.
Project root detection
For deps, dependents, impact, and graph, the tool auto-detects the project root by walking up the directory tree looking for .git, package.json, or pyproject.toml. Override with --root:
syms deps src/app.py --root /path/to/projectLimitations
Convention-based resolution — dependency resolution uses file path conventions, not compiler/build system integration. TypeScript/JavaScript
pathsfromtsconfig.json/jsconfig.jsonare supported (includingextends), but webpack/vite aliases defined outside tsconfig are not.File-level granularity — dependencies are traced at the file level (import graph), not at the function or symbol level. There is no call graph.
C/C++ includes —
#includeparsing and header resolution are not yet implemented. Symbol extraction works, but dependency tracing does not.Ruby/Scala/Bash — symbol extraction works via tree-sitter, but import parsing and dependency resolution are not implemented.
Dynamic imports — Python's
importlib.import_module(), JavaScript's computedrequire(), and similar dynamic patterns are not detected.Monorepo boundaries — the tool resolves imports within a single project root. Cross-package imports in monorepos may not resolve correctly.