Hop vs Terminal History MCP — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Hop vs Terminal History MCP
In-depth architectural comparison of the Hop and Terminal History MCP MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Hop
Command Line · Local stdio
Quality: 49/100 (Fair) | Auth: No auth required
Terminal History MCP
Command Line · Local stdio
Quality: 60/100 (Good) | Auth: No auth required
Verdict Summary: Choose Hop if you need specialized Command Line tools running via a local process. Choose Terminal History MCP if your workspace requires Command Line integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Hop when:
You need dedicated capabilities in the Command Line domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
Hop is categorized under Command Line and uses a local stdio subprocess. In contrast, Terminal History MCP belongs to Command Line using local stdio subprocess. Select Hop when you need capabilities focused on command line and Terminal History MCP when you require tools for command line.
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.
search_history
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.
recent_in_dir
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.
failed_commands
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.
command_chains
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.