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
7 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, the VCL edges (uses backend/probe/acl, includes, imports vmod, declared-unused) and HTTP routes (ROUTES_TO: the endpoint serving a handler) — 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 establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial operational detail: precedence-based matching, default code-only target filtering, disclosure when non-code matches are hidden, relationship buckets, homonym grouping, truncation notices, and dynamic-dispatch handling. There is no contradiction with 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 front-loaded with purpose and usage, then structured into matching, return behavior, scope, coverage, truncation, and parameter guidance. It is very long and somewhat repetitive around short-query matching and relationship coverage, but most detail is relevant for a complex graph-query tool.
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 reverse dependency traversal, four parameters, and no output schema, the description is highly complete. It explains return grouping, file/line locations, repository attribution, homonym grouping, truncation behavior, and entity-kind filtering, leaving little an agent needs to infer before calling it.
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 still adds useful meaning beyond the schema, especially how `entity_name` can be an exact name or signature fragment and how partial truncation should prompt raising `max_targets`; however, much of the `kinds` and `repo_name` guidance overlaps with already-detailed schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: read-only reverse dependency lookup to find all code that references, calls, extends, or implements an entity. It explicitly distinguishes itself from search tools and names the sibling `search_hybrid_context`, so an agent can tell when this graph lookup is the right tool.
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?
It gives explicit use cases ('impact analysis before refactoring', 'detect dead code') and an explicit exclusion: 'Do NOT use this for semantic feature discovery—use search_hybrid_context instead.' The alternative is named, so usage routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_endpointsList HTTP endpointsARead-onlyIdempotent
Read-only catalogue of the HTTP endpoints the indexed repositories serve, each with the handler method it routes to. Answers 'which endpoints does this service expose?' and 'which handler serves GET /api/owners/42?'.
Coverage: Java and Kotlin handlers annotated for JAX-RS (class/method @Path + @GET/@POST/@PUT/@DELETE/@PATCH/@HEAD/@OPTIONS) or Spring MVC (class @RequestMapping + @GetMapping/@PostMapping/@PutMapping/@DeleteMapping/@PatchMapping or @RequestMapping(method = ...)). Paths join the class-level and method-level paths, resolve string constants declared in the same file, and drop path-variable patterns ('{id: [0-9]+}' → '{id}'); a part that cannot be resolved is shown as ''. Paths are relative to the application: the context path (server.servlet.context-path, @ApplicationPath) is deployment configuration and is not applied. 'ANY' marks a @RequestMapping without 'method'. Declarative HTTP clients (@FeignClient, @RegisterRestClient interfaces) are not endpoints.
Usage: Use this for API-surface questions; then run 'find_callers' on the handler FQN for its callers, or on an endpoint name ('GET /api/owners/{id}') for the handler it routes to. Every endpoint is also an 'http_endpoint' entity reachable from 'search_hybrid_context' and 'explore_file', and a handler's 'find_callers' lists the endpoints routing to it under 'HTTP routes'.
Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: Method, Path, Handler, Location, Repository, ordered by (repository, path, method). At most 1000 rows; the reply states when more matched. When nothing matches, returns 'No HTTP endpoints matched.'.
Parameter guidance: 'method' is optional and case-insensitive ('GET'); 'ANY' endpoints match every method. 'path' is optional and matches segment by segment as a prefix ('/api/owners' matches '/api/owners/{id}' but not '/api/ownership'); an endpoint's '{variable}' segment matches any concrete segment, so a concrete URL path finds its endpoint. 'repo_name' scopes the catalogue.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional path filter, matched segment by segment as a prefix (e.g. '/api/owners'). An endpoint's '{variable}' segment matches any concrete segment, so '/api/owners/42' finds 'GET /api/owners/{id}'. | |
| method | No | Optional HTTP method filter, case-insensitive (e.g. 'GET'). Endpoints mapped to every method ('ANY') always match. | |
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint, idempotentHint, and non-destructive, the description adds substantial behavioral context: supported frameworks, path normalization rules, context-path omission, 'ANY' semantics, exclusion of declarative clients, return table format, row limit of 1000, and the exact no-match message. This goes well beyond the structured 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 well-structured, front-loading purpose and usage before moving to coverage rules and return format. Each section earns its place given the complexity of path resolution and framework support; there is no filler.
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 fully specifies the return shape: a Markdown table with named columns, ordering, row cap, and fallback message. Combined with the coverage rules and usage guidance, an agent has everything needed to call the tool correctly and interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description's 'Parameter guidance' section largely restates the schema: method case-insensitivity and 'ANY' matching, path prefix and variable matching, and repo_name scoping. It adds marginal value but does not compensate for any coverage gap because there is none.
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?
State a specific verb and resource ('Read-only catalogue of the HTTP endpoints the indexed repositories serve') and immediately distinguish the tool from siblings by naming the questions it answers. The description also clarifies scope (Java/Kotlin handlers) and what is not included (declarative clients), so an agent can confidently select it over find_callers or search_hybrid_context.
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 'Use this for API-surface questions' and then names the next step: run 'find_callers' on the handler FQN or on an endpoint name. It also notes alternative access paths via 'http_endpoint' entities in search_hybrid_context and explore_file, giving clear when-to-use guidance and alternatives.
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.
Relationship summary: each result's 'Called by' / 'Called via dispatch' counts come from the graph edges of that exact entity — the same edges 'find_callers' reports for its fully qualified name; same-named entities elsewhere never contribute. 'Calls' lists callees qualified with their owning type or module, capped at 8 plus '+N more'. Callers in test code count toward the totals but are shown as 'N in tests' unless 'include_tests' is true; a sample in the result's own file reads 'name (same file)'.
Detail: 'detail: "brief"' renders one line per result (kind, file:line, caller/callee counts) to scan many hits cheaply; expand the one you need with 'find_callers' / 'explore_file' or a default 'full' search.
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') | |
| detail | No | Optional detail level: 'full' (default) renders file, FQN, signature, docs and relationship summaries; 'brief' renders one line per result (kind, file:line, caller/callee counts). Scan with 'brief', then expand the hit you need with find_callers / explore_file or a 'full' search. | |
| 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. | |
| include_tests | No | Optional: set to true to list callers and usages from test code in the samples. By default they are only counted ('N in tests'); the counts always include them. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is structured data and repeating 'No side effects' earns little. The description does add real value beyond annotations: the hard prerequisite of an active knot-mcp server with Qdrant and Neo4j, the enforced max_results clamp with an explicit 'no pagination' contract, and the ranking/recall behavior that explains why results are ordered as they are. Those are genuine disclosures, though the ranking contract and generic-verb guard drift into internal implementation detail an agent cannot act on.
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 correctly: purpose, then prerequisite, then behavior/return, then usage, then the long contract sections. But the body runs well past 400 words, and the 'Ranking contract', 'Generic-verb guard', and 'Recall contract' paragraphs are dense internals that no agent action depends on. Every sentence does not earn its place, even though the ordering is sound.
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 7-parameter discovery tool with no output schema, the description covers the missing pieces: what the Markdown result contains (file paths, line numbers, snippets, cross-repository dependencies), the 'Called by' / 'Calls' semantics, the 'N in tests' convention, and the no-pagination bound. Nothing an agent needs to call it or interpret its output is absent.
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; the description earns a step above by adding guidance the schema lacks, notably that 'query' should be 2-5 words describing functionality, that max_results should be raised to 10-20 for broad discovery but held at 5 for focused search, and that repo_name belongs in the first query to avoid cross-repository pollution. It does not re-describe path, kinds, or include_tests beyond what the schema already says, so it is additive rather than redundant.
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 and resource ('semantic and structural code search combining vector embeddings with graph analysis') and immediately names the sibling it is not ('Do NOT use this to find all usages of a specific function—use find_callers'). An agent can distinguish it from explore_file, list_files, and find_callers without opening a 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 prescribes 'Use as your FIRST step when exploring unfamiliar code', gives an exclusion routing to find_callers, and adds concrete tuning advice (2-5 word queries, max_results 10-20 for broad discovery, include repo_name on the first query, scan with 'brief' then expand). Both when-to-use and when-not-to-use are covered with named alternatives.
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.13.0- Changed
search_hybrid_context2 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "Optional detail level: 'full' (default) renders file, FQN, signature, docs and relationship summaries; 'brief' renders one line per result (kind, file:line, caller/callee counts). Scan with 'brief', then expand the hit you need with find_callers / explore_file or a 'full' search.", + "maxLength": 16, + "minLength": 1, + "type": [ + "string", + "null" + ] +} - added
Input schema / properties / include_testsAdded value: +{ + "description": "Optional: set to true to list callers and usages from test code in the samples. By default they are only counted ('N in tests'); the counts always include them.", + "type": [ + "boolean", + "null" + ] +}
1 tool update
v1.12.0- Added
list_endpoints
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
TDQS
Scored across 7 tools
Each tool targets a distinct resource or operation: repository listing, file listing, file anatomy, semantic search, reverse call lookup, endpoint catalogue, and cross-repo dependencies. The descriptions explicitly disambiguate close pairs such as search_hybrid_context vs find_callers and list_files vs explore_file. No two tools appear interchangeable.
All tool names use snake_case and begin with a verb, producing a predictable verb_noun pattern: search_*, explore_*, find_*, and list_* variants. The one slight outlier, search_hybrid_context, still follows the same convention and is readable alongside the rest.
Seven tools is well-scoped for a read-only code-intelligence server. The set covers discovery, structural inspection, call-graph lookup, API surface, and cross-repo dependency questions without redundant tools.
The surface covers the main read-only workflows: discovering repositories and files, inspecting file anatomy, searching semantically, tracing callers, listing endpoints, and mapping repo dependencies. There are minor gaps, such as no dedicated source-body retrieval or explicit forward-call/callee lookup, though these are partly addressed by search results and caller metadata.
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.117 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.7 npm-
- AlicenseNot gradedqualityDmaintenanceA 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.1,290 PyPI815MIT
- 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.-