VaultZero
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VZ_BASE_URL | Yes | Bare HTTPS origin of the VaultZero API. | |
| VZ_CREDENTIAL | Yes | Bearer credential. Secret. | |
| VZ_KEY_STORE_PATH | No | Path where payload keys persist. Without it keys live in memory and every memory becomes unreadable when the process exits. | |
| VZ_EMBEDDING_MODEL | No | Embedding model. Changing it changes the vectors and makes existing memories unsearchable. | |
| VZ_EMBEDDING_SPACE | No | Embedding space identifier. Changing it changes the vectors and makes existing memories unsearchable. | |
| VZ_PERMITTED_SCOPES | No | Comma-separated scopes this process may use. | preferences,work,financial,medical |
| VZ_SERVERLESS_TOKEN | No | Token for IAM-protected endpoints. | |
| VZ_EMBEDDING_API_KEY | No | Bearer token for the embeddings endpoint. Secret. | |
| VZ_RETENTION_CHOICES | No | Retention values offered to the model. Add forever only for a credential with a retention grant. | 30d,90d,365d |
| VZ_EMBEDDING_BASE_URL | No | OpenAI-compatible embeddings endpoint, ideally customer-controlled. Without it a hashing test provider is used, which gives no meaningful retrieval. | |
| VZ_EMBEDDING_REVISION | No | Embedding model revision. Changing it changes the vectors and makes existing memories unsearchable. | |
| VZ_EMBEDDING_PREPROCESSING | No | Embedding preprocessing setting. Changing it changes the vectors and makes existing memories unsearchable. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| remember_factC | Store a fact in encrypted memory under a permitted scope. |
| recall_contextC | Recall encrypted memories most similar to a query across permitted scopes. |
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 2 tools
The two tools have clearly distinct purposes: remember_fact is a write/store operation and recall_context is a similarity-based read/query operation. There is no realistic scenario in which an agent would confuse which one to call.
Both names follow a verb_noun pattern (remember_fact, recall_context) in snake_case, which is consistent and readable. The nouns differ in style (fact vs context) slightly muddying the symmetry, but the pattern holds.
Two tools is thin for a memory server; store and retrieve are the core pair, but a domain like this typically warrants at least a delete/forget operation. It is borderline rather than clearly wrong, since the surface is minimal by design.
The write/read pair covers the basic memory lifecycle, but there is no way to forget, update, or correct a stored fact, and no listing or scope-management operation. These are notable gaps that could cause dead ends when memories become stale or incorrect.