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 Use 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
Each tool targets a clearly distinct operation — read/batch_read split single vs. multi-file, edit/batch_edit split single vs. batch edits, search/grep split semantic vs. exact matching, and the descriptions explicitly cross-reference each other (e.g., 'for several edits use batch_edit'). The hash/cache protocol tools (warm, stats, clear, edit_preview) have non-overlapping roles.
Tool names mostly follow a verb or verb_object pattern with consistent snake_case (read_image, batch_read, edit_preview, batch_edit), and the batch_ prefix family is coherent. Minor deviations: 'stats' is a noun rather than verb_noun (e.g., get_stats), 'warm' is a bare verb without an object, and grep/glob are domain jargon rather than descriptive verb phrases.
14 tools sits at the upper edge of a well-scoped set, but the broader domain (file read/write/edit plus cache indexing, search, and administration) justifies the count. Each tool has a distinct job — warm/search/grep form an indexing pipeline, read/batch_read/read_image cover consumption, and stats/clear handle cache lifecycle — so nothing feels redundant.
The cache-aware file lifecycle is fully covered: read, write, edit, batch_edit, delete, plus discovery (glob), search (grep/search), indexing (warm), and diagnostics (stats). The content_hash/known_hash protocol creates a coherent multi-step workflow with no dead ends. Minor gaps: no move/rename and no directory operations beyond glob, though those appear deliberately out of scope for a cache-centric server.