Unified History MCP

by palimpsest-labs

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct: list_domain enumerates files, read retrieves entries, summary provides AI-generated overviews, and rebuild manages indexes. The three search-related tools (search, search_history, search_log) could cause some confusion, but their descriptions clearly separate domain search from specific-file searches.
Naming Consistency3/5
Naming conventions are mixed: some tools use single verbs (search, read, summary, rebuild) while others use verb_noun patterns (list_domain, search_history, search_log). 'summary' is a noun rather than an imperative verb, breaking the expected pattern. Overall, the names are readable but not uniformly styled.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of providing unified search and read access to historical data. Each tool serves a distinct function without unnecessary bloat, and the count is appropriate for the domain.
Completeness4/5
The tool set covers the core lifecycle for a read-only history server: searching, listing, reading, and summarizing entries, plus index maintenance. The only notable gap is that the summary tool does not support the notifications domain, and there is no explicit tool for configuring domains (though rebuild handles index updates).
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions 'newest first' and default max_entries, but does not state that this is a safe read-only operation, how prefixes are matched, or any error/edge-case behavior. The description adds only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a one-sentence summary plus a concise, well-structured argument list. Each line provides necessary information with no redundancy or filler. The format is easy to scan and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers parameter meanings for a tool with moderate complexity and an output schema. However, it lacks usage context, behavioral caveats, and explicit differentiation from siblings, leaving overall completeness somewhat shallow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the parameter documentation in the description is essential. It explains each parameter with domain-specific details (e.g., role is for sessions, speaker for transcripts) and notes defaults and ordering behavior. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read entries from a domain file', which is a specific verb and resource. It conveys the core action and target, but does not explicitly differentiate from siblings like 'search' or 'list_domain', leaving some ambiguity about when 'read' is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It only documents parameters, with no mention of use cases, prerequisites, or exclusions. Sibling tools are not referenced or contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'Get', which implies a read operation, but does not explicitly confirm it is non-destructive or mention any side effects such as triggering summary generation if not already cached. No details about rate limits, permissions, or potential delays are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded with the core purpose, followed by concise parameter explanations. There is no fluff; every sentence earns its place. The use of an Args block is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return values, so the description need not explain them. For a simple getter tool with two parameters, the description is mostly complete. However, it lacks context about how 'summary' differs from 'read' or 'search', and does not address edge cases like missing summaries. This prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by defining 'domain' with example values ('sessions, transcripts') and clarifying 'id' as 'File/directory name or unique prefix.' This adds meaning beyond the bare schema and is genuinely helpful for correct invocation.
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?
The description clearly states the tool's function: 'Get the AI-generated summary for a domain entry.' This is a specific verb+resource pair and differentiates it from siblings like 'read' (which likely retrieves raw content) and 'search' (which looks for entries). The resource ('AI-generated summary') and scope (domain entry) are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is the appropriate tool for retrieving summaries, nor does it exclude cases where 'read' or 'search' would be preferable. No contextual cues about preconditions or selection criteria are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool rebuilds (a mutation), but fails to mention side effects, potential downtime, whether the operation is reversible, or performance implications. This is insufficient for an agent to assess the risk of invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a clear Args section, front-loaded with the purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks behavioral disclosures and usage guidance. It could be considered sufficient for a trivial tool, but the lack of side-effect documentation is a notable gap. The presence of an output schema aids but is not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, and the description compensates by explaining the 'domain' parameter: 'Domain to rebuild, or "all" for all configured domains.' This adds crucial meaning, clarifying the default value and the special 'all' option, which is essential for correct invocation.
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?
The description uses the specific verb 'Rebuild' and identifies the resource 'FST indexes' for 'configured domains', clearly distinguishing it from sibling tools like search, read, and list_domain. The action is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for rebuilding indexes but does not mention exclusions or preconditions. The one-line purpose is clear, but there is no direction about when a rebuild is necessary or how to check current index state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what side effects (if any) exist, or any details about the return behavior beyond the parameters. Since it only lists arguments and omits behavioral traits, transparency is weak.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear one-sentence purpose followed by a structured argument list. Each argument explanation is short and directly to the point, with no wasted words. This is an efficient format for a tool with four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists (so return values are covered), the description lacks behavioral context such as whether the search is read-only, any sorting or result limitations beyond max_results, or the nature of the vibehistory file. It is minimally viable but leaves gaps in usage context and behavioral expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description thoroughly explains each parameter (query, max_results, regex, case_sensitive) with meanings and defaults. It clarifies the regex behavior ('treat query as a regex pattern') and case sensitivity defaults, adding significant value beyond the raw schema.
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?
The description clearly states the tool's function: 'Search the Vibe command history (vibehistory file).' This uses a specific verb ('search') and resource ('Vibe command history'), and the parenthetical identifies the exact file. This distinguishes it from siblings like search_log, which targets logs, and generic search, by focusing on the history file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it is for searching command history. However, there is no explicit guidance on when to use this tool versus alternatives like 'search' or 'search_log'. No exclusions or alternative suggestions are provided, so the usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full responsibility for disclosing safety and side effects. The verb 'List' clearly implies a read-only operation, and the parameters are documented, but there is no explicit statement about permissions, return format beyond 'metadata and summaries', or any additional behavioral traits. With no annotations, the description offers only the basic expectation of a non-mutating listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single purpose sentence followed by a cleanly formatted Args block. There is no redundancy or filler. The front-loaded purpose makes the tool's intent immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema present, the description covers the essential aspects: purpose and parameters. It does not mention sorting or pagination, but the output schema likely handles return structure. The main gap is the lack of usage guidance, which is already penalized in the usage guidelines dimension. Overall, the description is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions, but the description adds meaningful semantics for every parameter. It enumerates allowed values for 'domain', specifies the date format and inclusivity for 'date_from' and 'date_to', and explains 'max_results' with its default. This fully compensates for the schema's lack of documentation.
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?
The description opens with a clear, specific verb-resource pair: 'List available files in a domain with metadata and summaries.' This distinguishes it from sibling tools like search or read, which focus on content retrieval rather than enumeration. The domain values (sessions, transcripts, notifications) further clarify the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose list_domain over the sibling tools (search, read, summary, rebuild, search_history, search_log). The presence of the domain argument implies usage, but there is no mention of alternatives or exclusions. For example, it does not say 'Use this to enumerate files; use search to find specific content.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It lists parameters but does not describe return behavior, error handling, whether the operation is read-only, or operational constraints (e.g., log rotation, permissions). This leaves a behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose followed by a clean parameter list. Every line adds value, and the format is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all parameters documented, the description is mostly complete for a log-search tool. It lacks usage guidance and some behavioral context but covers the essential invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides explicit meaning for all five parameters (query, max_results, regex, case_sensitive, level) including defaults and filtering behavior, fully compensating for the schema.
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?
The description opens with a specific verb and resource: 'Search the Vibe runtime log (vibe.log).' This clearly identifies the tool's function and distinguishes it from generic 'search' or 'search_history' siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching the Vibe log, but it does not explicitly say when to prefer this over sibling tools like 'search' or 'read', nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the search mechanism (FST-backed), domain definitions, and detailed parameter behaviors (regex, case_sensitive, role, speaker). However, it does not mention limitations or edge cases like what happens when using domain-specific filters with incompatible domains, or how results are ranked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, domains, and arguments. It is front-loaded with the core statement, and every line adds value. The length is justified because it documents 11 parameters with no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 11 parameters and multiple domains, and the description covers all of them thoroughly. The existence of an output schema means return values need not be described. The only notable gap is the lack of guidance on combining domain-specific filters with incompatible domains, which leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section is essential. It covers all 11 parameters with plain-language explanations, defaults, and domain-specific hints (e.g., role for sessions, speaker for transcripts). This fully compensates for the schema's lack of descriptions.
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?
The description opens with a clear statement 'Search across domains with FST-backed full-text search,' and then enumerates the specific domains (sessions, transcripts, notifications) and 'all' option. This makes the tool's purpose unmistakable and differentiates it from siblings like search_history and search_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit context about what domains are searched, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or when-not-to-use. The sibling tools search_history and search_log are not referenced, so usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![unified-history-mcp MCP server](https://glama.ai/mcp/servers/palimpsest-labs/unified-history-mcp/badges/card.svg)](https://glama.ai/mcp/servers/palimpsest-labs/unified-history-mcp)

Score Badge

Copy to your README.md:

[![unified-history-mcp MCP server](https://glama.ai/mcp/servers/palimpsest-labs/unified-history-mcp/badges/score.svg)](https://glama.ai/mcp/servers/palimpsest-labs/unified-history-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/palimpsest-labs/unified-history-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server