RelayVault
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RELAYVAULT_HOME | No | Selects the RelayVault data directory. All clients that need to share a vault must use the same home and salt. | ~/.relayvault |
| RELAYVAULT_SALT | No | Custom salt used by RelayVault. All clients that need to share a vault must use the same home and salt, and changing the salt prevents rehydration. | |
| RELAYVAULT_ALLOW_AGENT_REHYDRATE | No | Set to 1 to enable MCP rehydration, giving that MCP client access to plaintext secrets. MCP rehydration is off by default and should only be enabled for fully trusted clients. |
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 |
|---|---|
| relayvault_commit_checkpointA | Save a deterministic, zero-trust task checkpoint before switching AI models or hitting a rate limit. Automatically scrubs API keys, credentials, emails, and private IPs into local <RV_VAULT:...> tokens. |
| relayvault_checkout_handoffB | Load the latest (or specific commit_hash) task state checkpoint from another AI model. Returns structured state plus a synthesized handoff prompt with redacted <RV_VAULT:...> tokens intact. |
| relayvault_list_historyC | List recent cross-model checkpoints and DAG lineage for a workspace. |
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 3 tools
Each tool maps to a distinct lifecycle action: write a checkpoint, read/restore one, and enumerate history. 'Commit checkpoint' vs 'checkout handoff' could sound similar at a glance, but the descriptions make the write/read split unambiguous.
All three follow the same relayvault_ + verb_noun pattern (commit_checkpoint, checkout_handoff, list_history). The namespaced prefix is applied uniformly and verb choice is predictable.
Three tools is thin but matches the narrow save/load/list domain of a checkpoint vault. Every tool earns its place; nothing extraneous is present.
The core write/read/list cycle is covered, but there is no delete/expire operation for stale checkpoints and no way to inspect or rehydrate the redacted placeholder tokens. Agents can work around these gaps, but lifecycle coverage is only partial.