Terminal History MCP

Overview Schema Source Related Servers Discussions Admin

ask_history

Read-onlyIdempotent

Answers natural-language questions about your shell history by retrieving relevant commands and citing them, so you can find how past tasks were done.

Instructions

Read-only. Answers a natural-language question about your shell history, with citations (retrieval-augmented generation). Retrieves the top k entries with hybrid search, then, if TERMINAL_HISTORY_CHAT_MODEL is set, asks that chat model to answer only from those entries and cite them as [id:N]. Retrieved commands are passed as delimited untrusted data, never as instructions. Replies exactly "No relevant history found." when nothing retrieved is relevant. Without a chat model it returns the retrieved context only. Cited ids are checked against the retrieved set; any others are listed in invalid_citation_ids.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "ask_history"
  }
}

Input Schema

Name	Required	Description	Default
`k`	No	Number of entries to retrieve as context. Default 8.
`question`	Yes	Natural-language question, e.g. "how did I free up docker disk space?"

Output Schema

Name	Required	Description
`note`	No
`answer`	No	Model answer with [id:N] citations; null when no chat model is configured.
`cited_ids`	No	Cited ids that exist in the retrieved set.
`retrieved`	No	Context given to the model.
`cited_entries`	No
`keyword_error`	No
`retrieval_mode`	No	`hybrid`, or `keyword` if it fell back.
`fallback_reason`	No
`invalid_citation_ids`	No	Ids the model cited that were not retrieved.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Nov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the readOnlyHint annotation: it discloses the TERMINAL_HISTORY_CHAT_MODEL dependency and its no-model fallback, the untrusted-data delimiting used against prompt injection, the exact no-results string, and post-hoc citation validation yielding invalid_citation_ids. These are non-obvious behaviors an agent cannot infer from the annotations or schema.

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?

Front-loads the safety profile with "Read-only." and proceeds in a logical order: retrieval, model step, fallback, validation. It is dense but nearly every clause carries information; a couple of the mechanism sentences could be tightened without loss.

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

Completeness5/5

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

For a tool with an output schema, an environment-dependent model step, and injection exposure, the description covers what an agent needs to call it correctly and interpret several return cases (citations, no-results string, context-only, invalid citation ids). Nothing material is left unstated.

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

Parameters3/5

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

Schema coverage is 100%, so both `question` and `k` are already documented with a default and an example. The description only lightly reinforces `k` by tying it to "top k entries with hybrid search," which adds a small hint about retrieval method but no new parameter-level semantics. Baseline 3 is appropriate given the schema does the heavy lifting.

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?

States a specific verb and resource: answers a natural-language question about shell history, and pins the mechanism (hybrid retrieval + model answer with [id:N] citations). The retrieval-augmented-answer behavior inherently separates it from plain search siblings like search_history, so an agent can tell what it uniquely offers without opening the schema.

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?

Gives clear operating conditions: it answers only from retrieved entries, replies exactly "No relevant history found." when nothing is relevant, and degrades to returned-context-only when no chat model is configured. It stops short of explicitly naming search_history as the alternative when the agent wants raw entries rather than a synthesized answer, so the when-not guidance is implied rather than stated.

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

Deploy Server