echocache
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ECHOCACHE_DB_PATH | No | SQLite file location | ~/.echocache/cache.db |
| ECHOCACHE_MAX_BYTES | No | LRU ceiling on retained response bytes | 268435456 |
| ECHOCACHE_MAX_ENTRIES | No | LRU ceiling on retained entries | 10000 |
| ECHOCACHE_ENCRYPTION_KEY | No | 64 hex chars (32 bytes); enables AES-256-GCM at rest | |
| ECHOCACHE_DEFAULT_TTL_SECONDS | No | Freshness lifetime when a caller omits one | 86400 |
| ECHOCACHE_LINK_CANDIDATE_POOL | No | Recent entries a new write is compared against | 500 |
| ECHOCACHE_SIMILARITY_THRESHOLD | No | Similarity floor for auto-linking entries | 0.25 |
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 |
|---|---|
| cache_getA | Look up a cached LLM response by exact (model, prompt, params) match, like an HTTP cache checking a request against its cache key. Call this BEFORE issuing an expensive prompt to a model. Returns hit:false on a miss or an expired entry — in that case, run the prompt yourself and store the result with cache_set. On a hit, freshness mirrors HTTP semantics: fresh means use it as-is; stale means it is past its TTL but within its stale-while-revalidate window, so you may still use it but consider refreshing it. |
| cache_setA | Store a prompt/response pair in the cache. Call this AFTER getting a fresh response from a model that cache_get did not have. New entries are automatically linked in a similarity graph to existing entries with related content, so cache_related and cache_query can surface them later even without an exact key match. Pass derived_from with parent entry ids if this result was built from other cached entries — invalidating a parent with cascade can then clean up anything derived from it. |
| cache_queryA | Semantic search across all cached entries, independent of exact key matching. Use this when you suspect something related was already computed even though the prompt wording differs — the knowledge-graph equivalent of a cache lookup by meaning instead of by exact key. |
| cache_relatedA | Traverse the cache graph outward from one entry to find connected entries — ones auto-linked for content similarity ("similar" edges) or explicitly declared as built on top of it ("derived-from" edges). Use this to pull in everything already known that connects to a given cached result. |
| cache_invalidateA | Delete a cache entry, e.g. because the underlying source it was based on changed. With cascade:true, also deletes every entry that declared this one as a derived_from parent, and recursively theirs — dependency-graph invalidation instead of a manual hunt for stale copies. |
| cache_statsA | Cache analytics: entry/edge counts, exact-match hit rate, queryHits/queryMisses for semantic recall, and tokensServed — the token count handed back from cache. Note that tokensServed equals tokens saved only for entries that stand in for work which would otherwise be regenerated; serving a cached file read costs the same tokens as re-reading the file, so it saves nothing. |
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 6 tools
Each tool targets a clearly distinct operation: exact-match lookup, storing new entries, semantic search, graph traversal, invalidation, and analytics. Even though cache_query and cache_related both deal with connected content, the descriptions make their different access patterns unambiguous.
All tools share a consistent cache_ prefix and mostly use a verb as the second element: get, set, query, invalidate, stats. cache_related is the one outlier since 'related' is not a verb, but the overall pattern is still highly predictable.
Six tools is well-scoped for a cache server: read, write, semantic access, graph traversal, invalidation, and statistics. Each tool earns its place without redundancy or bloat.
The cache lifecycle is well covered: exact lookup, storage with derived-from tracking, semantic retrieval, related-entry traversal, invalidation with cascade, and stats. Minor gaps like bulk clearing or listing all entries could be useful but are not essential for the stated purpose.