How do I use kiro-total-recall?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kiro-total-recall find my preference about testing frameworks from past conversations" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kiro-total-recall

by danilop

Overview Schema Related Servers Score Discussions

Python

Local

Kiro Total Recall

Ever told Kiro "like we discussed yesterday" only to realize... it has no idea?

Total Recall gives Kiro the memory it's missing.

The Problem

Sessions Are Isolated: Each Kiro session starts fresh. Yesterday's architecture discussion? Gone.
Projects Don't Share Knowledge: Your preferences (testing style, package managers, patterns) aren't remembered across projects.
CLI and IDE Are Separate: Conversations in Kiro CLI don't connect to Kiro IDE.

Total Recall indexes every Kiro conversation and provides semantic search. Find discussions by meaning, not just keywords.

Related MCP server: claude-kb

Quickstart

As a Kiro Power (Recommended, IDE only)

In Kiro IDE: Powers panel → Add power from GitHub
Enter: https://github.com/danilop/kiro-total-recall
The power activates automatically when you mention "recall", "remember", or "past conversation"

Manual MCP Setup (CLI and IDE)

Add to ~/.kiro/settings/mcp.json (this config is shared by both CLI and IDE):

{
  "mcpServers": {
    "total-recall": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/danilop/kiro-total-recall", "kiro-total-recall"]
    }
  }
}

Restart Kiro CLI/IDE after adding. MCP servers are only loaded at startup.

Verify Installation

In Kiro CLI: /mcp should list total-recall

In Kiro IDE: Check the MCP Servers panel

How It Works

