Unified History MCP

by jmars

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
Disambiguation5/5
Each tool has a distinct purpose: search for full-text search, list_domain for listing files, read for reading entries, summary for AI summaries, rebuild for index rebuilding, search_history for command history, and search_log for runtime log. No overlap exists.
Naming Consistency3/5
Names use lowercase underscores, but the pattern is inconsistent: some are simple verbs (search, read, rebuild), one is a noun (summary), and three are verb_noun (list_domain, search_history, search_log). A more uniform verb_noun pattern would improve consistency.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of managing and querying history domains, command history, and logs. Each tool contributes meaningfully without redundancy.
Completeness4/5
The tool surface covers essential operations: search, list, read, and summarize across domains, plus separate search for history and log. Minor gaps like missing delete or create operations are acceptable for a viewer-oriented server.
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
- 7 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 carries the full burden. It implies a read-only operation (listing files) but does not disclose behavioral traits such as whether data is sorted, paginated, or if any side effects occur. No mention of authentication, permissions, or rate limits.
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?
The description is front-loaded with the purpose and includes a clean arg list. Every sentence adds value with no redundancy. Could be slightly more concise by omitting 'Args:' label, but overall efficient.
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?
Given that an output schema exists, the description does not need to detail return values. It covers parameter semantics adequately and implies the tool is for enumeration. However, it lacks context on sorting, pagination, or how to handle large result sets, which is reasonable for a listing tool.
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 description coverage is 0%, so the description compensates well by explaining the domain parameter with explicit allowed values, date parameters with format hints, and max_results with a default. This adds significant meaning beyond the raw 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 the tool lists files in a domain with metadata and summaries, using the specific verb 'List'. It mentions allowed domain values (sessions, transcripts, notifications), which clarifies scope. However, it does not explicitly differentiate from sibling tools like 'search' or 'summary', leaving some ambiguity.
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 notes that date parameters are optional and max_results has a default, but provides no guidance on when to use this tool versus alternatives (e.g., 'search' or 'read'). It does not specify prerequisites or conditions for use.
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 provided, the description must fully convey behavioral traits. It mentions the summary is 'AI-generated' but does not disclose whether the tool is read-only, has latency, requires authentication, or may fail for missing IDs. This omission leaves the agent uncertain about side effects or performance characteristics.
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 extremely concise with two short sentences plus an argument list. It is front-loaded, no redundant information, and every word adds value. Ideal length for a simple parameterized tool.
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?
Given the tool's simplicity (two parameters, no annotations, output schema exists), the description covers the core usage. It could benefit from noting that the domain must be supported (e.g., sessions or transcripts) and that the id should correspond to an existing entry. Nonetheless, it is nearly complete for a basic retrieval.
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?
The input schema has 0% description coverage, so the description must compensate. It adds meaning by explaining 'domain' can be 'sessions, transcripts' and 'id' is a 'file/directory name or unique prefix'. However, these explanations are somewhat vague (e.g., what constitutes a 'unique prefix'?) and do not provide full parameter semantics.
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 the tool retrieves an AI-generated summary for a domain entry, specifying domain and id as parameters. It distinguishes from siblings like read (full entry) and list_domain (listing entries) by its focus on summaries, but does not explicitly contrast them.
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 indicate prerequisites, such as needing to list domains first or that the summary might be generated on demand. This lack of usage context reduces the tool's usability for selecting between siblings.
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 behavioral traits. It only says 'Rebuild', which implies a write/destructive operation, but does not mention idempotency, side effects, or required permissions.
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 extremely concise with two lines plus a brief Args section, all front-loaded. Every sentence is necessary and there is no wasted text.
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?
Given the simplicity of one optional parameter and the existence of an output schema, the description covers the basic purpose. However, it lacks any mention of when rebuild is needed or what the output contains, making it minimally complete.
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?
With 0% schema description coverage, the description adds crucial meaning by explaining the 'domain' parameter and the special value 'all'. It could be improved by listing valid domain values or constraints.
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 action ('Rebuild') and the resource ('FST indexes'), and it distinguishes itself from sibling tools that are for searching, reading, or summarizing.
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 like 'search' or 'read'. It lacks any context about prerequisites or conditions for rebuilding indexes.
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?
The description discloses behavioral details: returns entries 'newest first' with default max_entries=50, and domain-specific filters for role and speaker. However, it does not mention whether the tool is read-only or has side effects, nor does it describe error handling or output format. Without annotations, more transparency would be beneficial.
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 very concise, front-loaded with the main purpose, and uses a clear bullet-like format for parameters. Each line serves a purpose with no extraneous text, making it efficient for an AI agent to parse.
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 description covers core functionality and parameter usage adequately for a read tool with 5 parameters. It explains ordering and defaults. However, it could be more complete by clarifying how the output is structured (though an output schema exists) and the exact semantics of the 'id' parameter (e.g., unique prefix matching). Overall, it is sufficient but not exhaustive.
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 description adds significant meaning to each parameter beyond the schema, which has 0% description coverage. It explains the purpose of domain, id, max_entries, role, and speaker, including domain-specific constraints (e.g., role only for sessions). This compensation is crucial and well-executed.
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 starts with 'Read entries from a domain file.', clearly stating the action and resource. It specifies domain options (sessions, transcripts, notifications) and the tool name 'read' naturally distinguishes from sibling tools like 'search', 'list_domain', etc., which have different verbs and purposes.
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?
No guidance on when to use 'read' versus alternatives like 'search' or 'list_domain'. The description only explains parameters without contextual advice or exclusions, leaving the agent to infer appropriate usage from tool names alone.
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?
No annotations are provided, so the description must carry the full burden. It discloses parameter behavior but does not state whether the tool is read-only, what side effects exist, or any permission requirements. The lack of explicit behavioral traits is a gap.
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?
The description is concise and front-loaded with the purpose, followed by a clear parameter list. Each sentence adds value, though the structure could be slightly more integrated.
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?
Given the presence of an output schema, the description adequately covers input parameters. However, it lacks context about the scope of the command history (e.g., user-specific or system-wide) and does not mention return format beyond what the schema provides.
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 description provides detailed explanations for all four parameters, including default values and the meaning of flags like regex and case_sensitive. Since the schema has 0% description coverage, this adds crucial meaning beyond the parameter names.
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 searches the Vibe command history file, with a specific verb and resource. This distinguishes it from sibling tools like 'search' and 'search_log' which likely operate on different data.
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 for searching command history but provides no explicit guidance on when to use this tool over alternatives like 'search' or 'search_log'. No when-not-to-use or alternative suggestions are given.
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?
The description explains key behaviors: regex usage, case sensitivity, level filtering, and max_results limit. It does not explicitly state that the operation is read-only, but with no annotations, the description provides good transparency about the search behavior.
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?
The description is well-structured with a clear bullet-like Args list. It is efficient but could be slightly more concise; however, it earns its length by covering all parameters meaningfully.
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?
Given that an output schema exists, the description need not explain return values. It fully covers input parameters and operation context. Could mention the log file location or that it's read-only, but overall complete.
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?
Every parameter (query, max_results, regex, case_sensitive, level) is described with its purpose, default value, and behavior. This fully compensates for the 0% schema description coverage.
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 searches the Vibe runtime log (vibe.log), with specific verb 'Search' and explicit resource. It distinguishes itself from siblings like 'search' by targeting a specific log 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 description explains what the tool does but does not explicitly state when to use it over alternatives (e.g., generic 'search' tool). It implies usage for log filtering but lacks explicit when-not or alternative references.
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?
No annotations are provided, so the description carries full burden. It discloses behavioral traits like FST-backed search, regex support, date range filtering, and default values. It does not mention read-only status, but the name and context imply no destructive effects.
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?
The description is well-structured with a brief intro, a domain list, and a parameter table. It is slightly lengthy but every sentence adds value. The main purpose is front-loaded, and the parameter descriptions are 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?
All 11 parameters are explained, and domains are explicitly listed. Although the output schema exists separately and the description does not detail return values, the input side is fully covered, making it complete for selection and invocation.
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?
Schema description coverage is 0%, but the tool description provides thorough explanations for all 11 parameters, including defaults and domain-specific applicability (e.g., role for sessions, speaker for transcripts). This far exceeds the schema's bare property definitions.
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 'Search across domains with FST-backed full-text search' and enumerates specific domains (sessions, transcripts, notifications, all). This distinguishes it from sibling tools like search_history or search_log by emphasizing cross-domain full-text search capabilities.
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?
The description lists domains and hints at use cases (e.g., 'transcripts supports speaker filter'), but does not explicitly state when to avoid this tool in favor of alternatives. However, the domain list provides clear context for selection.
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/jmars/unified-history-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jmars/unified-history-mcp)

Score Badge

Copy to your README.md:

[![unified-history-mcp MCP server](https://glama.ai/mcp/servers/jmars/unified-history-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jmars/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/jmars/unified-history-mcp'

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