Claude Code, Cline, Cursor, Zed 또는 모든 MCP 클라이언트에서 셸 기록(zsh / bash / fish)을 검색하세요. 로컬 전용입니다. SQLite FTS5를 사용합니다. 저장 전에 비밀 정보가 삭제됩니다.
"마지막으로 스테이징 서버에 ssh로 접속한 게 언제지?"
"최근 실패한 명령어들을 보여줘."
"어제 /etc/nginx에서 실행한 명령어가 뭐야?"
"3주 전에 사용했던 그 긴 docker compose 플래그가 뭐였지?"
"kubectl apply 전후로 실행된 명령어 체인을 보여줘."
Related MCP server: ClaudeX
npm install -g terminal-history-mcp
terminal-history-mcp index # one-time backfill from existing history(또는 클론 후 실행: git clone … && npm install && npm run build && npm link.)
claude mcp add --scope user terminal-history -- terminal-history-mcp
claude mcp liststdio MCP 서버 설정을 지원하는 모든 곳:
{
"mcpServers": {
"terminal-history": {
"command": "terminal-history-mcp"
}
}
}로컬 설치 없이 이 MCP 서버를 즉시 사용하세요:
npx -y mcpize connect @HasanJahidul/terminal-history --client claude또는 다음 링크에서 연결: https://mcpize.com/mcp/terminal-history
기본적으로 zsh/bash 기록 파일은 명령어만 저장합니다. recent_in_dir 및 failed_commands 기능을 사용하려면 셸 훅을 설치하세요:
terminal-history-mcp install-hook zsh # or bash, or fish
exec $SHELL # reload이 훅은 파이프로 구분된 줄을 ~/.terminal-history-mcp/extended.log에 추가합니다. 재색인 시 이 내용들이 포함됩니다.
스니펫을 먼저 확인하려면:
terminal-history-mcp print-hook zsh제거하려면:
terminal-history-mcp uninstall-hook zsh도구 | 기능 |
| 모든 기록에 걸쳐 FTS5 키워드 + 접두사 일치 검색 |
| 작업 디렉토리 내 최근 N개 명령어 (훅 필요) |
| 0이 아닌 종료 코드를 가진 명령어 (훅 필요) |
| 각 일치 항목에 대해 ±5분 이내의 명령어 나열 |
| 기록 파일 + 확장 로그 재파싱 |
모든 데이터는 로컬에 저장됩니다. DB는 ~/.terminal-history-mcp/history.db에 위치합니다. 외부로 업로드되는 데이터는 없습니다.
비밀 정보는 삽입 전에 삭제됩니다. 감지되는 패턴:
GitHub PAT (ghp_*, gho_*, …)
OpenAI 키 (sk-*)
Slack 토큰 (xox[baprs]-*)
AWS 액세스 키 (AKIA…)
Authorization: Bearer/Basic <value>
X-*-Token: …, X-*-Key: …, X-*-Secret: … 헤더
TOKEN / KEY / SECRET / PASSWORD / API_KEY를 포함하는 환경 변수
CLI 플래그 --token=…, --api-key …, -k …
URL 기본 인증 https://user:pass@host
JWT (eyJ.*.*)
유출을 발견하면 이슈를 열어주세요. 패턴 업그레이드 후 데이터를 삭제하고 재색인하려면:
rm ~/.terminal-history-mcp/history.db*
terminal-history-mcp indexgit clone https://github.com/hasanjahidul/terminal-history-mcp
cd terminal-history-mcp
npm install
npm run build
npm testMIT — LICENSE 참조.
Read-only. For each command matching query, returns the commands run within a time window around it (default ±5 min) — surfacing multi-step sequences like cd → npm run build → deploy. Useful for reconstructing "how did I do X last time?". Returns up to limit chains, each a time-ordered list of command rows. Local index only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of chains (one per anchor match) to return. Default 5. | |
| query | Yes | FTS5 query identifying the anchor command(s). Same syntax as `search_history`. | |
| window_ms | No | Half-width of the time window around each match, in milliseconds. Default 300000 (±5 min). |
| Name | Required | Description |
|---|---|---|
| count | No | |
| chains | No | Each chain is a time-ordered list of command rows around one anchor match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description starts with 'Read-only', matching annotations (readOnlyHint=true, destructiveHint=false). It also discloses that it returns time-ordered sequences and uses a local index only, providing full behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with 'Read-only', includes an example sequence and a practical use case. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but implied), the description need not detail return format. It covers behavior, use case, and limitations (local index), making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context like default window and purpose but doesn't significantly enhance parameter semantics beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns command chains around a query match, surfacing multi-step sequences. It distinguishes itself from siblings like search_history (which gives individual commands) and recent_in_dir (which shows recent commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'reconstructing how did I do X last time?'. While it doesn't explicitly exclude scenarios, the context of sibling tools implies when to use this vs. other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Lists recent commands that exited non-zero — a quick "what just broke?" feed. Optionally restrict to commands after a given epoch-millisecond timestamp. Requires the shell hook for exit-code capture (legacy entries have no exit code). Newest first. Local index only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of commands to return, newest first. Default 20. | |
| since_ts_ms | No | Only return commands with a timestamp at or after this epoch-millisecond value. Null/omitted = no lower bound. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds behavioral details: the need for a shell hook, legacy behavior, ordering (newest first), and scope (local index only). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. Each sentence serves a purpose: stating the function, describing optional filtering, and listing constraints. It is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters, the description covers purpose, constraints, filtering, and prerequisites (shell hook). Output schema exists for return values. Minor gap: no mention of what happens if hook is missing, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds minor value by restating the filter option in prose ('optionally restrict to commands after a given epoch-millisecond timestamp') and mentioning ordering, but the schema already defines the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent failed commands (non-zero exit) as a quick feed. It uses specific verb 'lists' and resource 'failed commands', and distinguishes from siblings like search_history by emphasizing its scope and immediacy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: read-only, requires shell hook for exit-code capture, legacy entries lack exit codes, and results are newest first and local index only. It doesn't explicitly name alternatives but implies when 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.
Read-only. Lists the most recent commands that were run with a given working directory — answers "what was I doing in this project?". Requires the shell hook to have been installed (legacy entries have no cwd and won't appear). Returns newest first with timestamps and exit codes. Local index only.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute working-directory path to filter by, e.g. `/Users/me/code/myapp`. Matched exactly. | |
| limit | No | Maximum number of commands to return, newest first. Default 20. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds prerequisite, limitation on legacy entries, return order (newest first with timestamps and exit codes), and scope (local index only). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding key info: read-only status, purpose, prerequisite, limitation, output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, annotations, and output schema, the description covers purpose, prerequisites, limitations, output order, and scope. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100% coverage). Description adds no extra parameter-specific detail beyond output format (newest first, timestamps). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists recent commands by working directory with a natural language example. Does not explicitly compare to siblings like search_history, but the specificity is sufficient for an agent to distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use it (recall commands in a project directory) and mentions a prerequisite (shell hook) and limitation (legacy entries excluded). Does not explicitly say when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-parses the local shell history files (~/.zsh_history, ~/.bash_history) and the hook's extended log into the SQLite index. Idempotent — already-indexed commands are skipped by hash, so it is safe to call repeatedly. Run it after a burst of shell activity to make recent commands searchable. Reads only local files; writes only to ~/.terminal-history-mcp/. Takes no arguments. Returns counts of parsed / inserted / skipped entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| parsed | No | History-file lines parsed this run. |
| skipped | No | Rows skipped because already indexed. |
| inserted | No | New rows added from history files. |
| ext_applied | No | Extended-log records merged into existing rows. |
| ext_inserted | No | Extended-log records inserted as new rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals idempotency (already-indexed skipped by hash), safety for repeated calls, reads only local files, writes only to a specific directory, and returns counts. Annotations provide idempotentHint=true and destructiveHint=false, and the description adds specific behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loaded with the main action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, an output schema (mentioned), and clear annotations, the description fully covers purpose, behavior, use case, and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no properties, and the description explicitly states 'Takes no arguments.' Schema coverage is 100%, so no additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-parses shell history files into a SQLite index. It distinguishes itself from sibling query tools by focusing on indexing, and it explicitly mentions idempotency and use case (after burst of shell activity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends running after a burst of shell activity to make recent commands searchable. It does not explicitly state when not to use it, but the sibling tools imply that this is for indexing rather than querying, providing sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Full-text search (SQLite FTS5, stemmed, Unicode-aware) over all indexed shell commands. Supports keyword and prefix queries — e.g. docker build, git reb*. Returns the most recent matches first, each with timestamp, shell, cwd, and exit code when available. Local index only; nothing is sent anywhere. If a query returns nothing you may need reindex first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching commands to return, newest first. Default 20. | |
| query | Yes | FTS5 query. Plain keywords are ANDed; append `*` for prefix match. E.g. `npm install`, `kubectl get po*`. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: declares read-only, specifies search algorithm (FTS5, stemming, Unicode), result ordering, returned fields (timestamp, shell, cwd, exit code), and privacy guarantee (local index only). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core action and key features. Every sentence adds essential information without redundancy. Efficiently covers purpose, usage, details, and fallback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage, annotations, and output schema existence, the description is complete. It covers what the tool does, how to use it, what to expect in return, privacy, and relationship to sibling tool, leaving no gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (100% coverage). Description adds value by explaining query syntax with examples and clarifying that prefix matching requires an asterisk, and by noting the default limit is 20 and results are newest first.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a full-text search over indexed shell commands using SQLite FTS5. Specifies resource (shell history) and action (search), with details on stemming and Unicode-awareness. Differentiates from sibling 'reindex' by mentioning it as a fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples of keyword and prefix queries, describes return fields and ordering, and advises when to use 'reindex' if no results. Does not explicitly compare to other sibling tools like command_chains or failed_commands, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.2command_chains5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / descriptionAdded value: +"Maximum number of chains (one per anchor match) to return. Default 5."Input schema / properties / query / descriptionAdded value: +"FTS5 query identifying the anchor command(s). Same syntax as `search_history`."Input schema / properties / window_ms / descriptionAdded value: +"Half-width of the time window around each match, in milliseconds. Default 300000 (±5 min)."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "chains": {
+ "description": "Each chain is a time-ordered list of command rows around one anchor match.",
+ "items": {
+ "items": {
+ "properties": {
+ "cmd": {
+ "description": "The command line as recorded (secrets already redacted at index time).",
+ "type": "string"
+ },
+ "cwd": {
+ "description": "Working directory the command ran in. Null for entries recorded before the hook was installed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_ms": {
+ "description": "Wall-clock duration in milliseconds, if the hook captured it.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "exit_code": {
+ "description": "Process exit code. Null when not captured.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shell": {
+ "description": "`zsh`, `bash`, `fish`, or `ext` (entry enriched by the shell hook).",
+ "type": "string"
+ },
+ "ts": {
+ "description": "Epoch milliseconds when the command ran, or null if the shell did not record a timestamp.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}failed_commands4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / descriptionAdded value: +"Maximum number of commands to return, newest first. Default 20."Input schema / properties / since_ts_ms / descriptionAdded value: +"Only return commands with a timestamp at or after this epoch-millisecond value. Null/omitted = no lower bound."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "cmd": {
+ "description": "The command line as recorded (secrets already redacted at index time).",
+ "type": "string"
+ },
+ "cwd": {
+ "description": "Working directory the command ran in. Null for entries recorded before the hook was installed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_ms": {
+ "description": "Wall-clock duration in milliseconds, if the hook captured it.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "exit_code": {
+ "description": "Process exit code. Null when not captured.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shell": {
+ "description": "`zsh`, `bash`, `fish`, or `ext` (entry enriched by the shell hook).",
+ "type": "string"
+ },
+ "ts": {
+ "description": "Epoch milliseconds when the command ran, or null if the shell did not record a timestamp.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}recent_in_dir4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / cwd / descriptionAdded value: +"Absolute working-directory path to filter by, e.g. `/Users/me/code/myapp`. Matched exactly."Input schema / properties / limit / descriptionAdded value: +"Maximum number of commands to return, newest first. Default 20."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "cmd": {
+ "description": "The command line as recorded (secrets already redacted at index time).",
+ "type": "string"
+ },
+ "cwd": {
+ "description": "Working directory the command ran in. Null for entries recorded before the hook was installed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_ms": {
+ "description": "Wall-clock duration in milliseconds, if the hook captured it.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "exit_code": {
+ "description": "Process exit code. Null when not captured.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shell": {
+ "description": "`zsh`, `bash`, `fish`, or `ext` (entry enriched by the shell hook).",
+ "type": "string"
+ },
+ "ts": {
+ "description": "Epoch milliseconds when the command ran, or null if the shell did not record a timestamp.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}reindex1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "ext_applied": {
+ "description": "Extended-log records merged into existing rows.",
+ "type": "number"
+ },
+ "ext_inserted": {
+ "description": "Extended-log records inserted as new rows.",
+ "type": "number"
+ },
+ "inserted": {
+ "description": "New rows added from history files.",
+ "type": "number"
+ },
+ "parsed": {
+ "description": "History-file lines parsed this run.",
+ "type": "number"
+ },
+ "skipped": {
+ "description": "Rows skipped because already indexed.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}search_history4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / descriptionAdded value: +"Maximum number of matching commands to return, newest first. Default 20."Input schema / properties / query / descriptionPrevious value: -"Keywords to search. Supports prefix match."New value: +"FTS5 query. Plain keywords are ANDed; append `*` for prefix match. E.g. `npm install`, `kubectl get po*`."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "cmd": {
+ "description": "The command line as recorded (secrets already redacted at index time).",
+ "type": "string"
+ },
+ "cwd": {
+ "description": "Working directory the command ran in. Null for entries recorded before the hook was installed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_ms": {
+ "description": "Wall-clock duration in milliseconds, if the hook captured it.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "exit_code": {
+ "description": "Process exit code. Null when not captured.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "shell": {
+ "description": "`zsh`, `bash`, `fish`, or `ext` (entry enriched by the shell hook).",
+ "type": "string"
+ },
+ "ts": {
+ "description": "Epoch milliseconds when the command ran, or null if the shell did not record a timestamp.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}command_chainsfailed_commandsrecent_in_dirreindexsearch_historyScored across 5 tools
Each tool has a clearly distinct purpose: command_chains finds related sequences, failed_commands lists failures, recent_in_dir shows commands in a directory, reindex manages the index, and search_history does full-text search. There is no overlap.
Tool names use snake_case but vary in pattern: command_chains and recent_in_dir are noun phrases, failed_commands is adjective+noun, while reindex and search_history are verbs. This mixing reduces predictability.
With 5 tools, the server is well-scoped for querying and managing terminal history. Each tool serves a specific need without being excessive or insufficient.
The tool surface covers major query types (search, chains, failures, directory context) and index maintenance. A minor gap is the lack of a tool to directly retrieve a single command by ID, but it's not essential for common use cases.
One searchable history across every AI coding tool, with secret scanning and a shared task board.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Hosted MCP memory: save sessions/decisions once, search from Claude, Cursor, ChatGPT. EU-hosted FTS.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
