MCP Roo Memory

by mcasdfgf

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

A "release" on Glama is not the same as a GitHub release. To create a Glama release:
1. if you haven't already.
2. Go to the Dockerfile admin page, configure the build spec, and click Deploy.
3. Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
Read the detailed guide
Disambiguation5/5
Each tool has a clear, distinct purpose. Desktop tools manage sessions and viewports, graph tools handle node and relation CRUD plus traversal, and vector tools handle semantic search and storage. Even similar-sounding tools like graph_search and vector_search are well-differentiated by their mechanics.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern, predominantly verb_noun (e.g., graph_add_node, vector_search). The naming is predictable and makes the tool's action and target clear.
Tool Count4/5
17 tools is slightly above the ideal 3-15 range, but the set is well-scoped for a memory server covering graph operations, search, session management, and temporal navigation. Each tool serves a distinct need without being excessive.
Completeness4/5
The tool surface covers CRUD for nodes, relations, search, session initialization, and temporal queries. Minor gaps exist (e.g., no direct relation deletion tool), but core workflows are fully supported with workarounds available.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose side effects (e.g., overwriting existing relations), prerequisites (e.g., node existence), or constraints (e.g., weight bounds). This is a significant gap 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 sentence with a parenthetical list, front-loaded with the core action. While the list of 22 types is lengthy, it is necessary for clarity and the overall structure is 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?
Despite having no output schema, the description does not explain return values, error handling, or preconditions (e.g., that nodes must exist). This lack of completeness makes it harder for an agent to use correctly without guessing.
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 baseline is 3. The description adds value by categorizing the 22 enum values into groups (Hierarchical, Semantic, etc.), which is not in the schema. However, no additional meaning is provided for 'weight' beyond what the schema states.
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?
Describes the action with a specific verb+resource ('Create a relation between two nodes') and enumerates 22 relation types in categories, clearly distinguishing it from sibling tools like graph_add_node (which creates nodes).
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?
No explicit when-to-use or alternatives are mentioned. The relation type categories provide implicit context, but the description does not guide the agent on when this tool is preferable to other graph tools (e.g., graph_decompose).
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 correctly implies a read operation with no side effects, but doesn't disclose auth needs, rate limits, or return format constraints.
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 plus a prominent note about workspace_id optionality; front-loaded and efficient, though could be more concise about limit parameter.
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 2-parameter read-only tool with no output schema, the description covers purpose and basic usage adequately, missing only pagination details for the limit parameter.
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 50%: workspace_id has description, limit does not. Description restates workspace_id optionality but adds no meaning for limit. Baseline 3 is appropriate as description 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?
Description clearly states 'Get navigation history for a workspace session', specifying a verb and resource. It distinguishes from siblings like 'session_timeline' by focusing on navigation history, though not explicitly differentiating.
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?
Provides use case hints ('understand what was recently worked on or restore context') but lacks explicit when-not-to-use or alternative tool recommendations among the 16 siblings.
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 burden. Discloses merging, sorting, and event types, but omits details like output format, handling of empty results, or potential destructive effects (likely none).
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?
Extremely concise, two sentences plus a note, with no wasted words. Front-loaded with the primary action.
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?
With no output schema, description could have hinted at output structure. It describes merging and sorting but is vague on actual data fields returned. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all 4 parameters with descriptions (workspace_id, from_time, to_time, limit). Description only restates workspace_id optionality, adding minimal extra meaning beyond 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 specifies the tool shows a flat timeline of session events (nodes created + navigation events) merged and sorted. It is distinct from siblings like graph_traverse or temporal_walk, but doesn't explicitly differentiate.
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?
Provides a use case ('what happened in this session over time?') but lacks guidance on when not to use or alternatives among siblings.
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?
Without annotations, the description carries full burden. It states key actions (creates subtask nodes and adds relations) but does not disclose side effects, idempotency, or failure behavior.
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 sentences with no wasted words, front-loading the key action and then adding usage context.
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's two required parameters and no output schema, the description covers basic purpose but lacks details about return values, reversibility, or constraints (e.g., only tasks can be decomposed).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds no extra meaning beyond the schema. The 'subtasks' parameter structure is not elaborated, leaving its semantics incomplete.
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: decomposing a task node into subtasks, creating subtask nodes and relations. This distinguishes it from sibling tools like graph_add_node or graph_add_relation by focusing on decomposition.
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 says to use it for planning and breaking down complex tasks, providing context but no explicit when-not-to-use or alternative tools among siblings like graph_add_node.
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 provided, the description carries the full burden. It discloses logging to navigation history for tier calculations, indicating state effects, but does not specify whether the operation is read-only, destructive, or other side effects. It provides moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two sentences and a separate line for workspace_id. Information is front-loaded, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains purpose, usage, and side effects but does not mention what the tool returns or its output format. Given no output schema, this is a gap. The parameter details are clear, but overall completeness is moderate.
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 baseline is 3. The description reiterates that workspace_id is optional and mentions fallback behavior, but the schema already includes that detail ('Falls back to env/CWD folder name / default'). No additional value beyond 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 the tool focuses on a node and expands its subgraph with relations and child nodes, using a specific verb and resource. It also mentions logging for tier calculations, providing good specificity. However, it does not explicitly distinguish from sibling tools like graph_traverse or temporal_walk, which have similar exploration purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when you need to explore context around a specific task, fact, or decision,' giving clear context for usage. Lacks explicit when-not-to-use or alternative tools, but the guidance is sufficient for appropriate use cases.
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 provided, the description must carry the full burden. It discloses that it uses a recursive CTE and respects a depth limit, implying a read-only traversal. However, it does not explicitly state that it has no side effects, nor mention any authorization requirements or performance implications. Some behavioral context is given, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the core action and optional filtering. The second adds technical details and a use case. Every word earns its place, with no redundancy or filler.
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 existence of siblings like graph_walk and temporal_walk, the description does not differentiate this traversal from alternatives. It does not describe the output format (no output schema), though the context of 'discovering connections' implies a list of nodes/paths. The description covers the basic functionality but lacks completeness in distinguishing from similar tools and describing return structure.
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 only 33% (relation has a description). The description adds meaning by explaining start_id as the starting node, relation as optional filter, and depth's default of 3. It also mentions 'recursive CTE up to specified depth' which clarifies the depth parameter. However, it does not provide detailed semantics beyond what the schema already hints, and start_id lacks explicit description in the schema. Overall, marginal added value.
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 traverses a graph from a starting node following relations, with optional filtering by relation type and depth control. It specifies the algorithm (recursive CTE) and the use case (discovering connections). This provides a specific verb+resource scope that distinguishes it from many siblings.
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 to use it 'to discover how nodes are connected in the graph,' implying a discovery use case. However, it lacks explicit guidance on when not to use it or alternatives like graph_walk, graph_search, or graph_decompose. No comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: automatic vector indexing for text in data.text/data.title, optional workspace_id with fallback, and special handling for fileref nodes. However, it does not mention return type, idempotency, or 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?
Two sentences plus a note, covering purpose and key details efficiently. Could be structured with bullet points for the type list for easier scanning, 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?
Lacks output schema and does not describe return values (e.g., node ID). For a creation tool, this is a significant gap. Also does not clarify if parent_id is required or optional despite being nullable.
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%, baseline 3. The description adds value by explaining how data.text and data.title trigger vector indexing, and that data.path is used for fileref nodes, going beyond the schema's generic 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?
Clearly states 'Add a node to the knowledge graph' with specific verb and resource. Lists supported types, distinguishing it from sibling tools like graph_add_relation and graph_delete_node.
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?
Provides some context like automatic indexing for vectorizable types and path for fileref, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like graph_update_node or graph_decompose.
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 provided, the description carries the full burden for behavioral transparency. It describes the tool as 'Get' (implying read-only) but fails to disclose potential cost of deep recursion (via depth parameter) or any forbidden side effects. More explicit statements about non-modification and performance considerations would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with the action and then the purpose. Every word earns its place 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?
Despite no output schema, the description adequately conveys what is returned: node, relations, and child nodes. For a graph retrieval tool, this covers the essential components. However, additional details on the response structure (e.g., fields of the node) would enhance completeness for complex graph data.
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 50% (only depth has a description). The tool description adds little beyond the schema: it mentions 'child nodes' but does not clarify how depth controls recursion or describe node_id format. The description adds marginal value, meeting the baseline for medium coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a node with its relations and child nodes', effectively distinguishing it from sibling tools like graph_search (which searches) and graph_add (which modifies). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use the tool 'to inspect a node's full context', providing a specific use case. However, it does not explicitly contrast with similar sibling tools like graph_traverse or graph_walk, nor state when not to use it. This leaves some ambiguity for an AI agent choosing among alternatives.
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. Reveals it walks specific relations and returns nodes in chronological order, but does not mention side effects, idempotency, or what happens when chain length exceeds steps limit. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action. Every piece of information is essential and no redundancy. Highly 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?
Covers purpose, specific relations, and output ordering. Lacks details on error behavior (e.g., no chain found) and exact return format of nodes. With no output schema, slight gap, but overall sufficient for its simplicity.
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 50%. Description adds meaning about relations and chronological order not in schema, but does not clarify that 'steps' parameter controls number of hops. Baseline 3 with moderate added value.
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?
Clearly states the verb 'walk' and specific resource 'reasoning chain following sequel_to, derives_from, and leads_to relations'. Distinguishes from siblings like graph_traverse and temporal_walk by specifying exact relation types and output order.
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 'Use to reconstruct the chain of thought', providing clear context. However, lacks explicit when-not-to-use or direct comparisons to sibling tools like graph_traverse or temporal_walk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses ordering (ASC) and optionality of workspace_id, but lacks details on auth needs, rate limits, or behavior with 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?
Two concise, front-loaded sentences with zero waste. Key information is presented first.
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?
No output schema exists, and the description does not specify output structure (e.g., array of nodes). Also, the default limit (50) is in schema but not mentioned in description. Somewhat incomplete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, and the description adds value beyond schema by explaining workspace_id fallback behavior (env/CWD). This helps the agent understand parameter nuances.
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 walks the graph along the time axis, returns nodes ordered by created_at ASC, and is used for chronological reconstruction. This distinguishes it from sibling tools like graph_walk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use (chronological sequence reconstruction) and notes workspace_id is optional. However, it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the responsibility. It discloses that the old node becomes stale, a new node is created with a supersedes relation, and history is preserved. This is sufficient for understanding side effects, though it does not mention potential impacts on related data or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action. Each sentence adds distinct value: action, usage context, and behavioral outcome. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description does not specify return value. However, the tool's mutation behavior is well explained, and the description covers key aspects of usage and effect. Slightly incomplete but adequate for most agents.
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 no new parameter-level details beyond the schema, so 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 tool's action: 'Supersede an old node with a new one'. It specifies the mechanism (marks old as stale, creates new with supersedes relation) and distinguishes it from siblings like graph_update_node or graph_delete_node by emphasizing history preservation.
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 explicit guidance: 'Use when a decision or fact fundamentally changes'. It also explains the outcome (old node remains searchable but deprioritized). However, it does not explicitly state when to avoid using this tool.
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 description carries the burden. It mentions automatic vectorization and optional workspace_id, but lacks details on side effects, persistence guarantees, or failure modes.
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 concise sentences plus a succinct note about workspace_id, with no wasted words and key information front-loaded.
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, and a key parameter detail; lacks return behavior but acceptable given no output schema and simple store operation.
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%, and description adds minimal parameter context beyond workspace_id being optional; text, node_type, and tags are not explained.
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 stores text with automatic vectorization into Qdrant and distinguishes it from graph_add_node by specifying it's for ad-hoc storage rather than structured knowledge.
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 provides when to use (quick ad-hoc storage) and when not to use (prefer graph_add_node for structured knowledge), including an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explicitly states destructive action and cascade behavior, with a cautionary note. Could be more explicit about side effects on relations but sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core purpose, followed by usage guidance. No unnecessary 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 simple tool with no output schema and few parameters, description covers purpose, behavior, and alternative. Missing details like return value but not critical for understanding tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% and description adds no new parameter semantics beyond what schema already provides for cascade; node_id has no description in schema or 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 it deletes a node and its vector from Qdrant, distinguishing it from sibling tool graph_supersede which preserves history.
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 advises using graph_supersede for history preservation, providing 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: automatic re-indexing of Qdrant vector when data.text changes. This adds value beyond the schema, though it does not describe other potential side effects or permissions.
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, each serving a clear purpose: purpose, behavioral note, and usage guideline. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and 15 sibling tools, the description covers purpose, behavior, usage, and alternatives. It does not describe return values or error conditions, but this is acceptable since no output schema exists and the return is likely the updated node.
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 50% (one of two parameters described). The tool description adds no parameter-specific information beyond what the schema provides. The missing 'node_id' description is not compensated, but the 'data' parameter is well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'node', specifying 'in-place' and labeling it as 'Strategy A: Update'. It distinguishes itself from the sibling 'graph_supersede' by mentioning an alternative for major changes.
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 provides usage context: 'Use for small corrections and improvements' and directly names the alternative tool 'graph_supersede' for different use cases, giving 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the two-step process (vector_search then subgraph expansion) and output structure. While no annotations exist, the description covers key behavioral aspects, though it could explicitly state non-destructive nature.
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 concise paragraphs, front-loaded with the core definition. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the hybrid complexity and lack of output schema, the description sufficiently explains output ('both vector results and their graph contexts') and performance benefits relative to alternatives.
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?
Adds meaning to both parameters: 'query' is the vector search query (not documented in schema) and 'workspace_id' controls cross-project scope. With 50% schema coverage, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Hybrid search: vector search + expanded subgraphs', defining a specific verb+resource+mechanism. It distinguishes from siblings like vector_search and graph_get_node by explaining the combined operation.
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?
Provides clear guidance: 'Use when you need deep context around search results — faster than calling vector_search then graph_get_node for each result manually.' Also explains cross-project behavior with workspace_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are nodes sorted by relevance score and mentions cross-project behavior. It does not cover rate limits or authentication, but for a read-only search tool, the behavioral disclosure is adequate.
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 and well-structured: first sentence states purpose, second provides result handling, third gives a clear usage pattern, and fourth explains cross-project behavior. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (semantic search across multiple indexed layers without output schema), the description provides sufficient context: purpose, usage pattern, parameter behavior, and follow-up tools. It is complete for effective agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters described in schema). The description adds value by explaining the workspace_id parameter's cross-project behavior and implies the top_k default. It adds modest meaning beyond the schema, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does semantic vector search across indexed layers (Entity + Chunk + Fact) to find relevant knowledge by meaning. It distinguishes from siblings by emphasizing it is the primary entry point for regression search, contrasting with tools like graph_get_node or desktop_focus.
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 guidance on when to use: for finding relevant knowledge by meaning, and outlines a regression search pattern (1. vector_search -> 2. graph_get_node -> 3. read files). It also clarifies cross-project behavior with workspace_id, helping the agent decide when to narrow scope.
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?
Despite no annotations, the description fully discloses return structure (session root, hot/cold/archive nodes with sizes) and default behavior based on workspace_id. No destructive behavior is implied, and the tool's effects are transparent.
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 reasonably concise and front-loaded with core purpose. It packs useful information but could be slightly more structured to improve readability.
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 no output schema, the description adequately explains return values and behavior. All parameters are covered, and usage context is fully provided. No gaps in essential information.
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% for the single parameter, but the description adds meaningful context: explains default behavior and explicit usage for other workspaces. This goes beyond the schema's basic 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 opens a workspace session and returns a Desktop Viewport with Hot/Cold/Archive tiers. It specifies it should be used at the start of every task to initialize or resume a session, distinguishing it from sibling tools like desktop_focus and desktop_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use at the START of every task to initialize or resume a session.' Also explains when to omit or include workspace_id, giving clear context for use versus alternatives.
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:

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

Score Badge

Copy to your README.md:

[![mcp-roo-memory MCP server](https://glama.ai/mcp/servers/mcasdfgf/mcp-roo-memory/badges/score.svg)](https://glama.ai/mcp/servers/mcasdfgf/mcp-roo-memory)

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/mcasdfgf/mcp-roo-memory'

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