Once kontxt is registered with your MCP client, these tools are available by name. Your host calls them automatically. Most users never invoke them manually.
Most MCP hosts follow the same loop:
- Your message provides a task.
- The host decides whether it needs context.
- The host calls
get_relevant_context with a query derived from your task.
- The host injects returned memories into the prompt as grounding context.
- During the conversation, the host may call
store_memory or summarization tools when it identifies durable information.
This means you should treat your vault like a source of stable facts, preferences, and decisions. You should not treat it as a raw transcript log.
Most tools use the same ideas:
query is a natural language string.limit controls how many results are returned.project scopes to a named project when provided.- Returned memories include an id. You can use that id for edit or delete workflows.
get_relevant_context
Semantic search over your vault. Returns the top-ranked memories for the active task.
When it’s called: At the start of most sessions, or when the host determines context would be useful.
Returns: An ordered list of memories ranked by relevance to the current task.
{
"tool": "get_relevant_context",
"input": {
"query": "auth implementation preferences",
"limit": 5
}
}
How to think about query
A good query is specific. It should name the topic and the intent.
Examples:
- “auth architecture decisions”
- “repo stack and conventions”
- “preferred formatting and tone”
search_memories
Search your vault with scores and stable IDs (useful for follow-up actions like edit/delete).
{
"tool": "search_memories",
"input": {
"query": "language preferences",
"limit": 20
}
}
list_memories
List vault contents, optionally filtered (for example by project).
{
"tool": "list_memories",
"input": {
"project": "4stax",
"limit": 50
}
}
Common uses
- You want to browse everything you have stored.
- You want to inspect a project scoped memory set.
- You want to find an id to delete or edit.
store_memory
Write a durable memory from the current conversation.
When it’s called: When you or the AI identifies something worth preserving, such as a decision, a preference, or a fact.
{
"tool": "store_memory",
"input": {
"content": "Uses JWT with 7-day expiry for API auth",
"type": "decision",
"importance": 0.9
}
}
Choosing a type
Use types consistently. Retrieval quality improves when types match intent.
Recommended mapping:
preference for stable personal preferences.fact for stable project facts and identity facts.project for ongoing context that is not a single fact.decision for decisions and tradeoffs.skill for capabilities and workflows.episodic for context you may want later but that is not permanent.
store_conversation_summary
Summarize and store a full thread as a single memory entry.
When it’s called: At the end of a long session to compress the context into something retrievable later.
{
"tool": "store_conversation_summary",
"input": {
"summary": "Designed the memory relevance scoring system. Decided on 4-signal ranking: semantic similarity, recency, frequency, importance.",
"session_id": "abc123"
}
}
When to use summaries
Use summaries when a session contains multiple decisions and stable facts, but storing each as a separate memory would be noisy.
Summaries are most useful for:
- Technical design sessions
- Project planning sessions
- Debugging sessions with a clear root cause
auto_capture
Like store_conversation_summary, but with stronger automatic typing/classification. Useful when you want passive “extract the durable bits” behavior.
auto_capture is opt-in and disabled by default. Enable it only if you want more passive capture.
Suggested workflow
If your host supports it, use auto capture near the end of a long session. It can extract multiple typed entries that are easier to retrieve later than a single long summary.
get_user_profile
Returns preferences and facts grouped for grounding. Used to establish who you are at the start of a session.
When it’s called: When the host needs a baseline context snapshot, typically on the first message.
Returns: A structured profile derived from your stored preferences and facts.
What belongs in a profile
Profiles are useful when they stay stable.
Good profile content:
- Your preferred language and formatting.
- Your default stack and tools.
- Stable constraints, such as “keep answers concise” or “prefer SQL migrations over ORM magic”.
delete_memory
Delete a memory by ID.
{
"tool": "delete_memory",
"input": {
"id": "mem_abc123"
}
}
Safety note
Deletion is permanent because the vault is local. If you need undo, back up your database file periodically.
| Tool | Status |
|---|
get_relevant_context | Available |
search_memories | Available |
list_memories | Available |
store_memory | Available |
store_conversation_summary | Available |
get_user_profile | Available |
auto_capture | Available. Opt in. |
delete_memory | Available |
Prompt resource: kontxt_context
Some hosts support prompt “resources” that are injected at session start. kontxt exposes a kontxt_context resource that provides top-ranked memories as grounding context.
If your host supports prompt resources, this is the simplest way to get “always on” grounding without manually requesting context. 
