Agentic Memory

by ArkaAiAdmin

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is overlap between `memory_recall_context` and `memory_recall`, and between `memory_system_health` and `memory_health_check`. Descriptions help differentiate, but these overlaps could cause minor confusion.
Naming Consistency5/5
All tools follow a consistent `memory_<verb>_<noun>` pattern in snake_case. The naming is predictable and uniform across the entire set.
Tool Count4/5
With 24 tools, the set is on the larger side but each tool serves a specific function within the memory management domain. A few tools could potentially be merged, but the count is still reasonable.
Completeness5/5
The tool surface covers all major aspects of memory management: CRUD, search, revision, beliefs, skills, health, coordination, sharing, and graph. No obvious gaps are present.
Average 3.7/5 across 24 of 24 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1525 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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

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 thoroughly explains the deep_rerank parameter's behavior, including performance implications and a known hang incident on Apple Silicon. However, it omits other behavioral traits such as whether the tool is read-only, side effects, or the structure of the output briefing.
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 purpose, which is good. However, the lengthy and highly specific deep_rerank details (incident report, env var workaround) make the description overly verbose for a general tool definition. Some content could be shortened or moved to the parameter description.
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 9 parameters with no schema descriptions, no annotations, and an existing output schema, the description should provide a high-level overview of the tool's behavior and parameters. It fails to explain most parameters and does not describe the output briefing structure, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only documents one parameter (deep_rerank) in detail, leaving the other 8 parameters (limit, query, action, days_recent, include_pinned, etc.) completely unexplained. This is a significant gap for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool's purpose: 'Assemble a structured memory recall briefing for agent cold-start or session continuity.' The verb 'assemble' and specific resource 'structured memory recall briefing' provide clarity. However, it does not explicitly differentiate from the sibling tool 'memory_recall', which may have overlapping functionality.
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 mentions usage context ('agent cold-start or session continuity') but provides no guidance on when to use this tool versus alternatives like 'memory_recall' or other siblings. There is no explicit when-not-to-use or mention of prerequisites.
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 provides some behavioral context (output is a validated executable file saved to a specific path) but does not disclose side effects like overwriting, validation failures, or required permissions.
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 a single sentence, making it concise. However, it sacrifices important details like parameter explanations and usage context, which could have been added without significant verbosity.
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 complexity (4 parameters, output schema exists) and the presence of many sibling tools, the description is incomplete. It lacks parameter semantics, usage guidelines, and sufficient behavioral transparency for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the four parameters. Terms like 'lesson note' loosely relate to lesson_slug but primary_triggers and secondary_triggers are not mentioned, leaving the agent without sufficient guidance to fill parameters correctly.
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 compiles a lesson note into a validated executable agent skill rule file, specifying the output location (~/.agents/skills/). This distinguishes it from sibling tools like memory_learn or memory_extract_skills.
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, no prerequisites (e.g., lesson note existence), and no exclusions. An agent cannot determine the appropriate context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only lists parameters and actions, omitting side effects, performance considerations, authorization needs, or read-only nature. The tool's behavior (e.g., whether it modifies data) is unclear.
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 and includes a structured args list. It is front-loaded with the main purpose, though the 'Args' block could be integrated more smoothly. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 4 actions, many siblings), the description is incomplete. It does not explain when to use each action, error conditions, or how it compares to similar tools. Output schema exists but not mentioned, though not required per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds basic parameter explanations (e.g., query for explore, start for traverse) beyond the schema (which has 0% description coverage). However, it lacks detail on formats (e.g., edge_patterns syntax) and does not clarify parameters for shortest_path and stats actions.
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 'Explore the knowledge graph' and lists four specific actions (explore, traverse, shortest_path, stats), clarifying it is a multi-purpose graph query tool. However, it does not distinguish from sibling tools like memory_search or memory_recall, missing explicit differentiation.
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., memory_search for semantic search, memory_recall for specific facts). The description lacks when-to-use, when-not-to-use, or prerequisite information.
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 carries full burden for behavioral disclosure. It fails to mention side effects, authorization requirements, or the impact of sharing. The description is too minimal to inform an agent about important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The Args section provides parameter info efficiently. However, the docstring-like formatting is slightly awkward but still effective.
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 (multiple actions) and presence of an output schema, the description is incomplete. It does not explain what 'stats' or 'import' do, and it conflicts with the schema by implying note_id is only required for 'share', while schema marks it always required. More context is needed for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains each parameter: note_id as 'Memory to share (required for share action)', share_with as 'Target agent ID (for share action)', and action as enumerating 'list | share | import | stats'. This adds meaning beyond the schema's names, but some parameters (like import, stats) lack details.
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's purpose: sharing memories or viewing the shared pool. It lists specific actions (list, share, import, stats), making the verb and resource clear. However, it does not explicitly differentiate from sibling memory tools.
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 lacks guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use information is provided, and no sibling tool comparisons are 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 full burden for behavioral disclosure. It fails to mention idempotency, side effects, latency, or safety. It only lists subsystems checked, but not behavioral traits like whether queries are destructive or read-only, or if network access is required.
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 and front-loaded with the main purpose. Each subsystem check is listed in a bullet-like format, which is easy to parse. Every sentence adds value, though the list could be slightly more 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?
Given 0 parameters, no annotations, but an output schema exists, the description covers the subsystems checked but does not mention error handling, performance implications, or what happens when a subsystem is unavailable. It is somewhat complete but lacks edge-case 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?
The tool has 0 parameters, and schema coverage is 100%. The description cannot add parameter meaning beyond the schema because there are none. Baseline score of 4 is appropriate given no parameters exist.
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 is a unified health check returning a JSON dict summarizing subsystem state. It lists specific subsystems checked, providing a specific verb and resource. However, it does not differentiate from sibling tool 'memory_system_health', which likely has overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It simply describes what it does without context on appropriate usage.
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 must convey behavioral traits. It only states the purpose, not whether it is read-only, what it returns, or any side effects. Very limited 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 with two sentences, no redundancy, and front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one optional param and an output schema exists, the description is adequate but lacks context about what the briefing contains or when to use it.
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 0% description coverage, so the description's line 'query: Optional topic to scope the briefing to' adds some meaning beyond the schema, but it is minimal.
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 'Retrieve the session startup briefing', which is a clear verb+resource. However, it does not differentiate from sibling tools like memory_recall_context, and 'session startup briefing' is somewhat ambiguous.
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 includes the optional query parameter but provides no guidance on when to use this tool versus alternatives, or when it should not be used.
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 provided, the description must fully disclose behavioral traits. It states 'View' which implies read-only, but it does not explicitly confirm non-destructive behavior, authentication needs, or error conditions. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise summary of the tool's purpose, followed by a clear Args list. It is efficient with no extraneous text, earning high marks for structure.
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 presence of an output schema (which explains return values), the description adequately covers the tool's inputs. However, it lacks guidance on edge cases (e.g., invalid action) and does not fully compensate for the lack of annotations, leaving some behavioral aspects unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameters by listing the allowed values for 'action' (stats, user, agents, skills, arc) and explaining that 'agent_id' is used only for action=agents. This compensates somewhat for 0% schema description coverage, but it could be more detailed (e.g., behavior of other actions, default behavior).
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: 'View user profile, agent scopes, ARC stats, and cached skills.' This is a specific verb and resource, and it distinguishes this tool from sibling tools that perform other memory operations.
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 does not provide explicit guidance on when to use this tool versus alternatives. It lists the actions but does not explain use cases or when to choose this over other memory tools like memory_recall_context or memory_system_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It mentions combining operations but does not specify read-only nature or side effects. The behavior is implied to be safe but not confirmed.
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 opening sentence. The 'Args' section adds value, though it could be more tightly integrated. No unnecessary 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?
An output schema exists but the description does not reference it or describe return values. For a recall tool with 3 optional parameters and many siblings, more detail on when to use and what to expect 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 coverage is 0%, so the description's 'Args' section adds meaning to query and session_id, but it omits tenant_id entirely. The parameter meaning is partially addressed but incomplete.
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 that the tool recalls context for a session or thread and that it combines two other tools. It distinguishes itself from siblings like memory_session_start and memory_recall_context.
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 notes that no query returns recent activity, but it does not provide explicit guidance on when to use this tool versus its siblings, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the coordination model and lists all actions with brief explanations. It discloses the relationship between messages and task status updates. However, it lacks details on error handling 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?
The description is front-loaded with purpose and well-structured with a bullet list and a concluding paragraph. It is somewhat verbose but organized, with each sentence adding value.
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 13 parameters, 0% schema coverage, and no annotations, the description should provide detailed parameter guidance. It only gives high-level action descriptions and lacks specifics on required fields, return values, or behavior per action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description lists actions but does not specify which parameters are required for each action or their formats. The agent must infer parameter usage from action names.
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 is for multi-agent coordination, including task management, file locking, and messaging. It distinguishes from sibling tools which are primarily memory operations.
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 for multi-agent coordination but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses auto-categorization and tagging behavior, but without annotations, it does not cover side effects, permissions, or destructive potential. For a tool with no annotations, more detail is needed.
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 a summary and Arg list, front-loading the purpose. It is slightly longer than necessary but remains clear and effective.
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?
With 5 parameters fully explained and an output schema presumably provided, the description is largely complete. It could mention prerequisites (e.g., memory system state) but is sufficient for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains each parameter in detail, adding meaning beyond the schema's titles. Given the 0% schema description coverage, this fully compensates and provides clear parameter semantics.
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 'Save a lesson or compile a skill from content,' which clearly defines the verb and resource. However, it does not explicitly differentiate from sibling tools like memory_save or memory_compile_skill, which may cause confusion.
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 lacks explicit guidance on when to use this tool versus alternatives. It mentions optional skill compilation but does not provide context for choosing this over memory_save for lessons or memory_compile_skill for skills.
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 burden. It discloses that the tool surfaces supersede/amend/revert/delete events from a specific log table, but it does not explicitly state that it is a read-only operation, does not mention permission requirements, rate limits, or whether it returns historical data only. The description lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence, then provides structured details in a docstring format. It is concise with no redundant information, though the Args section could be integrated more seamlessly.
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 three parameters, none required, and an output schema exists, the description provides sufficient context for a list/filter tool. It explains the log events and filtering options. The absence of required parameters reduces complexity, making this description complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by listing each parameter with its purpose: 'memory_id: Filter to a specific memory id (empty = all),' 'limit: Max results (default 20),' 'revision_type: Filter by type: supersede, amend, revert, delete (empty = all types).' This adds meaning beyond the schema, which only defines type and default.
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 'List revision-log entries for a memory or across the store' with a specific verb ('list') and resource ('revision-log entries'). It also defines the domain (memory revision log) and distinguishes from sibling tools like memory_search or memory_recall, which serve different purposes.
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 for auditing ('so the operator can audit what changed') but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. The parameter descriptions provide some filtering guidance but no exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details each subsystem checked and the output format (green/yellow/red with details and action). It implies a read-only diagnostic behavior but does not explicitly state read-only or mention auth/rate limits.
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. It front-loads the health status summary and then lists the six dimensions in bullet-point format. Every sentence serves a purpose with no waste.
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 presence of an output schema, the description does not need to detail return values. It covers the tool's purpose and subsystems thoroughly. The only gap is the unexplained 'conn' parameter, but it's optional and likely minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'conn' with no description (0% coverage), and the tool description does not explain what 'conn' is or how it affects behavior. The description adds no meaning beyond 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 'Comprehensive system health: green/yellow/red with actionable next steps' and lists six specific health dimensions. This differentiates it from the sibling 'memory_health_check' by being more comprehensive.
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 for checking overall system health but does not explicitly state when to use this tool versus alternatives like 'memory_health_check'. No direct guidance on context or exclusions.
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 fully disclose behavioral traits. It mentions that extraction uses the cron code path and that dry_run prevents writes, but it does not state whether the operation is destructive, idempotent, or requires specific permissions. The internal P0 fix comment adds developer context but does not help the agent.
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 structured with an Args block, but it includes a developer-oriented note ('P0 fix #5') that is irrelevant for an AI agent. This noise reduces conciseness. The first sentence is clear, but the internal reference should be removed.
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 an output schema present, the description does not need to detail return values. However, it lacks information about prerequisites, error conditions, or side effects beyond the dry_run flag. For a simple two-parameter tool, the description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter info in the schema. The description compensates fully by explaining both parameters: memory_id determines scope (specific vs all) and dry_run controls writing. This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Manually trigger skill extraction') and specifies the two modes of operation (single memory or full pass). This verb+resource combination is unambiguous and distinguishes it from sibling tools like memory_list_skills or memory_compile_skill.
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 guidance on when to use each parameter: memory_id for a specific memory or empty for full extraction, and dry_run for testing without writing. However, it does not explicitly state when not to use this tool or mention alternatives.
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 carry the full burden. It lists actions and parameters but does not disclose side effects, idempotency, permissions, or what happens on supersede (e.g., versioning). Minimal behavioral insight beyond action enumeration.
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 front-loaded with the purpose, then lists actions and parameters. It includes meta notes (Sprint 2) which add context but could be more streamlined. Generally efficient with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters and multiple actions, the description covers all actions and required parameters. Output schema exists so return value explanation is unnecessary. Lacks some context on constraints (e.g., max length) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning parameters lack schema descriptions. The description compensates fully by explaining each parameter's purpose (e.g., note_id format, additions/deletions for patch). Adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs CRUD operations on a specific memory note, listing multiple actions like read, update, delete, etc. It is specific and distinguishes from siblings that operate on collections or other aspects.
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 per-action parameter requirements (e.g., rationale for supersede) but does not explicitly compare to sibling tools or specify when to avoid using this tool. Usage context is implied but not fully elucidated.
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 responsibility. It discloses that skills are ordered by hit_count desc and lists included fields: topic, hit count, last-used timestamp, and description preview. This goes beyond a simple 'list' and gives behavioral insight into output format and ordering, though it lacks mentions of side effects or permissions (likely none for a list operation).
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 brief (two sentences plus a note) and front-loaded with the core purpose. The note adds contextual value for a specific fix, but could be considered slightly extraneous. Overall, it is efficiently structured and easy to parse.
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 that an output schema exists (as indicated by context signals), the description does not need to detail return values. It already mentions key output fields. However, it does not explain pagination behavior for the `limit` parameter or total count. For a simple list tool, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, `limit`, with a default of 50 and zero schema description coverage. The description does not mention `limit` or its purpose. Although the parameter is common for pagination, the description fails to add meaning beyond the schema, leaving the agent to guess its role.
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 "List extracted skills, ordered by hit_count desc." This makes the action (list) and resource (extracted skills) explicit, and the ordering distinguishes it from other memory tools like memory_extract_skills (extraction) and memory_compile_skill (compilation), which are siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note about "P0 fix #5: gives the operator a way to inspect what the lower-threshold extractor actually pulled in." This provides usage context (after extraction, for inspection) and implies when to use it. It does not explicitly mention when not to use or compare to alternatives, but the context is clear enough for an AI 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details each parameter's behavior, including defaults and special notes (e.g., auto-generation of title_slug, safety_wiring scanning). It does not describe the return value or side effects, but an output schema exists, so this is acceptable.
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 longer but well-organized with a summary sentence followed by parameter details in a bullet-style list. Every sentence adds value, though it could be slightly more terse.
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 parameter count (8, 1 required) and the presence of an output schema, the description covers all necessary aspects for effective use. It explains parameter behaviors and constraints, leaving no critical gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates excellently. Each parameter is explained with its type, default, and constraints (e.g., category options, importance range, safety_wiring purpose). This adds significant meaning beyond the schema's raw JSON.
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 'Save a memory note with sensible defaults,' providing a specific verb and resource. It lists all parameters but does not explicitly differentiate from sibling tools like memory_note or memory_learn, though the purpose is distinct enough.
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 includes guidance on safety_wiring parameter (when to set False) but lacks explicit instructions on when to use this tool versus alternatives. It implies usage through defaults but does not provide context for choosing this tool over siblings.
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 the tool delegates to memory_maintenance, that destructive ops require confirm=True, and mentions the confirmation gate. This is sufficient for transparency, though a bit more detail on what happens during delegation could help.
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 clear sections (args, security) and is front-loaded with purpose. Every sentence adds value, though the 'Args' block could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic nature and the existence of an output schema (not shown but signaled), the description provides essential information: the purpose, usage guidance, security warnings, and parameter explanations. It is complete enough for an escape hatch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains 'operation' as any operation name, 'kwargs' as operation-specific parameters, and 'tenant_id' as tenant identity. However, 'kwargs' is a string but not clarified whether it expects JSON or other format, leaving some ambiguity.
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 labels it as an 'escape hatch' for memory_maintenance operations, distinguishing it from sibling tools by stating 'use when a verb doesn't cover your use case.' This provides specific verb+resource context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (when a specific verb is unavailable) and provides security guidelines about confirm=True for destructive operations. It lacks explicit when-not-to-use but the context implies using specific verbs when possible.
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 mentions combining two functions and reviewing health, but does not disclose read-only nature, permissions, or error behavior. The existence of an output schema reduces the need for describing return values, but more behavioral context would be helpful.
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 succinct with a summary line followed by a well-organized argument list. Every sentence adds value with 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 low complexity (3 optional params) and an output schema, the description provides sufficient purpose and parameter details. It distinguishes from siblings by mentioning the combined nature. Minor gaps remain in behavioral aspects, but overall it is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema only provides type and default. The description adds clear explanations for all three parameters (hours, limit, include_errors), fully compensating for the lack of 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 reviews recent memory activity, errors, and system health, and that it combines audit_query and circuit_breaker_status. This provides a specific verb+resource and distinguishes it from similar siblings like memory_system_health and memory_health_check.
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 when both audit and circuit breaker status are needed, but does not explicitly state when not to use it or provide alternatives. It lacks explicit when/when-not 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 provided, the description adds some behavioral context: it notes that promotion sets `epistemic_source='agent'`, which is a specific side effect. It also clarifies that `note_ids` are required for promote/discard actions. However, it does not disclose whether discarding deletes auto-saves permanently or other side effects, leaving some behavioral 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 two paragraphs. The first sentence captures the core purpose, and the 'Args:' block lists parameters efficiently. While it is not overly verbose, the structure could be slightly improved by front-loading the action parameter more prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (curating auto-saves) and the presence of an output schema, the description does not need to detail return values. It explains the primary operations and their effects. However, it could be more complete by clarifying the state changes (e.g., whether promoted notes replace auto-saves or are created separately).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool's 'Args:' block provides clear, concise explanations for all 5 parameters: start_date, end_date, action (with valid values), note_ids (required for promote/discard), and category (default 'lessons'). This adds significant meaning beyond the schema's titles and defaults.
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 reviews auto-saved tool invocations and allows promoting or discarding them. It specifies the actions (list, promote, discard) and the resource (auto-saved notes). This distinguishes it from sibling memory tools like memory_save or memory_recall, which serve different 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?
The description explains that the agent can list auto-saved notes, then batch-promote or discard them. It implies a sequence of use and sets context for when to use this tool (for curating auto-saves). However, it does not explicitly state when not to use it or mention alternatives, though the context is clear enough for an agent.
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, so description carries full burden. It explains the tool writes a row to ctr_feedback with action=returned/clicked/etc., and that the search re-ranker reads this table. It does not mention side effects like permissions or idempotency, but it covers the core behavior well.
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?
Despite length, every sentence adds value. Clear section labeling (G4 fix, bullet lists) and front-loaded with purpose. No redundancy.
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?
Tool is simple, and description provides good purpose and usage context. However, it lacks parameter details and does not explain what the tool returns (output schema exists but not described). With 6 parameters and 0% schema coverage, more parameter-level information is needed for full completeness.
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 0%, so description should explain parameters. It only briefly mentions 'action=returned/clicked/etc.' and implies 'id' and 'query_id' are required, but does not describe 'source', 'returned_at', or 'ranking_params'. Agent would have to infer or guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool records click-through rate feedback for a search result. It distinguishes itself from memory_reinforce by explaining the difference between implicit and explicit signals, making the purpose unmistakable.
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 explicit guidance on when to use this tool vs. memory_reinforce, including concrete scenarios like 'delivered to user', 'user acted on it', and 'call both when...'. No ambiguity.
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 effectively discloses key behaviors: default soft-delete with 30-day recoverability, and the confirm parameter as a mandatory safety gate for irreversible hard deletes. It does not mention error handling but covers the main behavioral aspects.
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: one introductory sentence followed by a well-structured Args list. Every sentence is informative with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's behavior, parameter semantics, and safety mechanisms thoroughly. It does not mention error handling or idempotency, but given the presence of an output schema and the simplicity of a delete operation, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates fully by providing detailed explanations for all three parameters: note_id with an example, hard with default and effect, and confirm with its critical safety role. This adds significant meaning beyond 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 'Delete a memory note by ID' and distinguishes between soft and hard delete, making its purpose unambiguous among a broad set of sibling memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains soft vs hard delete and the required confirm safety gate, but does not explicitly compare to other memory tools or provide guidance on when to use this tool instead of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains hybrid search, CQRS journal supplementation, and parameter effects (like include_global defaults). It does not mention destructive actions, auth needs, or rate limits, which is acceptable for a read-only search 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 somewhat lengthy (13 lines) but well-structured, starting with the core purpose and then detailing parameters. It could be more concise, but the structure aids 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 the complexity (11 params, many filters) and existence of an output schema, the description is thorough. It covers all parameter behaviors, including edge cases (CQRS journal, default scoping for include_global). No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 11 parameters, including defaults, effects (e.g., mode options, belief_status values), and behavior (e.g., shared_with_me). This fully compensates for the lack of 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 'Search memories by semantic + FTS5 hybrid search' and 'The primary recall tool. Returns ranked memories matching the query.' This provides a specific verb-resource combination and distinguishes it from siblings like memory_recall and memory_recall_context.
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 identifies it as 'The primary recall tool' but does not explicitly state when to use alternatives or when not to use this tool. It provides context for the CQRS journal behavior but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is 'safe' by default but notes that the 'full' target can be destructive (purge) and requires confirmation. It also explains the dry_run option for previewing changes. This provides good insight into the tool's behavior, though it could further detail what each operation does (e.g., compact, dedup).
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. It starts with the main purpose, then lists targets and arguments in a clear bullet-point format. Every sentence provides necessary information 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 complexity of the tool (multiple targets, destructive potential) and the lack of schema descriptions, the description is complete. It covers what the tool does, the available targets, argument details, and safety considerations. The presence of an output schema means return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so excellently: it explains the possible values for 'target' (safe_default, full, compact, dedup) and conditions for 'confirm' (required when target='full' and dry_run=False). This adds meaning far beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run safe memory maintenance batch.' It specifies the verb 'run' and the resource 'memory maintenance batch'. The listing of different targets (safe_default, full, compact, dedup) further clarifies the scope. This distinguishes it from sibling tools, which have names like memory_save, memory_search, etc., indicating different functions.
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?
While the description does not explicitly compare this tool to alternatives, it provides clear context on when to use it by detailing the available targets and their compositions. It implies that this tool is for automated batch maintenance, which is distinct from individual operations like save or delete. However, no explicit guidance on when not to use it or contrasts with siblings is given, preventing a perfect score.
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, so description carries full burden. It discloses that it returns a structured list and filters, but does not explicitly state whether it modifies state or requires permissions. It is a read operation, but not explicitly flagged.
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, front-loads the purpose, then describes return structure, then lists parameters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters and an output schema (not shown but present), the description covers the tool's purpose, filters, and return structure. It is complete for a review tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: min_confidence (returns beliefs below threshold), belief_status, older_than_days, limit. It adds key semantics like 'maximum confidence threshold' and default behavior.
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 'Review' and the resource 'beliefs that may need agent attention', specifying low confidence, old, or stale beliefs. It distinguishes from other memory tools by focusing on attention-needing beliefs.
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 implies when to use (for reviewing beliefs needing attention) but does not explicitly state when not to use or provide alternative tool names. The context is clear enough for an agent.
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:

[![Agentic-Memory MCP server](https://glama.ai/mcp/servers/ArkaAiAdmin/Agentic-Memory/badges/card.svg)](https://glama.ai/mcp/servers/ArkaAiAdmin/Agentic-Memory)

Score Badge

Copy to your README.md:

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

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