Bismut Vector MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BISMUT_API_KEY | No | API key for a cloud (OpenAI-compatible) embedding endpoint | |
| BISMUT_DB_PATH | No | SQLite database file | ./.bismut/vectors.db |
| BISMUT_API_BASE | No | Base URL for an OpenAI-compatible embedding endpoint (Ollama, LM Studio, vLLM) | https://api.openai.com/v1 |
| BISMUT_CACHE_DIR | No | Model download cache directory | <db dir>/cache |
| BISMUT_LOG_LEVEL | No | Log level: silent, error, warn, info, debug, or trace | info |
| BISMUT_BATCH_SIZE | No | Embeddings per forward pass | 16 |
| BISMUT_COLLECTION | No | Default collection name | default |
| BISMUT_EMBED_DTYPE | No | Embedding dtype: q8, fp16, fp32, or quantized | q8 |
| BISMUT_EMBED_MODEL | No | Any transformers.js model | Xenova/paraphrase-multilingual-MiniLM-L12-v2 |
| BISMUT_CHUNK_TOKENS | No | Target chunk size | 320 |
| BISMUT_EMBED_DEVICE | No | Embedding device: cpu, gpu, or auto | cpu |
| BISMUT_CHUNK_OVERLAP | No | Overlap between chunks | 60 |
| BISMUT_EMBED_PROVIDER | No | Embedding provider: local or openai | local |
| BISMUT_MAX_FILE_BYTES | No | Skip files larger than this | 1048576 |
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 |
|---|---|
| index_pathsA | Index files or directories into a vector collection for semantic search. Safe to re-run: files whose content hash is unchanged are skipped. Honors .gitignore, skips binaries/oversized files, and uses language-aware chunking (markdown sections, code symbols, prose paragraphs). |
| index_textA | Index arbitrary text (notes, snippets, memory entries, error logs, user-provided context) into a collection. Use a stable |
| searchA | Run a semantic similarity query against indexed content. Returns ranked chunks with file path, line range, score (cosine similarity, 1 = identical), and text. Supports narrowing by path prefix, exact path, language, and content kind. Increase |
| get_contextA | Return contiguous chunks around a search hit (by chunk_id or document_id + ordinal) so you can read a whole function/section instead of an isolated fragment. Use after |
| list_sourcesA | List documents already indexed in a collection, with chunk counts and sizes. Use to check what is available before searching, or to confirm an index_paths run covered what you expected. |
| list_collectionsA | List all vector collections with their embedding model, dimensionality, document/chunk counts, and on-disk size. |
| delete_sourcesA | Remove documents from a collection by document id, exact uri, or path prefix. Vectors and chunks are deleted together. This is irreversible and requires at least one selector. |
| drop_collectionA | Permanently delete an entire collection and all its vectors, chunks, and documents. Irreversible. Prefer delete_sources when removing only some documents. |
| statsA | Show database path, embedding model/provider, collection count, and totals. Useful for verifying the server is healthy and which model is active before diagnosing empty search results. |
| get_chunkA | Return the full untruncated text of one chunk by its id, with its document metadata. |
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
Most tools have clearly distinct roles (index_paths vs index_text differ by source type, and list_sources vs list_collections differ by resource). The only mild overlap is between get_context and get_chunk, which both retrieve fuller content, though their descriptions distinguish fragment-level vs surrounding-context use.
Nearly all names follow a verb_noun pattern (list_collections, index_paths, delete_sources, drop_collection, get_chunk). Minor deviations are the bare single-word tools `search` and `stats`, but the overall convention is readable and predictable.
Ten tools is well within the ideal range and each one maps to a distinct stage of the index/search/retrieve lifecycle. No tool feels redundant or superfluous.
The surface covers the full lifecycle: indexing (paths/text), discovery (collections/sources), search, context retrieval (get_context/get_chunk), and deletion (delete_sources/drop_collection) plus health via stats. The main gap is an explicit create_collection or metadata-update operation, but these are likely handled implicitly by indexing.