Semantic Cache MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging verbosity (DEBUG, INFO, WARNING, ERROR) | INFO |
| EMBEDDING_MODEL | No | FastEmbed model for search/similarity | BAAI/bge-small-en-v1.5 |
| EMBEDDING_DEVICE | No | Embedding hardware: cpu, cuda (GPU), or auto (detect) | cpu |
| MAX_CONTENT_SIZE | No | Max bytes returned by read operations | 100000 |
| TOOL_OUTPUT_MODE | No | Response detail (compact, normal, debug) | compact |
| MAX_CACHE_ENTRIES | No | Max cache entries before LRU-K eviction | 10000 |
| SEMANTIC_CACHE_DIR | No | Override cache/database directory path | |
| TOOL_MAX_RESPONSE_TOKENS | No | Global response token cap (0 = disabled) | 0 |
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 |
|---|---|
| readA | Read a file, returning as few tokens as possible. For 2+ files, use The first read returns the file's full content plus a A file larger than For a large or unfamiliar file,
|
| read_imageA | Read an image file so the model can see it. Returns an MCP image block (base64 data + mime type) plus a small JSON
metadata sidecar ( The format is detected from the file's magic bytes, not its extension, so
a mis-named image still works and a non-image (e.g. text saved as |
| statsA | Report cache health, token savings, and runtime diagnostics. Returns storage occupancy (files, tokens, documents, DB size), session and lifetime token savings and cache hit rates, per-tool call counts, and process memory. Use it to measure or debug — not as a routine step in read/edit loops. Takes no arguments. |
| clearA | Empty the cache. Does not touch any project file. Removes every cached file entry and returns how many were dropped; the
next |
| deleteA | Delete one file or symlink and evict its cache entries. Use this for explicit single-path removal instead of shelling out. A
missing path is reported as status Statuses: |
| writeA | Create a file or replace its entire contents. Use this for new files or full rewrites; for localized changes prefer
A full write supplies the whole file, so the |
| editA | Edit one file by exact text replacement. Three modes:
Pass |
| edit_previewA | Show where Returns the match count, 1-based line numbers, and short snippets so you
can confirm an anchor is unique before calling |
| batch_editA | Apply many exact edits to one file in a single atomic call. Preferred over repeated
Prefer line-range entries when you already have line numbers from |
| searchA | Find cached files by keyword relevance (BM25 ranking). Searches only files already in the cache — index them first with |
| batch_readA | Read several files at once under a shared token budget. Cheaper than many single |
| warmA | Index files into the cache so Costs a few dozen tokens however many files it indexes: no content, no previews, no paths for the files that succeeded — just how many were indexed, how many were already current, and how many were not. Anything not indexed is counted in Use it before searching an unfamiliar tree, then |
| globA | List files matching a glob and show which are already cached. Use it to discover files and see what |
| grepA | Search cached file contents for an exact string or regex. Fast, exact, line-numbered matching over files already in the cache — it
does NOT touch disk, so index files first with Counts are complete unless the response says otherwise: if a cap stops the
scan, Each file's hits come back as A repeated group wrapping an unbounded quantifier ( |
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 14 tools
Tools are largely distinct: read vs batch_read (one vs many), edit vs batch_edit (one vs many), edit vs edit_preview (apply vs probe), search (BM25 concept) vs grep (exact/regex), read (text) vs read_image (images). The main soft spot is the discovery cluster (warm, glob, search, grep), which all deal with cached files, but the descriptions draw clear boundaries between indexing and searching.
Names are consistently snake_case and mostly verb-led (read, write, edit, delete, search, warm, grep, clear), with predictable batch_ and edit_preview qualifiers. Minor deviations are the noun-style names stats and glob, which break the verb pattern but remain readable and unambiguous.
14 tools sit comfortably in the well-scoped 3-15 range, and each earns its place by covering a distinct slice of file I/O plus cache management. No redundant or filler tools are present.
Core lifecycle is covered: create (write), read (read/batch_read), update (edit/batch_edit), delete, plus discovery (glob/grep/search/warm) and diagnostics (stats/clear). Gaps like directory creation, move/rename, and symlink operations are minor and workable, but agents needing those will hit dead ends.