Lorekeeper

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Tools are mostly distinct: lore_insert and lore_remember both add memories but target different use cases (bulk vs single fact). Otherwise, each tool has a clear, separate purpose.
Naming Consistency4/5
All tools use consistent snake_case verb_noun pattern with 'lore_' prefix. The only slight deviation is 'lore_processed_sessions' where 'processed' is an adjective instead of a verb, but it still follows the overall pattern.
Tool Count5/5
With 8 tools covering insert, search, update, soft-delete, link suggestion, and session reflection, the count is well-scoped for a memory store server.
Completeness4/5
Core CRUD operations are present, plus advanced features like link recommendation and quality feedback. Missing an undelete tool but it's a minor gap that agents can work around.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 79 of 125 community issues answered or closed in the last 6 months
- 184 commits in the last 12 weeks
- Last stable release on June 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 provided, so description carries full burden. It states 'Insert' indicating a write operation, but lacks details on side effects, authorization needs, or whether existing memories can be overwritten (force parameter is not explained).
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 bullet points and front-loads the main action. It is moderately long but each part adds value. Could be slightly more concise by removing redundant phrasing.
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?
Provided output schema exists but description does not mention return values. Details for memories and links are thorough, but missing explanation of 'force' parameter. For an insertion tool, this is adequate but not complete.
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 0%, but description compensates well for 'memories' and 'links' parameters by specifying required fields and optional fields with defaults. However, it does not mention the 'force' parameter, leaving its role unclear.
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 'Insert memories and/or links into the store.' It details the specific structure of memory dicts and links, distinguishing from sibling tools like lore_search or lore_forget by focusing on insertion.
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 use for inserting data, but does not explicitly state when to use this tool versus alternatives like lore_update or lore_reflect. No when-not scenarios or alternative tool mentions.
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 only describes the action as 'capture instantly' and mentions 'minimal effort', but fails to disclose side effects (e.g., persistence behavior, deduplication, or auth requirements). The description is too vague for a storage operation.
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, using short paragraphs and imperative tone. It front-loads the purpose and usage, but the motivational third paragraph is not strictly necessary. Overall, it is efficient.
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 relatively simple with 2 parameters and an output schema (present but unused in description). The description does not mention return values or confirm what happens after capture. It is adequate but could be more complete.
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%, and the tool description adds no new information beyond what the schema already explains. The baseline score is 3, and the description does not justify a higher score.
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 verb 'capture' and names the resource 'thought'/'fact', clearly indicating the tool's action. It distinguishes from siblings like lore_forget and lore_search by emphasizing 'one fact, one call' and storage rather than retrieval or deletion.
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 explicitly states when to use the tool: 'when you discover something worth keeping' with specific examples (decision, bug root cause, etc.). It implies when not to use it by contrasting with sibling tools, but does not provide explicit exclusions.
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 must disclose behavioral traits. It does so by explaining the auto_insert parameter, which automatically inserts memories with specific scores and duplicate guarding. This is a significant side effect clearly communicated. However, it does not mention other potential behaviors like authorization requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately convey the purpose and minimal usage. Every sentence is essential and well-structured, with no wasted words.
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 13 parameters, 2 required, and the presence of an output schema, the description is reasonably complete. It addresses the core purpose, minimal usage, and the auto_insert behavior. However, it could be improved by noting expected return values (though output schema exists) or conditions for use versus other tools.
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%, with all parameters having descriptions. The tool description adds value by emphasizing minimal usage (session_id and summary) and characterizing other parameters as 'extras', which helps prioritize. But it doesn't add significant new meaning beyond the schema descriptions.
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 is for reflecting on a completed session and saving learnings. It uses specific verbs (reflect, save) and resources (session, summary). However, it does not explicitly differentiate from sibling tools like lore_insert or lore_remember, which might also involve saving information. The context of 'session' provides some distinction.
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 clear minimal usage ('pass session_id and summary') and notes that other parameters are extras for substantial discoveries. This implies when to use the tool (after a session) but does not offer guidance on when not to use it or how it compares to alternative tools like lore_insert or lore_remember.
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?
With no annotations, the description carries full burden. It states a read operation (returning IDs) but does not mention safety, side effects, or access requirements. The description is minimal but adequate for a simple retrieval 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?
One sentence, no wasted words. Efficient 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and existence of an output schema, the description is largely sufficient. It could mention that it returns all processed session IDs, which it does. Lacks detail on potential pagination or limits, but for a simple tool it is complete enough.
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?
There are no parameters, so schema coverage is 100%. The description confirms that no filtering is possible, which aligns with the schema. Baseline for 0 parameters is 4, and the description adds no unnecessary details.
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 verb 'Return', the resource 'session IDs that have been marked as processed', and the condition 'via lore_reflect'. It effectively distinguishes from siblings like 'lore_reflect' which marks sessions as processed.
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 after 'lore_reflect' has been called, but does not explicitly state when to use or when to use alternatives. No guidance on exclusions or prerequisites.
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, the description carries full burden. It discloses that the tool is read-only ('Does NOT write any links') and returns ranked candidates with scores. It does not cover error handling or prerequisites, but the core behavioral trait is clear.
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 sentences, front-loading purpose and output, then adding critical behavioral detail. No wasted words.
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 output format is partially described ('ranked candidates with per-signal scores'), and the tool relationship is given. However, input parameters are not elaborated, and differentiation from other siblings (e.g., lore_search) is missing. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only implicitly explains 'lore_id' as the source memory through phrasing. 'top_k' is not mentioned at all. The description does not add sufficient meaning beyond the schema, leaving parameter purpose unclear.
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 suggests link candidates between a memory and related memories, using specific action ('suggest') and resource ('link candidates'). It distinguishes from the sibling tool 'lore_insert' by explicitly noting that it does not write links.
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 provides clear context for using this tool (to get link candidates) and directs to call lore_insert for actual writing. However, it does not explicitly mention when not to use it beyond the write action.
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 of behavioral disclosure. It states that the tool returns top candidates from the pending queue sorted by quality score, implying a read-only operation. This is sufficient for a simple retrieval, though it does not explicitly confirm non-destructive behavior or any authorization needs.
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, consisting of only two sentences plus a usage hint. It is front-loaded with the main purpose, and every sentence contributes value without any redundant or extraneous information.
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, the presence of an output schema (so no need to explain return values), and good schema coverage, the description is largely complete. It provides the core purpose, a usage guideline, and references the sibling tool. It does not cover edge cases or prerequisites, but for this straightforward retrieval, it is sufficient.
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%, with both 'limit' and 'min_score' parameters already well-documented in the input schema. The description adds little beyond what the schema provides, such as noting the 'quality score' sorting. Hence, the description adds only marginal value, fitting the baseline score of 3.
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 'Retrieve' and clearly identifies the resource as 'pending link suggestions' sorted by quality score. It distinguishes itself from the sibling tool 'lore_review_suggestion' by implying a sequential workflow, making the tool's purpose unambiguous.
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 explicitly tells the agent to use 'lore_review_suggestion' for acceptance or rejection, providing a clear next step and some context on when this tool is appropriate. However, it does not explicitly state when not to use this tool or mention alternatives beyond the one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: independent processing per item, no deletion of suggestion rows (audit trail), fallback type on accept, and idempotency with 'skipped' status. This covers all critical 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 concise (~100 words) with a clear, front-loaded main action. Each sentence adds necessary detail without fluff. The structure (overview, process details, idempotency) is logical and easy to scan.
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?
Given the tool's complexity (batch processing with side effects), the description sufficiently explains independence, idempotency, status updates, and fallback behavior. An output schema exists further complementing the documentation, so no additional return value info is needed.
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 the description adds minimal extra meaning beyond the schema. It confirms action values ('accept'/'reject') and that suggestion_ids can be one or many, but these are already clear from the schema types and 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 clearly states the tool's purpose: 'Accept or reject one or more link suggestions'. This specific verb+resource combination distinguishes it from siblings like lore_get_suggestions (retrieval) and lore_recommend_links (generation).
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 reviewing suggestions after retrieval, but does not explicitly state when to use this tool versus alternatives (e.g., when to use lore_get_suggestions first). No when-not or alternative tool guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the soft-delete behavior, the marking of soft_deleted=1, exclusion from search, and the fact that undeleting is only possible at DB level.
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?
Two sentences, no wasted words, front-loaded with the main purpose.
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 delete operation, the description covers the action, side effects, and a key behavioral note (no undelete tool). Output schema is present, so return values need not be explained.
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?
Input schema covers 100% of parameters with descriptions. The tool description adds no new information about parameters beyond the schema, meeting the baseline but not exceeding it.
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 'soft-delete' and the resource 'memories by ID', distinguishing it from sibling tools like lore_insert or lore_search.
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 explains the effect (soft deletion, exclusion from search) and notes irreversibility via tool, but does not explicitly advise when not to use it or compare to 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, the description discloses key behaviors: two pipeline modes, silent skipping of unknown IDs in ID lookup, effects of 'format' on token cost and 'include_links', interaction between 'refine_from' and ID cap, and sorting behavior differences. Missing explicit statement about read-only nature or authentication needs, but overall transparent.
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?
Highly efficient: a two-line summary upfront, then concise details about the ID path. Every sentence adds necessary information without redundancy. No filler.
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?
Given 12 parameters, 100% schema coverage, and an output schema, the description covers all key behavioral aspects: dual modes, parameter interactions, constraints (cap on IDs, UTC requirement), and formatting options. It is thorough and leaves no critical gaps for agent understanding.
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 100%, so baseline is 3. The description adds value by explaining inter-parameter dependencies (e.g., 'ids' ignores 'query', 'format=title' forces 'include_links=False'), constraints (max IDs for 'ids', UTC requirement for timestamps), and behavior variations ('sort_by' modes). This exceeds mere schema 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?
Clear verb ('search') and resource ('memories') with two distinct modes: semantic+keyword query and bulk-fetch by ID. The description distinguishes from sibling tools by specifying the types of retrieval operations, leaving no ambiguity about what the tool does.
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?
Provides explicit guidance on when to use the ID path versus the search path, including that 'query' is ignored in ID mode. However, it lacks direct comparison to siblings like 'lore_reflect' or 'lore_insert', relying on the context that this is a search/retrieval tool.
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, the description fully explains behavior: the effect of useful=True/False, confidence scaling, and soft-delete on repeated false low confidence. It omits error handling and permissions but covers core behavioral traits adequately.
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?
Five sentences, each necessary: purpose first, then detailed feedback structure, then behavioral effects and usage advice. No fluff.
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?
Given that an output schema exists, the description need not explain return values. It covers parameter structure, behavioral effects, and usage context completely for a feedback loop tool.
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 coverage is 0%, but the description provides complete structure for both parameters, specifying keys (id, useful, confidence) and types/range. This fully compensates for the schema's lack of detail.
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 explicitly states the verb 'rate' and the resources 'memories' and 'links', clearly indicating the tool's function. It distinguishes itself from siblings by specifying it drives the 'quality signal loop' and is used after lore_search.
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 explicitly states to call after every lore_search to keep scores calibrated, providing clear when-to-use guidance. It does not include when-not-to-use or alternative tools, but the context is strong enough for correct invocation.
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:

[![Lorekeeper MCP server](https://glama.ai/mcp/servers/Jessinra/Lorekeeper/badges/card.svg)](https://glama.ai/mcp/servers/Jessinra/Lorekeeper)

Score Badge

Copy to your README.md:

[![Lorekeeper MCP server](https://glama.ai/mcp/servers/Jessinra/Lorekeeper/badges/score.svg)](https://glama.ai/mcp/servers/Jessinra/Lorekeeper)

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/Jessinra/Lorekeeper'

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