The symbols server provides source code intelligence for analyzing structure and dependencies across a codebase — no language server or build step required.
Extract symbols (syms_list): Retrieve top-level declarations (functions, classes, types, constants) from source files or directories, with optional recursive scanning and filtering by symbol kind
Parse imports (syms_imports): Extract all import statements from source files or directories
Analyze dependencies (syms_deps): Find all files a given file depends on (imports from), with optional transitive traversal
Find dependents (syms_dependents): Discover which files import a given file, with optional transitive traversal
Impact analysis (syms_impact): Get a full breakdown of direct and transitive dependents — useful for understanding the blast radius of a change
Search symbols (syms_search): Find symbols by name across a project with ranked matching (exact > prefix > contains) and optional kind filtering
Project graph summary (syms_graph): Generate a project-wide dependency graph showing file counts, import edges, most depended-on files, heaviest importers, and circular dependencies
Supports Python, TypeScript, JavaScript, Go, Java, Kotlin, Rust, C#, PHP, and more.
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.
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.
Related MCP server: loctree-mcp
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.
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
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 toolsgit clone https://github.com/Jordan-Horner/symbols.git
cd symbols
go build -o syms .
sudo mv syms /usr/local/bin/Requirements: Go 1.26+
# Install directly to /usr/local/bin
curl -L https://github.com/Jordan-Horner/symbols/releases/latest/download/syms-$(uname -s)-$(uname -m) -o /usr/local/bin/syms
chmod +x /usr/local/bin/symsbrew tap Jordan-Horner/tap
brew install symssyms --versionSymbol 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 | — | — |
# 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 78syms imports server.pyOutput:
### `server.py`
from flask import Flask, jsonify # line 1
from .models import User, Post # line 2
import os # line 3# 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.pysyms 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
...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.pyAll 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"]'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/ --json# 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:12Run 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).
After installing syms, configure it as an MCP server:
Project-level (recommended for teams):
Create .mcp.json in your project root:
{
"mcpServers": {
"symbols": {
"command": "syms",
"args": ["mcp"]
}
}
}Commit this file so your team gets the symbols server automatically.
Global (all projects):
Create or edit ~/.mcp.json:
{
"mcpServers": {
"symbols": {
"command": "syms",
"args": ["mcp"]
}
}
}After configuration:
Restart Claude Code
When prompted, approve the symbols MCP server
Claude Code will now have access to code intelligence tools in all your projects
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.mod module name stripping, package-to-directory mapping
Java/Kotlin: dot-to-slash convention, standard source root prefixes (src/main/java/)
Rust: crate/self/super path resolution, mod.rs convention
C#: namespace-to-path with progressive prefix stripping
PHP: PSR-4 backslash-to-slash mapping, require/include path resolution
Directory scanning uses early pruning of .git, node_modules, dist, build, vendor, target, and other common non-source directories.
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/projectConvention-based resolution — dependency resolution uses file path conventions, not compiler/build system integration. TypeScript/JavaScript paths from tsconfig.json/jsconfig.json are supported (including extends), 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 — #include parsing 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 computed require(), 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.
List files that depend on (import from) a given file
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Absolute file path | |
| root | No | Project root (auto-detected if omitted) | |
| transitive | No | Include transitive dependents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the purpose, omitting details about side effects, permissions, performance, or error handling. There is no mention of whether the tool is read-only or what happens with parameters like 'transitive' or 'root'.
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 a single sentence that is front-loaded and concise, but it is too brief to be fully informative. While it avoids redundancy, it could include more useful content without becoming verbose.
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?
Given the tool has three parameters, no output schema, and no annotations, the description is insufficient. It does not explain the output format, how results are returned, or how to interpret them. The presence of sibling tools implies a complex environment, but this description lacks the detail needed for effective use.
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 input schema provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description does not add any additional meaning beyond the schema, such as clarifying the effect of 'transitive' or the behavior when 'root' is omitted.
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 clearly states 'List files that depend on (import from) a given file', which is a specific verb and resource. It indicates the direction of dependencies (reverse), distinguishing it from siblings like 'syms_deps' which likely list forward dependencies, though this is not explicitly stated.
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?
No guidance is provided on when to use this tool versus alternatives like 'syms_deps', 'syms_impact', or 'syms_imports'. The description lacks context about the intended use case or conditions that would make this tool preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files that a given file depends on (imports from)
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Absolute file path | |
| root | No | Project root (auto-detected if omitted) | |
| transitive | No | Include transitive dependencies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits like side effects, performance implications, or whether it performs a static parse or runtime analysis. With no annotations, the description should provide more context but does not.
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?
Single sentence, no unnecessary words. Efficient but could be improved by adding usage context without increasing length significantly.
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?
No output schema and no annotations. The description covers the basic function but lacks detail on what 'depends on' means (e.g., only imports, or also include other kinds of dependencies?). Adequate but not rich.
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 description coverage is 100%, so the schema already documents each parameter. The description adds only the overall purpose, not additional meaning for individual parameters like 'transitive' or 'root'. Baseline of 3 is appropriate.
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 clearly states the action 'List' and the resource 'files that a given file depends on (imports from)'. It is specific and effectively distinguishes from siblings like syms_dependents, which likely lists reverse dependencies.
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?
No guidance on when to use this tool versus alternatives such as syms_dependents or syms_imports. Does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project-wide dependency graph summary with hot spots, heaviest importers, and circular dependencies
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions 'summary' but does not disclose behavioral traits such as whether it is read-only, performance implications, or authentication needs. Insufficient for an agent to understand side effects or costs.
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?
Single sentence with no waste. Information is front-loaded and efficient.
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?
Given no output schema, description should clarify output structure. It names key elements (hot spots, heaviest importers, circular dependencies) but lacks detail on format or data types. Could be more complete.
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 already describes the 'root' parameter adequately (100% coverage). Description does not add new meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Description clearly states verb+resource: 'Project-wide dependency graph summary with hot spots, heaviest importers, and circular dependencies'. It distinguishes itself from siblings like syms_deps and syms_list by focusing on a project-wide overview.
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?
Description implies high-level overview usage but does not explicitly state when to use vs alternatives like syms_dependents or syms_impact. No when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impact analysis: direct and transitive dependents of a file
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Absolute file path | |
| root | No | Project root (auto-detected if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only hints at returning dependents without specifying order, depth limits, side effects, or permissions. The term 'impact analysis' is vague.
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 extremely concise—a single sentence that conveys the core purpose without extraneous words. It is front-loaded with the key action and resource.
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?
Given no output schema and the complexity of dependency analysis, the description is insufficient. It does not explain the output format, whether the result is a flat list or a tree, or how it handles cycles. Missing details for an agent to reliably 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?
The input schema has 100% description coverage for both parameters (file path and root), which are self-explanatory. The description adds no further parameter-specific semantics beyond the schema, so baseline 3 is appropriate.
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 clearly states the tool performs impact analysis, specifically focusing on direct and transitive dependents of a file. It distinguishes itself from siblings like syms_dependents and syms_deps, which likely handle direct dependencies only.
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?
No guidance is provided on when to use this tool over siblings like syms_dependents or syms_deps. The description lacks explicit usage context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse import statements from source files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | File or directory paths | |
| recursive | No | Scan directories recursively |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Parse') but does not explicitly state lack of side effects or permissions needed. No annotations provided, so the description carries full burden but fails to fully disclose behavioral traits.
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?
One sentence, no redundancy. However, it is very brief and could include more context without becoming verbose.
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 tool with 2 parameters and no output schema, the description is minimally viable. It does not explain the output format or error behavior, and lacks differentiation from siblings.
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 the description need not add much. However, it provides no additional meaning beyond the parameter names and the schema descriptions (e.g., what 'paths' specifically refers to). Adequate but not improved.
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 clearly states the tool's action ('Parse') and resource ('import statements from source files'), distinguishing it from sibling tools like syms_deps or syms_graph which deal with dependencies and graphs.
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?
No guidance on when to use this tool versus alternatives (e.g., syms_search or syms_impact). The description does not mention conditions or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract top-level symbols (functions, classes, types, constants) from source files
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Optional symbol kind filter (e.g. class, function, constant) | |
| paths | Yes | File or directory paths | |
| recursive | No | Scan directories recursively |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'top-level' and lists symbol kinds, but lacks details on output format, recursion behavior (beyond parameter name), or any side effects. It is adequate but not thorough.
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?
A single 12-word sentence that is completely front-loaded with the essential action. No filler or redundancy.
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?
Given no output schema and no annotations, the description is too minimal. It omits details about the return value format, whether symbols are fully qualified, and how recursion interacts with directory paths. More information is needed for complete understanding.
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 adds context ('top-level' and example symbol types) that complements the schema but does not significantly enhance understanding of parameters.
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 uses a specific verb ('extract') and resource ('top-level symbols from source files') and lists examples (functions, classes, types, constants). This clearly distinguishes it from sibling tools like syms_graph or syms_search.
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?
No guidance is provided on when to use this tool over alternatives (e.g., syms_search for searching symbols). There is no mention of use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for symbols by name across a project. Matches are ranked: exact > prefix > contains (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Optional symbol kind filter | |
| query | Yes | Symbol name to search for | |
| root | No | Project root (auto-detected if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses non-destructive search, case-insensitivity, and ranking, but lacks details on return format or pagination. Adequate for a simple tool.
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?
Single sentence with no wasted words, front-loaded with purpose, then ranking details. Highly concise and well-structured.
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?
Given no output schema and simplicity of the tool, the description is sufficient for selection and invocation. It covers purpose, ranking, and scope (across a project). Could mention output format but not required.
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 the schema already documents all parameters. The description adds no extra parameter meaning beyond the 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 clearly states 'Search for symbols by name across a project' with a specific verb and resource, and the ranking explanation distinguishes it from sibling symbol tools.
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 provides explicit ranking order (exact > prefix > contains, case-insensitive), which helps the agent understand result behavior, but does not explicitly mention when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
syms_dependentssyms_depssyms_graphsyms_impactsyms_importssyms_listsyms_searchScored across 7 tools
Most tools have distinct purposes, but there is some overlap: syms_dependents and syms_impact both deal with dependents (though impact includes transitive), and syms_deps and syms_imports both relate to dependencies vs. import statements. This could cause minor confusion.
All tools follow a consistent pattern: 'syms_' prefix plus a descriptive second part using underscores. No mixed conventions (all lowercase snake_case).
Seven tools is well-scoped for a code symbol and dependency analysis server. Each tool covers a focused aspect without being overwhelming or too sparse.
The set covers dependency analysis, symbol listing, and search. Minor gaps exist, such as no tool for detailed symbol metadata or reference finding, but the core analysis workflow is well-supported.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Stateless TS/JS compiler facts for agents: references, imports, impact. No repo index or OAuth.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
