ctxvault
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| warmup_statusA | Check if the embedding model has finished initializing. Use this to verify warmup status before attempting queries or writes. |
| queryB | Search for relevant information in a CtxVault vault using semantic similarity. Use this when the user asks a question that might be answered by their personal knowledge base or documents. Returns the most relevant text chunks with their source files. |
| write_docB | Save new information or agent-generated content to a semantic vault for future retrieval. Use this only with semantic vaults, to persist important context, summaries, or notes that should be remembered across sessions. Supports .txt, .md, and .docx formats. |
| list_vaultsA | List all available vaults. Use this before querying or writing to discover which vaults exist and choose the right one. |
| list_docsA | List all indexed documents inside a specific vault. Use this to understand what knowledge is available before performing a search. |
| write_skillB | Create and store a new skill in a skill vault. Use this to persist procedural knowledge, instructions, or how-to guides that agents can retrieve and execute later. The skill will be indexed by name and description for fast lookup. Use this only with skill vaults. |
| list_skillsA | List all available skills inside a specific vault. Use this to understand what skills are available before trying to fetch one. |
| read_skillA | Read one skill from a skill vault: its name, description and full instructions. Use this after list_skills, once you know which procedure fits the task, and follow the instructions it returns. |
| write_episodeA | Record something that happened or something the user stated, in an episodic vault. Use this for facts with a lifetime — situations, preferences, relationships, plans — rather than for documents. Give the entities it is about so it can be looked up later, and a salience between 0 and 1 for how much it matters. |
| query_episodesA | Retrieve episodes from an episodic vault. By default only statements that still hold are returned. Filter by entity for 'everything about X', pass valid_at to ask what was true at a past moment, or known_at to ask what the vault had already learned by then. Query text is optional and ranks results; without it the newest come first. |
| invalidate_episodeA | Mark an episode as no longer true, without deleting it. Use this when something ends and nothing replaces it. If a corrected version exists instead, use supersede_episode so the two stay linked. |
| supersede_episodeA | Replace an episode with a corrected or updated version. The old statement is closed exactly where the new one begins and the two are linked, so the history of what changed stays readable. Entities and salience carry over from the old episode unless you pass new ones. Use this whenever new information contradicts something already recorded. |
| revise_episodeA | Restate an episode more precisely, when the world did not change but you can now say it better ('lives in Padova' -> 'lives in Padova, in the Arcella'). The revision opens where the original did and inherits its attestations and open disputes; the original stays in the history but is no longer what the vault states. Use supersede_episode instead when the world changed. |
| confirm_episodeA | Record that a statement already in the vault was asserted again. Use this when you hear something the vault already holds, instead of writing it a second time: the episode stays as it is and gains one attestation, so a fact heard once can be told from one heard many times. |
| dispute_episodesA | Record that two open statements cannot both hold, when you cannot tell which one is wrong. Neither is closed: both keep coming back from queries, each flagged with the other in disputed_with, so you can ask instead of assert. The dispute ends by itself when one side is invalidated or superseded. If you do know which one is wrong, use supersede_episode or invalidate_episode instead. |
| episode_historyA | Show every version of a statement, oldest first. Use this to explain why the vault believes something, or to see what an episode used to say before it was corrected. |
| list_entitiesA | List the entities an episodic vault knows about, with how many episodes mention each one. This is the vault's vocabulary: use it to find out what subjects exist before querying for them, to spot the name a person or thing is recorded under, or to see what has gone quiet. Unlike query_episodes it enumerates rather than ranks, so nothing is left out. By default only entities named by statements that still hold are listed; pass include_closed to see everything the vault ever recorded. |
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 17 tools
Tools split cleanly into three domains (document vaults, skill vaults, episodic memory) and the descriptions cross-reference each other explicitly, e.g. invalidate_episode points to supersede_episode and revise_episode distinguishes 'world changed' from 'said better'. The only residual overlap is between query/query_episodes/list_docs, which is mitigated but not eliminated by the doc-vs-episode framing.
Fourteen of seventeen tools follow a clean verb_noun snake_case pattern (list_vaults, write_doc, read_skill, supersede_episode, list_entities). The outliers — query, episode_history, warmup_status — are readable but break the verb-first convention.
Seventeen tools is slightly heavy but justified by covering three distinct storage modes (documents, skills, temporal episodes) plus warmup and entity enumeration. No tool looks redundant enough to remove; episode lifecycle tools each handle a genuinely different case.
Episodic memory is exceptionally complete (write, query, confirm, invalidate, supersede, revise, dispute, history), but the document and skill surfaces are write/list/read only — no update, delete, or move for docs or skills, and no create_vault despite list_vaults implying vault management. These gaps will cause dead ends for maintenance workflows.