Claude Historian

by Vvkmnn

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, such as extract_compact_summary for session summaries and find_file_context for file-related conversations. However, find_similar_queries and search_conversations could potentially overlap in functionality, as both involve searching through conversation history, which might cause minor confusion for an agent.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as extract_compact_summary, find_file_context, and search_conversations. This predictability makes it easy for an agent to understand and navigate the tool set without naming-related confusion.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose of analyzing conversation history and patterns. Each tool appears to serve a specific function, such as summarizing sessions, finding errors, or searching plans, making the count appropriate and manageable for the domain.
Completeness4/5
The tool set covers key aspects of conversation analysis, including summarization, searching, error resolution, and pattern detection. A minor gap might be the lack of tools for modifying or annotating historical data, but the surface is largely complete for querying and insights, allowing agents to work effectively within the domain.
Average 3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 of behavioral disclosure. It mentions analysis but does not detail how the analysis is performed, what data sources are used, whether it involves read-only operations or mutations, or any rate limits or permissions required. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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 a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and waste, making it easy to parse. However, it could be slightly more structured by explicitly separating the analysis focus from the output implications, but overall it is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analysis of patterns with 3 parameters) and lack of annotations or output schema, the description is incomplete. It does not explain what the analysis yields, how results are formatted, or any behavioral traits like data sources or limitations. This makes it inadequate for an agent to fully understand the tool's operation and expected outcomes.
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 100% description coverage, clearly documenting all three parameters with enums and defaults. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analyze tool usage patterns, workflows, and successful practices,' which provides a general purpose but lacks specificity about what resources or data it operates on. It distinguishes itself from siblings like 'search_conversations' or 'list_recent_sessions' by focusing on patterns rather than direct data retrieval, but the verb 'analyze' is vague without clarifying the analysis method or output format.
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 explicit guidance is provided on when to use this tool versus alternatives. The description implies usage for analyzing patterns, but it does not specify scenarios, prerequisites, or exclusions. For example, it does not differentiate from 'find_similar_queries' or 'get_error_solutions,' leaving the agent to infer based on general terms without clear context.
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 mentions 'intelligent summary' and 'key insights', which hints at analysis behavior, but it doesn't describe critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like. For a tool with no annotations, this is a significant gap in transparency.
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 single, efficient sentence that front-loads the core purpose ('Get intelligent summary of a conversation session') and adds a clarifying detail ('with key insights'). There is no wasted verbiage, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context, usage guidelines, and details on output format, which are crucial for an agent to use the tool effectively. The high schema coverage helps, but the description doesn't compensate for other gaps.
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 schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds no additional semantic information about the parameters beyond what the schema provides, such as explaining the 'focus' options in more detail or giving examples. Thus, it meets the baseline score without compensating further.
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's purpose with a specific verb ('Get') and resource ('summary of a conversation session'), and it adds value by specifying 'intelligent summary' and 'key insights'. However, it doesn't explicitly differentiate this from sibling tools like 'search_conversations' or 'list_recent_sessions', which might also involve conversation analysis, so it doesn't reach the highest score.
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 doesn't mention sibling tools like 'search_conversations' or 'list_recent_sessions', nor does it specify contexts or exclusions for usage. This leaves the agent without clear direction on tool selection.
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 burden. It mentions 'smart activity detection and summaries' which hints at some processing behavior, but doesn't disclose critical details like whether this is a read-only operation, what permissions might be needed, rate limits, or how the 'smart' detection works. The description is vague about actual behavioral traits.
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 single, efficient sentence that gets straight to the point. Every word contributes to understanding the tool's purpose without any wasted text. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'recent' means temporally, what format the results come in, what 'smart activity detection' entails, or how summaries are generated. The description leaves too many questions unanswered for a tool that presumably returns structured session data.
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 description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how parameters interact or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Browse') and resource ('recent sessions'), and mentions additional features ('smart activity detection and summaries'). However, it doesn't explicitly differentiate this tool from sibling tools like 'search_conversations' or 'extract_compact_summary', which might have overlapping functionality.
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. With siblings like 'search_conversations' and 'extract_compact_summary' available, there's no indication of when this browsing tool is preferred over those search or extraction tools.
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 carries full burden but only vaguely mentions 'smart insights' without explaining what these entail (e.g., ranking, relevance scoring, or AI-enhanced filtering). It doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'search' means operationally (e.g., full-text, metadata). This leaves significant gaps for a search tool.
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 a single, efficient sentence that front-loads the core purpose. However, 'smart insights' is vague and could be more precise. It avoids redundancy but misses opportunities to add critical context, making it slightly under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or the 'smart insights' feature, leaving the agent unsure of behavioral outcomes. Given the complexity and lack of structured data, more detail is needed to guide effective tool use.
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 description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema, not explaining how 'query' interacts with 'smart insights' or clarifying parameter interdependencies. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with additional context.
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 searches through 'Claude Code conversation history with smart insights', specifying both the verb (search) and resource (conversation history). It distinguishes from siblings like 'list_recent_sessions' (which lists rather than searches) and 'find_similar_queries' (which focuses on queries rather than conversations). However, it doesn't explicitly mention what 'smart insights' entail, 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 provides no guidance on when to use this tool versus alternatives like 'list_recent_sessions' for recent conversations without search, 'find_similar_queries' for query analysis, or 'search_plans' for different content. It mentions 'smart insights' but doesn't clarify what contexts benefit from them versus basic search, offering no explicit when/when-not instructions.
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 mentions 'find all conversations and changes,' implying a read-only operation, but doesn't specify permissions, rate limits, data sources, or response format. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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 single, efficient sentence: 'Find all conversations and changes related to a specific file.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.
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 tool has 4 parameters with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral context, usage guidance, and output details. For a search tool with moderate complexity, it should do more to compensate for the missing structured data.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, default behaviors, or practical examples. With high schema coverage, the baseline score of 3 is appropriate.
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's purpose: 'Find all conversations and changes related to a specific file.' It specifies the verb ('find'), resource ('conversations and changes'), and target ('specific file'). However, it doesn't explicitly differentiate from sibling tools like 'search_conversations' or 'list_recent_sessions', which might have overlapping functionality.
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 doesn't mention sibling tools like 'search_conversations' or 'list_recent_sessions', nor does it specify prerequisites, exclusions, or contextual triggers for usage. The agent must infer usage from the purpose alone.
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 carries full burden for behavioral disclosure. It mentions 'enhanced matching' but doesn't explain what this means operationally—how similarity is determined, what data sources are searched, whether results are ranked, or what the output format looks like. This leaves significant gaps for a search tool.
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 single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core 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?
Given the tool's moderate complexity (search with similarity matching), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavior, output format, and usage context that would help an agent invoke it correctly.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, meeting the baseline for high coverage.
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's purpose: 'Find previous similar questions or queries with enhanced matching'. It specifies the verb ('Find') and resource ('previous similar questions or queries'), but doesn't differentiate from siblings like 'search_conversations' or 'get_error_solutions' which might have overlapping functionality.
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 is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'search_conversations' or 'get_error_solutions', nor does it specify context or prerequisites for using this tool.
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 mentions 'enhanced matching,' which hints at improved search capabilities, but doesn't explain what 'enhanced' entails, such as fuzzy matching or prioritization. It also omits details like rate limits, authentication needs, or response format, leaving gaps in understanding the tool's behavior.
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 single, efficient sentence: 'Find solutions for specific errors with enhanced matching.' It's front-loaded with the core purpose and avoids unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on behavioral traits, usage context, or output expectations. While it covers the basics, it doesn't fully compensate for the absence of annotations or output schema, leaving room for improvement in completeness.
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 100% description coverage, clearly documenting all parameters: 'error_pattern,' 'limit,' and 'detail_level.' The description doesn't add any extra semantic meaning beyond this, such as examples or usage tips. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or enhance the parameter understanding.
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's purpose: 'Find solutions for specific errors with enhanced matching.' It specifies the verb ('Find') and resource ('solutions for specific errors'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_similar_queries' or 'search_conversations,' which might also involve error-related searches, so it doesn't reach the highest score.
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 doesn't mention sibling tools or contexts where this tool is preferred, such as for error troubleshooting versus general search. Without such distinctions, users might struggle to choose between this and tools like 'search_conversations' or 'find_similar_queries.'
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 states the tool searches for 'past implementation approaches, decisions, and patterns,' implying a read-only operation, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or response format. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Search Claude Code plan files for past implementation approaches, decisions, and patterns') contributes directly to understanding the tool's function, making it appropriately concise and well-structured.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose but lacks usage guidelines, behavioral details, and output information. Without annotations or an output schema, the agent has incomplete context for effective tool invocation, though the schema provides good parameter coverage.
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 description coverage is 100%, so the schema fully documents all three parameters (query, limit, detail_level) with descriptions, defaults, and an enum. The description adds no additional parameter semantics beyond what's in the schema, such as query syntax examples or detail-level implications. This meets the baseline score of 3 when schema coverage is high.
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's purpose: 'Search Claude Code plan files for past implementation approaches, decisions, and patterns.' It specifies the verb ('Search'), resource ('Claude Code plan files'), and target content ('implementation approaches, decisions, and patterns'). However, it doesn't explicitly differentiate from sibling tools like 'search_conversations' or 'find_tool_patterns,' which might have overlapping search domains.
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 doesn't mention sibling tools like 'search_conversations' or 'find_tool_patterns,' nor does it specify contexts, prerequisites, or exclusions for usage. The agent must infer usage from the purpose alone.
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:

[![claude-historian-mcp MCP server](https://glama.ai/mcp/servers/Vvkmnn/claude-historian-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Vvkmnn/claude-historian-mcp)

Score Badge

Copy to your README.md:

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

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