Changes Memory MCP

by formonkey

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct, but list_changes and list_change_index both list changes, and search_changes vs get_relevant_changes could overlap. Descriptions help clarify the intended use cases, so the ambiguity is limited.
Naming Consistency5/5
All tool names follow a consistent verb-first snake_case pattern (e.g., add_local, search_changes, get_change). The add_local/add_global pair uses a predictable scope suffix, and the naming aligns well across the set.
Tool Count5/5
With 8 tools, the server is well-scoped for a memory management system. Each tool serves a clear purpose, and the count is within the expected range to avoid unnecessary complexity.
Completeness3/5
The server covers creation, retrieval, search, and listing, but lacks update and delete operations for changes. Without these, correcting or removing stored memories is not possible, which is a notable gap in lifecycle coverage.
Average 3.5/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=false, which matches the 'Guarda' action, but the description adds no further behavioral context. It does not mention persistence semantics, overwrite behavior, authorization requirements, or side effects, which is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It is concise and readably structured, though its brevity sacrifices important details that are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, only readOnlyHint=false as an annotation, and a rich set of sibling tools, the description is far too sparse. It fails to address return values, the meaning of fields like before/after/relatedPaths, or how global entries interact with local ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10% (only the 'tags' parameter has a description), and the tool description does not explain any parameters. Required fields like title, summary, requestedChange, and rationale are left entirely to name inference, which is insufficient for a 10-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Guarda') and the resource ('memoria global'), specifying the content type ('correccion o criterio transversal'). The 'global' qualifier distinguishes it from sibling add_local, though it could more explicitly contrast local vs global storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is given. The description does not mention when to prefer add_global over add_local, nor any prerequisites or exclusion criteria. The only hint is the word 'global', which is implicit rather than explicit.
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?
Annotations indicate readOnlyHint=false, and the description confirms a write action ('guarda'), but no additional behavioral details are disclosed, such as whether it overwrites existing entries, merges with prior data, or requires specific permissions. The description adds little beyond what the annotation already conveys.
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 superfluous words. It is concise and to the point, ensuring the core purpose is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 5 required, no output schema), the minimal description is insufficient. It does not clarify required fields, what the tool returns (if anything), or side effects, leaving significant gaps for a mutation tool with many inputs.
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?
With only 18% schema description coverage, the description should compensate, but it does not explain the 11 parameters or the 5 required fields beyond a generic notion of 'correccion o criterio aprendido'. Tags and projectPath have limited schema descriptions, but title, summary, requestedChange, rationale, and others remain undocumented, leaving the agent without sufficient guidance.
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 ('Guarda') and identifies the resource ('una nueva correccion o criterio aprendido') with a clear location ('en la memoria del proyecto'). This distinguishes it from the sibling tool add_global, which targets global memory, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'memoria del proyecto' implies a local scope, suggesting use for project-specific knowledge, but the description does not explicitly contrast with add_global or other alternatives like search_changes. No exclusions or 'when not to use' guidance are provided, so usage is inferred but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares a safe read operation, so the description does not need to repeat that. The description adds the 'free text' search behavior but does not disclose scope (project vs global) or return format. This is acceptable given the annotation covers the main safety concern.
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, focused sentence with no wasted words. It is front-loaded and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description is minimally adequate but lacks important context. It does not explain how this tool differs from 'get_relevant_changes', nor does it mention that the search operates on local memory (as indicated by projectPath and includeGlobal). The schema provides parameter details, but without an output schema, the return format is not disclosed, and the description does not compensate.
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 60%, with descriptions for projectPath, includeGlobal, and includeProject, but not for query and limit. The description adds meaning to 'query' by calling it 'texto libre' (free text), but does not clarify 'limit' or other parameters beyond what the schema already provides. It provides some added value but does not fully compensate for the missing parameter 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 'Busca cambios por texto libre' clearly states the tool's function: searching changes by free text. It uses a specific verb (search) and resource (changes). However, it does not distinguish from the sibling tool 'get_relevant_changes', which likely also searches changes in a similar manner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_relevant_changes' or 'list_changes'. There is no mention of intended use cases, exclusions, or relationships to sibling tools.
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?
Annotations declare readOnlyHint=true, and the description's 'Devuelve' is consistent (read operation). The description adds little beyond the annotation, not explaining how relevance is determined or that it uses local/project memory (as suggested by parameters). With annotations covering the safety profile, a 3 is appropriate.
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, concise sentence with no redundancy or fluff. It front-loads the verb and resource, though it could briefly mention the memory aspect without becoming verbose.
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 description states the tool returns relevant changes but does not explain the retrieval mechanism or the use of global/project memory (evident from parameters). With no output schema, more details about the returned content would improve completeness, but the purpose is still clear.
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 description clarifies that the 'task' parameter refers to a task or risk ('tarea o riesgo concreto'), adding meaning to the otherwise undocumented schema field. However, it does not explain 'limit' or other parameters, and schema coverage is only 60%, so the description only partially compensates.
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 uses the verb 'Devuelve' (returns) and identifies the resource 'cambios relevantes' (relevant changes) for a specific task or risk, providing specific scope. It distinguishes from sibling tools like list_changes or get_change by focusing on relevance to a task/risk, though it does not explicitly contrast with alternatives.
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 'para una tarea o riesgo concreto' gives a clear use case, implying when to use the tool. However, it provides no exclusions or comparison with siblings like search_changes, so guidance on alternatives is missing.
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?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds the scope of the listing (project and global memory), which is somewhat useful but does not disclose any other behavioral details such as ordering, pagination, or default inclusion of both memory types (though that is in the schema).
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 concise sentence that immediately conveys the function with no fluff.
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 description is brief but adequate for a simple read-only list operation, especially with the schema providing parameter details and annotations declaring safety. However, it lacks any usage guidance or mention of output format, and does not clarify when to prefer this over sibling search/relevant-change 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 already describes 3 of 4 parameters (limit lacks description but has type/min/max). The description does not add meaning beyond saying the changes come from project and global memory, which matches includeProject/includeGlobal. Thus it adds little beyond 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 the tool lists changes saved in project and global memory (verb 'Lista' + resource 'cambios guardados'). This distinguishes it from siblings like search_changes (search) and get_change (retrieve specific change).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like search_changes or get_change. It only states what it does, without any exclusions or recommendations.
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?
Annotations declare readOnlyHint=true, so the read-only nature is already communicated. The description adds that the retrieval is 'exacto' (exact) by id, but it does not disclose behavior when the id is not found, return format, or how includeGlobal/includeProject affect the lookup.
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 immediately expresses the core functionality with no filler or redundancy. It efficiently uses the available space.
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?
With no output schema, the description should explain what a 'cambio' contains or what happens on failure, but it does not. The optional memory-related parameters are entirely omitted from the description, leaving their behavior solely to schema definitions, which is insufficient for a complete understanding.
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 description clarifies that the 'id' parameter is the change's identifier, which is missing from the schema description for id. However, the other three parameters (projectPath, includeGlobal, includeProject) already have detailed schema descriptions, so the description adds minimal value beyond that.
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 'Recupera un cambio exacto por id' clearly states the action (retrieves), the resource (a change), and the identifier used for retrieval. This distinguishes it from sibling tools like list_changes or search_changes, which operate on collections or queries.
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 'por id' implies that the tool is for retrieving a specific known change by its identifier, but it does not explicitly compare against alternatives like search_changes or list_changes. No exclusions or when-not-to-use guidance is provided, 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?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about the response format (compact index with specific fields) and the decision-making purpose, but does not disclose details like sorting or pagination behavior. This is modest added value beyond 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?
The description is a single, well-structured sentence that front-loads the core function and includes no filler.
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 read-only listing tool, the description covers the essentials: what is returned, and why to use it. However, with no output schema and sibling tools like list_changes/search_changes, a little more distinction would help, so not a 5.
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 already covers 80% of parameters with descriptions. The description doesn't add parameter-specific guidance; it only implies the index is compact. Baseline 3 is appropriate given high schema 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 uses a specific verb ('Lista') and clearly identifies the resource: a compact index of changes with specific fields (id, title, store, type, tags, paths). It also conveys the purpose of aiding subsequent queries, distinguishing it from similar tools like list_changes.
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 the context of use: to decide which changes to query later, implying it is a preliminary browsing tool. However, it does not explicitly name alternative tools or provide exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds behavioral context by explaining that it provides a recommended catalog for memory saving, though it doesn't disclose return format or potential empty results.
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 concise sentence that directly states action and purpose, with no wasted 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?
For a parameterless, read-only tool with no output schema, the description fully explains purpose and usage context, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers the input, and the description appropriately doesn't discuss parameters, matching the baseline for parameterless tools.
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 ('Lista') and resource ('catalogo recomendado de tags'), and explicitly connects to sibling tools (add_local, add_global) for context, clearly distinguishing this from other list 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?
It states the exact use case: get recommended tags when saving memory with add_local or add_global, giving clear context for when to invoke it. It doesn't mention exclusions, but the purpose is unambiguous.
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:

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

Score Badge

Copy to your README.md:

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

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