midas-memory-mcp

by vornicx

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
Disambiguation5/5
Each tool targets a distinct memory operation: storage, retrieval, deletion, inspection, checks, context assembly, and commitment tracking. Detailed descriptions clearly differentiate similar-looking tools like recall, memory_state, and open_loops.
Naming Consistency5/5
Tools follow a consistent verb_noun pattern in snake_case (e.g., check_forbidden_action, remember_code). Single-word verbs like capture and maintain are exceptions but still clear and predictable within the naming convention.
Tool Count5/5
23 tools is a reasonable number for a comprehensive memory MCP server. Each tool serves a specific and justified purpose, covering storage, retrieval, maintenance, auditing, and checks without redundancy.
Completeness5/5
The tool surface covers the full memory lifecycle: creation (remember, capture), retrieval (recall, memory_state, project_state), deletion (forget, forget_all, forget_matching), maintenance (maintain, memory_policy), and auditing (audit_use, stats). Missing update is handled via supersession, and additional features like context assembly (build_context, resume) and conflict detection (memory_conflicts) round out the set.
Average 4.2/5 across 23 of 23 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 122 commits in the last 12 weeks
- Last stable release on July 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context: the output includes guard decision, provenance, history, and attributability score, and notes it is deterministic and requires no LLM.
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 four sentences, front-loaded with the core purpose, and every sentence adds essential information without extraneous words.
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 good purpose and behavioral clarity, the tool lacks output schema and the description omits parameter semantics, leaving the agent with incomplete context for correct 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?
With 0% schema description coverage, the description provides no explanation for the 3 parameters (query, namespace, intended_use). The agent receives no guidance on parameter meaning or usage, a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool produces a compliance audit artifact for a memory-justified use, including the guard decision, provenance, and attributability score. It distinguishes itself from sibling tools like check_memory_use by emphasizing audit trail generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for formal compliance auditing ('Hand this to an auditor') but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like check_memory_use.
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?
Annotations indicate readOnlyHint=true, and the description confirms no LLM involvement. It explains the scoring heuristics (NLI or same-slot heuristic). No mention of side effects or destructive actions, which aligns with read-only. The description adds context beyond annotations without contradiction.
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 paragraph with multiple sentences, each adding value. It is fairly concise but could be more structured with bullet points or separate sections for parameters. Still, it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so return format is undocumented. Parameters are not explained. The description covers purpose, scoring, and post-action advice, but the missing parameter documentation and output format make it incomplete for an agent to use effectively.
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%, meaning parameters have no documentation. The description does not mention 'limit' or 'namespace', so it adds no meaning beyond parameter names. Given low coverage, the description should compensate but fails to explain what these parameters control.
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 defines the tool's purpose: returning contradictory beliefs from shared memory. It specifies the multi-agent failure mode, scoring methods (NLI or heuristic), and distinguishes the tool from siblings by focusing on conflicts. The verb is implicit but the action is clear.
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 verify with the user and then use 'forget' or capture the corrected value, which guides post-use. However, it does not explicitly state when to use this tool versus alternatives like 'audit_use' or 'check_memory_use', though the context makes it inferable.
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?
Annotations already provide readOnlyHint=true and openWorldHint=false. Description adds valuable behavioral context: 'Deterministic, no LLM' and 'Live (non-superseded) memories only', clarifying filtering and reliability beyond structured 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?
Description is relatively short (3 sentences) and front-loaded with key purpose. Every sentence adds value: definition, usage guidance, determinism, and related SDK helpers. Could be slightly more structured but 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?
Given 2 params, no output schema, and many siblings, the description covers purpose and usage well but lacks output format details. 'Grouped by code_kind' hints at structure but does not specify return shape, pagination, or behavior when limit is exceeded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but does not mention parameters. 'project' is implied but not described; 'limit' (default 200) is completely omitted. No details on how limit affects results or expected format.
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 returns the current code-state of a project grouped by code_kind, with examples like architecture_decision. It distinguishes from siblings like remember_code (capture) and check_forbidden_action (single check), and explicitly says 'call this to ONBOARD into a project, or to see what is decided and what is forbidden before acting.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: for onboarding or before acting to check decisions/forbidden actions. Mentions 'Deterministic, no LLM' indicating a safe query. While it implies alternatives via SDK helpers, it does not directly compare to siblings like check_forbidden_action or memory_state.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds context by specifying that output includes exact stored text, provenance, timestamps, and score components, and that no LLM rewrites are generated. This provides useful behavioral details beyond the annotations, though it omits information about rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose, then details returns and key parameters. It is reasonably concise, though the structure could be improved by using bullet points or explicit sections. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11 parameters, 1 required, presence of output schema, and clear annotations, the description covers the main purpose, behavioral traits, and two important parameters. It explains historical query usage and hybrid mode. However, it does not address all parameters, which limits completeness for a complex tool. Still, it is adequate for basic usage.
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?
With 0% schema description coverage, the description explains two key parameters (hybrid, as_of) but leaves others unaddressed. The explanation of hybrid's utility for exact identifiers adds meaning beyond the schema, but many parameters (e.g., kind, fusion, namespace) remain undocumented in the description. The description partially compensates but is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves relevant memories with deterministic, source-traceable evidence, which is a specific verb+resource. It emphasizes no LLM rewrites, distinguishing it from other memory tools that may use generative capabilities. The purpose is unambiguous and well-articulated.
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 guidance for using hybrid mode with exact identifiers and explains the as_of parameter for historical queries. However, it does not explicitly contrast with sibling tools like inspect_memory or capture, nor does it state when not to use this tool. The guidance is present but incomplete.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds context: commitments persist across sessions and are visible in open loops until closed. This goes beyond annotations by explaining lifecycle and visibility, though it does not detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with key purpose and lifecycle information. However, it could be more structured by listing all parameters and their roles without adding length.
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 and sibling tools like 'open_loops' and 'close_loop', the description integrates well with the loop system. But it lacks parameter coverage for 4 of 5 parameters, making it incomplete for an agent unfamiliar with the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only clarifies 'due' as a free-text deadline. It fails to explain 'content' (required), 'project', 'session', or 'namespace', leaving the agent with minimal guidance for invoking with those parameters.
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 defines the tool's purpose as recording a commitment (open loop) for promised work. It uses specific verbs and resources, and distinguishes from siblings like 'remember' and 'close_loop' by framing it as a persistent, session-spanning promise.
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 commitments remain visible in 'open_loops'/'resume' until closed via 'close_loop', providing clear when-to-use context. It also mentions 'due' as an optional deadline, but does not explicitly exclude alternative tools like 'remember' for non-commitment data.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds behavioral context: it explains that the tool decides based on intended_use types and that for external/destructive actions it requires user_confirmation provenance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that front-load the purpose and follow with usage guidelines. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and many sibling tools, the description is too brief. It covers intended_use but omits the other parameters and does not describe return values or behavior when memory does not justify use. Completeness is adequate but not strong.
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 the description must compensate. It only explains the 'intended_use' parameter (listing possible values) but does not clarify 'query', 'limit', 'namespace', or 'acting_agent'. This leaves significant gaps for a 5-parameter tool.
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 a specific verb ('decide') and resource ('whether recalled memory may justify the intended use'). It distinguishes from sibling tools like 'audit_use' and 'check_forbidden_action' by focusing on memory justification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: it states that external/destructive actions require user_confirmation provenance; otherwise ask the user first. This helps with usage context, though it could also mention when not to use.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds that the tool is deterministic and does not use an LLM, and describes what the returned context contains. This provides additional behavioral context beyond annotations, though some details like authentication or rate limits are absent.
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 dense paragraph that front-loads the purpose. Every sentence adds value, but it could be slightly more structured. Still, it is concise for the amount of information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not fully specify the response format, though it mentions 'context is prompt-ready and token-budgeted'. Additionally, only one of four parameters is explained. For a session-start tool, these are notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the hours parameter (default of a week) but does not cover project, namespace, or token_budget. This partial coverage is insufficient for a tool with four undocumented parameters.
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 resumes a session with all necessary context in one call, listing specific components (directives, rules, state, commitments, conflicts). It also distinguishes itself from sibling build_context by being query-less, making the purpose very specific and 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 explicitly contrasts with build_context, indicating when to use resume (start of session without a query). While it doesn't provide explicit when-not-to-use scenarios, the contrast with a sibling tool gives clear contextual 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?
Annotations already indicate destructive behavior (`destructiveHint=true`). Description adds that supersession chains are relinked to preserve belief-revision history, which is useful behavioral context beyond the annotation.
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, no wasted words. Information is front-loaded and every sentence contributes meaning.
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 simplicity (1 param, output schema exists), the description covers the deletion behavior, parameter source, and the relinking detail. Missing explicit mention of return value, but output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only states that IDs come from `recall`, adding minimal meaning to the `memory_id` parameter. No format, constraints, or examples provided.
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 single memory by ID, with IDs sourced from `recall`. This distinguishes it from siblings like `forget_all` and `forget_matching`.
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?
Specifies that IDs come from `recall`, guiding when to use. However, it does not explicitly state when not to use or mention alternatives like `forget_matching` for pattern-based deletion.
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?
Annotations provide readOnlyHint, and the description adds that it operates without search, mutation, or embedding exposure. This adds valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 13 words, front-loaded with core action. Every word adds value. 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, but no output schema exists. Description should at least hint at what 'inspect' returns (e.g., memory contents or metadata). Missing this information makes it incomplete.
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 must compensate. It states 'by id', linking the parameter to its purpose, but lacks details on id format, constraints, or return value. Minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Inspect' and resource 'memory by id', and distinguishes from sibling tools like recall (search), remember (mutation), and build_context (embedding exposure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does not do (search, mutation, embedding exposure), providing clear context for when to use it. However, it does not explicitly name alternative tools for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that importance influences recall and forgetting, auto-derive behavior, session grouping, and provenance rules. Annotations confirm non-destructive, and description adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with line breaks for parameters is reasonably concise. Could be more structured but no wasteful sentences.
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 all parameters, behavior, and output schema exists. Adequately complete for a tool with 7 parameters and complex memory semantics.
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?
Despite 0% schema description coverage, the description explains each parameter's purpose and default behavior in detail, effectively compensating for missing 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?
States 'Store a memory for later recall' — clear verb+resource. Differentiates from siblings like recall, forget, etc.
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 no explicit when-to-use vs. alternatives like recall or inspect_memory. Mentions provenance but not usage context for which tool is appropriate.
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?
Annotations are neutral (non-readonly, non-destructive). The description adds context like 'for the coding-agent views', ties to check_forbidden_action and project_state, and warns 'No LLM', providing useful behavioral hints beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet packed with essential information, front-loaded with the core action and tags, followed by enumerated categories and usage directives. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the critical parameters (code_kind, provenance) and ties to related tools, it omits details on remaining 5 parameters and does not explain return values (no output schema). This is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains code_kind values and their use, and the provenance parameter. However, content, project, session, namespace, and importance receive no additional explanation, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'capture' and resource 'CODE memory', with tags 'category + project', distinguishing it from siblings like 'remember' and 'remember_commitment'. The list of valid code_kind values further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using forbidden_action for rules that gate check_forbidden_action and setting provenance only on user confirmation. However, it does not contrast with alternatives like 'remember' or 'remember_commitment'.
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?
The description explains that Midas evaluates importance, checks relevance and duplicates, and returns whether the item was stored and why. It aligns with annotations (readOnlyHint=false, destructiveHint=false) by confirming it is a write operation that is not destructive, and adds value beyond annotations by describing the filtering logic.
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 informative and well-structured: it starts with core purpose, explains behavior, then lists parameter hints. It is slightly verbose but every sentence adds value, and the structure is logical.
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 the return value and filtering behavior, but lacks detail on optional parameters (actor, session, namespace) and does not provide usage examples. For a tool central to memory, more completeness on parameter semantics would be beneficial.
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?
With 0% schema coverage, the description must compensate. It explains two parameters (kind and provenance) with example values, but does not describe actor, session, namespace, or content parameters. Content is implicitly covered but lacks clear format or constraints.
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: to forward durable information to memory for automatic filtering and storage by Midas, without LLM involvement. It distinguishes itself from other memory tools by emphasizing automatic, hands-off remembering, and provides explicit types (kind) and sources (provenance).
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 when to use the tool ('forward anything durable') and implies it is safe to use freely ('capture freely without polluting'). However, it does not explicitly mention when not to use it or compare with alternative sibling tools like 'remember' or 'forget'.
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?
Beyond annotations (readOnlyHint=true), description adds 'Deterministic, no LLM', assuring predictability and no AI generation. This provides useful behavioral insight not captured by annotations alone.
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 front-loaded with core purpose. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only diff tool with two optional parameters and no output schema, the description covers key aspects: purpose, output format (added/revised beliefs), and behavior (deterministic). Minor gap on return structure but sufficient.
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%. The description explains 'hours' parameter by referencing 'last `hours`', but does not mention or explain the 'namespace' parameter. Partial compensation.
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 shows memory changes over a time period, specifying newly added and revised beliefs. It distinguishes itself from siblings like memory_state or recall by focusing on changes since last session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as a 'what's new since our last session' view for resuming long-horizon work. While it doesn't mention alternatives, the context is clear enough for appropriate use.
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?
Annotations already mark readOnlyHint=true, so the description adds value by specifying ordering (oldest first) and the concept of 'unresolved commitments.' No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded definition. Every sentence serves a purpose: definition, usage guidance, and related tool pointers.
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?
Adequate for a simple read-only list tool, but lacks explanation of parameters (limit, project, namespace). With no output schema, more detail on filtering and results would improve 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 has 0% description coverage for 3 parameters. Description does not explain limit, project, or namespace, relying on self-explanatory names but fails to fully compensate for schema gaps.
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 defines open loops as unresolved commitments, oldest first. Distinguishes from sibling tools remember_commitment and close_loop by mentioning them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'check this when resuming so promised work isn't silently dropped.' Also gives actionable guidance on recording and closing loops.
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?
Annotations declare readOnlyHint=true; description adds that it uses lean memory lines, dates, a header, and trims to token_budget. No contradictions. Additional context like 'highest-value memories first' and 'standing user directives pinned' provides useful behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact paragraph, front-loaded with the core purpose. It could be slightly more structured (e.g., bullet points for usage notes) but remains efficient and clear without superfluous 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 presence of an output schema and 5 parameters, the description covers the core behavior, output format, and key constraints (budget, date anchoring, directive pinning). It adequately prepares an agent to use the tool correctly, though minor details about parameter interactions could be added.
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 should compensate; it explains the token_budget parameter's role ('trimmed to token_budget') but does not explain limit, hybrid, or namespace. Parameter names are intuitive but the description leaves ambiguity, particularly for 'hybrid'. Baseline 3 due to partial compensation.
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 assembles a budgeted, prompt-ready context block for a query, distinguishing it from sibling tools like recall and inspect_memory by specifying it returns a lean, dated string optimized for LLM prompts.
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 instructs when to use this tool (building context for a prompt) and when to use alternatives ('call recall or inspect_memory when you need full provenance/source evidence'), plus notes that standing directives are always included.
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?
Annotations already declare readOnlyHint=true. The description adds that results are 'newest first' and 'live (non-superseded)', plus the note about no LLM/similarity search, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise but covers essential aspects: purpose, usage guidance, and one parameter explanation. Could be slightly tighter, but overall well-structured and 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?
For a read-only tool with 3 params and no output schema, the description covers purpose, usage, and one param. Missing details on limit/namespace are minor given the tool's simplicity and annotations.
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%. The description explains the 'kinds' parameter (comma-separated list of options), but does not explain 'limit' or 'namespace', leaving gaps for the agent.
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 that the tool returns 'the current durable state of a project/scope: the live (non-superseded) decisions, constraints, facts, and preferences, newest first.' It uses specific verbs and resources, and differentiates from siblings by noting when 'recall under-retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to ONBOARD into a project or before planning — when a broad 'what's the current state?' has no single matching turn, so recall under-retrieves.' Also notes what it is not: 'Not a similarity search and no LLM.'
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?
Annotations already indicate destructiveHint=true, and the description adds the 'fresh start' context, reinforcing the irreversible nature. It does not disclose specific behavioral details like confirmation or rollback, but the destructive hint covers the main concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is minimally complete. It could mention irreversibility or confirmation requirements, but the annotations already acknowledge destructiveness, making the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description does not need to add parameter information. The schema coverage is 100% (no params), so the baseline is appropriate. The description provides no additional semantic value for parameters, but none is needed.
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 'Clear all stored memories (fresh start)' uses a specific verb 'clear' and explicitly names the resource 'all stored memories', clearly distinguishing it from siblings like 'forget' (specific memory) and 'forget_matching' (filtered deletion).
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 implies a fresh start and is suitable for resetting all memories, it does not explicitly state when to use this tool versus 'forget' or 'forget_matching'. However, the context signals and sibling names provide implicit guidance.
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?
The description adds significant detail beyond annotations: dry-run safety, that deletion bypasses durability protections, and that the tool returns the list of removed memories as an audit trail. This fully discloses the behavioral implications.
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 sentences, each serving a distinct purpose: purpose statement, dry-run explanation, and deletion behavior/audit. No verbose or redundant phrasing. Well 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?
Given no output schema and 5 parameters, the description covers the key behaviors (dry-run, deletion, audit). It could mention namespace filtering, but overall it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains min_relevance (relevance threshold) and dry_run (dry-run vs actual deletion) but does not describe query, limit, or namespace parameters. While helpful for two parameters, it leaves three undocumented.
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 states 'Topic-level erasure ("forget what you know about X") with a reviewable audit.', which clearly specifies the verb (erase/forget) and resource (memories matching a topic). It distinguishes from siblings like 'forget' and 'forget_all' by focusing on concept-based matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default dry-run behavior and the need to call again with dry_run=false to delete. It also notes that deletion bypasses durability protections. However, it does not explicitly compare to alternative tools (e.g., when to use 'forget' vs matching) or state prerequisites.
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?
The description adds value beyond annotations by specifying the exact output: 'memory policy text and guard parameters'. Annotations already declare readOnlyHint=true and openWorldHint=false, and the description aligns with them, providing additional context about what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and result. No extraneous information is present; every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no parameters and no output schema, the description is largely adequate. It could hint at the format of the policy text (e.g., plain text), but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description need not add parameter details. The baseline of 4 is appropriate since there is nothing missing; the schema coverage is complete.
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 'Return' and the specific resource 'MCP-injected memory policy text and guard parameters'. It is precise and distinct from sibling tools, which deal with memory operations rather than policy retrieval.
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 guidance is provided on when to use this tool versus alternatives. However, the tool is straightforward (retrieve policy) and likely used whenever policy information is needed. The lack of exclusions or context reduces the 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?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value by explaining the temporal tiers (short/medium/long) and the breakdown dimensions, which helps the agent understand the scope and limitations of the data returned.
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 with two sentences plus a parenthetical clarification. It front-loads the core purpose and efficiently explains tiers and parameter usage without extraneous text.
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 tool has one optional parameter, no output schema, and the description explains the return value (counts, breakdowns) and parameter semantics. While the exact output structure isn't specified, it is adequate for the agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the only parameter 'namespace'. The description compensates by stating 'Pass namespace to scope the counts to one project/agent scope,' adding semantic meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Memory stats: total count, breakdown by kind, namespace, and the temporal-tier distribution.' It specifies the verb (stats) and resource (memory), and distinguishes from sibling tools like inspect_memory or forget by focusing on aggregate counts.
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 context on when to use: for memory statistics, with an optional namespace to scope counts. It doesn't explicitly state when not to use or compare to alternatives, but the purpose is clear enough for the agent to decide.
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?
Adds context beyond annotations: deterministic (no LLM), superseded/retired rules ignored, noisy advisory tier (~31% false positives), and separation from check_memory_use. No contradiction with readOnlyHint.
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?
Concise with front-loaded purpose. Two paragraphs well-structured. Some detail on false positives could be trimmed but adds transparency.
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 logic, confidence tiers, and recommended actions. No output schema, but return value is implied. Sufficient for an AI agent to use correctly.
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 has 0% description coverage. Description implicitly defines action and project via context but lacks explicit parameter details (format, examples). Adequate but could be improved.
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 checks an action against forbidden_action rules, distinguishes two tiers (forbidden and possibly_forbidden), and separates from check_memory_use. It is specific and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Before a code action, check it...' and prescribes behavior for each outcome: refuse for forbidden, ask user for possibly_forbidden. Mentions false positive rate and separation from provenance gate.
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?
The description explains key behaviors: it 'supersedes the open loop' and ensures 'promise -> resolution history stays auditable'. It also describes the effect on open_loops. This adds value beyond the annotations, which only indicate non-read-only and non-destructive.
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, no wasted words. The first sentence states the purpose and effect, the second gives a usage hint. Information is front-loaded and easy to parse.
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?
With only 2 required params, no enums, and an output schema present, the description adequately covers the tool's purpose, input source, and side effects. It is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description adds meaning by explaining that loop_id comes from open_loops and that resolution is recorded. This compensates for the schema's lack of descriptions, though it could provide more detail on resolution format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Close' and identifies the resource as 'open commitment' (loop). It clearly states the action: records the resolution and supersedes the open loop. This distinguishes it from sibling tools like open_loops.
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 a usage hint: 'Get loop_id from open_loops', indicating how to obtain the required parameter. It implies when to use (to close a loop) and the effect on open_loops. However, it does not explicitly state when not to use or mention alternatives.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that durable memories and supersession chains are never dropped, and explains parameter effects on what gets removed. It also mentions the return format (counts and ids), providing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core action, then a high-level purpose, followed by a parameter list with clear explanations. 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 no output schema, the description mentions the return of counts and ids. All parameters are fully described. The tool's role as a maintenance pass and its relation to retention policies is complete. No gaps are evident.
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 explain parameters. It does so thoroughly: ttl with default and special cases, min_value, max_records, and consolidate_threshold. Each parameter's effect and default behavior are clearly stated.
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 runs a no-LLM memory-maintenance pass and returns a deletion audit. It distinguishes from sibling tools like forget by emphasizing it bounds storage without LLM involvement. The title 'Maintain memory' aligns well.
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 positions the tool as an enterprise retention / 'right to be forgotten' lever, implying use for memory cleanup without LLM cost. It says it 'bounds storage and keeps recall clean,' providing context on when to use. However, it does not explicitly contrast with specific sibling tools beyond this.
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:

[![Midas MCP server](https://glama.ai/mcp/servers/vornicx/Midas/badges/card.svg)](https://glama.ai/mcp/servers/vornicx/Midas)

Score Badge

Copy to your README.md:

[![Midas MCP server](https://glama.ai/mcp/servers/vornicx/Midas/badges/score.svg)](https://glama.ai/mcp/servers/vornicx/Midas)

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/vornicx/Midas'

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