Reflex
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_locationsA | Cheapest way to find every place a pattern occurs. Prefer this over Glob-based path hunting and over Grep when you only need file + line numbers (no previews). Returns an array of Use this for: enumerating locations before deciding which files to Read; counting affected sites; listing all hits of a pattern without paying for previews. Supports Example: |
| count_occurrencesA | Count-only statistics for a pattern. Prefer this over piping Use this for: "how many times is X used?"; impact checks before refactoring; validating search scope. Returns Example: |
| search_codeA | Default code search across the whole codebase. Prefer this over Grep / Modes: full-text by default (definitions + usages); Result shape is columnar: Pagination: if |
| search_regexA | Regex code search across the whole codebase. Prefer this over Use this for patterns with special characters or regex operators: For simple alphanumeric patterns use
|
| search_astA | Structure-aware search using Tree-sitter AST patterns (S-expressions). ⚠️ SLOW: bypasses trigram optimization and scans the ENTIRE codebase (500ms-10s+). In 95% of cases, prefer Use this only when you must match code structure rather than text: "all async functions containing a Example patterns — Rust: |
| index_projectA | Rebuild or update the code search index. Call this whenever any Reflex search tool returns an "Index not found" or "stale" error — the retry will then succeed. Also call after large git operations (checkout, merge, rebase, pull), user file edits, or when results seem stale or missing. Incremental by default (only changed files re-indexed). Pass |
| get_dependenciesA | List every import (dependency) of a single file. Prefer this over grep-ing for Use this for: understanding file dependencies, analyzing import structure, finding what a file depends on. Path matching is fuzzy — exact paths, fragments, or bare filenames all work. Only static imports (string literals) are extracted; dynamic imports are filtered by design. On "Index not found" / "stale" error, call |
| get_dependentsA | Reverse dependency lookup — find every file that imports a given file. Prefer this over grep-based find-callers: Reflex answers from its pre-built reverse-import index in one call, which grep cannot replicate without scanning every file. Returns the list of importing file paths. Use this for: impact analysis before changing a module; finding consumers of a library; detecting file importance. Path matching is fuzzy — exact paths, fragments, or bare filenames all work. Only static imports (string literals) are considered; dynamic imports are filtered by design. On "Index not found" / "stale" error, call |
| get_transitive_depsA | Walk the transitive dependency tree of a file up to Use this for: understanding the full dependency chain, analyzing deep coupling, planning refactoring blast radius. Example: |
| find_hotspotsA | Rank files by how many other files import them (dependency hotspots). Prefer this over any grep-based "most-imported file" heuristic — Reflex answers from its pre-built dependency index in one call; grep cannot answer this without scanning every file. Use this for: finding critical-path files; identifying refactoring blast radius; ranking modules by coupling; architecture review. Returns Example: |
| find_circularA | Detect circular dependencies (cycles A → B → C → A) in the static import graph. Prefer this over manually grepping for import chains — Reflex does the cycle detection directly. Returns |
| find_unusedA | List files that no other file imports — orphan candidates for deletion. Prefer this over manual Glob + Grep cross-referencing — Reflex answers from the static import graph in one call. Returns |
| find_islandsA | Find disconnected components (islands) in the static import graph — groups of files that have no imports crossing group boundaries. Prefer this over manual Glob + Grep cluster analysis — Reflex computes the connected components directly. Returns |
| analyze_summaryA | One-call overview of codebase dependency health. Prefer this over running Example: |
| find_referencesA | Atomic symbol definition + every usage in one call. Prefer this over the two-step Grep-based find-all-callers pattern ( Use this for: "find all callers of X" (the most common agent refactoring task); impact analysis before changing a function or class; rename planning; dead-code detection before deleting a function. By default, matches inside string literals and comments are excluded (so test fixtures and doc comments don't drown out real call sites); pass |
| gather_contextA | One-shot codebase orientation: structure, file types, project type, frameworks, entry points, test layout, config files. Prefer this over Glob-based recon at session start — Reflex returns a single consolidated overview instead of multiple glob calls. By default (no parameters) all context types are gathered; pass individual flags ( Use this for: getting oriented in an unfamiliar codebase; locating entry points; confirming which frameworks/languages are in use. For finding where a specific symbol/pattern lives, use |
| check_index_statusA | Check whether the Reflex search index is fresh, stale, or missing — without running any search. Call this once at session start and before any bulk search/refactoring task; if Returns Example fresh: |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Each tool targets a distinct aspect of codebase analysis (search, dependency, structure, indexing) with clear differences. Overlaps between list_locations and search_code are well-explained, and all tools have unique purposes.
Tool names are mostly consistent with a verb_noun pattern (search_code, find_references, count_occurrences), though a few use different orders (gather_context, analyze_summary, check_index_status). Still readable and predictable.
17 tools is somewhat high for a typical server, but each serves a distinct, well-justified purpose in code analysis. The count feels appropriate for the comprehensive scope, though it borders on heavy.
The tool set covers text, regex, and AST search; dependency analysis; indexing; and project orientation. No critical gaps like missing update/delete/creation tools, but those are out of scope for analysis.