N3MO is a structural code intelligence server that transforms source code into a queryable knowledge graph, enabling AI agents to understand codebases structurally rather than through text search.
Index a codebase (n3mo_index): Crawl and parse an entire workspace directory using AST analysis, storing symbols, call graphs, and dependencies into a knowledge graph for fast querying.
Blast radius / impact analysis (n3mo_get_blast_radius): Trace the transitive impact of changing any function or class — discover every caller up to a configurable depth, so you know exactly what will be affected before making edits.
Symbol search (n3mo_search_symbol): Locate the exact definition of any function or class in the indexed codebase, returning the file path and line number.
Forward dependency graph (n3mo_get_dependencies): Find all external symbols that a given function or class calls, mapping its outward dependencies.
File symbol listing (n3mo_get_file_symbols): List all classes and functions defined inside a specific file, giving a structural overview of any module in the codebase.
A structural code intelligence layer that transforms source code into a queryable knowledge graph for search, impact analysis, and AI-powered development.
Parse once. Query forever. Know exactly what breaks before it does.
"Text diffs are the source of all code review anxiety. A developer modifies a core utility, and the reviewer has to spend an hour mentally tracing downstream services to guess if it's safe to merge. N3MO replaces human guesswork with hard math."
📜 Licensed under PolyForm Noncommercial 1.0.0 — Source available for noncommercial use. • Need commercial use? Get a commercial license →
What is N3MO • Capabilities • Installation • Usage • MCP • CI/CD SaaS • Benchmarks • Tutorial • Sponsor
N3MO is a symbol-centric code intelligence layer. Instead of scanning raw text, it parses your source code's ASTs, maps call graphs, and models dependencies in a queryable relational database — deterministically, with zero LLM calls at index time.
For engineering leaders and teams, N3MO acts as a structural insurance policy for your codebases.
🛡️ Eliminate Regression Risks — Utility functions are rarely refactored because developers fear unknown side effects. N3MO maps the transitive blast radius of any symbol to arbitrary depth, showing you exactly what will break before you make the edit. Automate this in your CI/CD →
🏎️ Rapid Developer Onboarding — Instead of senior engineers spending hours explaining codebase flow to new hires, developers run one command to visualize complex call chains and parent-child dependencies interactively.
🤖 AI-Agent Ready Infrastructure — Modern LLM agents (Cursor, Claude Desktop) are limited by context windows and text search. N3MO's native MCP server lets agents query the actual code graph, enabling fast, hallucination-free refactoring.
⚡ No Embeddings, No Drift — N3MO is pure static analysis: Tree-sitter AST parsing into PostgreSQL. There's no vector index to keep in sync, no embedding cost per repo, and no semantic-similarity guesswork — every edge in the graph is an exact, verifiable relationship.
Capability | Grep / Text Search | IDE "Find References" | N3MO Code Graph |
Analysis Basis | Substring matching | AST-based, direct refs only | Relational knowledge graph |
Transitive Traversal | ❌ None | ❌ Manual, one level at a time | ⚡ Instant to arbitrary depth |
Blast Radius Mapping | ❌ None | ❌ Flat search-result list | 🎨 Interactive visual orbit map |
CI/CD Integration | ❌ None | ❌ Bound to IDE runtime | ⚙️ Dockerized CLI + CTE queries |
AI Agent Integration | ❌ Injected file chunks | ⚠️ Manual context copy | 🤖 Native MCP server |
Language Coverage | ✅ Any text file | ⚠️ Language-specific plugins | ✅ 27 Tree-sitter grammars |
Indexing Method | N/A | N/A | ✅ Deterministic AST parse — no embeddings, no LLM calls |
❌ Without N3MO
✅ With N3MO
N3MO doesn't find text — it understands structure. It traces the actual call graph, not string matches.
Questions N3MO answers instantly:
Question | How | |
🔎 | What functions and classes exist in this repo? | Full symbol index across 27 languages |
🎯 | Where is this symbol used — directly and transitively? | Recursive CTE traversal to arbitrary depth |
💥 | What is the blast radius of changing this function? | Interactive orbit map with depth slider |
🕸️ | How do these components actually connect? | Call graph + parent-child hierarchy |
🤖 | Can my AI agent understand this codebase structurally? | Native MCP server for Cursor / Claude |
Related MCP server: CodeGraph
Start here | |
Individual Developers |
|
Code Reviewers & Team Leads | Stop merging blindly. Install the N3MO Webhook via n3mo.shop to get deterministic blast-radius comments on every PR automatically. |
Engineering Leaders | Offload pipeline infrastructure entirely. Zero-config, cloud-managed graph engine. No local PostgreSQL to maintain, zero data retention, and strict privacy. |
Multi-language support — 27 Tree-sitter grammars supported (dynamically loaded); actively benchmarked on 10 major languages including Python, JS/TS, Go, Java, and C/C++
Parallel AST ingestion — ProcessPoolExecutor distributes CPU-bound parsing across all available cores
Incremental re-indexing — SHA-256 file hashing skips unchanged files automatically
Idempotent operations — re-indexing updates existing data without duplication
Smart exclusions — case-insensitive directory filters and camelCase-aware filename checks prevent false positives (e.g. allows contest.py while skipping test_*.py)
Symbol extraction — functions, classes, methods with full file path + line context
Hierarchical modeling — parent-child relationships (Module → Class → Method)
Call graph construction — who calls whom, resolved at ingestion time
Scope-aware resolution — class scope > local file > imports > qualified dot paths > global
Blast radius analysis — recursive CTE traversal to arbitrary depth with cycle guards
Connection pooling — ThreadedConnectionPool eliminates per-symbol DB round trips
Batch inserts — symbols, imports, and calls batched per file in single transactions
Optimized queries — SPLIT_PART fix delivered a 2× speedup on call resolution
Interactive graph — vis.js orbit map with click-to-inspect nodes, sidebar, and depth slider
Dark mode — toggleable canvas dark mode with real-time node/edge updates, persisted in localStorage
Premium styling — sleek interactive dashboard landing page UI and graph visualizer styled with Bricolage Grotesque, Inter, and JetBrains Mono typography
SKILL.md profile — system instructions to configure Claude as an impact-aware coding agent
Native MCP server — first-class integration with Cursor, Claude Desktop, and Windsurf
Git hooks — automatic re-indexing on every commit
CI pipeline — GitHub Actions with linting (ruff), type checking (mypy), and pytest
…and more |
Tree-sitter parsing supported for 27 languages. Deep semantic call graph mapping currently optimized for Python, JS/TS, and Java.
Install N3MO directly from PyPI:
# Install the package
pip install n3mo
# Start Docker containers & initialize the database
n3mo setupAlternatively, for contributors running in editable mode:
git clone https://github.com/RajX-dev/N3MO.git
cd N3MO
pip install -e .
n3mo setupcd /path/to/your/project
n3mo indexWhat gets indexed:
✅ Source files in all 27 supported languages
❌ Virtual environments (venv/, .venv/)
❌ Dependencies (node_modules/, site-packages/)
❌ Build artifacts (.git/, __pycache__/, dist/)
❌ Test / fixture directories (tests/, mocks/, specs/)
Example terminal output:
◈ IMPACT ANALYSIS
──────────────────────────────────────────────────────────────────
Target: authenticate_user
──────────────────────────────────────────────────────────────────
◉ Direct Callers (3 symbols)
▸ login_endpoint api/auth.py:12
▸ refresh_token api/token.py:23
▸ validate_session middleware/auth.py:89
◎ Ripple Effects (5 symbols)
╰─▸ POST /login routes.py:67
╰─▸ admin_login admin/views.py:34
╰─▸ require_auth decorators.py:12
╰─▸ dashboard_view views/dashboard.py:8
╰─▸ settings_view views/settings.py:22
──────────────────────────────────────────────────────────────────
Total impacted: 8 references │ depth ≤ 3graph LR
A[main.py] --> B[auth.py::login]
A --> C[db.py::connect]
B --> D[utils.py::hash_password]
B --> E[models.py::User]
C --> F[config.py::DB_URI]
style A fill:#ff6b6b,stroke:#c92a2a,stroke-width:2px,color:#fff
style B fill:#4ecdc4,stroke:#0ca89e,stroke-width:2px,color:#000
style C fill:#45b7d1,stroke:#1098ad,stroke-width:2px,color:#000
style D fill:#96ceb4,stroke:#63b598,stroke-width:2px,color:#000
style E fill:#ffd93d,stroke:#f5c200,stroke-width:2px,color:#000
style F fill:#e0e0e0,stroke:#a0a0a0,stroke-width:2px,color:#000https://github.com/user-attachments/assets/tutorial.mp4
Index a repository, trace blast radius, and visualize the dependency graph — all in under 30 seconds.
What the tutorial covers:
Step | What You'll See |
1. Install & Setup |
|
2. Index a Codebase |
|
3. Query Impact |
|
4. Visualize |
|
5. PR Webhook | A live GitHub PR triggers N3MO's automated blast-radius comment |
💡 Prefer hands-on? Follow the Quick Start to run N3MO locally in under 60 seconds.
N3MO includes a native MCP server that exposes repository analysis and graph traversal tools to LLM agents (like Claude, Cursor, or Windsurf).
# Navigate to the workspace you want Claude to analyze, then run:
n3mo mcp installThis registers N3MO and sets up the paths automatically. Restart Claude Desktop and you're ready!
To configure Claude to run N3MO impact queries proactively before changing code in the editor, import or copy-paste the custom instructions from the SKILL.md profile.
Go to Settings → Models → MCP.
Click + Add New MCP Server.
Set the configuration details:
Name: n3mo
Type: command
Command: n3mo mcp start (or uvx n3mo mcp start to run directly)
Environment Variables: TARGET_CODE_DIR=/absolute/path/to/your/active/workspace
Click Save, and Cursor will instantly be able to index and query your workspace blast radius.
Bringing AI agents to your team workspace? Stop forcing every developer to run heavy indexing pipelines and PostgreSQL instances on their local laptops.
Connect Cursor directly to the global cloud graph at n3mo.shop to bypass local machine database overhead entirely. Your agents query the cloud graph instantly.
Tool | Description |
| Ingests and indexes the codebase |
| Locates the definition of a symbol across the workspace (file path, line number) |
| Finds all external symbols that a given symbol calls (forward-dependency graph) |
| Lists all classes and functions defined inside a specific file |
| Traces the transitive impact/call graph of a code symbol |
Running deterministic AST parsing in a local loop is great, but manually building multi-step YAML actions, maintaining CI database infrastructure, and orchestrating PR timeline events is a massive friction point for engineering teams.
n3mo.shop is our definitive, zero-maintenance infrastructure layer that abstracts all of this away.
Zero-Config Webhooks: 2-click GitHub App sync. No YAML boilerplate to maintain.
Automated Inline PR Comments: N3MO hooks into your repository and posts the exact blast radius directly into your GitHub review timeline:
◈ N3MO Pull Request Impact Analysis
⚠️ Blast Radius Detected: Modifying `core_auth.py` transitively impacts 3 downstream services.
- `api/billing.py:process_payment()`
- `web/handlers.py:login_route()`
- `cron/sync_users.py:execute()`Strict "Zero-Trust" Privacy: We only parse structural AST metadata (symbol relationships). Your raw source code is never stored on our servers. The ephemeral parsing container is instantly destroyed the millisecond the PR comment is posted.
Offload your pipeline infrastructure today at n3mo.shop →
All benchmarks measured on Intel i5-13450HX, 24 GB RAM, NVMe SSD.
Django is the primary benchmark target: 3,021 files, ~43K symbols, ~181K calls.
Django Index Time (minutes)
═══════════════════════════════════════════════════════════════
v0.3 Baseline ██████████████████████████████████████████████ 23 min 1×
SPLIT_PART Fix ██████████████████████ 11 min 2×
Batch Inserts █████████ 5 min 4.6×
+ Multiprocessing ████ 2.5 min 9× 🚀
═══════════════════════════════════════════════════════════════Optimization | Index Time | Speedup | What Changed |
v0.3 baseline | 23 min | 1× | Per-symbol DB inserts, naive call resolution |
+ SPLIT_PART query fix | 11 min | 2× | Eliminated redundant string splitting in call resolution |
+ Batch inserts | 5 min | 4.6× | Symbols, imports, and calls batched per file (1 transaction) |
+ Multiprocessing | ~2.5 min | ~9× |
|
✅ All results are real measurements on the Django repository. Multiprocessing gains scale with core count.
Tested on TensorFlow — a 36,000-file, multi-language (C++/Python) monorepo.
Metric | Result |
Repo size (total files) | ~36,000 |
Files processed & indexed | 14,611 (after filtering tests, configs, and non-source files) |
Total symbols extracted | 79,523 |
Total call edges extracted | 480,851 |
Full index time (cold start) | 14.06 minutes |
Peak memory (Docker container) | 185 MB RAM |
CPU utilization | ~5% |
N3MO scales from a 3K-file pure-Python repo (Django) to a 36K-file multi-language enterprise monorepo (TensorFlow) — roughly a 5× larger indexing job at near-linear throughput, without significant resource overhead. Symbol/edge-per-file and incremental (warm) re-index numbers for TensorFlow are being finalized in the full benchmark report.
Tested on ScanCode Toolkit — ~600K lines of Python.
Metric | Result |
Lines of code | ~600,000 |
Full index time | ~3 minutes |
Processing mode | Single-threaded (v0.3) |
N3MO uses SHA-256 file hashing to skip unchanged files on subsequent runs.
Scenario | Time | Notes |
Full index (first run) | Baseline | All files parsed and inserted |
No changes (re-run) | < 1 second | Hash comparison only, zero DB writes |
1 file modified | < 2 seconds | Only the changed file is re-parsed and upserted |
These results are from the built-in benchmark script on a 20-file synthetic repository. Real-world incremental performance is proportional to the number of changed files, not the total repository size.
Impact analysis uses PostgreSQL recursive CTEs with cycle guards. Query times are independent of repository size — they depend only on the size of the result subgraph.
Query Type | Typical Latency |
Direct callers of a symbol | < 10 ms |
Full blast radius (depth ≤ 5) | < 50 ms |
Complete graph traversal | < 200 ms |
python benchmarks/benchmark_indexing.pyN3MO's core architecture and distribution phases (Foundations, Performance, Correctness & Scaling, and Distribution) have been successfully completed. The project is currently stable, actively maintained, and ready for production use.
1. Structure before semantics Map the code skeleton (AST) before adding AI analysis. A correct graph is worth more than a smart but wrong one.
2. Database as source of truth All state lives in PostgreSQL, eliminating in-memory complexity and enabling graph queries that application-level traversal cannot match.
3. Correctness over speed The parser must handle syntax errors gracefully without corrupting the graph. A fast indexer that silently drops symbols is worse than a slow one that gets everything right.
4. Idempotent operations Re-running ingestion produces identical results, enabling safe incremental updates and CI/CD integration.
Contributions are welcome! Please read the CONTRIBUTING.md guide to get started with setting up the project, coding standards, and running checks locally.
# Install with dev dependencies
pip install -e ".[dev]"
# Lint
ruff check n3mo/
# Type check
mypy n3mo/
# Tests
pytest tests/N3MO is free under the PolyForm Noncommercial 1.0.0 License for local usage and single-developer MCP integrations.
100% Free & Local — CLI queries, local MCP integrations, and the visualizer with zero limits.
Commercial SaaS & Webhooks — To use N3MO in team environments, CI/CD pipelines, and private GitHub webhooks, purchase a commercial license at n3mo.shop.
Enterprise Licensing — for large-scale organization deployments, custom SLAs, or zero-trust air-gapped environments, reach out for Enterprise options.
Licensed under the PolyForm Noncommercial 1.0.0 License.
✅ Free for personal projects, academic research, and hobby tools
✅ Source available — view, modify, and distribute for noncommercial purposes
⚠️ Noncommercial — you may not use it for commercial purposes
⚠️ Restrictions apply on offering it as a service
For commercial deployments or proprietary modifications, contact for licensing options.
See LICENSE for full legal details.
If N3MO saves you time during code reviews or helps your AI agents understand your codebase, consider sponsoring the project to support continued development.
Your sponsorship helps fund:
🔧 Continued maintenance and new language support
🚀 Performance improvements and scaling
📖 Better documentation and tutorials
🌍 Keeping the CLI and MCP server free for individual developers
Raj Shekhar — Delhi Technological University
Tree-sitter — for robust, incremental, error-tolerant parsing
PostgreSQL — for making recursive graph queries possible without a graph database
Docker — for reproducible, single-command environments
vis.js — for the interactive graph visualization
FastAPI — for the high-performance REST layer
⭐ Star this repo if you find it useful — thanks for visiting!
Building tools for understanding code at scale.
Query the impact analysis / blast radius of a code symbol (class or function).
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Traversal depth limit (default: 3). | |
| symbol_name | Yes | Name of the function or class to trace. | |
| project_path | No | Absolute path to workspace directory (default: current directory). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether this is a read-only operation, performance considerations, or side effects. Terms like 'impact analysis' imply a computation with potential complexity, but no behavioral details are given.
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, front-loaded sentence that conveys the core purpose efficiently. There is no unnecessary information, and it reads clearly. Slightly more structure (e.g., listing what the tool retrieves) could improve it, but it is largely effective.
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 complexity of blast radius analysis and the absence of an output schema, the description is incomplete. It does not explain what the tool returns (e.g., a graph, list of affected symbols), how the depth parameter affects results, or any prerequisites. Sibling tools suggest a suite, but this description lacks sufficient detail for an agent to understand the tool's full functionality.
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% coverage with descriptions for all three parameters (symbol_name, depth, project_path). The description adds no additional semantic meaning beyond the schema; it only mentions 'class or function', which aligns with symbol_name. Baseline 3 is appropriate since schema already describes parameters well.
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 queries 'impact analysis / blast radius' of a code symbol, specifically class or function. It uses a specific verb 'Query' and resource 'impact analysis / blast radius', which distinguishes it from sibling tools like dependency or file symbol queries. However, it does not explicitly differentiate itself from similar 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?
No guidance is provided on when to use this tool versus alternatives (e.g., n3mo_get_dependencies or n3mo_search_symbol). There are no usage conditions, exclusions, or examples. The description only states the tool's function without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all external symbols that a given symbol calls (the forward-dependency graph).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol_name | Yes | Name of the function or class to inspect. | |
| project_path | No | Absolute path to workspace directory (default: current directory). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what the tool does, not how it behaves—missing details on indexing requirements, scope (direct vs transitive), error handling, or performance characteristics.
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 wasted words. However, it could be slightly more informative (e.g., mentioning indexed requirement) without losing conciseness.
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?
Without output schema, the description should explain return format or behavior; it does not. Leaves ambiguity about whether dependencies are direct or transitive, and whether indexing is 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 baseline is 3. The description adds 'forward-dependency graph' context but no additional meaning beyond the schema's parameter names and 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 uses a specific verb ('Find') and identifies the resource ('external symbols that a given symbol calls'), with the clarifying phrase 'forward-dependency graph' that distinguishes it from likely reverse-dependency siblings like n3mo_get_blast_radius.
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 implies the tool is for exploring forward dependencies but provides no explicit guidance on when to use it versus alternatives (e.g., n3mo_get_blast_radius, n3mo_search_symbol) or prerequisites like prior indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all symbols (classes/functions) defined inside a specific file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file to inspect (or a substring match). | |
| project_path | No | Absolute path to workspace directory (default: current directory). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the basic action without mentioning performance, side effects, error handling, or what happens if the file is not found or contains no symbols.
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 direct and free of extraneous words. It front-loads the essential information efficiently.
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's moderate complexity (2 parameters) and lack of output schema or annotations, the description barely covers the minimum. It omits return value or error conditions, which an agent would need for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions; it merely repeats the concept of inspecting a file.
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 verb 'List' and the resource 'symbols (classes/functions)' from a specific file. It effectively distinguishes itself from sibling tools like n3mo_search_symbol (which searches across the workspace) and n3mo_get_dependencies (which finds 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?
The description implies usage for inspecting a single file's symbols, but provides no explicit guidance on when to use this tool versus alternatives like n3mo_search_symbol or n3mo_get_blast_radius. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger N3MO to crawl and index the active workspace folder.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Absolute path to workspace directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects, duration, or permissions. For a mutation tool, more transparency is needed.
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 redundancy, directly states the tool's purpose.
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?
Simple tool with one param and no output schema; description covers the core function but lacks detail on behavior or return value.
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%, but the description adds no extra meaning beyond the schema. Parameter 'project_path' is adequately described in schema.
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 ('Trigger') and resource ('active workspace folder'), clearly distinguishing from sibling tools that query rather than initiate actions.
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 vs siblings (e.g., n3mo_get_file_symbols). Does not mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the indexed codebase for the exact location and definition of a symbol (class or function).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol_name | Yes | Name of the function or class to search for. | |
| project_path | No | Absolute path to workspace directory (default: current directory). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states that the tool searches for the 'exact location and definition' of a symbol, but does not clarify what that entails (e.g., file path, line number, or code snippet). The description is adequate but lacks detail about the search behavior or output format.
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 of 14 words, highly concise and front-loaded with the core purpose. No extraneous information or redundant phrases.
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?
Despite the tool's simplicity, the description fails to specify what the tool returns (e.g., file path, line number, code snippet). It also does not mention that the codebase must be indexed beforehand. Given the lack of an output schema, this information is essential for the agent to use the tool correctly.
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%, and both parameters have descriptions in the input schema. The tool description adds no additional meaning beyond what the schema already provides (e.g., it does not elaborate on the 'project_path' parameter or provide examples). Baseline score is 3.
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 verb 'Search', the resource 'indexed codebase', and the object 'symbol (class or function)', with the aim of finding its exact location and definition. It is distinct from sibling tools like n3mo_get_dependencies or n3mo_get_file_symbols, which have different purposes.
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 such as n3mo_get_file_symbols or n3mo_get_blast_radius. The description does not specify prerequisites (e.g., the codebase must be indexed first) or scenarios where this tool is preferred.
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. Dates show when Glama detected each change.
v2.0.1n3mo_get_blast_radiusn3mo_get_dependenciesn3mo_get_file_symbolsn3mo_indexn3mo_search_symbolEach tool has a clear, distinct purpose without overlap: blast radius, dependencies, file symbols, indexing, and symbol search cover different aspects of code analysis.
All tools follow the 'n3mo_verb_noun' pattern consistently, using snake_case and predictable verbs (get, index, search).
With 5 tools, the server is well-scoped for code analysis—neither too few nor too many for the intended functionality.
Core workflows like indexing, searching, and dependency analysis are covered. Minor gaps such as missing reverse dependency query or file listing are not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RajX-dev/N3MO'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