┌─────────────────────────────────────────────────────────────────────────┐
│                         Kiro CLI & IDE                                  │
│  ┌──────────────────────────┐    ┌──────────────────────────────────┐   │
│  │  CLI: SQLite DB          │    │  IDE: .chat JSON files           │   │
│  │  ~/Library/App Support/  │    │  ~/Library/App Support/Kiro/     │   │
│  │  kiro-cli/data.sqlite3   │    │  User/globalStorage/.../*.chat   │   │
│  └────────────┬─────────────┘    └─────────────┬────────────────────┘   │
│               └────────────────┬───────────────┘                        │
│                                ▼                                        │
│                    ┌───────────────────────┐                            │
│                    │   Unified Loader      │                            │
│                    └───────────┬───────────┘                            │
└────────────────────────────────┼────────────────────────────────────────┘
                                 ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                      Kiro Total Recall                                  │
│  ┌─────────┐    ┌──────────┐    ┌─────────┐    ┌────────────────────┐   │
│  │ loader  │───▶│ indexer  │───▶│  query  │───▶│  MCP server        │   │
│  │ CLI+IDE │    │ 384-dim  │    │ cosine  │    │  4 search tools    │   │
│  └─────────┘    └────┬─────┘    └─────────┘    └────────────────────┘   │
│                      ▼                                                  │
│         ~/.cache/kiro-total-recall/embeddings.pkl                       │
└─────────────────────────────────────────────────────────────────────────┘

The Index: Making Search Fast

On first search, Total Recall:

Loads all messages from CLI (SQLite) and IDE (.chat files)
Embeds each message using all-MiniLM-L6-v2 (384-dimensional vectors)
Caches embeddings to ~/.cache/kiro-total-recall/embeddings.pkl

Subsequent searches are fast because:

Fingerprinting: Only rebuilds when conversations change
Incremental updates: New messages get embedded; existing embeddings loaded from cache
Hash-based deduplication: Same text = same embedding (no recomputation)

Features

Semantic Search: Find by meaning, not just keywords
Dual Source: Searches both CLI and IDE conversations
Context Windows: See surrounding messages for each match
Date Filtering: Filter by time range (ISO 8601)
Incremental Indexing: Only processes new conversations
Memory Limits: Configurable RAM usage (default: 1/3 of RAM)

MCP Tools

Tool	Scope	Use Case
`search_project_history`	Current workspace	Bugs, decisions in this codebase
`search_global_history`	All workspaces	Preferences, patterns across all work
`search_cli_history`	CLI only	Kiro CLI conversations
`search_ide_history`	IDE only	Kiro IDE conversations

Parameters

All tools accept:

Parameter	Default	Description
`query`	required	Keywords or sentence to search
`after`	none	Filter to messages on/after this date (inclusive). ISO 8601 format.
`before`	none	Filter to messages before this date (exclusive). ISO 8601 format.
`context_size`	3	Messages before AND after each match
`threshold`	0.2	Minimum similarity (0-1, higher = stricter)
`max_results`	10	Maximum results to return
`offset`	0	Skip results (for pagination)

Date Filtering Examples

# Messages from a specific day
search_project_history(query="auth bug", after="2025-01-15", before="2025-01-16")

# Messages from the past week
search_project_history(query="refactoring", after="2025-01-25")

# Messages in January
search_project_history(query="database", after="2025-01-01", before="2025-02-01")

Response Structure

{
  "results": [
    {
      "matched_message": {
        "role": "assistant",
        "content": "To fix the authentication bug...",
        "timestamp": "2025-01-15T10:30:00",
        "workspace": "/Users/dev/myproject",
        "session_id": "abc123",
        "uuid": "msg-456",
        "source": "cli"
      },
      "score": 0.8542,
      "context": [
        {"role": "user", "content": "How do I fix this auth bug?", "timestamp": "...", "is_match": false},
        {"role": "assistant", "content": "To fix the authentication bug...", "timestamp": "...", "is_match": true}
      ]
    }
  ],
  "query": "authentication bug fix",
  "total_matches": 25,
  "offset": 0,
  "has_more": true,
  "hint": "Showing 1-10 of 25 matches. Use offset: 10 for more."
}

Usage Examples

Just ask naturally:

"How did we fix that auth bug?"
"What did we discuss about the database schema?"
"What's my usual approach to error handling?"
"Find our React component discussions from last week"

Or use tools directly:

search_project_history(query="authentication bug fix")
search_global_history(query="React component patterns")
search_cli_history(query="deployment", after="2025-01-01")

Configuration

Create ~/.config/kiro-total-recall/config.toml to customize:

[sources.cli]
enabled = true
paths = [
    "~/Library/Application Support/kiro-cli/data.sqlite3",
    "~/.local/share/kiro-cli/data.sqlite3",
    "~/AppData/Roaming/kiro-cli/data.sqlite3",
]

[sources.ide]
enabled = true
patterns = [
    "~/Library/Application Support/Kiro/User/globalStorage/kiro.kiroagent/*/*.chat",
    "~/.config/Kiro/User/globalStorage/kiro.kiroagent/*/*.chat",
    "~/AppData/Roaming/Kiro/User/globalStorage/kiro.kiroagent/*/*.chat",
]

[embedding]
model = "all-MiniLM-L6-v2"
cache_dir = "~/.cache/kiro-total-recall"

[search]
default_threshold = 0.2
default_max_results = 10
default_context_window = 3

[memory]
fraction = 0.33  # Use 1/3 of RAM
# limit_mb = 512  # Or set explicit limit

Memory Management

Total Recall limits in-memory index size to prevent excessive memory usage. By default, it uses 1/3 of physical RAM. When the limit is reached, the oldest sessions are excluded from the index (newest sessions are kept).

Variable	Description	Default
`KIRO_RECALL_MEMORY_LIMIT_MB`	Override memory limit in MB	1/3 of RAM
`KIRO_RECALL_NO_MEMORY_LIMIT`	Set to any value to disable limit	-

Testing

# Test server starts
uvx kiro-total-recall
# Ctrl+C to exit

# Test search directly
uv run python -c "
from kiro_total_recall.query import search_conversations
result = search_conversations(query='bug fix', max_results=3)
print(f'Found {result.total_matches} matches')
"

Project Structure

