Terminal History MCP indexes your local shell history (zsh/bash/fish) and exposes tools to search, explore, and debug past commands — all stored locally, with secrets automatically redacted.
search_history(query, limit): Full-text keyword and prefix search across all indexed shell commands, returning results with timestamps, working directory, and exit codes.
recent_in_dir(cwd, limit): List the most recent commands run in a specific working directory (requires shell hook for cwd capture).
failed_commands(since_ts_ms, limit): Retrieve commands that exited with a non-zero status, useful for debugging recent errors (requires shell hook for exit code capture).
command_chains(query, window_ms, limit): For any matching command, surface surrounding commands run within ±5 minutes, revealing multi-step sequences like cd → build → deploy.
reindex: Re-parses ~/.zsh_history, ~/.bash_history, ~/.fish_history, and the extended log to refresh the local SQLite database.
Privacy: All data stays on your machine (~/.terminal-history-mcp/history.db). Sensitive values (API keys, tokens, passwords, JWTs) are redacted before storage. A shell hook can be installed for zsh/bash/fish to capture additional context (cwd, exit codes) needed by some tools.
Search your shell history (zsh / bash / fish) from Claude Code, Cline, Cursor, Zed, or any MCP client. Local-only. SQLite FTS5. Secret-redacted before storage.
"When did I last ssh into the staging server?"
"Show recent failed commands."
"What did I run yesterday in /etc/nginx?"
"What's that long docker compose flag I used 3 weeks ago?"
"Show command chains around kubectl apply."
Related MCP server: ClaudeX
npm install -g terminal-history-mcp
terminal-history-mcp index # one-time backfill from existing history(Or run from a clone: git clone … && npm install && npm run build && npm link.)
claude mcp add --scope user terminal-history -- terminal-history-mcp
claude mcp listAnywhere that takes a stdio MCP server config:
{
"mcpServers": {
"terminal-history": {
"command": "terminal-history-mcp"
}
}
}Use this MCP server instantly with no local installation:
npx -y mcpize connect @HasanJahidul/terminal-history --client claudeOr connect at: https://mcpize.com/mcp/terminal-history
By default zsh/bash history files store only the command. To unlock recent_in_dir and failed_commands, install the shell hook:
terminal-history-mcp install-hook zsh # or bash, or fish
exec $SHELL # reloadThe hook appends pipe-delimited lines to ~/.terminal-history-mcp/extended.log. Reindex picks them up.
To inspect the snippet first:
terminal-history-mcp print-hook zshTo remove:
terminal-history-mcp uninstall-hook zshTool | What it does |
| FTS5 keyword + prefix match across all history |
| Last N commands in a working dir (needs hook) |
| Commands with non-zero exit (needs hook) |
| For each match, list commands within ±5 min |
| Re-parse history files + extended log |
Everything is local. The DB lives at ~/.terminal-history-mcp/history.db. Nothing is uploaded.
Secrets are scrubbed before insert. Detected patterns:
GitHub PATs (ghp_*, gho_*, …)
OpenAI keys (sk-*)
Slack tokens (xox[baprs]-*)
AWS access keys (AKIA…)
Authorization: Bearer/Basic <value>
X-*-Token: …, X-*-Key: …, X-*-Secret: … headers
Env vars containing TOKEN / KEY / SECRET / PASSWORD / API_KEY
CLI flags --token=…, --api-key …, -k …
URL basic-auth https://user:pass@host
JWTs (eyJ.*.*)
If you find a leak, please open an issue. To wipe and re-index after upgrading patterns:
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 — see 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.
