Loading ToolBench
Local-first code intelligence MCP server: Tree-sitter + SCIP + SQLite + MCP
Synapse provides 27 well-named, read-only code intelligence tools with consistent verb_noun naming (find_*, get_*, search_*, list_*, detect_*, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present with type declarations and parameter descriptions. However, output schemas are not documented in the provided source, critical for LLM planning. Many descriptions lack actionable context (e.g., 'when to use this vs similar tools'). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Error handling and recovery guidance are absent. Parameter constraints (e.g., limit ranges, pattern validation) are mentioned in descriptions but not formalized in schema. The server is well-structured for code analysis but lacks production-grade LLM-facing polish.
Recursively expand incoming and outgoing call trees for a symbol. Returns a tree structure showing callers and callees.
Compute code metrics for files or symbols: complexity, size, coupling, cohesion.
Detect circular dependencies in the codebase. Returns cycles found in the call graph.
Explore a symbol from multiple angles: definition, references, outgoing calls, and incoming calls in one response.
Identify symbols that are defined but never referenced (dead code detection).
Find all files that import a given module or symbol.
List every incoming reference (call, import, extends, implements, generic reference) for symbols matching the given name. Use this to answer "who uses X?".
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., file paths, line numbers, symbol IDs) without knowing response structure.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). All 26 read-only tools lack explicit safety markers; reindex_file (write) lacks destructiveHint. LLMs cannot distinguish safe from risky operations.
Parameter constraints not formalized in schema. Descriptions mention 'default 25', 'default 50', 'default 100' but JSON Schema lacks minItems, maxItems, minimum, maximum. LLMs cannot validate before calling.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
Look up symbols (functions, classes, types, variables, ...) defined in the indexed repo by exact name. Returns file:line locations and signatures.
Return the primary definition location (and any alternative matches) for a symbol name. Use this when the model needs the canonical site of a name before reading code.
Read a source code slice with context lines. Specify file path and line range.
Return repo-wide aggregate counts: files, symbols, edges, and per-language breakdowns.
Show git blame information for a file or line range.
Show git commit history for a file or symbol.
Search for text patterns in source code using regex or literal string matching.
Combine keyword and semantic search for symbols. Blends lexical matching with embedding-based similarity.
Return indexing status: schema version, freshness, drift detection, and whether a reindex is in progress.
Return a list of all indexed files in the repository.
Return every symbol defined in a single file, with kinds and locations.
Return all outgoing edges (calls, imports, extends, implements) from a symbol.
Read offloaded symbol metadata (e.g. docstrings, signatures) from the database.
Atomically reindex a single file: parse it, extract symbols and edges, and update the database.
Scan the codebase for common security issues and anti-patterns.
Substring (or wildcard) search across indexed symbols with optional filters by kind, language, or file glob pattern. Returns matches ranked by relevance with a Levenshtein distance hint.
Search for symbols by semantic similarity using embeddings. Requires an embedding provider to be configured.
Search for code patterns using AST-based structural matching (via ast-grep).
Return the most referenced symbols in the codebase, ranked by incoming edge count.
Verify that a symbol exists and is correctly indexed. Returns detailed metadata about the symbol.
No error recovery guidance. Tools lack descriptions of failure modes (e.g., 'symbol not found', 'file not indexed', 'embedding service unavailable'). LLMs cannot self-correct or suggest alternatives.
Descriptions lack 'when to use' context. E.g., find_symbol vs search_symbols vs semantic_search are similar; descriptions do not explain which to call for exact match vs substring vs semantic intent. LLMs waste reasoning cycles.