knot
knot
knot is a high-performance codebase indexer that extracts structural and semantic information from source code, enabling AI agents to understand, analyze, and navigate large code repositories. Currently supports Java, Kotlin (v0.7.4+), TypeScript, JavaScript/Node.js, Rust (v0.8.x), Python (v0.9.3), Groovy (v0.10.3), C/C++ (v1.0.0), HTML, and CSS/SCSS, plus Build Systems (Maven pom.xml, Gradle build.gradle, Jenkins pipeline, Cargo.toml — v1.2.0), Configuration Files (YAML, JSON, .properties — v1.2.0), and Kubernetes + Helm (v1.2.0) with full cross-language linking.
The indexer automatically builds:
Vector Search Database (Qdrant) — semantic understanding via embeddings
Graph Database (Neo4j) — architectural relationships via call graphs
This dual-database approach powers both:
MCP (Model Context Protocol) Server — Exposes three tools to any LLM client (Claude, Gemini, ChatGPT, Cursor, etc.)
CLI Tool (v0.10.1) — Standalone
knotcommand for terminal and scripting environments
✨ Key Features
🔍 Code Intelligence Tools
search_hybrid_context: Semantic + structural search. Find code by meaning, class name, method signature, docstrings, or comments. Returns full context including dependencies.find_callers: Reverse dependency lookup. Identify dead code, perform impact analysis, or understand the full call chain of any function/method. When multiple entities share the same name (e.g.,find_nearest_entity_by_linein different files), results are automatically grouped by target showing which specific entity each caller references.explore_file: File anatomy inspection. Quickly see all classes, interfaces, methods, and functions in a file with signatures and documentation.
🏗️ Multi-Language Support
Java: Full AST extraction with package awareness
Kotlin (v0.7.4+): Complete support for Kotlin codebases with classes, interfaces, objects, companion objects, functions, methods, and properties. Fully compatible with tree-sitter-kotlin-ng grammar.
TypeScript/TSX/CTS: Complete support for modern JavaScript/TypeScript codebases, including CommonJS TypeScript files
JavaScript/Node.js (v0.7.4+): Vanilla JS, Node.js, and module systems (
.js,.mjs,.cjs,.jsx)Hybrid Web Ecosystem (v0.6.5): Cross-language linking between JavaScript, HTML, and CSS for full-stack SPA analysis
HTML (v0.6.3+): Custom elements (Web Components, Angular),
idandclassattribute indexing for cross-language CSS searchJSX/TSX Attributes (v0.6.3+): Extracts
idandclassNamefrom React components for unified HTML/CSS discoveryCSS/SCSS (v0.6.4+): Stylesheet indexing with class/ID selector extraction and variable tracking (CSS/SCSS variables, mixins, functions)
Rust (v0.8.11): Struct, enum, union, trait, function, method, module extraction with trait implementation tracking (IMPLEMENTS relationships) and macro invocation references. NEW in v0.8.6: Type alias, constant, static, and macro definition extraction with full docstring and signature support. NEW in v0.8.7: Enhanced type reference detection inside macros (
vec![],println!(),assert!(), etc.) with intelligent string literal filtering and comprehensive edge case handling. NEW in v0.8.11: O(N) nested macro traversal optimization for large Rust codebases with deeply nestedtoken_treenodes.Python (v0.9.3): Full Python extraction with class, function, method support, constants, module-level imports,
ValueReferencetracking for keyword arguments, class inheritance (EXTENDS), decorator extraction (@property,@staticmethod,@route(...),@dataclass), generic type hints (List[str],Optional[Dict],*args/**kwargs), Py2/Py3 exception syntax compatibility, andself.method()resolution with inherited method walking. Capturesclass_definition,function_definition(including async via optionalasyncmodifier), lambda assignments, and distinguishes methods from functions via parent context detection.Groovy (v0.10.3): Full Groovy language support via hybrid tree-sitter + ad-hoc lexical parser. Extracts classes, interfaces, traits, enums, typed/
def/quoted methods (incl. Spock specs), constructors, closures, script-level variables, fields/properties with visibility modifiers, nested classes, and decorators. Tracks package FQN and enclosing class relationships. NEW in v0.10.3: Multi-line signatures (closure default params), assignment-vs-declaration disambiguation, innermost assignment for nested closures, UUID collision fix for duplicate method names,find_callersaccurately tracks private methods including those in anonymousnew AnActionclosures.Build Systems (v0.10.0): Maven
pom.xml(dependencies + plugins via roxmltree), Gradlebuild.gradle(deps + plugins + tasks), andJenkinsfilepipeline (stages + steps) extraction.Cargo.toml (v1.2.0): Rust package manager support with package metadata, features, workspace members, and multi-format dependency parsing (simple, table, git, path).
Configuration Files (v1.2.0): YAML (.yml/.yaml), JSON (.json), and Java Properties (.properties) with leaf-key granularity. Special handling for package.json (npm dependencies as BuildDependency, scripts as ConfigProperty).
Kubernetes + Helm (v1.2.0): K8s manifest parsing (Deployment, Service, ConfigMap, Secret, Ingress, Namespace) with label/annotation tracking and cross-resource references. Helm chart indexing (Chart.yaml metadata, values.yaml key-value pairs, template variable extraction via {{ .Values.X }}).
C/C++ (v1.0.0): Complete C/C++ support with namespace-aware FQN resolution (
Engine::MyClass::start), class/struct extraction, function/method tracking, macro definition and usage detection (uppercase identifier heuristic), type reference tracking (declarations,newexpressions), and full call graph analysis. Supports.c,.h,.cpp,.hpp,.cc,.cxx,.hh,.hxxextensions via tree-sitter-c and tree-sitter-cpp parsers. Includes intelligent auto-detection for.hheaders to parse them correctly as C or C++ based on their contents.
📚 Rich Comment Extraction
Captures docstrings (JavaDoc, JSDoc) preceding declarations
Extracts inline comments within method/function bodies
Respects nesting boundaries (class comments don't capture method comments)
Intelligently aggregates comment blocks
📊 Dual-Database Architecture
Qdrant: Vector search for semantic code understanding
Neo4j: Graph relationships for structural navigation
🚀 High Performance
Parallel Streaming Pipeline: Overlaps CPU-bound embedding with I/O-bound ingestion via MPSC channels (v0.5.0+)
Incremental Indexing: Uses SHA-256 hashes to skip unchanged files
Real-time Watch Mode: Automatically re-indexes changed files in seconds via
--watchCPU Parallelism: AST extraction via Rayon
Scalable: Configurable batch processing and constant memory footprint (~2GB) regardless of repository size
Performance Benchmarking (v1.1.0+): Three-level validation framework
Unit benchmarks: Criterion-based benchmarks for parse, embed, and graph write throughput (
benches/)E2E benchmarks: Full pipeline metrics capture with per-stage timing (
tests/benchmark_e2e.sh)CI regression tracking: Automated baseline comparison against tolerance thresholds (
scripts/compare_perf_metrics.sh)
Related MCP server: MCP-RAG
🛠️ Installation
Prerequisites
Component | Version | Notes |
Docker | 20.10+ | For running Qdrant and Neo4j |
qdrant | 1.x | Vector database (docker) |
neo4j | 5.x | Graph database (docker) |
Option A: Pre-compiled Binaries (macOS & Modern Linux)
Go to the Releases page and download the native executable for your platform.
Install knot binaries (CLI, MCP server, and indexer):
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/knot/releases/latest/download/knot-installer.sh | shDownload agent-skills guides separately (optional):
curl -sO https://raw.githubusercontent.com/raultov/knot/master/.knot-agent.md && curl -fsSL https://raw.githubusercontent.com/raultov/knot/master/.knot-agent-skills.tar.gz | tar -xzThe first command installs the knot binary to your PATH. The second (optional) downloads the agent skill index (.knot-agent.md) and extracts comprehensive guides for using knot CLI with AI agents and code analysis tools.
Linux Requirements:
Full install (knot-indexer + CLI + MCP): glibc 2.38+
Ubuntu 24.04 LTS or later
Debian 13 (Trixie) or later
Fedora 39+ / RHEL 10+
Arch Linux (rolling release)
Lightweight clients-only (knot CLI + MCP server, no indexing): glibc 2.35+ (even older systems like Debian 12 Bookworm work fine)
For older Linux distributions or Windows, see the Lightweight Clients section below or use Docker (Option B).
Option B: Docker (Universal Compatibility)
Docker images provide universal compatibility for any Linux distribution and Windows.
Full Install (All Binaries: knot-indexer, knot CLI, knot-mcp)
Build the image:
docker build -t knot:latest . --network=hostRun the indexer:
# Use --network host to connect to databases running on your host machine
docker run --rm \
-v /path/to/your/repo:/workspace \
-e KNOT_REPO_PATH=/workspace \
-e KNOT_NEO4J_PASSWORD=your-password \
--network host \
knot:latest \
knot-indexerRun the CLI tool:
docker run --rm \
-v /path/to/your/repo:/workspace \
-e KNOT_REPO_PATH=/workspace \
-e KNOT_NEO4J_PASSWORD=your-password \
--network host \
knot:latest \
knot search "user login flow"Run the MCP server:
docker run --rm \
-e KNOT_REPO_PATH=/workspace \
-e KNOT_NEO4J_PASSWORD=your-password \
--network host \
knot:latest \
knot-mcpNote: Uses Debian Trixie (glibc 2.38+) and includes ONNX Runtime for full functionality.
Lightweight Clients (Only knot CLI + knot-mcp, No Indexer)
For older systems (Debian 12 Bookworm, Ubuntu 22.04) or production deployments that only need to query existing indexes without indexing new code:
Build the lightweight image:
docker build -t knot:clients -f Dockerfile.clients . --network=hostImage size: ~100MB (vs ~160MB for full install)
Run the CLI tool (query existing index):
docker run --rm \
--network host \
knot:clients \
knot callers "MyClass"Run the MCP server:
docker run --rm \
--network host \
knot:clients \
knot-mcpAvailable tools in lightweight mode:
✅
knot search(structural only, no semantic search)✅
knot callers(reverse dependency lookup)✅
knot explore(file structure inspection)❌ Semantic search requires the full install
Note: Uses Debian Bookworm (glibc 2.35+) and excludes ONNX Runtime, making it compatible with older Linux distributions.
Option C: Install via Cargo
cargo install --git https://github.com/raultov/knotOption D: Build from Source
Full Install (All Binaries):
1. Start infrastructure with Docker:
docker compose up -d2. Clone and build:
git clone https://github.com/raultov/knot
cd knot
cargo build --release3. Configure:
cp .env.example .env
$EDITOR .env # Set KNOT_REPO_PATH and Neo4j credentials4. Index a codebase:
./target/release/knot-indexer5. Query via CLI:
./target/release/knot search "your query"Option E: Lightweight Clients (No Indexing)
For older Linux distributions (e.g. Debian 12 Bookworm, Ubuntu 22.04) or production deployments where you only need the CLI and MCP server (not the indexer), compile without the embedding dependencies:
Build lightweight clients:
cargo build --release --no-default-features --features only-clientsThis produces only knot and knot-mcp binaries (~8-10 MB each), excluding the 30+ MB of ONNX Runtime dependencies.
Available tools in lightweight mode:
✅
find_callers: Reverse dependency lookup (graph search). Automatically groups results by target when multiple entities share the same name.✅
explore_file: File structure inspection❌
search_hybrid_context: Semantic search (requires embeddings, not available in this mode)
Use case: Query an existing Qdrant + Neo4j index that was built elsewhere, without needing the indexer on your machine.
Docker alternative (for lightweight mode):
docker build -t knot:clients-only -f Dockerfile -f - . << 'EOF'
FROM rust:1.90-slim-bookworm AS builder
WORKDIR /build
COPY . .
RUN cargo build --release --no-default-features --features only-clients
FROM debian:bookworm-slim
COPY --from=builder /build/target/release/knot* /usr/local/bin/
CMD ["knot-mcp"]
EOF6. Start the MCP server:
./target/release/knot-mcp📖 Usage
📥 Quick Downloads
Download knot binaries (CLI + MCP server):
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/knot/releases/latest/download/knot-installer.sh | shDownload agent-skills documentation (index + all guides):
curl -sO https://raw.githubusercontent.com/raultov/knot/master/.knot-agent.md && curl -fsSL https://raw.githubusercontent.com/raultov/knot/master/.knot-agent-skills.tar.gz | tar -xz📖 Agent-Skills Guides
Comprehensive documentation for using knot tools. The download above extracts:
search.md — Semantic code discovery guide with examples
callers.md — Reverse dependency lookup with critical usage rules
explore.md — File anatomy inspection guide
workflows.md — Common patterns and best practices
For quick reference without downloading, see .knot-agent.md.
Using the CLI (v0.8.0+)
The knot CLI provides the same capabilities as the MCP server via command-line commands, making it ideal for:
Terminal-only environments
Bash scripting and automation
CI/CD pipelines
Direct integration with other tools
Three main commands:
knot search — Semantic Code Search
knot search "user authentication" --max-results 10 --repo my-appFind code entities by meaning, class names, docstrings, or comments.
knot callers — Reverse Dependency Lookup
knot callers "LoginService" --repo my-appFind all code that references a specific entity (dead code detection, impact analysis, call chains). When multiple entities share the same name in different files, results are automatically grouped by target with file locations and signatures.
knot explore — File Structure Inspection
knot explore "src/services/auth.ts" --repo my-appList all classes, methods, functions in a file with signatures and documentation.
For detailed CLI usage guide, see .knot-agent.md — a machine-readable skill that teaches LLMs how to use knot CLI for autonomous code analysis.
Indexing a Codebase
Incremental Indexing (Default, v0.4.3+)
# First run: indexes all files
knot-indexer --repo-path /path/to/your/repo --neo4j-password secret
# Subsequent runs: only re-indexes changed files (fast!)
knot-indexer --repo-path /path/to/your/repo --neo4j-password secret
# NEW: Real-time Watch mode (v0.5.2+)
knot-indexer --watch --repo-path /path/to/your/repo --neo4j-password secretHow it works:
Tracks file content via SHA-256 hashes in
.knot/index_state.jsonAutomatically detects: modified, added, and deleted files
Only re-parses and re-embeds changed files
Preserves graph relationships to unchanged files
Processes entities in memory-efficient 512-entity chunks
Performance:
Initial index (3800 files): ~60 minutes on standard hardware
Incremental update (3 files changed): ~5-10 seconds
Memory usage: Constant ~2GB regardless of repository size
Full Re-Index (Clean Mode)
# Force complete re-index (deletes all existing data)
knot-indexer --clean --repo-path /path/to/your/repo --neo4j-password secretUse --clean when:
You want to rebuild the entire index from scratch
You've changed Tree-sitter queries or embedding models
Troubleshooting indexing issues
Running E2E Integration Tests
To ensure indexer stability, run the E2E integration test suite:
# Run all language E2E tests (Java, TS, JS, HTML, CSS, Kotlin, Rust)
./tests/run_e2e.sh
# Run only Kotlin E2E tests
./tests/run_kotlin_e2e.sh
# Run only Rust E2E tests
./tests/run_rust_e2e.shSee tests/KOTLIN_E2E_TESTS.md for detailed coverage and troubleshooting.
Using the MCP Server
The MCP server exposes three tools to any compatible AI client:
Tool 1: search_hybrid_context
Find code by meaning or keywords
Query: "How is user authentication implemented?"
Result: All auth-related code, signatures, docstrings, and dependenciesCapabilities:
Semantic search by functionality
Class/method/function name lookup
Docstring and inline comment search
Architectural pattern discovery
Full dependency context
Tool 2: find_callers
Find who calls a specific function
Query: "Find callers of getCurrentTimeInSeconds"
Result: All code that invokes this function + file locationsAdvanced: Search by Signature (NEW in v0.7.4)
# Find by full signature (Java)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"registerUser(String"}}}' | knot-mcp
# Find by parameter type (Kotlin)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"findById(Int"}}}' | knot-mcp
# Find by type annotation (TypeScript)
echo '{"method":"tools/call","params":{"name":"find_callers","arguments":{"entity_name":"(EventData"}}}' | knot-mcpUse Cases:
Dead Code Detection: Zero callers = unused code
Impact Analysis: "What breaks if I modify this?"
Refactoring Safety: Find all references before removing
Tool 3: explore_file
Understand file structure
Query: "What's in BrowserService.ts?"
Result: All classes, methods, and functions with signatures and docsUse Cases:
Quick file navigation
Module structure overview
Finding all methods in a class without reading line-by-line
🔗 MCP Client Configuration
Supported Clients
knot works with any MCP-compatible AI client:
✅ Claude Desktop (Anthropic)
✅ Gemini CLI (Google)
✅ ChatGPT CLI / GPT (OpenAI)
✅ Cursor (AI IDE)
✅ Any standard MCP client
Configuration Examples
Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"knot": {
"command": "/absolute/path/to/knot/target/release/knot-mcp",
"env": {
"KNOT_REPO_PATH": "/path/to/indexed/repo",
"KNOT_QDRANT_URL": "http://localhost:6334",
"KNOT_NEO4J_URI": "bolt://localhost:7687",
"KNOT_NEO4J_USER": "neo4j",
"KNOT_NEO4J_PASSWORD": "your-password"
}
}
}
}Gemini CLI
{
"mcpServers": {
"knot": {
"command": "/absolute/path/to/knot/target/release/knot-mcp",
"env": {
"KNOT_REPO_PATH": "/path/to/indexed/repo",
"KNOT_QDRANT_URL": "http://localhost:6334",
"KNOT_NEO4J_URI": "bolt://localhost:7687",
"KNOT_NEO4J_USER": "neo4j",
"KNOT_NEO4J_PASSWORD": "your-password"
}
}
}
}ChatGPT / GPT CLI
Similar JSON configuration in your client's MCP configuration file.
⚙️ Configuration Reference
All options can be set via environment variables (.env) or CLI flags. Environment variables take precedence.
| CLI Flag | Default | Description |
|
| (required) | Root directory of the repository to index |
|
| (auto-detected) | Repository name for multi-repo isolation (auto-detected from last path component) |
|
|
| Qdrant server URL |
|
|
| Qdrant collection name |
|
|
| Neo4j Bolt URI |
|
|
| Neo4j username |
|
| (required) | Neo4j password |
|
|
| Embedding vector dimension |
|
|
| Entities per batch |
|
|
| Force full re-index (delete all existing data) |
|
| (none) | Path to CA certificate bundle for corporate SSL proxies |
| (env only) |
| Log level: |
🎨 Custom Tree-sitter Queries
The built-in extraction queries (queries/java.scm, queries/typescript.scm) can be overridden without recompiling:
KNOT_CUSTOM_QUERIES_PATH=/path/to/my/queries ./target/release/knot-indexerPlace java.scm and/or typescript.scm in your custom directory. Missing files fall back to built-in defaults.
🔐 Corporate SSL / CA Certificates
In restricted corporate environments with SSL-inspecting proxies, you may need to provide a custom CA certificate bundle so that knot can download the embedding model from HuggingFace.
Via environment variable:
export KNOT_CUSTOM_CA_CERTS=/etc/ssl/certs/corporate-bundle.pem
./target/release/knot-indexer --repo-path /path/to/repo --neo4j-password secretVia CLI flag:
./target/release/knot-indexer \
--custom-ca-certs /etc/ssl/certs/corporate-bundle.pem \
--repo-path /path/to/repo \
--neo4j-password secretVia .env file:
echo "KNOT_CUSTOM_CA_CERTS=/etc/ssl/certs/corporate-bundle.pem" >> .env
./target/release/knot-indexerThis works for all three binaries: knot-indexer, knot-mcp, and knot.
🔄 Workflow Example
Step 1: Index a Java project
./target/release/knot-indexer --repo-path /home/user/my-java-app --neo4j-password secretStep 2: Query via CLI (Instant search)
./target/release/knot search "authentication logic"
./target/release/knot callers "UserService.login"Step 3: Start MCP server (For AI Agents)
./target/release/knot-mcpStep 4: Use with Claude Desktop
Claude will list the three tools in its Tools menu
Ask: "Search for all authentication logic"
Ask: "Find who calls the login method"
Ask: "Explore the structure of UserService.java"
🤖 Auto-Configuring AI Agents
knot includes a universal .prompt file in its root directory that automatically configures modern AI coding agents (Cursor, Cline, opencode, Claude, etc.) to use the knot-mcp tools correctly.
The directive explicitly instructs AI agents to prioritize:
search_hybrid_context— for semantic code discovery (instead ofgrep)find_callers— for reverse dependency analysis (instead of finding references manually)explore_file— for file structure inspection (instead of reading line-by-line)
This ensures that when you ask an AI agent to analyze, refactor, or understand your code, it leverages the full power of the vector and graph databases rather than falling back to context-blind regex searches. The .prompt file is universal and tool-agnostic, working with any LLM client that reads codebase directives.
🤝 Contributing
Contributions are welcome! Please ensure:
All code passes
cargo clippyCode is formatted with
cargo fmtChanges are compatible with Rust 2024 edition
All new functionality includes unit tests
Performance regressions are validated with the benchmark framework before submitting PRs
Performance Benchmarking
The project includes a three-level benchmarking framework to validate optimizations and detect regressions:
Level 1 — Unit Benchmarks (Criterion):
cargo bench --bench pipeline_bench # Parse + prepare throughput per language
cargo bench --bench graph_upsert_bench # Neo4j UNWIND batching speedup (needs Neo4j)
cargo bench --bench channel_backpressure_bench # Bounded channel overheadLevel 2 — E2E Integration Benchmarks:
# Full pipeline metrics with memory and per-stage timing
./tests/benchmark_e2e.sh --focus rust_e2e --output-dir /tmp/perf_results
# Compare against baseline (fails CI if tolerance exceeded)
scripts/compare_perf_metrics.sh /tmp/perf_results .perf_metrics/baseline.jsonBaseline files: .perf_metrics/baseline.json stores the last known good metrics (committed, updated on main/master merges). Tolerance thresholds in .perf_metrics/threshold_tolerances.json control regression gates (±5% time, ±10% memory by default).
CI Integration: The test-performance job in .github/workflows/ci.yml runs after all E2E correctness tests pass, comparing results against baseline and fails the build on regression.
📜 License
This project is licensed under the MIT License. See LICENSE for details.
🚀 Roadmap
Next Release (v1.1.0 — Performance Optimization) ✅
✅ Neo4j UNWIND Batching (Phase 1-2): Replaced N individual
MERGEqueries with singleUNWIND $entitiesbatch queries — 10-50x speedup on entity/relationship writes✅ Bounded Channels (Phase 3): Parse/embed/res channels bounded with backpressure — peak memory <400MB (was 500MB unbounded)
✅ Concurrent Ingestion (Phase 4): JoinSet + Semaphore for parallel Neo4j/Qdrant writes — 2-3x ingestion throughput
✅ Rayon Thread Pool Config (Phase 5): Configurable
KNOT_RAYON_THREADSenv var (default N-1 cores)✅ Parallel Relationship Resolution (Phase 6):
par_iter_mut()for O(N/num_cpus) resolution✅ Three-Level Benchmarking Framework (Section 9):
Criterion unit benchmarks:
pipeline_bench,graph_upsert_bench,channel_backpressure_benchE2E benchmark script:
tests/benchmark_e2e.shwith metrics captureCI regression tracking:
scripts/compare_perf_metrics.sh+test-performancejob
✅ Memory targets: ~300-400MB peak (well below 2GB nice-to-have, far from 5GB hard limit)
✅ Criterion benchmarks at
benches/| Baseline metrics at.perf_metrics/baseline.json✅ cargo fmt clean | cargo clippy clean | 521 unit tests passing
Current Release (v1.2.0 — Cargo.toml, Config Files, Kubernetes + Helm) ✅
✅ Phase 12A — Cargo.toml Parser: Package metadata, dependencies (simple/table/git/path), features, workspace members via
toml = "0.8"✅ Phase 12B — Configuration Files: YAML (.yml/.yaml), JSON (.json), Java Properties (.properties) with recursive walk, depth limit 10, leaf-key granularity, lock file exclusions, 500KB file size limit. package.json special handling: npm deps as BuildDependency, scripts as ConfigProperty, ProjectIdentity emission
✅ Phase 12C — Kubernetes + Helm: 10 new EntityKind variants (K8sDeployment, K8sService, K8sConfigMap, K8sSecret, K8sIngress, K8sNamespace, K8sResource, HelmChart, HelmValue, HelmTemplateVar). K8s manifest parsing with label/annotation/reference extraction, Helm Chart.yaml/values.yaml/templates support with {{ .Values.X }} variable tracking
✅ 74+ new unit tests across 6 parser modules + 29 E2E tests (6 Cargo + 6 Config + 9 K8s/Helm)
✅ 10/10 E2E test suites pass: JS/TS/Java, Kotlin, Rust, Python, Build Systems (extended), Config Files, K8s/Helm, Groovy, Cross-Language Ref, C/C++
✅ cargo fmt clean | cargo clippy clean | 520 unit tests passing
Previous Release (v0.10.3 — Groovy Private Methods, Nested Closures & UUID Collision Fix) ✅
✅ UUID Collision Fix:
ParsedEntityidentity now includesstart_line✅ Multi-line Method Extraction:
try_extract_typed_method_multilinehandles closure default params✅ Innermost Assignment: method calls in nested closures go to the innermost method
✅ 10 E2E test cases: typed/
def/no-paren callers, multi-line closures, innermost assignment✅ 441 unit tests | clippy clean | fmt applied
Previous Release (v0.8.7 — Enhanced Rust Type Reference Detection in Macros) ✅
✅ Macro Type Reference Extraction: Type references inside macro invocations (
vec![],println!(),assert!(),format!(), etc.) are now correctly captured✅ Intelligent String Filtering: Filters out false positives from string literals using quote-counting heuristics
✅ Comprehensive Edge Case Handling: Validates identifiers, handles nested macros, supports
macro_rules!definitions✅ Improved Accuracy: EntityKind references increased by +95.7% (46→90 references), now captures test function usage
✅ Enhanced Test Coverage: Added 4 new tests for token_tree extraction covering various macro types and edge cases
Previous Release (v0.8.6 — Rust Type Aliases, Constants, and Docstrings) ✅
✅ Rust Type Alias Extraction: Extracts type alias declarations with full signature (e.g.,
type Callback = fn(u32) -> u32)✅ Rust Constant/Static Extraction: Captures
constandstatic mutdeclarations with type signatures✅ Rust Docstring Support: Full doc comment extraction for Rust entities (handles nested
doc_commentnodes in tree-sitter-rust)✅ Rich Vector Embeddings: Type signatures and documentation are now included in embeddings for better semantic search
✅ Improved Search Ranking: Rust entities like
Callbacknow rank in top 5 search results when querying by name
Previous Release (v0.8.5 — Rust Module Refactoring & Clippy Fixes) ✅
✅ Rust Module Refactoring: Extracted Rust parsing logic into dedicated
src/pipeline/parser/languages/rust.rsfor better maintainability and mirroring existing language module architecture.✅ Clippy Compliance: Fixed unused import (
uuid::Uuid) and unnecessarymutwarning in Rust module tests.✅ Rust Support Complete: Phase 8 implementation fully integrated with 17 unit tests and 22 E2E test cases passing.
Previous Release (v0.8.4 — Agent-Skills Documentation Installer & Lightweight Clients) ✅
✅ Dry-Run Mode: MCP server can run in offline mode for quality checks on deployment platforms.
✅ Platform-Agnostic: Removed all platform-specific references; compatible with any deployment platform.
✅ Enhanced Reliability: Graceful handling of missing database connections for validation scenarios.
Previous Release (v0.10.0 — Build Systems & CI/CD Support) ✅
✅ Build Systems Support (Phase 9): Maven
pom.xml(dependencies + plugins via roxmltree), Gradlebuild.gradle(deps + plugins + tasks), and Jenkinsfile pipeline (stages + steps) extraction✅ 22 unit tests + 8 E2E tests (Maven search, pom.xml explore, Gradle dep/task search, Jenkins stage/step search)
✅ BuildDependency, BuildPlugin, BuildTask, PipelineStage, PipelineStep entity kinds with explore_file formatting
Previous Release (v0.9.3 — Python Search Stability & CI Fixes) ✅
✅ Fixed CLI
explore&searchqueries that queried the default collection instead of test collection by appending-r "$REPO_NAME"✅ Python CLI search bug handled; resolved
knot searchqueries failing in specific collection bounds✅ Replaced unreliable
nc -znetwork checks with Neo4j-specific Docker health checks (docker inspect)✅ 426 unit tests | 23 Python E2E | 22 Rust E2E | 10 Kotlin E2E
Earlier Release (v0.8.2 — Quality & Doc Refactor) ✅
✅ MCP Quality: Enhanced tool descriptions for better agent discovery and usage safety.
✅ Token-Efficient Docs: Modularized agent skill guide into
docs/agent-skills/for on-demand loading.✅ Rust Phase 1: Infrastructure prepared for Rust 2024 integration.
✅ Rust Phase 2-5: Complete Rust language support including entity extraction, macro tracking, and comprehensive E2E testing (v0.8.x).
Earlier Release (v0.8.1 — CLI UX & Docker Integration) ✅
✅ Silenced CLI Logs: Default log level set to
errorforknotCLI (cleaner Markdown output).✅ 100% E2E Dual-Testing: All 35 integration tests simultaneously verify both MCP and CLI.
✅ Docker CLI Support: Official Docker image now includes the
knotbinary.✅ Agent Guidance: Enhanced
.knot-agent.mdwith signature-based search warnings.
Phase 7 (v0.8.10 — CLI UX & Corporate Network Support) ✅
✅ Human-friendly output formatting: Colorized table output as default with per-entity-kind ANSI colors
✅ Interactive result navigation: Pager support via
less -R -ewith auto-exit at end of content✅ Configurable output formats:
--outputflag supportstable(default),json, andmarkdown✅ Custom CA Certificates:
--custom-ca-certs/KNOT_CUSTOM_CA_CERTSfor corporate SSL-inspecting proxies✅ O(N) Macro Traversal Optimization (v0.8.11): Substring skipping for deeply nested
token_treenodes
Phase 8 (v0.8.11 — Rust Support) ✅
✅ Support
.rsfiles with tree-sitter-rust parser✅ Struct, enum, union, trait, and impl block extraction
✅ Function, method, macro definition and invocation tracking
✅ Type alias, constant, static, and module extraction with signatures
✅ Docstring extraction for all Rust entity types
✅ O(N) nested macro traversal optimization for large Rust codebases
✅ 17 unit tests for Rust entity and reference extraction
✅ 22 end-to-end integration tests covering all Rust language constructs
Phase 11 (v1.0.0 — C/C++ Support) ✅
✅ Support
.c,.cpp,.cc,.cxx,.h,.hpp,.hh,.hxxfiles via tree-sitter-c and tree-sitter-cpp✅ Intelligent auto-detection of
.hfiles to parse them as C++ if they contain classes, namespaces, or templates✅ Namespace-aware FQN resolution (
Engine::MyClass::start)✅ Class, struct, function, and method extraction with full signatures
✅ Macro definition and usage tracking (uppercase identifier heuristic)
✅ Type reference tracking (declarations,
newexpressions, qualified types)✅ Call graph analysis including method calls, field access (
obj->method()), and scope resolution (std::vector::size())✅ 3 unit tests for C++ entity and reference extraction
✅ 4 end-to-end integration tests covering FQN, call graphs, macro usage, and type references
Upcoming (v1.3.x)
Phase D: Cross-Repo Dependency Linking
Automatic inter-repository call resolution via
:Repositorygraph model withDEPENDS_ONedgesProjectIdentitymarker entity from build files (Maven GAV, Cargo package, npm name)knot depsCLI subcommand +list_repo_dependenciesMCP tool for dependency graph visualizationRetroactive linking for out-of-order indexing
Long-Term Vision
Reestructure E2E test suites to gain velocity by sharing binaries with unit tests and avoid Docker overhead
Markdown documentation indexing
Go support
C# support
IDE plugins (VS Code, IntelliJ, Vim)
Web UI for graph visualization
Language Server Protocol (LSP) integration
Automated Code Review tool (MCP-based)
💬 Questions?
For issues, feature requests, or discussions, please open a GitHub issue.
Available Tools
6 toolsexplore_fileExplore file anatomyARead-onlyIdempotent
Read-only file anatomy inspection. Use this to list all classes, methods, and properties within a specific source file without reading its entire contents. Provides a structural bird's-eye view of a file, showing entity signatures and docstrings to quickly grasp a module's layout.
Usage: Use AFTER identifying an interesting file via 'search_hybrid_context' to understand its available methods, or before modifying a file. Do NOT use this for searching across multiple files.
Behaviour & Return: Read-only operation. Returns a Markdown-formatted outline of the file's entities, grouped by type (Classes, Methods, Interfaces, Constants, etc.), including line numbers for direct editor navigation. Attribute-usage markup references (html_class, html_id) are summarized in a separate section by default to avoid inflating code lists; set include_markup to true to list them in full. No side effects.
Path handling: file_path should be a repo-relative path (e.g. 'src/services/user.ts'). Absolute paths under your local checkout are also accepted; the tool strips the known local root automatically. The returned file_path is normalized to the same repo-relative form regardless of how it was queried. If the query is ambiguous across multiple repositories, the answer includes an 'ambiguous_path_candidates' list — retry with a longer path or pass repo_name.
Parameter guidance: 'file_path' must be a relative or absolute path to a valid source file. Include 'repo_name' if the file path might be ambiguous across multiple indexed repositories. Set 'include_markup' to true to expand attribute-usage markup tokens.
Supports Java, Kotlin, C#, and TypeScript codebases.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the source file to explore. PREFERRED: a repo-relative path (e.g. 'src/services/user.ts'). ALSO ACCEPTED: an absolute path under the repository's local checkout (the tool strips KNOT_REPO_PATH / CWD automatically). | |
| repo_name | No | Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories. | |
| include_markup | No | Optional: set to true to list all attribute-usage markup tokens (html_class, html_id) in full rather than in a compact summary. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description adds that it returns a Markdown-formatted outline grouped by type with line numbers, summarizes markup tokens by default, and normalizes paths. It also discloses ambiguity handling via 'ambiguous_path_candidates'. These details go well beyond the annotations.
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 structured with clear paragraphs and front-loads the core purpose in the first sentence. Each section addresses a distinct concern (usage, return, path handling, params, languages), so the length is justified despite minor redundancy with the schema.
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?
The tool is complex (path handling, ambiguity, markup control) and the description covers all of it: when to use, what it returns, how paths are normalized, what the markup flag does, and which languages are supported. The absence of an output schema is compensated by the explicit return-format description.
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 schema already documents all three parameters thoroughly (100% coverage). The description's parameter guidance largely reiterates the schema, but it adds extra value by explaining path normalization, the 'ambiguous_path_candidates' retry hint, and the supported languages (Java, Kotlin, C#, TypeScript), which helps interpret valid file_path values.
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 opens with 'Read-only file anatomy inspection' and explicitly says it lists all classes, methods, and properties within a specific source file without reading its entire contents. This states a specific verb and resource and differentiates it from file-listing and search siblings.
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 explicitly directs use AFTER search_hybrid_context and before modifying a file, and warns 'Do NOT use this for searching across multiple files.' It names the alternative and the condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_callersFind callers (reverse dependencies)ARead-onlyIdempotent
Read-only reverse dependency lookup. Use this to find all code that references, calls, extends, or implements a specific entity. Answers 'who uses this code?' by querying the graph database. Differs from search tools by providing exact dependency tracking.
Usage: Use for impact analysis before refactoring or to detect dead code. Do NOT use this for semantic feature discovery—use 'search_hybrid_context' instead.
Matching is precedence-based: exact FQN (containing '.' or '::') → FQN suffix (Type.member) → exact name → signature prefix (accept(List) → name prefix (queries under 4 characters) → fuzzy substring (queries of 4+ characters). The first tier that matches wins, so an exact name never returns fuzzy noise. Queries shorter than 4 characters resolve by anchored name prefix instead of substring, avoiding substring noise on short strings. Pass a qualified name (Namespace.Type.Member) to disambiguate homonyms. Responses state which tier matched and flag fuzzy results explicitly.
Behaviour & Return: Read-only graph traversal with no side effects. Returns Markdown grouped by relationship type (Calls, Extends, Implements, References, Overridden by, Overrides, Dispatched calls) with exact file paths and line numbers. Each caller entry and each resolved target states its repository as (repo: name), so rows are attributable when multiple repositories are in scope. For JVM code (Java/Kotlin/Groovy) and C#, 'Overridden by' lists method implementations/overrides in subtypes and 'Overrides' lists the supertype methods a method implements/overrides. 'Dispatched calls' lists callers bound to an override or to a supertype method of the target (dynamic dispatch), each under the method it is statically bound to, so an interface method called only through its implementation is never reported as unused. When the query resolves to more than one entity with that name (homonyms, e.g., 'find_nearest_entity_by_line' in orphans.rs vs rust.rs), results are grouped by target entity showing which specific target each caller references — even when only one of the homonyms has callers. Each caller entry includes: name, kind, file_path:line_number, and signature. When multiple targets exist, each group shows the target's location and signature.
Entity-kind scope: target resolution is code-only by default — documentation, configuration, build-system and Kubernetes/Helm metadata (markdown_section, config_property, build_dependency, cargo_package, project_identity, k8s_*, helm_*, …) can never be presented as resolved targets. When the filter removed matches, the response says so ('Non-code matches hidden — N entities …'), never silently. Pass kinds='all' (or '*') to disable the filter, or a comma-separated allow-list of exact kinds/aliases ('callable', 'config', 'docs', 'rust_function', 'build_dependency', …) to scope resolution explicitly. The response's resolution.kind_filter field states which scope applied ('code_default', 'any', 'explicit').
Relationship coverage: the buckets cover every edge type the pipeline produces — Calls, Extends, Implements, References, Macro calls (MACRO_CALLS), DOM references (JS → HTML id), CSS class usage (JS → CSS class), script/stylesheet imports, and the VCL edges (uses backend/probe/acl, includes, imports vmod, declared-unused) — plus Overridden by / Overrides / Dispatched calls.
Truncation & completeness: the queried name is first resolved to concrete targets (capped at 25 by default). When more targets match than fit the cap, the response states 'Truncated — N targets matched; showing the first M by FQN' and 'Counts below are partial — they cover only the M of N targets shown', so bucket counts are never mistaken for the complete impact set. Raise 'max_targets' (up to 500) to retrieve more targets when the notice reports truncation.
Parameter guidance: 'entity_name' supports exact names or signature fragments (e.g., 'handleRequest' or 'handle(Request'). Include 'repo_name' to filter results to the specific codebase being analyzed.
Supports Java, Kotlin, C#, Rust, and TypeScript codebases.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | Optional entity-kind scope for target resolution. Omit for the default code-only scope (docs/config/build metadata are hidden from the target list and the response discloses them). Use 'all' (or '*') to disable filtering, or a comma-separated allow-list of exact kinds or aliases ('callable', 'class', 'config', 'docs', 'rust_function', 'build_dependency', ...). | |
| repo_name | No | Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories. | |
| entity_name | Yes | The name of the function, method, or class to find callers for | |
| max_targets | No | Maximum number of resolved targets to include (default: 25, max: 500). Raise this when the response reports a truncated target list and you need the complete impact set. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, yet the description adds substantial non-obvious behavior: precedence-ordered match tiers, resolution notices naming the matched tier, fuzzy-result flagging, 25-target default cap with explicit truncation wording, and repo attribution per row. Dynamic-dispatch handling ('Dispatched calls') is a genuinely important disclosure that prevents false 'unused code' conclusions.
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?
Purpose and usage are front-loaded and every section is labeled, which suits a tool this behaviorally complex. It is long, though, and some points are stated twice — the sub-4-character prefix behavior appears twice, and the kind-filter/truncation guidance partly repeats the schema's own parameter descriptions.
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 exists, and the description fully compensates: it describes the Markdown grouping by relationship bucket, per-row fields (name, kind, file:line, signature), homonym grouping, and the resolution.kind_filter field. Truncation semantics and supported languages are also covered, leaving no material gap for correct invocation.
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%, but the description still adds meaning the schema lacks: the exact matching precedence ladder for entity_name (FQN → suffix → exact name → signature prefix → name prefix → fuzzy), the 4-character threshold that switches prefix to substring matching, and the advice to pass a qualified name to disambiguate homonyms. It also explains the practical payoff of max_targets and kinds rather than restating them.
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?
Opens with a specific verb+resource+scope: 'Read-only reverse dependency lookup' and frames the question it answers ('who uses this code?'). It explicitly contrasts itself with search tools ('Differs from search tools by providing exact dependency tracking'), so an agent can place it among the siblings without reading the schema.
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?
Gives concrete when-to-use cases ('impact analysis before refactoring or to detect dead code') and an explicit exclusion with a named alternative: 'Do NOT use this for semantic feature discovery—use search_hybrid_context instead.' That is the strongest form of routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filesList indexed repository filesARead-onlyIdempotent
Read-only listing of the files an indexed repository carries, with entity counts and deterministic order. Answers 'list every file under src/hooks' or 'which files live in src/api/**' without prior path knowledge.
Usage: Use this BEFORE 'search_hybrid_context' when you do not know the codebase layout; then pass the same prefix to the search's optional 'path' parameter to scope results to those files. Do NOT use this to enumerate entities — use 'explore_file' on a file from this listing for its anatomy.
Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: REPOSITORY, FILE, ENTITIES, ordered by (repository, path). When output exceeds 2000 files, the table displays the first 2000 matches alongside a truncation notice stating the exact total when known, or an explicit lower bound when the scan stopped early. When nothing matches the prefix, returns 'No indexed files matched the given path'.
Parameter guidance: 'path' is optional. PREFERRED: a repo-relative directory prefix (e.g. 'src/api') matched on a path boundary, or a glob ('src/**/*_test.rs'). Prefixes and globs page all indexed files in pages with per-page boundary filtering without dropping candidates. Absolute paths under the local checkout are accepted and normalized like 'explore_file'. Omit to list every indexed file (capped; the reply notes truncation).
Parameter guidance: 'repo_name' scopes the listing. Accepts a single repository name or a comma-separated list; include it when several indexed repositories may share path shapes.
Supports all languages indexed by knot.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional repo-relative directory prefix (e.g. 'src/api', matched on a path boundary) or glob pattern (segments: `*` segment wildcard, `**` any depth, `?` one char). Absolute paths under the local checkout are accepted and normalized like 'explore_file'. Omit to list every indexed file. | |
| repo_name | No | Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. Include it when several indexed repositories may share path shapes. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive, but the description adds behavioral details beyond hints: deterministic ordering by (repository, path), a 2000-file cap with a truncation notice showing exact or lower-bound totals, and the exact empty-result string. There is no contradiction with the annotations.
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 long but deliberately sectioned (Usage, Behaviour & Return, Parameter guidance) and front-loaded with its core purpose. Some prose repeats annotation facts and schema descriptions, so it is not maximally tight, but the structure keeps the extra length navigable and each section earns its place.
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 two-parameter read-only listing tool, the description covers intended use, chaining with siblings, exact return columns and order, truncation behavior, empty-match response, and both parameter semantics. Since there is no output schema, explicitly documenting the return format and edge cases is valuable and fully handled.
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 baseline is 3, but the description goes well beyond schema text: it explains path-boundary prefix matching, glob semantics, paging behavior ('per-page boundary filtering without dropping candidates'), absolute-path normalization, and when repo_name is needed (shared path shapes across repositories). This materially improves call construction.
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 first sentence states a specific verb ('listing'), a specific resource ('files an indexed repository carries'), and two distinguishing outputs (entity counts, deterministic order). It explicitly distinguishes its contribution from search_hybrid_context and explore_file, so it cannot be confused with siblings.
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 'Usage' section states concretely when to use it ('BEFORE search_hybrid_context when you do not know the codebase layout'), how to chain it with that sibling, and an explicit negative instruction ('Do NOT use this to enumerate entities — use explore_file'). This is explicit, actionable routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_repo_dependenciesList cross-repository dependenciesARead-onlyIdempotent
Read-only cross-repository dependency graph lookup. Shows which repositories depend on each other via build system declarations (Maven, Gradle, Cargo, npm, NuGet). Answers 'which repos does this repo depend on?' and 'which repos depend on this repo?'.
Usage: Use BEFORE cross-repo analysis to discover which other indexed repos are available for call tracing. Use reverse mode for impact analysis before making breaking changes in shared libraries.
Behaviour & Return: Read-only graph traversal with no side effects. Returns a JSON array of repository names. Empty results mean no DEPENDS_ON relationships exist for that repo. Empty lookups are explained in the response text with a three-way classification: declares-but-resolves-without-edge (stale graph, re-index hint), declares-but-nothing-resolves (not indexed), or nothing declared; the reverse direction names consumers that declare the repo without an edge yet.
Parameter guidance: 'repo_name' is required and must match the name used during indexing. 'max_depth' defaults to 3 (1 = direct only) and applies to both directions — in reverse mode it follows dependents transitively. 'reverse' toggles between forward and reverse dependency lookup.
Supports all build systems indexed by knot: Maven, Gradle, Cargo, npm, NuGet (.csproj + Central Package Management via Directory.Packages.props). C# repos that previously reported build_system: "none" now report "nuget" on re-index; knot-indexer --clean is recommended for immediate effect.
| Name | Required | Description | Default |
|---|---|---|---|
| reverse | No | If true, show repositories that depend ON this repo (reverse lookup). If false (default), show repositories this repo depends ON. Use reverse for impact analysis before breaking changes. | |
| max_depth | No | Maximum depth for transitive dependency traversal (default: 3, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively. | |
| repo_name | Yes | Repository name to show dependencies for. Must match the name used during indexing (e.g., 'my-java-repo', 'auth-service'). This is REQUIRED — there is no default. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing that it is a side-effect-free graph traversal, specifying the JSON array return type, and explaining empty result semantics with a three-way classification including stale-graph and not-indexed cases. This is rich, actionable behavioral detail.
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 long but exceptionally well structured with labeled paragraphs for usage, behavior, return values, parameter guidance, and supported build systems. Every sentence carries actionable information and is front-loaded with the core purpose before caveats.
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 there is no output schema, the description fully compensates by explaining return shape, empty-result semantics, direction behavior, depth semantics, and supported build systems. For a 3-parameter tool with rich annotations, nothing essential is missing.
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 mostly restates the schema's parameter guidance (repo_name required, max_depth default/applies to both directions, reverse toggling) rather than adding entirely new meaning, though it does usefully summarize the key constraints in one place.
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 states a specific verb ('lookup') and precise resource ('cross-repository dependency graph'), and explicitly frames the two questions it answers: which repos does this repo depend on and which depend on it. This clearly distinguishes it from sibling tools like list_repositories and find_callers.
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?
Explicit usage guidance is provided: use before cross-repo analysis for call tracing, and use reverse mode for impact analysis before breaking changes. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_repositoriesList indexed repositoriesARead-onlyIdempotent
Read-only listing of all indexed repositories with optional name filtering. Shows repository metadata including entity count, file count, build system, and primary language. Answers 'what codebases have I indexed?' and 'which repositories match this name?'.
Usage: Use this tool FIRST to discover available codebases before searching or exploring. Once you know the repository name, switch to 'search_hybrid_context' for semantic search, 'find_callers' for reverse dependency lookup, 'explore_file' for file anatomy, or 'list_repo_dependencies' for cross-repo dependency graphs. Do NOT use this tool to search for code entities — use 'search_hybrid_context' instead.
Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: REPO, BUILD SYSTEM, LANGUAGE, FILES, ENTITIES. When no repositories match the filter, returns 'No repositories found.'
Parameter guidance: 'filter' is optional. When provided, only repositories whose name contains the filter string are returned (case-insensitive substring match). Omit to list all indexed repositories.
Supports all languages and build systems indexed by knot.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional filter to narrow down repositories by name (case-insensitive substring match). When provided, only repositories whose name contains this string are returned. Examples: 'auth' matches 'auth-service' and 'Auth-Lib', 'api' matches 'my-api'. Omit to list all indexed repositories. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the return is a Markdown table with named columns, and the no-match case returns 'No repositories found.' That extra disclosure is valuable since there is no output schema, though permission/indexing prerequisites are not addressed.
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?
Front-loaded with purpose, then clearly sectioned into Usage, Behaviour & Return, and Parameter guidance. Slightly longer than necessary because the filter semantics and read-only nature repeat structured fields, but every section is scannable and earns its place.
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?
With no output schema, the description supplies the return shape and empty-result behavior; with four sibling tools, it routes the agent to the correct alternative; with one fully-documented param, nothing else is needed. Complete for a low-complexity read 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?
Schema description coverage is 100% and the single 'filter' param is fully documented in the schema (substring, case-insensitive, examples, optional). The description restates the same semantics rather than adding new meaning, so the 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?
States a specific verb+resource ('Read-only listing of all indexed repositories') plus the metadata surfaced and the questions it answers. An agent can distinguish it from search_hybrid_context, find_callers, explore_file, and list_repo_dependencies without opening any schema.
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?
Explicitly says to use this tool FIRST to discover codebases, names the exact sibling to switch to for each follow-up intent, and includes an explicit 'Do NOT use this tool to search for code entities' exclusion. Full when/when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hybrid_contextHybrid semantic + structural searchARead-onlyIdempotent
Read-only semantic and structural code search combining vector embeddings with graph analysis. Use this for initial codebase discovery to find features by their meaning (e.g., 'user authentication'). Locates code based on natural language descriptions instead of exact keywords, returning relevant files, signatures, and documentation.
⚠️ PREREQUISITE: This tool requires an active knot-mcp server with vector database (Qdrant) and graph database (Neo4j) initialized.
Behavior & Return: Performs a read-only dual query against vector DB (for semantic similarity) and graph DB (for architectural relationships). Returns Markdown-formatted results with file paths, line numbers, code snippets, and cross-repository dependencies. No side effects.
Usage: Use as your FIRST step when exploring unfamiliar code or discovering architectural patterns. Do NOT use this to find all usages of a specific function—use the 'find_callers' tool for that instead.
Ranking contract: results are kind-aware — function/method/class/struct definitions outrank markdown docs, test files, config properties and build-dependency entities for natural-language queries; callers and helpers appear as context attached to a definition, never as substitutes. The shared entry point of the highest-ranked helpers outranks those helpers a loose paraphrase surfaces.
Generic-verb guard: an entity merely named after a generic verb or noun (find/get/create/build/acquire/borrow/current/…) does not win on that name alone; the full name boost is paid only when the entity's container context (FQN) corroborates a second query token.
Recall contract: entity embeds carry identifier tokens and the tokenized call names of the entity's body, so a paraphrase of what a definition does (even one with no doc comment) still surfaces it. Entities whose identifier shares a word with the query enter the candidate pool by token match alone.
Result bound: 'max_results' is 1-100 (default 5) and is enforced — a larger request is clamped to 100 and the reply says so. There is no pagination: when the bound is not enough, narrow the scope with 'kinds' / 'path' / 'repo_name' or refine the query rather than raising the limit.
Parameter guidance: 'query' should be 2-5 words describing functionality. Increase 'max_results' to 10-20 for broad discovery, keep at 5 for focused search. Include 'repo_name' in your first query to avoid cross-repository pollution.
Supports Java, Kotlin, C#, and TypeScript codebases.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional path filter. A repo-relative directory prefix ('src/api', matched on a path boundary so 'src/api-notes.md' never matches) or a glob ('src/**/*_test.rs'). Use 'list_files' first when you do not know the layout. Omit to search every file. | |
| kinds | No | Optional entity-kind filter. Accepts exact wire-format kinds (`'rust_function'`, `'markdown_section'`, `'kotlin_class'`, …) or aliases: `'definition'` (all functions/methods/types), `'callable'`/`'function'`/`'method'` (all callable kinds), `'class'`/`'type'`/`'struct'` (all type kinds). Comma-separate for multiple values. Omit to search all kinds. | |
| query | Yes | Search query describing what you're looking for (e.g., 'user authentication', 'API error handling') | |
| repo_name | No | Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories. | |
| max_results | No | Maximum number of results to return (default: 5, max: 100). Requests above 100 are clamped to 100 and the reply says so — there is no cursor or pagination; to look past the bound, narrow the search with 'kinds' / 'path' / 'repo_name' or refine the query. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, but the description adds substantial context: no side effects, clamping behavior on max_results, absence of pagination, ranking kind-awareness, recall contract, and the prerequisite server/database setup. This goes far beyond what annotations convey and is consistent with them.
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 comprehensive but quite lengthy, with many distinct sections (prerequisite, behavior, usage, ranking contract, recall contract, result bound, parameter guidance, supported languages). While each section earns its place for a complex tool, the overall length dilutes focus. It is well-structured with headers and emoji but could be tightened without losing critical information.
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 hybrid search tool with no output schema, the description covers prerequisites, return format, ranking, recall, result bounds, parameter tuning, and language support. The agent has everything needed to invoke it correctly and interpret results, including explicit exclusions (no pagination, clamp behavior).
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, but the description adds practical guidance beyond the schema: recommends 2-5 word queries, suggests max_results ranges for broad vs focused discovery, and explains path boundary matching and glob usage. This meaningfully supplements the 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 clearly states it is a read-only semantic and structural code search combining vector embeddings with graph analysis, and explicitly contrasts itself with find_callers for usage-of-a-function. The verb+resource+method is specific and unambiguous.
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?
Explicitly tells the agent to use this as the first step for unfamiliar code or architectural discovery, and gives a concrete 'do NOT use' with the alternative tool (find_callers). Also includes parameter guidance (query length, max_results values, repo_name) and a ranking contract that governs result interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.11.1- Changed
explore_file1 field changed- added
Input schema / properties / include_markupAdded value: +{ + "description": "Optional: set to true to list all attribute-usage markup tokens (html_class, html_id) in full rather than in a compact summary. Defaults to false.", + "type": [ + "boolean", + "null" + ] +}
4 tool updates
v1.9.6- Changed
find_callers2 fields changed- added
Input schema / properties / kindsAdded value: +{ + "description": "Optional entity-kind scope for target resolution. Omit for the default code-only scope (docs/config/build metadata are hidden from the target list and the response discloses them). Use 'all' (or '*') to disable filtering, or a comma-separated allow-list of exact kinds or aliases ('callable', 'class', 'config', 'docs', 'rust_function', 'build_dependency', ...).", + "maxLength": 1024, + "minLength": 1, + "type": [ + "string", + "null" + ] +} - added
Input schema / properties / max_targetsAdded value: +{ + "default": 25, + "description": "Maximum number of resolved targets to include (default: 25, max: 500). Raise this when the response reports a truncated target list and you need the complete impact set.", + "maximum": 500, + "minimum": 1, + "type": [ + "integer", + "null" + ] +}
- Added
list_files - Changed
list_repo_dependencies1 field changed- changed
Input schema / properties / max_depth / descriptionPrevious value: -"Maximum depth for transitive dependency traversal (default: 3). Use 1 for direct dependencies only. Higher values follow chains deeper. Must be between 1 and 10."New value: +"Maximum depth for transitive dependency traversal (default: 3, max: 10). Use 1 for direct dependencies only. Requests above 10 are clamped to 10 (and below 1 to 1). Applies to both directions: with reverse=true it follows dependents transitively."
- Changed
search_hybrid_context4 fields changed- added
Input schema / properties / kindsAdded value: +{ + "description": "Optional entity-kind filter. Accepts exact wire-format kinds (`'rust_function'`, `'markdown_section'`, `'kotlin_class'`, …) or aliases: `'definition'` (all functions/methods/types), `'callable'`/`'function'`/`'method'` (all callable kinds), `'class'`/`'type'`/`'struct'` (all type kinds). Comma-separate for multiple values. Omit to search all kinds.", + "maxLength": 255, + "minLength": 1, + "type": [ + "string", + "null" + ] +} - changed
Input schema / properties / max_results / descriptionPrevious value: -"Maximum number of results to return (default: 5)"New value: +"Maximum number of results to return (default: 5, max: 100). Requests above 100 are clamped to 100 and the reply says so — there is no cursor or pagination; to look past the bound, narrow the search with 'kinds' / 'path' / 'repo_name' or refine the query." - changed
Input schema / properties / max_results / maximumPrevious value: -20New value: +100 - added
Input schema / properties / pathAdded value: +{ + "description": "Optional path filter. A repo-relative directory prefix ('src/api', matched on a path boundary so 'src/api-notes.md' never matches) or a glob ('src/**/*_test.rs'). Use 'list_files' first when you do not know the layout. Omit to search every file.", + "maxLength": 500, + "minLength": 1, + "type": [ + "string", + "null" + ] +}
5 tool updates
v1.9.4- Changed
explore_file1 field changed- changed
Input schema / properties / repo_name / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
find_callers1 field changed- changed
Input schema / properties / repo_name / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
list_repo_dependencies2 fields changed- changed
Input schema / properties / max_depth / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Input schema / properties / reverse / typePrevious value: -"boolean"New value: +[ + "boolean", + "null" +]
- Changed
list_repositories1 field changed- changed
Input schema / properties / filter / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
search_hybrid_context2 fields changed- changed
Input schema / properties / max_results / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Input schema / properties / repo_name / typePrevious value: -"string"New value: +[ + "string", + "null" +]
3 tool updates
v1.8.1- Changed
explore_file1 field changed- changed
Input schema / properties / repo_name / descriptionPrevious value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
- Changed
find_callers1 field changed- changed
Input schema / properties / repo_name / descriptionPrevious value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
- Changed
search_hybrid_context1 field changed- changed
Input schema / properties / repo_name / descriptionPrevious value: -"Optional but HIGHLY RECOMMENDED: repository name to filter results to a specific codebase (e.g., 'my-java-repo'). If you know the repository you are working on, include this in your FIRST query to avoid mixed results from other indexed projects. Omit only to search across all repositories."New value: +"Optional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository. If you know the repository you are working on, include it in your FIRST query to avoid mixed results from other indexed projects. Omit to search across all repositories."
1 tool update
v1.5.1- Changed
explore_file1 field changed- changed
Input schema / properties / file_path / descriptionPrevious value: -"Absolute path to the source file to explore"New value: +"Path to the source file to explore. PREFERRED: a repo-relative path (e.g. 'src/services/user.ts'). ALSO ACCEPTED: an absolute path under the repository's local checkout (the tool strips KNOT_REPO_PATH / CWD automatically)."
1 tool update
v1.4.11- Added
list_repositories
4 tool updates
v1.4.0- Added
explore_file - Added
find_callers - Added
list_repo_dependencies - Added
search_hybrid_context
4 tool updates
v1.3.8- Removed
explore_file - Removed
find_callers - Removed
list_repo_dependencies - Removed
search_hybrid_context
TDQS
Scored across 6 tools
Each tool targets a distinct stage of codebase exploration: repository discovery, file listing, file anatomy, semantic search, reverse call lookup, and cross-repository dependency inspection. The descriptions explicitly define boundaries and warn against using one tool for another's job, leaving little room for misselection.
All tools use snake_case and mostly follow a verb_noun pattern such as list_files, find_callers, and explore_file. Minor deviations exist: list_repositories and list_repo_dependencies use different forms of 'repository', and search_hybrid_context is verb_adjective_noun rather than strictly verb_noun.
Six tools is well-scoped for a read-only code intelligence server. Each tool has a clear, non-redundant role in discovery, inspection, search, or dependency analysis.
The surface covers repository discovery, file listing, file anatomy, semantic search, reverse callers, and cross-repo build dependencies. Some useful gaps remain, such as forward callee lookup, exact symbol search, or direct source/entity retrieval, though agents can partially work around these via search_hybrid_context and explore_file.
Maintenance
Related MCP Connectors
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Related MCP Servers
- AlicenseBqualityDmaintenanceA complete MCP server for Retrieval-Augmented Generation with file management and vector memory for agents. Supports multiple document formats (PDF, DOCX, TXT, MD, CSV, JSON) with semantic search using Hugging Face embeddings and ChromaDB for efficient vector storage.115 npm1MIT
- AlicenseNot gradedqualityNot gradedmaintenanceTurns Claude Desktop into a personal document question-answering system using local vector search. Index PDF, TXT, and Markdown documents into collections and get answers based strictly on your documents with zero hallucination.5 npm-
- AlicenseNot gradedqualityCmaintenanceA graph-powered code intelligence engine that indexes codebases into a structural knowledge graph to provide AI agents with deep context on function calls, types, and execution flows. It offers local, zero-dependency tools for hybrid search, impact analysis, and dead code detection across Python, JavaScript, and TypeScript projects.814MIT
- FlicenseNot gradedqualityDmaintenanceA minimalist indexing tool that provides AI agents with semantic search and structural AST parsing for deep codebase understanding. It enables autonomous agents to navigate large codebases predictably using vector embeddings and native language server capabilities like definition and reference tracking.-