nexus-mcp-ci
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEXUS_LOG_LEVEL | No | Logging level | INFO |
| NEXUS_LOG_FORMAT | No | Log format: text or json | text |
| NEXUS_SEARCH_MODE | No | Search mode: hybrid, vector, or bm25 | hybrid |
| NEXUS_STORAGE_DIR | No | Storage directory for indexes | .nexus |
| NEXUS_MAX_MEMORY_MB | No | Memory budget | 350 |
| NEXUS_CHUNK_MAX_CHARS | No | Max code snippet size per chunk | 4000 |
| NEXUS_EMBEDDING_MODEL | No | Embedding model (jina-code, bge-small-en) | jina-code |
| NEXUS_EMBEDDING_DEVICE | No | Device for embeddings: auto (CUDA > MPS > CPU), cuda, mps, cpu | auto |
| NEXUS_MAX_FILE_SIZE_MB | No | Skip files larger than this | 10 |
| NEXUS_FUSION_WEIGHT_BM25 | No | BM25 engine weight in RRF | 0.3 |
| NEXUS_FUSION_WEIGHT_GRAPH | No | Graph engine weight in RRF | 0.2 |
| NEXUS_FUSION_WEIGHT_VECTOR | No | Vector engine weight in RRF | 0.5 |
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Use at the start of a session, or when unsure if search results might be stale. Reports whether a codebase is indexed, index size/engine availability, memory usage, and a stale/staleness_warning pair if files changed since the last index (a background reindex is auto-triggered). |
| healthA | Use for liveness/readiness probes only (uptime, which engines are up)
— not for checking whether the index is fresh or complete; use |
| indexA | Use first on any new or changed codebase, before any other tool —
everything except |
| searchA | Use for any "where is/how does/find" code question — preferred over
Grep/Glob, and usually answerable from the returned code_snippet without
a follow-up Read. Falls back to live grep automatically when hybrid
results are sparse. Returns a non-null |
| find_symbolA | Use to look up a specific function/class/symbol by name — preferred over Grep since it returns the definition plus its call-graph relationships in one call. Set exact=False for fuzzy substring matching when unsure of the exact name. |
| graphA | Use to trace who calls a function (direction='callers'), what it calls (direction='callees'), or — with transitive=True — the full transitive blast radius of changing it. MUST use transitive=True before refactoring or editing a widely-shared symbol; grep can't show transitive impact. |
| analyzeA | Use for code review or quality assessment — preferred over manually
reading files to eyeball complexity, since it computes cyclomatic/
cognitive complexity, dependency analysis, code smells (long/complex
functions, large classes, dead code), and an overall quality score in
one call. Read-only; requires an index (see |
| explainA | Use for onboarding to an unfamiliar symbol — combines its call-graph relationships, related code found via semantic search, and quality metrics in one call, so Read is often unnecessary. Use verbosity='summary' for a quick look, 'full' when you need everything. |
| mapA | PREFERRED over Glob/ls/manual browsing for project understanding. Use 'summary' for a quick project orientation, 'architecture' for design/dependency structure, 'full' for both in one call. |
| memoryA | Persist and retrieve project context across sessions. Use action='store' to save a decision/note, action='search' to find memories by semantic similarity, action='delete' to clean up by ID, tags, or type. |
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 10 tools
Each tool has a clearly distinct responsibility: index/status/health manage the index lifecycle, map/search/find_symbol/graph/explain serve different code-comprehension needs, analyze covers quality, and memory handles persistent context. Even the potentially overlapping status/health pair is explicitly differentiated by freshness vs liveness.
Tool names are consistently lowercase and concise, mostly single imperative verbs. The pattern is slightly uneven because find_symbol uses verb_noun and memory is a noun rather than an action, but there are no mixed casing conventions or vague generic names.
Ten tools is well within the ideal scope for a code-intelligence server. Each tool covers a meaningful capability without redundancy, and the count feels neither thin nor bloated.
The set covers the full workflow of indexing, monitoring, searching, navigating, analyzing, explaining, and retaining project context. Minor gaps exist—there is no explicit unindex/forget tool or a way to list all indexed codebases—but core workflows have no dead ends.