memory-bank-mcp

by gcorroto

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.2.15
Disambiguation5/5
Each tool targets a distinct operation: indexing, search, task management, documentation, agent coordination, file I/O, etc. Descriptions are detailed and clearly differentiate purposes, leaving no ambiguity.
Naming Consistency5/5
All tools follow the consistent pattern 'memorybank_verb_noun' in snake_case, with no mixing of conventions or deviant styles.
Tool Count5/5
19 tools cover the full scope of memory bank management (indexing, search, tasks, docs, agents, files) without being excessive or insufficient.
Completeness5/5
The tool surface comprehensively covers initialization, indexing/search, documentation lifecycle, task management, progress tracking, decision logging, context updates, agent coordination, and file operations. No obvious gaps for the domain.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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?
No annotations are provided, so the description carries full burden. It discloses the AI model used and that projectId is mandatory, but does not explain side effects (e.g., overwriting, file creation location), idempotency, or any destructive potential, leaving behavioral understanding incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and lists documents, but includes extraneous sentences (e.g., 'Útil para que agentes menos avanzados...') that could be streamlined. It is moderately concise but not optimally structured.
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 clarify what the tool returns or how docs are delivered. It lists the documents but omits return format, file location, or output behavior, leaving a significant gap for agent 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?
Input schema covers 100% of parameter descriptions. The description adds emphasis on projectId being mandatory and matching the indexing ID, but provides no new semantic details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates structured project documentation using AI, listing the six specific markdown documents. It also mentions complementing semantic search, which provides some differentiation from sibling tools like memorybank_search, but does not explicitly name 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 description implies use for obtaining global project context ('complementa la búsqueda semántica precisa') and for less advanced agents, but lacks explicit when-to-use vs when-not-to-use guidance or direct comparison to siblings like memorybank_get_project_docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that a request is created in the destination board, but does not explain side effects (e.g., whether the original task remains, ownership changes, or if delegation is reversible).
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 very concise (two sentences). No wasted words, but it could be slightly more structured with separate lines for purpose and outcome.
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 has 5 parameters and no output schema, the description should explain return values or success indicators. It does not, leaving gaps for the agent.
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% (all parameters described). The description adds no additional meaning beyond the schema descriptions. Baseline score of 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 action ('delegate a task') and the resource ('to another project'). It specifies the result ('creates an external request in the destination project's board'), distinguishing it from sibling tools like route or claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., memorybank_route_task). No exclusions or prerequisites mentioned.
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. It does not disclose any behavioral traits such as whether the tool is read-only, what format the results are in, or any side effects. The description is limited to the purpose and does not explain what happens when the tool is invoked.
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, consisting of two short sentences. Every word adds value: it states the core action and a typical use case. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter with full schema coverage, no output schema, and no annotations, the description is somewhat adequate but lacks behavioral transparency and usage guidelines. It provides the basic purpose but does not fully describe what the agent can expect from the tool's output or how to integrate it with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% for the single query parameter, and the schema description already explains it is a search term by ID, description, or keywords. The tool description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers other projects in the local Memory Bank ecosystem. It uses a specific verb ('Descubre') and resource ('otros proyectos indexados'). While it distinguishes from siblings by focusing on discovering projects rather than searching or managing tasks, it does not explicitly contrast with similar tools like memorybank_search or memorybank_get_project_docs, so it is slightly above average.
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 only implicitly suggests usage via 'Útil para coordinar tareas entre proyectos', which gives a vague use case but no explicit guidance on when to use this tool versus alternatives like memorybank_search or memorybank_get_project_docs. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'indexes', implying a write operation, but fails to mention whether it is destructive, requires permissions, or how it affects existing indices. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear warning section and bullet-point examples. Every sentence adds value, though it could be slightly shorter.
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 complexity (indexing code) and lack of an output schema, the description should explain what happens after indexing (e.g., success message, status). It does not describe the return value or error conditions, leaving 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?
Schema description coverage is 100%, so the baseline is 3. The main description adds value by emphasizing the absolute path requirement for the 'path' parameter, but does not enhance other parameters beyond the schema.
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 it indexes code from a directory for semantic searches. The verb 'index' and resource 'directory' are specific, but it does not explicitly differentiate from sibling tools like 'memorybank_search' (which uses the index) or 'memorybank_read_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit rules about the path being absolute and a directory, with correct and incorrect examples. It advises indexing a directory when targeting a specific file. However, it does not compare this tool to alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the action (mark as completed) but does not mention side effects, irreversibility, permissions, or whether it triggers notifications. For a mutation tool, this is insufficient.
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 with no filler. Every word contributes to the meaning. The structure is front-loaded and efficient.
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?
Without annotations or output schema, the description lacks return value, error conditions, prerequisites (e.g., task must be open), and how it interacts with other tools. For a simple action, it could be adequate, but with 18 siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds that the tool works for both TASK-* and EXT-* task IDs, which is slightly redundant with the schema's taskId description but provides confirmation.
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 'Marca' and the resource 'tarea como completada', and specifies it works for both internal (TASK-*) and external (EXT-*) tasks. This distinguishes it from siblings like claim_task, delegate_task, or route_task.
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 implies usage when a task is completed, but provides no explicit guidance on when to use this tool versus alternatives. There are siblings like claim_task and delegate_task, but no comparison or exclusion criteria.
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?
Al no haber anotaciones, la descripción debe revelar efectos secundarios, pero solo menciona 'evitar conflictos' y 'coordinación'. No detalla si las acciones son destructivas, requisitos de autenticación, o qué sucede con los locks. La transparencia es insuficiente para una herramienta que modifica estado.
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?
La descripción es concisa (una oración) y frontaliza el propósito. El contenido justifica su extensión, aunque podría estructurarse mejor separando acciones.
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?
Aunque la descripción menciona el retorno de 'estado global' y 'detalles de tareas', no hay esquema de salida. Para 9 parámetros, falta detalle sobre la estructura de la respuesta y el modelo del Agent Board. Es suficiente para acciones básicas pero no exhaustivo.
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?
El esquema cubre el 100% de los parámetros con descripciones adecuadas. La descripción añade poco valor semántico adicional, limitándose a listar acciones. Se mantiene la línea base de 3 puntos.
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?
El verbo 'Coordina' especifica la acción principal, y el recurso 'agentes usando una pizarra central (Agent Board)' es claro. La descripción enumera las capacidades (registrar, pedir recursos, ver estado, obtener detalles), diferenciándolo de herramientas hermanas más específicas como 'claim_task' o 'complete_task'.
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 se proporciona orientación explícita sobre cuándo usar esta herramienta en lugar de otras como 'memorybank_claim_task' o 'memorybank_delegate_task'. Aunque la descripción lista acciones que se superponen con herramientas hermanas, no se mencionan criterios de cuándo preferir una u otra.
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 burden. The name and 'lee el contenido' imply a read-only operation, but there is no explicit statement that the tool does not modify data. This is adequate for a simple read tool, but could be more transparent by confirming no side effects.
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 short (two sentences plus an example line) and front-loaded with the core purpose. It avoids unnecessary words. The warning and example are relevant. It is concise but could be slightly more structured (e.g., separating the usage tip from the example).
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-file tool, the description covers the main purpose and provides a usage tip. Given no output schema and moderate complexity (4 params), it is fairly complete. It does not mention error handling or return format, but those are often implicit for such tools. The sibling context is not leveraged.
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 input schema has 100% description coverage, so the baseline is 3. The description adds value by recommending absolute paths and providing an example ('C:/workspaces/proyecto/src/index.ts'), which helps the agent use the 'path' parameter correctly. This extra guidance justifies a 4.
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 'Lee el contenido de un archivo específico' which directly indicates the action and resource. The tool name 'read_file' aligns perfectly, and the sibling 'write_file' provides clear differentiation. However, the phrase 'Usa para obtener contexto adicional' is slightly vague, preventing a perfect score.
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 suggests using the tool for 'obtener contexto adicional', giving a clear context. It does not explicitly state when not to use it or mention alternatives among siblings (e.g., search or index). The tip about absolute path is more about parameter usage than when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it's a semantic search, but lacks details on whether it reads/writes, rate limits, prerequisites (e.g., index must exist), or result format. Minimal behavioral context beyond schema.
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?
Two sentences, front-loaded with purpose. Each sentence is meaningful. Could be slightly improved by adding a note on indexing prerequisite, but still concise.
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 tool with 6 params and no output schema, the description should explain return values and usage context (e.g., 'results include chunk and score'). Does not mention output or indexing dependency, leaving 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?
Schema coverage is 100% with good parameter descriptions. The description adds only that projectId is mandatory (already in schema). No additional meaning beyond 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?
The description clearly states it searches code via semantic vector search, using the verb 'busca' and specifying the resource. It distinguishes itself from sibling tools like memorybank_index_code or memorybank_analyze_coverage.
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 says 'Usa esta herramienta SIEMPRE que necesites información sobre el código' (always use when you need code info), providing strong when-to-use guidance. Does not specify when not to use, but given context of siblings, it's clear.
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 provided, so description carries full burden. It discloses intelligent task merging to avoid duplicates and states no AI is used. However, it does not clarify whether updates replace or merge milestones/blockers, nor any permissions or side effects beyond task merging.
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?
Description is well-structured with a bullet list of capabilities. It is concise and front-loaded, but could be slightly shorter. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (nested objects, 6 params, no output schema), the description covers main use cases but lacks information on return format, error handling, or what happens to existing data beyond tasks. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about merging tasks and repeats severity levels already in schema, but does not explain additional parameter meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates project progress with tasks, milestones, and blockers, and lists specific actions. It differentiates from siblings by focusing on overall progress tracking rather than individual task actions like claim/completed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through listed capabilities (mark tasks, update milestones, etc.) but does not explicitly state when to use this tool versus siblings like memorybank_claim_task or memorybank_record_decision. No exclusions or alternatives are mentioned.
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 disclose behavior. It mentions auto-reindexing and path preference but does not clarify overwrite behavior, file existence handling, permissions, or error scenarios. Basic disclosure but insufficient for a potentially destructive write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a warning line. Every sentence serves a purpose without redundancy. Front-loaded with the main action, followed by a practical tip.
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 has 4 parameters, no output schema, and no annotations, the description should cover error handling, overwrite behavior, permissions, or reindexing details. It lacks this context, leaving significant gaps for a reliable tool invocation.
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 schema already describes all four parameters. The description adds a usage hint for absolute paths, which has minimal overlap with the schema's example. No additional semantics for content, projectId, or autoReindex. 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 writes a file and automatically reindexes it in the Memory Bank. The verb 'Escribe' and object 'un archivo' are specific, and the auto-reindexing distinguishes it from siblings like memorybank_read_file or memorybank_index_code.
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 advises using an absolute path to avoid errors and provides an example. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., memorybank_index_code, memorybank_read_file), and no when-not-to-use or prerequisite conditions are mentioned.
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 carries full burden. It discloses the state change (PENDING to IN_PROGRESS), which is a key behavioral trait. However, it does not mention error conditions (e.g., task not found, already claimed), security/permissions, or side effects beyond the state change.
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 consists of two short, front-loaded sentences that state the action and the state transition. Every sentence adds value; no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally hint at return values (e.g., success confirmation, updated task details). It does not. Additionally, there is no mention of prerequisites (e.g., task must exist, user authorization). However, for a simple claim action, the core function is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (both 'projectId' and 'taskId' are described with examples and context). The tool description adds no additional parameter meaning beyond what the schema already provides, so it meets the 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?
The description uses a specific verb ('Reclama'/'Claims'), identifies the resource ('una tarea pendiente'/'a pending task'), and clearly states the effect ('Cambia el estado de PENDING a IN_PROGRESS'). This distinguishes it from siblings like 'memorybank_complete_task' (likely transitions to COMPLETED) and 'memorybank_delegate_task' (reassigns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pending tasks but does not explicitly state when to use it vs. alternatives, nor does it provide exclusions (e.g., 'do not use if task is already IN_PROGRESS'). No 'when-to-use' or 'when-not-to-use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It states the tool does not use AI and maintains a history of the last 10 sessions for tracking. This gives good insight into its behavior. However, it could be more explicit about whether updates overwrite or append, though the history mention suggests preservation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear first sentence followed by a bullet list. It avoids unnecessary words. The information is front-loaded. However, the phrase 'No usa IA' is slightly redundant but still adds value. A more compact presentation might improve structure.
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 has 6 parameters (1 required), nested objects, and no output schema, the description covers the purpose, lists what can be recorded, and mentions the history feature. It provides sufficient context for an AI agent to understand the tool's function, though it lacks details about error handling or return values (which would be expected given no 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?
The input schema has 100% description coverage, so the baseline is 3. The description enumerates categories of fields (session, changes, questions, etc.) but adds little semantic value beyond what the schema descriptions already provide. It does not clarify constraints or formatting beyond what is in the schema.
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 the tool updates the active project context with current session information. It lists specific data that can be recorded, making the purpose clear. However, it does not explicitly differentiate from sibling tools like memorybank_record_decision or memorybank_track_progress, so it loses a point for lack of sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No usa IA - actualización directa del documento' (Doesn't use AI - direct document update), which provides some guidance about when to use this tool (for direct updates). However, it does not specify when to use it versus alternatives, nor does it state prerequisites or exclusions. Guidelines are implied but not 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?
No annotations are provided, so the description must disclose behavioral traits, but it does not mention whether the tool is read-only, what happens if projectId is invalid, or any side effects. The description only lists document types and usage context, leaving the agent unaware of potential errors or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It is reasonably concise but includes some repetition (e.g., listing document types both in text and as a list). Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain the structure of the returned markdown documents or what 'full' vs 'summary' entails in terms of output format. The description covers purpose and usage well but could be more specific about the return value to complete the context.
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%, but the description adds value by explaining each document type (e.g., 'projectBrief: Descripción general del proyecto') beyond the schema's parameter descriptions. It also reinforces that projectId is mandatory, though that is redundant with 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 the tool retrieves project documentation generated by AI, lists the document types (projectBrief, productContext, etc.), and distinguishes itself from the sibling tool memorybank_search by positioning it as providing high-level context versus semantic search. The verb 'Lee' and the resource 'documentación del proyecto' are specific.
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?
The description explicitly says 'Usa esta herramienta al inicio de cada sesión' (use at the start of each session) and contrasts it with memorybank_search, which is for precise semantic search. This provides clear when-to-use and alternative guidance.
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 burden. It adds the behavioral trait 'No usa IA - registro directo en el documento' (no AI, direct write). However, it omits other important behaviors like whether it appends or overwrites, permission requirements, or idempotency, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose followed by an itemized list of fields. It uses a bullet style that is easy to scan, though it could be slightly shorter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the main functionality and fields but lacks details on error handling, whether the decision log is append-only, or if existing project validation occurs. This leaves some practical context incomplete for an agent.
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 value by listing all decision fields and providing explicit category enum values (architecture, technology, etc.), which are not in the schema as an enum. This helps agents understand valid values beyond the schema's generic description.
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 records a technical decision in the project's decision log, with a specific verb ('Registra') and resource ('decisión técnica en el log de decisiones'). It distinguishes itself from sibling tools like memorybank_write_file by focusing on decisions, not generic file writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is useful for maintaining an architectural/technical decision history for future reference, providing clear context for when to use it. However, it does not explicitly mention when not to use it or suggest alternatives, though the context is sufficient for an agent to infer appropriate usage.
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 carries the burden. It correctly implies a read-only operation (getting stats) without side effects. However, it adds no extra behavioral details beyond the obvious.
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, front-loaded with purpose and usage advice. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the purpose and usage context adequately. It could mention the return format, but the description is sufficient for a simple stats 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 tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter information; baseline is 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 clearly states the tool retrieves statistics (stats) from the Memory Bank, listing specific examples like indexed files, total chunks, and last indexation. It is distinct from sibling tools that handle tasks, files, or project management.
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 recommends using this tool at the start of each session, providing clear context. It does not mention when to avoid it, but the instruction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the load. It discloses performance (RÁPIDO ~2s), default behavior (no tree), and side effects of includeTree (LENTO). It does not mention auth or rate limits, but for a read-only analysis tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (7 lines), front-loaded with purpose, and uses visual structure (emojis, bold) to highlight important warnings. Every sentence adds value with no 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 no output schema, the description covers purpose, input constraints, and performance. It doesn't explain return format, but for a simple coverage analysis, the purpose is self-explanatory. A minor gap is not stating what 'coverage' means concretely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that path must be absolute, providing an example, and explaining the includeTree default and performance implications. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analiza la cobertura de indexación del proyecto' (Analyzes project indexing coverage). It specifies the verb (analiza), resource (cobertura de indexación), and context (project). This distinguishes it from siblings like memorybank_search or memorybank_index_code.
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 explicit usage instructions: path must be absolute, includes an example, and warns about includeTree performance. While it doesn't explicitly say when not to use or name alternatives, the context is clear enough for an agent to use correctly.
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 for behavioral disclosure. It describes auto-recovery behavior and multi-source scanning. However, it does not explicitly state if the tool modifies files outside the registry or if it requires specific permissions, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes sections and bullet lists, which aids readability. However, some redundancy exists (e.g., repeating 'AUTO-RECUPERACIÓN' in multiple places). It is well-structured but could be more concise.
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 zero parameters, no output schema, and no annotations, the description covers the tool's purpose, usage scenarios, and behavior comprehensively. It lacks detail about the return value or output format, which would improve completeness.
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 input schema has zero parameters, so baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the tool's behavior and use cases.
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 synchronizes and auto-recovers projects from multiple sources. It distinguishes itself from siblings by detailing the multi-source discovery and auto-recovery features, which are not mentioned in sibling tool names like memorybank_discover_projects or memorybank_generate_project_docs.
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?
The description provides explicit scenarios when the tool is useful, such as corrupt registry, indexed code without docs, outdated registry, etc. This gives clear guidance on when to use it versus 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, description discloses it does not use AI, creates static templates, and requires absolute path. Could mention idempotency or overwrite behavior, but current coverage is good.
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?
Well-structured with bullet list of files and warnings. Slightly verbose but informative. Every sentence adds value.
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?
Covers purpose, usage, parameter constraints, and sibling differentiation. Lacks return value description but is sufficient for an initialization tool without output schema.
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%. Description adds the absolute path requirement example, and clarifies projectId is mandatory. Adds value beyond schema for projectPath.
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 initializes Memory Bank for a new project by creating directory structure and 7 markdown documents with templates. It lists the exact files and distinguishes from sibling memorybank_generate_project_docs.
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?
Explicitly says when to use (new project initialization) and when not to (use memorybank_generate_project_docs for detailed docs). Includes requirement for absolute path.
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 of behavioral disclosure. It transparently describes the orchestration process (reads responsibilities, analyzes task, assigns components, returns plan) and the output format (myResponsibilities, delegations, suggestedImports). This fully informs the agent of the tool's behavior without contradictions.
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 with emojis, clear sections, and bullet points. Every sentence is meaningful: the opening emphasis, the step-by-step process, the warnings, and the output specification. It is appropriately sized and front-loaded with the most critical information.
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?
Despite no output schema, the description explicitly details the return format (myResponsibilities, delegations, suggestedImports) and explains the rationale for using the tool. This is complete for a routing tool given its simplicity and the clear parameter schema.
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 both parameters already have descriptions. The tool description adds context by explaining the role of projectId as the requesting project and taskDescription as the task to route. It also frames parameters within the overall process, adding value beyond the schema alone.
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: analyzing a task and determining which parts belong to which project based on responsibilities. It uses specific verbs ('Analiza', 'determina', 'asigna') and resources ('tarea', 'proyecto'). It distinguishes itself from sibling tools like memorybank_delegate_task by focusing on routing before any implementation.
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?
Explicitly states it is 'OBLIGATORIO antes de implementar cualquier código' and 'DEBES llamar esta herramienta ANTES de escribir código'. It lists concrete negative consequences of not using it (creating DTOs in API when lib-dtos exists, duplicating services, violating separation of responsibilities), serving as clear when-to-use and when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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