kiro-total-recall/
├── POWER.md                      # Kiro Power manifest + steering
├── mcp.json                      # MCP server config for Power
├── config.default.toml           # Default configuration
├── src/kiro_total_recall/
│   ├── server.py                 # FastMCP server, tool definitions
│   ├── query.py                  # Search engine, deduplication
│   ├── indexer.py                # Embedding, caching, fingerprinting
│   ├── loader.py                 # Unified loader (CLI + IDE)
│   ├── cli_loader.py             # SQLite parsing for CLI
│   ├── ide_loader.py             # JSON parsing for IDE .chat files
│   ├── config.py                 # Configuration management
│   └── models.py                 # Pydantic data models
├── pyproject.toml
└── LICENSE

Technical Details

Component	Technology
Embedding model	all-MiniLM-L6-v2 (384 dimensions)
Vector search	Cosine similarity via NumPy dot product
Cache format	Python pickle with file locking
MCP framework	FastMCP
Package manager	uv

License

MIT License

Available Tools

4 tools

search_cli_historyA

Search Kiro CLI conversation history only.

Use this to find conversations from Kiro CLI sessions specifically.

Args: query: Keywords or sentence describing what to find after: Filter to messages on/after this date (ISO 8601) before: Filter to messages before this date (ISO 8601) context_size: Messages before AND after each match (default: 3) threshold: Minimum similarity 0-1 (default: 0.2) max_results: Maximum results (default: 10) offset: Skip results for pagination (default: 0)

Returns: Search results from CLI conversations only

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`query`	Yes
`before`	No
`offset`	No
`threshold`	No
`max_results`	No
`context_size`	No

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It explains the search scope and parameter effects but does not mention side effects, idempotency, authentication needs, or rate limits. It adds some value but lacks comprehensive transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, usage note, parameter list, and return description. It is concise, though the first two sentences are slightly redundant ('Search Kiro CLI conversation history only.' and 'Use this to find...').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and no output schema, the description covers most needed context: parameter meanings, defaults, and a basic return description. Missing details include pagination behavior (offset interaction with max_results) and result ordering, but it is largely sufficient for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description includes an 'Args' section that explains each parameter (query, after, before, etc.) with defaults and brief descriptions. This fully compensates for the schema's lack of semantic information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches 'Kiro CLI conversation history only,' using strong verbs and resource specificity. It effectively distinguishes from siblings like search_global_history by narrowing to CLI conversations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using this tool for Kiro CLI sessions, providing clear context. However, it does not explicitly mention when not to use it or reference sibling tools, though sibling names are available.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_global_historyA

Search conversation history across ALL WORKSPACES.

Use this to find cross-project knowledge: user preferences, coding patterns, common solutions, and insights from all previous work.

Args: query: Keywords or sentence describing what to find after: Filter to messages on/after this date (ISO 8601: "2025-01-15") before: Filter to messages before this date (ISO 8601) context_size: Messages to include before AND after each match (default: 3) threshold: Minimum similarity 0-1 (default: 0.2) max_results: Maximum results to return (default: 10) offset: Skip results for pagination (default: 0)

Returns: Search results with matched messages, scores, workspace, context, pagination

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`query`	Yes
`before`	No
`offset`	No
`threshold`	No
`max_results`	No
`context_size`	No

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It describes the search behavior across all workspaces and details parameter defaults, but lacks disclosure on performance implications, rate limits, or error handling. The transparency is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear purpose sentence, a usage context sentence, a bulleted list of parameters with defaults, and a return summary. Every sentence adds value with no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, no output schema, and no annotations, the description covers parameter semantics thoroughly and gives a brief return overview. It lacks details on result structure or edge cases, but is sufficient for a search tool with good defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides detailed explanations for all 7 parameters, including acceptable values (e.g., ISO 8601 for dates), defaults, and purpose for each. This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search conversation history across ALL WORKSPACES', which is a specific verb+resource combination. It distinguishes itself from sibling tools like search_cli_history and search_project_history by emphasizing the global scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using this tool for cross-project knowledge discovery, listing examples like user preferences and coding patterns. It does not explicitly exclude scenarios, but the sibling tools' scopes provide implicit guidance on when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_ide_historyA

Search Kiro IDE conversation history only.

Use this to find conversations from Kiro IDE sessions specifically.

