codebaxing
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHROMADB_URL | No | ChromaDB server URL | http://localhost:8000 |
| GEMINI_API_KEY | No | Gemini API key (alternative to CODEBAXING_GEMINI_API_KEY) | |
| OPENAI_API_KEY | No | OpenAI API key (alternative to CODEBAXING_OPENAI_API_KEY) | |
| VOYAGE_API_KEY | No | Voyage API key (alternative to CODEBAXING_VOYAGE_API_KEY) | |
| CODEBAXING_DTYPE | No | Model quantization (local only): fp32, fp16, q8, q4 | q8 |
| CODEBAXING_DEVICE | No | Compute device (local only): cpu, cuda | cpu |
| CODEBAXING_WORKERS | No | Worker threads for parallel embedding (local only, 0=off) | 2 |
| CODEBAXING_MAX_CHUNKS | No | Max chunks to index | 500000 |
| CODEBAXING_MODEL_CACHE | No | Model cache directory (local only) | ~/.cache/codebaxing/models |
| CODEBAXING_MAX_FILE_SIZE | No | Max file size in MB | 1 |
| CODEBAXING_GEMINI_API_KEY | No | Gemini API key (or use GEMINI_API_KEY) | |
| CODEBAXING_OPENAI_API_KEY | No | OpenAI API key (or use OPENAI_API_KEY) | |
| CODEBAXING_VOYAGE_API_KEY | No | Voyage API key (or use VOYAGE_API_KEY) | |
| CODEBAXING_EMBEDDING_MODEL | No | Override embedding model name | |
| CODEBAXING_FILES_PER_BATCH | No | Files per batch (lower = less RAM) | 100 |
| CODEBAXING_PARALLEL_BATCHES | No | Concurrent batches | 3 |
| CODEBAXING_EMBEDDING_BASE_URL | No | Custom API endpoint for cloud providers | |
| CODEBAXING_EMBEDDING_PROVIDER | No | Embedding backend: local, gemini, openai, voyage | local |
| CODEBAXING_EMBEDDING_DIMENSIONS | No | Override embedding dimensions | |
| CODEBAXING_METADATA_SAVE_INTERVAL | No | Save progress every N batches | 10 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| indexA | Index a codebase for semantic search. REQUIRED FIRST STEP. Modes:
Creates a .codebaxing/ folder in the codebase directory. |
| searchA | Semantic search for code. Returns ranked code chunks with file paths and line numbers. Examples:
|
| statsB | Get statistics about the currently loaded codebase index. |
| languagesA | List all supported programming languages and file extensions. |
| cleanA | Clean all indexed data for a codebase. Deletes ChromaDB collection and .codebaxing/ data. Preserves user config (ignore.json). Use this to fix corrupted indexes or start fresh. |
| rememberB | Store a memory for later retrieval. Memory types: conversation, status, decision, preference, doc, note TTL options: session (24h), day, week, month, permanent (default) |
| recallA | Retrieve memories using semantic search. Filters: memory_type, tags, time_range (today, week, month, all) |
| forgetA | DESTRUCTIVE: Remove memories matching specified criteria. Delete by: memory_id, memory_type, tags, older_than (1d, 7d, 30d, 1y) |
| memory-statsA | Get statistics about stored memories for the current project. |
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 9 tools
Each tool has a distinct purpose: index, search, stats, languages, memory-stats, clean, remember, recall, forget. No overlapping or ambiguous tools; even stats and memory-stats are clearly scoped to different domains.
All tool names are single-word lowercase verbs or nouns that clearly indicate their action (e.g., index, search, remember, forget). This is consistent and predictable, though not verb_noun, the pattern is uniform and intuitive.
With 9 tools, the server is well-scoped, covering indexing, searching, memory management, and cleanup. Each tool is necessary for the core workflows, and the count is within the ideal range (3-15).
The toolset covers the full lifecycle: index creation/update, search, stats, memory CRUD (create, read, delete), and cleanup. A minor gap is the lack of a tool to list all memories or update a specific memory, but the core functionality is well covered.