Claude Conversation Memory System

by adamkwhite

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Most tools target distinct resources or actions: add/get/update are clear CRUD operations, and the metadata-specific searches (by_tag, by_session_id, by_conversation_type) are well-scoped. However, search_conversations and search_by_topic overlap conceptually, and the distinction between generic content search and topic search is not sharply defined.
Naming Consistency4/5
The naming is predominantly verb_noun snake_case, with add_conversation, get_conversation, update_conversation, and generate_weekly_summary following a clear pattern. The search tools are slightly inconsistent because some use search_conversations while others use search_by_tag/search_by_session_id/search_by_conversation_type, but the style is still recognizable and predictable.
Tool Count4/5
Ten tools is a reasonable size for a conversation memory system, and the CRUD core plus search variants cover most expected workflows. The count is slightly search-heavy, with six retrieval-related tools, but none feel redundant enough to remove outright.
Completeness3/5
The system covers add, get, update, search, summary, and stats, which handles the core lifecycle for stored conversations. Notable gaps include no delete/forget operation, no list-all conversations tool, and no dedicated search_by_user_id even though user_id is described as a universal metadata field.
Average 3.6/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 99 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 behavioral burden. It implies a read-only search but does not disclose whether matching is exact, fuzzy, case-insensitive, or how results are ordered. It also omits any mention of pagination, limits beyond the schema default, or access/permission requirements.
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, front-loaded sentence that is easy to parse. It wastes no words and communicates the core action and resource immediately, though that brevity contributes to the lack of behavioral detail.
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 two parameters, no annotations, and several closely related sibling tools, the description is incomplete. An agent would need extra information about parameter semantics and when to prefer this over search_by_tag or search_conversations to invoke it correctly.
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 description coverage is 0%, and the description does little to compensate. It maps to the 'topic' parameter but says nothing about how topics are matched or interpreted, and it entirely ignores the 'limit' parameter and its default behavior.
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 states a clear verb ('Search'), a resource ('conversations'), and a filtering dimension ('by a specific topic'). This distinguishes it from siblings like search_by_tag and search_by_session_id, though it does not clarify the exact matching semantics of 'topic'.
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?
There is no guidance on when to use this tool versus alternatives such as the general search_conversations or the more specific search_by_tag. No context about typical use cases or exclusions is provided, leaving the agent to infer applicability from the tool name 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says a summary is generated; it does not clarify whether this is read-only, how the past week is calculated, whether it aggregates across all conversations or only certain types, or what data the summary contains.
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, tight sentence that front-loads the core purpose without wasted words. However, its brevity comes at the cost of omitting useful parameter and behavior details, so it is concise but slightly under-specified.
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?
Although the tool is simple and has an output schema, the description leaves the meaning of week_offset undefined, which is essential for correct invocation. An agent cannot determine how to request the desired week without additional assumptions, so the description is not complete enough on its own.
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?
The only parameter, week_offset, is not mentioned in the description at all. The schema provides its name, title, type, and default, but not what the offset means (e.g., 0 = current week, 1 = previous week) or how it relates to 'past week'. With 0% schema description coverage, the description needed to compensate and does not.
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 states a specific action ('Generate') and resource ('a summary of conversations') with a time constraint ('past week'). This distinguishes it from the sibling search/add/update/get tools as an aggregation operation, though it does not explicitly contrast it with any of them.
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 phrase 'past week' implies the tool is appropriate when a weekly summary is needed, but the description provides no explicit guidance on when to use this tool versus search_conversations or search_by_topic. No exclusions or alternative conditions are given.
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 the full behavioral burden. It does convey a read-style operation over stored conversations and mentions 'relevant content', which implies some relevance ranking, but it does not explain whether search covers full transcripts, metadata, summaries, or how results are ordered and limited.
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 with no filler and places the action and resource early. It earns its conciseness, though it is arguably too sparse to support tool selection among siblings.
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?
The input schema is simple and an output schema exists, so return structure may be covered elsewhere, but the tool sits in a crowded sibling set with multiple specialized search variants. The description does not explain when generic search is appropriate, leaving a meaningful selection gap for an agent.
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 description coverage is 0%, so the description must compensate for undocumented parameters, but it never mentions 'query' or 'limit' explicitly. The phrase 'relevant content' hints that query drives a relevance search and limit likely caps results, but that is inferred rather than stated.
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 states a specific verb ('search') and a clear resource ('stored Claude conversations'), so an agent can tell this is a search operation. It does not differentiate from sibling tools like search_by_topic, search_by_tag, search_by_session_id, or search_by_conversation_type, which all share the same search family.
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?
There is no guidance on when to use this generic search versus the specialized sibling search tools. With four search-by-* siblings plus get_search_stats, the description leaves the agent to infer which tool fits a given request.
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 at all, the description carries the full burden. It discloses validation/sanitization and the persistence/indexing behavior of the four metadata fields, which is useful. It does not mention the return value, whether the tool can duplicate conversations, or any side effects or failure modes beyond validation.
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 compact and readable, front-loading the core action and then explaining the metadata fields. The formatting is clean, though the trailing phrase about external imports is slightly tangential and could be trimmed.
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?
For a 7-parameter write operation with no annotations and no parameter descriptions in the schema, the description is under-equipped. It explains why the four universal fields exist and the indexing behavior, but it does not clarify return values, error conditions, or the meaning of date/title/content. The presence of an output schema helps, but the description still leaves significant 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 input schema lists 7 parameters but none of them have descriptions, and the description adds meaning only for session_id, user_id, tags, and conversation_type by explaining they are persisted and indexed. date, title, and content receive no semantic explanation beyond their names and types, which is a notable gap given the 0% schema description 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 adds a new conversation to the memory system, and it names the universal metadata fields. However, it does not explicitly contrast itself with the update_conversation sibling, which is an easy distinction to miss in an agent's selection process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the optional fields can be used for metadata search and that they may originate from external imports, which implies when these fields matter. It does not spell out when to prefer add_conversation over update_conversation or when certain metadata fields are required, leaving usage context implicit.
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 must carry behavioral context itself. It adds useful details: conversation_type is a D2 metadata field, typical values are chat/code/analysis, and SQLite FTS is required. However, it does not disclose read-only behavior, result-set behavior, or what happens when FTS is unavailable, leaving some burden unmet.
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: purpose first, then typical values, then the key prerequisite. Every sentence earns its place with no filler or repetition of schema 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?
For a simple single-field search tool, the description covers the essential domain context (D2 metadata field, typical enum-like values) and the important prerequisite (SQLite FTS). The presence of an output schema reduces the need to describe return values, so the remaining gaps are minor.
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 0%, so the description must compensate. It adds real meaning to the required conversation_type parameter by explaining it is a D2 metadata field and giving typical values. The optional limit parameter remains unspecified, though its name, type, and default make it fairly self-explanatory.
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 a specific verb ('Search') and resource ('conversations') filtered by 'conversation_type', so an agent immediately knows what the tool does. It does not explicitly compare against sibling tools, but the focused field name already differentiates it from search_by_topic, search_by_tag, and generic search_conversations.
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 gives no guidance on when to choose this tool over search_conversations or the other search_by_* siblings. It mentions a technical prerequisite ('Requires SQLite FTS') but does not explain alternative conditions, exclusions, or preferred usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It adds meaningful context: tags originate from importers, are universal, and can take namespaced forms like 'workspace:my-project'. The SQLite FTS dependency is also a useful behavioral hint. However, it does not mention return shape, limit handling, pagination, or potential errors, leaving several behavioral aspects undisclosed.
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 concise sentences, each earning its place: the core purpose, the tag semantics with concrete examples, and a required dependency. It is front-loaded with the action and contains no filler or 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?
For a simple two-parameter search tool with an output schema, the description covers the essential tag concept, provides real-world examples, and notes a critical prerequisite. The main gaps are the lack of explanation for the 'limit' parameter and the absence of sibling differentiation, but the output schema likely covers return values, so overall completeness is strong.
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 0%, so the description must compensate. It does explain the key 'tag' parameter thoroughly, including its nature as a D2 metadata field and providing examples. The 'limit' parameter, however, is entirely left to the schema's name and default value, with no description in either place.
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 states a specific action and resource: 'Search conversations tagged with a specific tag.' It further clarifies that tags are D2 metadata fields with concrete examples, which helps distinguish the tool from siblings like search_by_topic or search_by_session_id. However, it does not explicitly contrast itself against those sibling tools, so it stops short of a 5.
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 gives useful context for when the tool is applicable: tags are universal metadata populated by importers, and examples like 'starred' and 'archived' imply common use cases. It also states a prerequisite ('Requires SQLite FTS'), which is a form of usage constraint. Yet it offers no explicit guidance on when to prefer this tool over search_by_topic, search_by_conversation_type, or search_conversations, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The verb 'Get' implies a read-only operation and the lack of parameters suggests no destructive side effects. Still, it does not explicitly confirm safety, rate limits, or what 'performance information' includes.
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, front-loaded sentence with no filler. Every word contributes to identifying the tool's 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 parameterless tool with an output schema available, this description is sufficient for an agent to select and invoke it correctly. The lack of parameters removes invocation complexity, and the output schema covers return value details.
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 tool has zero parameters, which sets the baseline at 4. There is no parameter semantics to explain, and the description does not need to compensate for undocumented inputs.
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 a specific verb ('Get') and identifies a clear resource ('search engine statistics and performance information'). It is distinct from all sibling tools, none of which obviously cover search engine statistics.
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 intended use is implied by the name and description: use this when search engine statistics or performance are needed. However, there is no explicit guidance about when to use it versus alternatives, nor any mention of prerequisites or 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?
With no annotations provided, the description carries full behavioral burden. It adds meaningful traits beyond the schema: 'Results are sorted chronologically' and 'Requires SQLite FTS'. It does not mention exact-match semantics or permissions, but the read-oriented wording and presence of an output schema reduce ambiguity.
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 concise sentences: the first states the core function, the second gives the primary use case with examples, and the third provides ordering and a system prerequisite. Every sentence earns its place and there is no filler or 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?
For a two-parameter read tool with an output schema present, the description covers the purpose, a concrete use case, chronological ordering, and the SQLite FTS dependency. It does not explain the limit parameter's effect or mention alternative tools, but these are minor given the tool's simplicity and available output schema.
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 0%, so the description must compensate. It adds meaning for session_id by calling it a 'D2 metadata field' and explaining its role in reconstructing sessions, but the limit parameter is not described at all beyond its schema default. This partial compensation leaves one parameter without added context.
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 uses a specific verb ('Find') with a concrete resource ('all conversations sharing a session_id') and clarifies that session_id is a 'D2 metadata field', clearly distinguishing this from sibling tools that search by topic, tag, or conversation type. An agent can immediately understand what the tool returns and how it differs from alternatives.
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 clear context for when to use the tool: 'reconstructing a multi-turn session that spans several stored conversation records', with concrete examples like a Cursor working session or a Claude thread continued across days. It does not explicitly name alternatives or state when not to use it, but the use case is unambiguous.
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 the full burden and adds useful behavioral details: the read is from the 'authoritative JSON store', and the response content is capped to protect model context. It could mention error behavior when the ID is not found, but the disclosed behaviors go beyond a bare getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lean sentences with no filler. The primary purpose is front-loaded, and the second sentence adds a meaningful operational constraint about content truncation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description covers purpose, source, and the one tunable behavior (content cap). It is adequate for an agent to select and call the tool, though it leaves not-found/error behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does: conversation_id is contextualized as an ID returned from a search tool, and max_chars is explained as the content cap that can be increased when needed. It does not specify units or range, but the default in the schema covers some of that gap.
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 a specific verb ('Retrieve') and a clear resource ('a stored conversation by an ID'), which immediately identifies it as a point-lookup tool. The mention that the ID comes from a search tool further separates it from the search-family siblings.
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 usage context: call this after obtaining a conversation ID from a search tool. It does not explicitly name sibling alternatives or state when not to use it, but the intended workflow is evident.
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 carries the full burden and succeeds. It discloses that the first line of content is rewritten with a self-documenting audit line, change_note can be auto-derived, tag operations have specific replace/mutate semantics with mutual exclusivity, metadata is validated/sanitized, and record_audit=False preserves imported content verbatim. These are all meaningful behavioral traits beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the core purpose in the first sentence. Each paragraph earns its place: partial update mechanics, audit behavior, tag semantics, metadata validation, and special record_audit usage. It is detailed without being bloated.
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 annotations, and no schema-level descriptions, this description is remarkably complete. It covers partial updates, audit-line side effects, tag exclusivity, metadata sanitization, and audit suppression. The presence of an output schema covers return-value expectations, so no critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does well for tags, change_note, record_audit, conversation_id, and metadata fields, but title and content are only covered implicitly via 'any subset of fields to change.' The tag semantics and audit behavior add substantial value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update fields on an existing conversation in place.' This clearly identifies the action and scope, distinguishing it from add_conversation, get_conversation, and the search family without ambiguity.
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 gives clear context for when to use the tool: modifying an existing conversation by passing conversation_id with a subset of fields. It also provides usage guidance for record_audit, recommending default audit for interactive updates and record_audit=False for preserving authoritative imports, but it does not explicitly name sibling tools or state when not to use it.
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:

[![universal-memory-mcp MCP server](https://glama.ai/mcp/servers/adamkwhite/universal-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adamkwhite/universal-memory-mcp)

Score Badge

Copy to your README.md:

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

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