Returns: Search results from IDE conversations only

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`query`	Yes
`before`	No
`offset`	No
`threshold`	No
`max_results`	No
`context_size`	No

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose if the tool is read-only, whether it requires authentication, rate limits, or other behavioral traits. The return value is only briefly mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the purpose, then listing parameters in a structured Args section. No unnecessary sentences, though the Args section could be more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description covers purpose and parameter meanings but lacks details on pagination behavior, response format, or error handling, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description adds value by listing all parameters with brief explanations and defaults. The descriptions (e.g., 'Filter to messages on/after this date (ISO 8601)') are adequate but not highly detailed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'Kiro IDE conversation history', and explicitly limits to IDE sessions, distinguishing it from sibling tools like search_cli_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for IDE history but does not explicitly state when to use versus alternatives or provide exclusion criteria. Context from sibling names helps but is not in the description itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_project_historyA

Search conversation history for the CURRENT WORKSPACE only.

Use this to find workspace-specific context: past decisions, implementation details, bugs discussed, architecture choices in this codebase.

Returns: Search results with matched messages, scores, context, and pagination info

ParametersJSON Schema

Name	Required	Description	Default
`after`	No
`query`	Yes
`before`	No
`offset`	No
`threshold`	No
`max_results`	No
`context_size`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the scope (current workspace) and parameter behavior but does not explicitly state read-only nature. The behavior is clearly a search operation without side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise intro sentence, a usage guidance paragraph, and a clear Args list. Every sentence adds value, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description mentions return structure (messages, scores, context, pagination info). Parameter documentation is complete. However, it could be slightly more detailed about the return format, but it is sufficient for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates fully with an explicit Args section explaining each parameter's purpose, type, and default. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches conversation history for the current workspace only. The verb 'search' and resource 'project history' are specific, and it distinguishes from siblings like search_global_history by emphasizing workspace scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use for workspace-specific context and implies not for global searches. It names sibling tools but does not explicitly tell when to use alternatives. However, the scope restriction is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct scope (CLI, IDE, current workspace, all workspaces) with clear descriptions, leaving no ambiguity about which to use.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (search_*_history) with snake_case, making the naming predictable and easy to understand.

Tool Count5/5

With 4 tools, the set is well-scoped for searching conversation history across different contexts; not too few or too many.

Completeness5/5

The tools cover all relevant search scopes (CLI, IDE, workspace, global) and include necessary parameters like date filters, pagination, and similarity threshold, leaving no obvious gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ContextStream MCP Server
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
139
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2
Amber
com.ambermem
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Knowledge & Memory RAG Systems Vector Databases
2
TeamShared B
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1041

Related MCP Servers

Chat Context MCP
Knowledge & Memory Developer Tools Search
aolshaun
F
license
Not graded
quality
Not graded
maintenance
Enables AI to automatically search, retrieve, and organize your Cursor chat history across sessions. Supports tagging, nicknames, project-scoped search, and full-text search to maintain context between conversations.
Updated 10 months ago (2025-10-28 13:47 UTC)
claude-kb
RAG Systems Search Vector Databases
tenequm
A
license
Not graded
quality
C
maintenance
Enables searching and retrieving Claude Code conversation history via hybrid semantic and keyword search, allowing the agent to access its own past interactions.
Updated 4 months ago (2026-05-07 19:15 UTC)
4
MIT
Lore
Knowledge & Memory RAG Systems Developer Tools
jordanhindo
A
license
Not graded
quality
B
maintenance
Enables infinite searchable memory for coding agents across sessions, allowing them to recall past decisions and context.
Updated 2 months ago (2026-06-26 00:02 UTC)
62
13
MIT
MCP Claude Code Conversation
Knowledge & Memory Search
Stefan-Nitu
A
license
A
quality
D
maintenance
Enables Claude Code to search, browse, and read its own past conversation history across all projects using BM25 keyword search.
Updated 5 months ago (2026-03-27 17:09 UTC)
1
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danilop/kiro-total-recall'

If you have feedback or need assistance with the MCP directory API, please join our Discord server