Rekindle

by Skitchy

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: v0.3.3
Disambiguation4/5
Most tools have distinct purposes: memory CRUD vs. session handoff vs. capture recovery. The only potential confusion is between capture_now and end_session, but descriptions clarify that end_session creates a structured handoff while capture_now preserves raw context for compaction recovery.
Naming Consistency5/5
All tool names follow a consistent snake_case verb-first pattern: end_session, list_captures, read_capture, store_memory, search_memory, list_memories, delete_memory, update_memory. Even boot_report and capture_now fit the verb-first style. No mixed conventions or unpredictable naming.
Tool Count5/5
Ten tools is well within the ideal 3-15 range and each tool serves a clear function in the memory/session management domain. No redundancy or bloat; the set feels appropriately scoped for the server's purpose.
Completeness4/5
Memory CRUD is covered (store, search, list, update, delete) and session handoff/orientation is addressed with end_session and boot_report. However, there's no direct 'get memory by ID' tool, which could force agents to use search or list and manually filter, a minor gap in the read path.
Average 4.5/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on August 9, 2026
- 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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states it is read-only and does not modify stored data, and it discloses that orientation scores are structural checks, not guarantees of loaded context. This adds valuable context beyond the basic function, though it doesn't detail the output format or potential edge-case errors.
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 efficiently structured: the first sentence states the core purpose, the second sentence explains the data sources and operations, and the third provides workflow and caveats. Every sentence contributes meaningful information without redundancy.
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 complexity (multiple inputs, calculations, and output), the description covers inputs, actions, and output semantics (orientation score, open loops, captures). No output schema exists, so the description does well to mention what the report includes. It lacks explicit return format details, but the description is strong overall.
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 all three parameters are already well-documented. The description adds no additional parameter-specific details beyond what the schema provides, but it does reiterate the purpose of identity and transcript paths. This matches the baseline for high 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 generates a session orientation report, with a specific verb (generate) and resource (session orientation report). It distinguishes itself from sibling tools by detailing its unique function of reading identity, scanning memory, and calculating an orientation score, which none of the siblings perform.
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?
It explicitly provides a workflow directive: 'call boot_report first thing every session, before any substantive work.' This gives clear contextual guidance on when to use it. However, it does not explicitly mention alternatives or when not to use it, but none are needed given its unique role.
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 full burden. It discloses read-only nature ('Read-only; does not modify any data'), ordering (newest first), and return fields. It does not cover potential pagination beyond the limit parameter or error handling, but overall provides solid 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 four sentences, front-loaded with the main action, and each sentence adds value. No unnecessary words or repetition. Highly efficient.
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 low complexity (3 optional parameters, no output schema, no annotations), the description covers purpose, usage guidance, behavior, return format, and ordering. It is complete enough for an agent to understand how and when to use the tool.
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 need not add much. It reinforces the ordering ('Newest memories are returned first regardless of limit') and lists return fields, which is helpful but not essential. The description does not significantly deepen understanding of the parameters beyond what the schema already provides.
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 'list', the resource 'memories', and the key distinction from sibling 'search_memory' by noting it does not require a query. It specifies the ordering (newest first) and return fields, making the 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 states when to use: 'to browse what has been stored, audit memory contents, or check memory counts per category or project'. It also contrasts with 'search_memory' (requires a query). However, it does not explicitly state when not to use or provide alternative tools beyond the mention of search_memory.
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 details three modes with token cost implications ('summary' cheap, 'structured' moderate, 'raw' expensive) and advises using raw only when lighter modes are insufficient. This goes beyond a simple read, giving the agent actionable behavioral guidance without contradicting any structured metadata.
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 about five sentences and front-loaded with the core purpose, then provides mode details and a workflow. It is efficient and avoids redundancy, though it lacks bullet-point formatting that could improve scannability. 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?
The tool has a moderate complexity (2 params, 3 modes) and no output schema. The description gives enough context for the agent to understand what to expect from each mode and how to use the tool effectively, covering purpose, mode selection, cost, and workflow. It does not describe error cases or exact return structures, but these are not critical for basic invocation.
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 100%, so baseline is 3. The description adds meaningful extra semantics, especially for the mode parameter: it expands on the schema by explaining 'summary' as one paragraph, 'structured' as decisions/loops/warnings, and 'raw' as full transcript excerpt, plus cost guidance. This enriches the schema 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 the verb 'Read' and the resource 'PreCompact capture by ID', and specifically ties it to recovering context lost during mid-session compaction. This distinguishes it from sibling tools like list_captures or capture_now by focusing on reading a specific capture.
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 says when to use the tool ('recover context lost during mid-session compaction') and provides a workflow: 'read recovered captures before relying on the latest checkpoint; start with the lightest mode that answers your question.' This gives clear context and usage strategy, though it does not explicitly mention alternatives to other sibling tools.
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?
Discloses file creation location, artifact equivalence with PreCompact, and optional parameters with auto-discovery. No annotations provided, so description carries full burden. Could mention idempotency or error handling but still provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence clearly states action and output. Second provides usage and parameter notes. Perfectly front-loaded and 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?
Describes artifact and auto-discovery for parameters, but does not explicitly state return value or success indication. With no output schema, the description could mention what the tool returns (e.g., path to capture). Still, very informative overall.
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?
Input schema has 100% description coverage. Description adds value by noting that session_id and transcript_path can be omitted and auto-discovered, going beyond schema. Reason parameter is not elaborated in description but schema covers it. Extra context earns above baseline.
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?
Description states specific verb ('capture') and resource ('current session context') and target location ('.rekindle/captures/'). Clearly distinguishes from siblings like list_captures and read_capture, as this is the creation tool.
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?
Explicitly states when to use: 'before a complex operation, when context feels at risk, or when the user requests it.' Also contrasts with automatic PreCompact hook. Lacks explicit 'when not to use' but positive guidance is strong.
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 the burden. It reveals the behavioral context of PreCompact captures and the recovery workflow, but doesn't detail return format or side effects, which are minimal for a list operation. Adds value beyond a simple 'list captures'.
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?
Three sentences, each earning its place: purpose, context, and workflow. Front-loaded with the primary action, concise with 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?
For a simple listing tool with one optional parameter and no output schema, the description provides sufficient context for selection and invocation. It also integrates with sibling tools (boot_report, read_capture, end_session), making the workflow 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?
The schema covers 100% of the parameters, so baseline is 3. The description does not add any extra semantic detail about session_id; it is fully explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists PreCompact captures, with a specific verb and resource. It distinguishes from siblings like read_capture by focusing on listing, and adds context about preserving pre-compaction context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow is given: if boot_report lists PreCompact captures, call list_captures then read_capture to recover context before relying on the checkpoint; also check for unreviewed captures before end_session. This clearly indicates when to use the tool versus alternatives.
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?
No annotations are provided, so the description carries full responsibility. It discloses key behaviors: partial field updates (omitted fields left unchanged), automatic updated_at timestamp, full-text search index rebuild on content change, and the exact return format for success and failure. This is comprehensive.
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 four sentences long, well-structured: first sentence states main purpose, second clarifies partial update behavior, third lists side effects, fourth gives use cases. No unnecessary words.
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 (partial updates, side effects like FTS rebuild, no output schema), the description covers all critical aspects: what fields can be updated, what happens to omitted fields, automatic timestamp, index rebuild, and the exact return format for both success and failure cases.
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 each parameter already described in the schema. The description adds minimal additional context, such as 'id' being obtainable from other tools. The partial update behavior is implied by the schema's 'Omit to keep' statements, so the description just reinforces. Baseline 3 is appropriate.
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: updating an existing memory in a local SQLite database. It specifies the verb 'update' and the resource 'memory', and distinguishes from sibling tools like store_memory and delete_memory by mentioning it avoids deleting and re-creating.
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 provides use cases: 'correct inaccurate memories, adjust importance, or reclassify a memory's category'. It implies not to use for creation (use store_memory) or deletion (use delete_memory), though it doesn't explicitly list when not to use or name 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 carries full burden. It discloses persistence across sessions, no deduplication, return value (generated ID), and that content should be self-contained. It also notes that memories are surfaced by other tools. No destructive behavior is relevant, and the description covers the key 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 paragraph of about 6 sentences, well-structured: action, details, usage examples, cross-references to other tools, return value, and a caveat. Every sentence earns its place without redundancy.
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 4 parameters with full schema descriptions, no output schema but return value explained, and no nested objects, the description is complete. It covers persistence, deduplication, and cross-tool integration, leaving no significant gaps for an AI agent to use this tool correctly.
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 100%, but the description adds significant value beyond the schema descriptions. For 'content' it specifies plain text with no length limit; for 'category' it explains impact on orientation scoring; for 'importance' it clarifies ranking and defaults for specific use cases; for 'project' it explains scoping and omission. This enriches the agent's understanding.
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 'Store' and the resource 'memory', and identifies it as persistent with auto-generated UUID and timestamp. It lists specific use cases (preferences, lessons, etc.) and explicitly connects to sibling tools (boot_report, search_memory, list_memories), distinguishing this creation tool from retrieval and deletion tools.
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 enumerates appropriate use cases (preferences, lessons, project context, etc.) and warns about the lack of deduplication. While it does not explicitly state when not to use, the positive guidance is strong and the deduplication caveat helps avoid misuse.
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 provided, the description fully covers behavioral traits: it warns of irreversibility ('This action is irreversible'), explains immediate deletion of both row and full-text search index entry, and details return values for both success and failure cases ('Returns {success: true} if found... or {success: false, message: 'Memory not found'} if ID does not exist'). It also states that other memories or session records are unaffected.
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 three sentences with no unnecessary words. The first sentence immediately conveys the action and scope. Each subsequent sentence adds important detail (irreversibility, usage guidance, return values). Everything is front-loaded and earns its place.
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 has only one parameter, no output schema, and no annotations, the description covers all necessary aspects: what it does, when to use it, behavioral implications (irreversibility), parameter sourcing, and return values. It is fully complete for this simple 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?
The only parameter 'id' is already described in the input schema ('The UUID of the memory to delete. Obtain from store_memory, search_memory, or list_memories results.'). The tool description reinforces this by mentioning how to obtain the ID. With 100% schema coverage, baseline is 3; the extra context in the description (e.g., 'Obtain from...') adds value, justifying a 4.
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 a specific verb ('Permanently delete') and resource ('a single memory from the local SQLite database'), clearly distinguishing it from sibling tools like store_memory, update_memory, or list_memories. The action is 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 states when to use the tool: 'Use when a memory is outdated, incorrect, or no longer relevant.' This provides clear context. However, it does not explicitly mention when not to use it or suggest alternatives (e.g., update_memory for correction), so it falls slightly short of a 5.
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?
No annotations are provided, so the description carries the full burden. It explicitly discloses multiple behavioral traits: writes to a local SQLite database, stores records with a typed 'type' column, links to session_id, creates a session row with summary/orientation/gap count, includes a warning for unreviewed PreCompact captures, and mentions searchability and boot_report retrieval. This is thorough and non-misleading.
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?
Although the description is moderately long, it is dense and well-structured. It begins with the core purpose, flows into storage details, and concludes with the workflow. Every sentence adds operational information, and there is no redundancy or 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 11 parameters, no output schema, and no annotations, the description covers all critical aspects: what gets written, how records are typed and linked, how to retrieve them later, the session row side-effect, and the warning behavior. It also explains the intended workflow. This is a complete description for a complex 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 coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by explaining the overall storage model (typed column, session_id linkage), the relationship to boot_report, and the workflow. However, it does not add much per-parameter detail that isn't already in the schema, so a 4 is appropriate.
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 a specific verb and resource: 'Capture a structured session handoff.' It clearly distinguishes from siblings like list_captures or store_memory by focusing on session-end aggregation and persistence. The phrase 'Writes multiple records to the local SQLite database' further specifies scope and behavior.
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 states a clear usage trigger: 'call end_session at the end of every substantive session so the next session can pick up the thread.' It provides clear context but does not explicitly name alternative tools or when not to use it, so it falls short of a 5.
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?
Discloses key behaviors: uses FTS5, results ranked by relevance and importance, increments retrieval_count on matched memories, returns specific fields, and returns empty array on no match. This is comprehensive given no annotations.
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?
Concise and well-structured (~90 words), each sentence serves a purpose: purpose, ranking info, side effect, usage, return structure, and empty case. No redundancy.
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?
Covers all essential aspects: search mechanism, ranking criteria, side effect (increment retrieval_count), return fields, and empty result handling. No output schema but description adequately describes return structure.
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 already has descriptions for all parameters (100% coverage). The description adds value by explaining query semantics ('Broader queries return more results') and limit behavior ('Results are ranked by relevance and importance before truncation').
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 performs a full-text search on stored memories using SQLite FTS5, distinguishing it from sibling tools like list_memories (which likely lists all memories) and other CRUD tools.
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 usage scenarios: 'Use at session start to load relevant context, or mid-session to recall specific information.' While it does not explicitly exclude alternatives, the guidance is clear and actionable.
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:

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

Score Badge

Copy to your README.md:

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

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/Skitchy/rekindle'

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