Unified MCP server for conversation history. Exposes 6 tools for reading history data: get_summaries, get_session, get_history, get_response, get_trace, and search_history. Provides semantic search via ChromaDB and session summaries grouped by source channel.
mcp-history is a read-only history/search utility with 6 well-named tools. Naming is excellent (get_*, search_* verbs are clear and unambiguous). Descriptions are present and informative, ranging from 150 - 280 characters, above the 10-char minimum but some could be more concise for LLM token efficiency. Input schemas are visible in the code and properly typed (string, integer with descriptions). However, OUTPUT schemas are not documented anywhere, LLMs cannot see what fields these tools return, forcing guesswork about downstream chaining. Error handling is minimal: no guidance on what to do if a date is invalid, if a UUID is not found, or if the ChromaDB index is corrupted. All tools are read-only (good for safety), but there is no explicit documentation of this in tool metadata. Parameter validation is implicit in helper functions (parse_date, get_limit) but not exposed as schema constraints. Composition is strong, each tool has a single, clear responsibility. The server is missing tool annotations (readOnlyHint) that would signal safety to the agent.
List entries with previews for a date range. Shows entry_id, timestamp, source, tool-use flag, and user message preview (truncated at 200 chars). Use entry_id with get_response or get_trace to see full text. Date required. Returns up to 20 entries by default.
Get the full assistant response text for a specific entry. Requires entry_id from get_history or get_session, plus the date it was recorded.
Get all raw history entries for a specific session by UUID. Use after get_summaries to drill into a session of interest. Returns entries in the same format as get_history. Use get_response or get_trace for individual entries within the session.
START HERE — always call this first when you need context about past conversations. Returns Haiku-generated session summaries grouped by source channel. A full week fits in ~200 lines. Each session has a UUID — use get_session(uuid) to see the entries, then get_response/get_trace for details. Date defaults to last 7 days if not specified. IMPORTANT: When the user asks about recent or today's conversations (e.g. 'what was I talking about with X', 'what did we discuss about Y'), always pass TODAY's date explicitly — do not rely on the 7-day default. Recency-implied questions always mean today first.
Get the full tool call / reasoning trace for a specific entry. Shows all assistant thinking blocks, tool calls, tool results, and command executions. Requires entry_id from get_history, plus the date.
Output schemas are not documented. Tool descriptions explain what the tools do, but not what fields or structures are returned. LLMs must infer return types, risking incorrect field access and failed downstream chaining.
No tool annotations (readOnlyHint). All 6 tools are read-only and safe to retry, but this is not explicitly declared in the MCP schema. Agents cannot automatically detect that these tools have no side effects.
Error handling lacks recovery guidance. If a UUID is not found in get_session, the error message is inferred from code but not explicitly returned. If date parsing fails, there is no hint about valid formats. Errors should guide the LLM on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Semantic search via ChromaDB. Finds entries semantically similar to your query across all available history. Returns entry_id, date, and preview for each match. Use with get_response or get_trace for full details. Limit defaults to 5; increase for broader results.
Parameters accept free-form strings for date and UUID without explicit format constraints in the schema. The description says 'YYYY-MM-DD format' but the schema has no regex pattern or enum. LLMs may pass invalid dates and get unclear errors.
No pagination details in output. Tools like get_summaries, get_history, and search_history accept a 'limit' parameter but do not document whether they return a total_count, next_cursor, or whether results are sorted in any particular order. This blocks intelligent pagination and sorting.