reposynapse
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REPOSYNAPSE_ROOT | No | Project root override | process.cwd() |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_project_contextA | Call FIRST. Returns project context. Use section param for specific info. |
| annotateB | Add/remove/list project annotations (business rules, gotchas, warnings). |
| read_fileA | Smart reader. <200L: full content. >200L: outline. Optional line range. |
| read_file_outlineB | File outline: symbols with line ranges (~100 tokens). Use depth=1 for top-level only (~80t vs ~450t on complex files). |
| read_file_symbolA | Read function/class by name. Fuzzy matching supported. |
| search_in_fileC | Search pattern in file. Regex supported. |
| search_in_projectA | Search across all project files. Default: 1-line compact output — total matches, file count, top 10 hottest files. Use max_files=N for code detail on N files. Use max_files=-1 with file_pattern to get all matching files grouped and sorted (replaces grep). |
| list_filesB | List files/dirs. Respects .gitignore. |
| generate_project_docsA | Regenerate .reposynapse/ docs. Usually automatic. |
| get_diagnosticsA | Run project diagnostics and return ONLY fatal errors. Auto-detects language (TypeScript, Rust, Go, Python, .NET, Java, Ruby, Swift, PHP) and runs the appropriate checker. Spelling errors and warnings are filtered out to save tokens. |
| search_symbolA | Search for a symbol (function, class, interface, type, const, enum) across project files. Returns file location, type, signature, and exported status. Supports fuzzy matching and regex (e.g. "get.*Context"). Use path_filter to limit search scope. Use context_filter to find symbols by return type or param type. |
| get_complexityA | List functions/methods above complexity thresholds (too many lines or params). Ultra-compact output to help prioritize what to refactor without reading every file. |
| patch_fileA | Apply a unified diff patch to a file. The AI only sends changed lines, not the full file — saves tokens on large files. |
| replace_symbolA | Replace the full body of a named function, class, or interface. The AI sends only the new implementation — no need to read the full file first. |
| insert_after_symbolB | Insert code immediately after a named function or class. Useful for adding a new method or helper next to a related one. |
| batch_renameA | Rename a symbol (word-boundary match) across all source files in the project. Returns a list of modified files and replacement count. |
| add_importA | Add an import statement to a file. Automatically checks for duplicates and inserts after the last existing import. |
| remove_dead_codeA | Find exported symbols that are never imported by any other file in the project. dry_run=true (default) reports only; dry_run=false deletes them. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| project-context | Injects project context into conversation. Use at start. |
| project-summary | Ultra-minimal project summary (~50 tokens) |
| file-reader-guide | Injects instructions for efficient file reading. Use for large files. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Project Summary | Ultra-compact project summary (~50 tokens). Embed this for instant context. |
| Full Project Context | Complete project analysis in compact format. |
| Tech Stack | Languages, frameworks, and dependencies. |
| Project Structure | Folder layout and entry points. |
| API Endpoints | REST/GraphQL endpoints if detected. |
| Data Models | Schemas, types, and interfaces. |
| Hot Files | Large/complex files that need special attention. |
| Project Annotations | Human-written business rules, gotchas, and warnings. |
| Import Graph | Internal dependency graph: hub files, orphan files. |
| Project Context (JSON) | Full context in JSON format for programmatic use. |
| File Outlines | All source file outlines: functions, classes, interfaces with line ranges. Use to navigate large files. |
TDQS
Scored across 18 tools
The tool families are mostly distinct: read_file* covers whole-file vs outline vs symbol access, search_* covers file/project/symbol scopes, and editing tools separate patch vs symbol replacement vs insertion. Minor overlap remains between search_in_project and search_symbol for locating definitions, and between patch_file and replace_symbol.
Most tools follow a clear verb_noun or verb_preposition_noun pattern, with consistent families such as read_file_outline/read_file_symbol and search_in_file/search_in_project. Small deviations like annotate, batch_rename, and search_symbol (without in_) do not seriously undermine the convention.
At 18 tools, the surface is slightly above the ideal 3-15 range, but the count is justified by the broad scope: context, annotations, reading, searching, diagnostics, complexity, patching, symbol refactoring, imports, and dead-code removal. A few tools could be consolidated, but none feels redundant enough to be a real problem.
The set covers the full read-edit-refactor workflow, including diagnostics after edits, symbol-aware operations, and dead-code detection. It lacks an explicit arbitrary file create/delete tool and import removal, but patch_file and the existing symbol tools cover most real workflows.