A
licenseA
qualityA
maintenancePersistent long-term memory for AI agents — semantic recall across Claude, Cursor, ChatGPT & MCP.
10
519
21
MIT
midas-memory-mcp
by vornicx
Midas Memory MCP is a fully local, LLM-free, auditable long-term memory layer for AI agents — zero API cost, no data egress, with provenance-based safety guardrails.
Memory Storage
remember— Explicitly store a memory (fact, decision, preference, constraint) with kind, importance, and namespace taggingcapture— Offer a turn to memory; Midas auto-decides whether to keep it based on importance scoring and duplicate detectionremember_code— Store code-specific memories by category (architecture decisions, bugs, conventions, forbidden actions, etc.)remember_commitment— Record an open commitment/promise that persists across sessions
Retrieval & Context
recall— Retrieve relevant memories via semantic search with optional hybrid BM25, score explanations, and historical (bitemporal) queriesinspect_memory— Fetch a single memory by IDbuild_context— Assemble a token-budgeted, prompt-ready context block for a given query
Session & Project State
resume— One-call session onboarding: pinned directives, forbidden rules, recent changes, current state, open commitments, and conflictsmemory_state/project_state— View current live (non-superseded) decisions, constraints, facts, and code statememory_diff— See what changed in the last N hours (added/revised beliefs)open_loops— List unresolved commitments, oldest firstclose_loop— Mark a commitment resolved, preserving the promise→resolution historymemory_conflicts— Detect live contradictory beliefs (multi-agent conflict detection)
Safety & Governance
check_memory_use— Guard that decides whether recalled memory justifies an intended action; blocks external/destructive actions on unconfirmed or stale memorycheck_forbidden_action— Check a proposed code action against project-level forbidden rules (hard block vs. advisory warning)audit_use— Generate a full compliance audit artifact showing the guard decision and provenance historymemory_policy— Retrieve the injected memory policy text and guard parameters
Maintenance & Forgetting
forget— Delete a single memory by ID while relinking supersession chainsforget_matching— Topic-level erasure with dry-run previewforget_all— Clear all stored memoriesmaintain— Deduplicate near-duplicates, enforce TTL, trim to max records, evict low-value items, and return a full deletion audit
Monitoring
stats— View memory counts by kind, namespace, and temporal tier (short/medium/long)
It supports multiple AI agents sharing one live memory store, works fully offline, and is configurable with per-project namespaces, various embedder backends, and optional encryption at rest.
Your AI assistant forgets everything between sessions. Midas is the memory that lives next to it, on your machine. Your coding agent remembers the decisions, conventions, and bugs from three sessions ago — without piping every message through an LLM to "extract" facts. It costs nothing per message, nothing leaves your computer, every memory traces back to the exact turn it came from, and it won't let an agent act on memory that's stale or never confirmed.
uv tool install "midas-memory[mcp,local]" # install
midas init # create the shared memory + wire up your MCP clients
# or, no Python: npx -y midas-memory-mcp # TypeScript port
# or, as a library: pip install "midas-memory[local]"
uv tool upgrade midas-memory # Update MidasWhy Midas
Most memory tools call an LLM to summarize every session — so you pay in tokens forever, add latency, ship every turn to a provider, and get back rewritten facts you can't audit. Midas makes the opposite bet, and that bet is what makes it cheap, private, and trustworthy:
$0 and private by construction. No LLM at ingest or query → no API spend, nothing leaves your machine, fast local ops (~tens of ms, no per-turn network round-trip).
You can trust what it recalls. Recall returns the verbatim source turn, not an LLM rewrite — so there's no extraction step that can silently hallucinate a "fact" you never said.
It stays current on its own. Typed belief revision supersedes the old value instead of piling up duplicates; selective forgetting keeps it bounded — all with no LLM.
It's safe to build on. A provenance guard lets memory inform planning but blocks memory-justified external or destructive actions unless you explicitly confirmed them — and a superseded memory can't authorize an action at all.
One file, many tools. Point Claude Code, Cursor, and your chat app at one SQLite file and they share one live memory.
Proven, not asserted. Every claim has a reproducible benchmark — including the experiments that failed.
Related MCP server: auxly-memory-cli
How Midas compares
Every Midas number below is measured and reproducible from this repo; the LLM-at-ingest column reflects the structural properties of that design class (Mem0, Zep, Hindsight) and the figures documented in BENCHMARKS.md.
Midas | LLM-at-ingest systems (Mem0, Zep, Hindsight) | |
LLM calls at ingest | 0 | ≥1 per session |
Cost per message | $0 | per-token API spend, forever |
Data egress at ingest | None | every turn leaves the box |
Ingest latency | ~16–116 ms, local, embed-bound | ~668 ms + API round-trip |
Recall returns | verbatim source turn, traceable | LLM-rewritten facts (source |
Deterministic & reproducible | yes — every number, one command | no |
Works fully offline | yes (measured end-to-end with a local Ollama reader) | no |
LongMemEval- | 0.84 | 0.84 — Observational Memory, with LLM ingest |
Whole-conversation aggregation / summarization | ❌ by design — top-k retrieval can't cover it (documented) | ✅ their structural edge |
The last row is deliberate: Midas trades whole-conversation abilities for $0, privacy, and auditability, and publishes the measurements that show exactly where that trade bites.
More than recall: a memory you can govern
Finding a buried fact is table stakes. A long-horizon coding agent needs memory it can act on safely and resume from cleanly — which is where similarity search alone falls short:
You ask… | Midas answers with | Why top-k recall can't |
"Can I run this destructive migration?" | Guard: allowed only if you confirmed it, and only if that confirmation is still current | provenance + currency aren't a similarity match |
"What's the current state of project Apollo?" |
| a broad "current state" query matches no single turn |
"What changed since our last session?" |
| "what's new" isn't a content query at all |
"How do I speed up the transactions list?" | the prior fix resurfaces, so the agent doesn't re-diagnose it | — |
These properties are measured, not asserted — the agent-memory bench suite scores action-safety, decision-adherence, repeated-mistake avoidance, resume fidelity, conflict detection/precision (live contradictions between agents found without over-flagging), and adversarial memory-safety across scripted multi-session projects. The safety eval blocks 10 / 10 adversarial attacks (ASR 0.00) — including a planted confirmation next to a prohibition, a confirmation for a different action, a provenance-laundering supersession, and a cross-namespace approval — with no over-blocking (benign-pass 1.00). Deterministic, $0, no LLM. Reproduce every number with one command:
uv run python -m eval.benches # the whole governance suite — or `midas bench` from a checkoutHow it does on the benchmarks
Deterministic, reader-independent retrieval (recall@k — fraction of the gold supporting turns
pulled into context) on the full public sets, vs a recency-window baseline:
Benchmark (full set) | baseline | Midas |
LongMemEval- | 0.01 | 0.92 |
LoCoMo — 10 conversations, n=1,540 | 0.05 | 0.73 |
BEAM — frontier benchmark, 100K → 10M tokens | 0.00 | 0.56 → 0.32 |
And the cross-system metric, judged answer-rate (same gpt-4o judge the leaderboards use):
Judged answer | baseline | Midas |
LongMemEval- | — | 0.84 |
BEAM-100K (gpt-4o judge, raw-turn floor, $0 ingest) | 0.05 | 0.40 |
All of it at 0 LLM calls, $0, and 0 data egress at ingest. Full numbers, per-category breakdowns, reproduce commands, and the head-to-head vs Mem0/Zep/Mastra are in BENCHMARKS.md.
Eval-first means we publish the misses too. Hybrid retrieval, reranking, thread-diversification, dual-granularity indexing, and naive distillation were all measured to not help (or to hurt) and are documented as such. That honesty is the point — see BENCHMARKS.md and
docs/frontier-2026.md.
Connect it to your coding agent
One command wires up everything:
midas init # creates the shared memory + configures every MCP client it finds
midas status # check what's wired · run `midas init --dry-run` to preview firstBoth take --json to emit a machine-readable client wiring receipt — which memory each client got
wired to, under which scope/policy, and which clients were skipped (config paths only, never memory
contents). Paste it into a bug report, or let another agent verify the setup without scraping prose.
midas init creates one shared memory (~/.midas/memory.sqlite3) and points the MCP clients it
detects — Claude Code, Codex, Grok Build, Cursor, Claude Desktop, Windsurf, VS Code, Gemini CLI,
Cline, Zed — at it. So all your agents read and write the same memory, autonomously, with no
per-client paths to keep in sync.
Prefer a single endpoint over per-client launches? Run one server and give your clients an MCP URL:
midas serve --http # → http://127.0.0.1:7077/mcp (one server, one memory, every client shares it)
midas serve --http --token <secret> # require `Authorization: Bearer <secret>` on every requestKeep Midas current with midas update. See your memory anytime with midas inspect.
Already carrying agent memory in files? midas import --from claude-md CLAUDE.md (or
--from cursorrules, --from jsonl, --from mem0, --from zep) turns those rules and exports into
first-class, recallable, governable memories — tagged with where they came from, idempotent on re-run.
Want memory even when the agent never calls capture? midas init --claude-hook installs a
Claude Code SessionEnd hook that offers each session's user turns to memory — Midas's no-LLM policy
still decides what is actually kept.
Midas is a standard MCP server: point any client at the midas-mcp command. It uses the shared store
by default — no path needed. The universal block:
{ "mcpServers": { "midas": { "command": "midas-mcp", "env": { "MIDAS_MCP_EMBEDDER": "local" } } } }Client | Where the config goes |
Claude Code |
|
Cursor |
|
Claude Desktop | Settings → Developer → Edit Config ( |
Codex CLI |
|
Grok Build |
|
Windsurf |
|
VS Code | user |
Gemini CLI |
|
Cline |
|
Zed |
|
Anything else | point it at command |
No Python |
|
Override per client with env: MIDAS_MCP_DB (default ~/.midas/memory.sqlite3; :memory: = ephemeral)
· MIDAS_MCP_MAX_RECORDS · MIDAS_MCP_MIN_IMPORTANCE · MIDAS_MCP_NAMESPACE.
⚠️ GUI apps don't share your shell
PATH. If a client says "command not found", use the absolute path fromwhich midas-mcp. On Windows use forward slashes in JSON paths.
Once connected, Midas injects a short policy into the agent (recall first, then capture durable
facts/decisions/preferences/constraints/corrections). The agent captures freely; Midas decides what's
kept — it scores importance (no LLM), drops trivia, skips duplicates, revises stale beliefs, and forgets
the low-value tail to stay bounded. Before any memory-justified external or destructive action, the agent
calls check_memory_use and is blocked unless you confirmed it (and that confirmation is still
current).
One memory, many clients
By default every client shares one live memory (~/.midas/memory.sqlite3) — each detects the others'
writes (SQLite data_version) and refreshes, so a fact captured in your IDE is recallable from your chat
app seconds later, no restarts.
Want per-project separation instead? midas init --project-scoped (or MIDAS_MCP_NAMESPACE=auto)
gives each project its own partition in the same store — the scope is derived from the git repo / cwd the
server runs in. Or scope it manually per project/agent/user with MIDAS_MCP_NAMESPACE.
Tools: remember, capture (policy-gated auto-store), recall (source-traceable), build_context
(compact, dated, today-anchored prompt block), resume (the one-call session-onboarding pack: pinned +
state + changes + open loops + conflicts), memory_state (current project state), memory_diff
(what changed since), memory_conflicts (live beliefs that contradict each other, ranked),
open_loops / remember_commitment / close_loop (promised work that survives sessions),
check_memory_use (guard), memory_policy, maintain (TTL + dedup + forgetting, returns a deletion
audit), stats, forget (chain-safe), forget_matching (topic-level erasure, dry-run by default),
forget_all. Prompts: memory_session, distill.
Env: MIDAS_MCP_DB · MIDAS_MCP_EMBEDDER (local / hashing / multilingual / any fastembed id) ·
MIDAS_MCP_MAX_RECORDS · MIDAS_MCP_MIN_IMPORTANCE · MIDAS_MCP_NAMESPACE (=auto → per-project scope) · MIDAS_MCP_ANN=1 (sub-linear
IVF for huge stores) · MIDAS_MCP_SUPERSEDE · MIDAS_MCP_NLI=1 (NLI-gated revision) ·
MIDAS_MCP_AUTO_MAINTAIN=<min> (idle-time upkeep) · MIDAS_MCP_PINNED (pin standing directives) ·
MIDAS_MCP_TTL (per-kind retention, e.g. chat=30,note=90) · MIDAS_MCP_TOKEN (HTTP bearer auth) ·
MIDAS_MCP_KEY (SQLCipher encryption at rest — pip install "midas-memory[encrypted]").
Troubleshooting
Something not wired right? midas doctor is the one-command diagnosis — it checks midas-mcp is on
PATH, that your store opens, whether the local embedder is available, and which clients are actually
wired, with a fix hint per failed check. It reads config paths and versions only — no memory contents,
so its output is safe to paste into a bug report.
midas doctor # ✓/⚠ per check, with a hint for each failure
midas status # what's wired + the store's record countSymptom | Likely cause & fix |
Client says "command not found" | GUI apps don't inherit your shell |
Recall feels weak / lexical | The offline hashing embedder is in use. Install the local embedder: |
A client doesn't see another's memory | Confirm both point at the same store — |
MCP server won't start | The SDK is installed but the |
Still stuck? Open a bug report
(it pre-fills the midas doctor block) or ask in Discussions.
Use it from Python (the SDK)
from midas import Memory, LocalEmbedder
mem = Memory(embedder=LocalEmbedder()) # fully local. (Or Memory() for a zero-setup offline embedder.)
mem.remember("Decision: the primary database is PostgreSQL.", kind="constraint", importance=5)
mem.remember("The launch date moved to September 14.", kind="fact", importance=5)
mem.capture("lol ok cool") # filler — auto-scored below the floor, skipped (no LLM)
mem.assemble("when do we launch?", token_budget=128) # prompt-ready, dated, source-traceable
for hit in mem.recall("which database did we pick?", limit=3):
print(f"{hit.score:.2f} {hit.record.content}") # each hit traces to its sourcefrom midas import Memory, LocalEmbedder
from midas.nli import LocalNLI
from midas.sqlite_store import SQLiteStore
from midas.state import memory_state, memory_diff # the control-plane views
# Durable, shareable, no native extension. Safe across threads & processes (live data_version refresh).
mem = Memory(store=SQLiteStore("memory.db"), embedder=LocalEmbedder(),
supersede=True, nli=LocalNLI()) # a turn that CONTRADICTS an old belief supersedes it
# Control-plane: the current state of a project, and what changed since a point in time (no LLM):
memory_state(mem, scope={"project": "apollo"}) # live, non-superseded decisions/constraints/facts
memory_diff(mem, since=last_session_epoch) # {added: [...], revised: [(old, new), ...]}
mem.forget_decayed(max_records=50_000) # evict lowest value (importance × recency); protects facts
mem.recall("when is the launch?", as_of=1_700_000_000) # bitemporal: "what did we believe on date X"
# Right-to-be-forgotten — preview, then erase, with an audit trail:
mem.forget_matching("the user's home address", dry_run=True)
mem.forget_matching("the user's home address")
# Back LangGraph's long-term memory with Midas:
from midas.integrations.langgraph_store import MidasStore
store = MidasStore(); store.put(("user", "123"), "pref", {"text": "prefers dark mode"})See & control your memory — midas inspect
Most memory is a black box of LLM-rewritten facts. Midas is glass-box: run a local inspector over your store and see exactly what your agent remembers, why, and from what source — then correct, pin, or forget it.
midas inspect --db ~/.midas/memory.sqlite3 # opens http://localhost:7777 — local only, zero egress
# before install: python -m midas.inspector --db <your.sqlite3> --embedder hashingOverview — counts, attributability, a 30-day activity chart, and kind/provenance/recency breakdowns, each kind and provenance color-coded consistently across every view (a fixed categorical palette, validated for colorblind-safe contrast in both themes — never color-only, every value keeps its label).
Browse + search every memory (verbatim, with provenance + source), filterable by kind, provenance, and sort order.
Belief history + time-travel — what you believed, what it superseded, and when.
Project state (decisions / bugs / forbidden) and what changed since a date.
Governance — would memory authorize an action, and why (the audit trail); forget with a receipt.
Conflicts and Open loops — the same control-plane views from
memory_conflicts/open_loops, with one-click resolve/close from the UI.Audit log — the hash chain's verification status and its most recent entries.
Light + dark themes (a real second theme, not an inverted dark one), keyboard shortcuts (⌘K to jump anywhere or search, / to focus search), and a responsive layout down to phone width.
And every mutation (write / revise / forget) appends to a tamper-evident, hash-chained audit log
inside the store — hashes only, never content. midas audit shows it; midas audit --json verifies
the whole chain and reports the first broken entry if anyone rewrote history.
No LLM, no account, runs on your file. The thing a black-box memory can't show.
Free & open source
Midas is fully free and open source under MIT — the memory engine, the guard, the MCP server, the CLI, the inspector, the TypeScript port, and the entire bench suite. No paid tiers, no feature gates, no telemetry, no account. Use it, fork it, embed it in commercial products — the license permits all of it.
If Midas is useful to you, the best ways to give back are a ⭐, a reproduced benchmark number, a bug report, or a measured contribution — see the roadmap for where help matters most.
Honest status
Midas is early but built narrow and measured-first. Where it stands, plainly:
Retrieval is its strength and is essentially maxed for a no-LLM design — confirmed by our own A/Bs and by the frontier papers (the retriever is not the bottleneck). The benchmark numbers above are the result.
The frontier's extra lever is structure-preserving extraction — and it needs a capable model Midas deliberately won't run at ingest. We built the judged harness and measured it on BEAM's summarization category: a small local extractor doesn't help (raw 0.28 vs replace 0.07 rubric coverage), and the lift is gated on a strong model — so it belongs to the agent's model, not Midas's. The optional distillation dial ships off by default; we don't claim it as a win. (Details:
docs/frontier-2026.md§2b.)Where it's heading: from recall to a governed memory control-plane —
memory_state/memory_diff, the provenance guard that won't act on stale or unconfirmed memory, and the Agent Continuity Bench that measures those properties. Local, auditable, and honest about what's proven.
The eval harness
eval/ (dev-only) runs Midas and competitors through synthetic / LoCoMo / LongMemEval / multiday /
conflicts-v1 / BEAM with deterministic recall@k + precision@k, cost/latency instrumentation, a
dumb-reader ablation (proves the numbers aren't reader-inflated), and an optional local-or-hosted LLM
judge. The anti-cheating checklist (no query rewriting, no LLM at ingest, no gold leakage, seeded sampling),
conflict handling, failure traces, and the verbatim MCP policy are in
docs/methodology.md.
python -m eval.runner --dataset longmemeval --variant s --local --midas-no-rerank --max-questions 40
python -m eval.runner --dataset beam --beam-tier 100K --local --dumb-reader # frontier benchmark
python -m eval.continuity # Agent Continuity BenchPrivacy & license
Local-first: every memory lives in a SQLite file on your machine, recall returns the exact stored text,
and capture/recall/forget make no network calls. No account, API key, or telemetry. The only outbound
traffic is a one-time embedding-model download (for the local backend) and the package install.
Optional encryption at rest: set MIDAS_MCP_KEY with the [encrypted] extra and the store is a
SQLCipher database — unreadable without the key (and Midas fails closed rather than silently writing
plaintext). Full details in PRIVACY.md · MIT.
Available Tools
23 toolsaudit_useAudit memory useARead-only
The compliance audit artifact for a memory-justified use: the guard decision + the full provenance and belief-revision history of every supporting memory + an attributability score (fraction of evidence with both a source and an actor). Hand this to an auditor to prove WHY an action is or isn't justified. Source-traceable, deterministic, no LLM.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| namespace | No | ||
| intended_use | No | external_action |
TDQS
A3.5/5.0
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.
build_contextBuild contextARead-only
Assemble a budgeted, prompt-ready context block for a query.
Highest-value memories first, with same-session neighbours pulled in, trimmed to token_budget.
Drop the returned string straight into an LLM prompt. It uses lean memory lines by default;
call recall or inspect_memory when you need full provenance/source evidence. Each line is dated
and the header anchors today's date so the reader can resolve relative time. Standing user
directives ("from now on…", "always…") are pinned in regardless of query relevance.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| hybrid | No | ||
| namespace | No | ||
| token_budget | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
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.
captureCapture turnA
Offer a turn to memory; Midas decides whether to keep it (no LLM).
Forward anything that might be durable — a fact, decision, preference, constraint, or correction. Midas scores its importance and keeps it only if it clears the relevance policy and isn't a duplicate, so you can capture freely without polluting memory. Returns whether it was stored and why (so you learn the bar). This is the workhorse for hands-off, automatic remembering. kind: note | chat | fact | preference | constraint | mission. provenance: planning | action | observation | user_confirmation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | chat | |
| actor | No | ||
| content | Yes | ||
| session | No | default | |
| namespace | No | ||
| provenance | No | observation |
TDQS
A4.2/5.0
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.
check_forbidden_actionCheck forbidden actionARead-only
Before a code action, check it against the project's live forbidden_action rules. Two tiers, by
confidence (deterministic, no LLM; superseded/retired rules ignored):
forbidden(HIGH confidence, lexical match) → do NOT do it; refuse and citerules.possibly_forbidden(ADVISORY, semantic/paraphrase match) → ASK the user before proceeding; the semantic signal is noisy (~31% false positives,eval.forbidden_eval), so it warns, not blocks. Separate from the provenance/currency gate (check_memory_use).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| project | Yes |
TDQS
A4.5/5.0
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.
check_memory_useCheck memory useARead-only
Decide whether recalled memory may justify the intended use.
intended_use: planning | answer | external_action | destructive_action. External/destructive actions require user_confirmation provenance; otherwise ask the user first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| namespace | No | ||
| acting_agent | No | ||
| intended_use | No | planning |
TDQS
A4/5.0
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.
close_loopClose loopA
Close an open commitment: records the resolution and supersedes the open loop with it, so
open_loops stops returning it while the promise -> resolution history stays auditable. Get
loop_id from open_loops (the record id).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| loop_id | Yes | ||
| resolution | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
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.
forgetForget memoryADestructive
Delete a single memory by id (ids come from recall). Supersession chains through the
deleted record are relinked, so belief-revision history stays walkable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
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.
forget_allForget allADestructive
Clear all stored memories (fresh start).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.4/5.0
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.
forget_matchingForget matchingADestructive
Topic-level erasure ("forget what you know about X") with a reviewable audit.
Matches memories at relevance >= min_relevance. By default this is a DRY RUN: it returns what would be deleted so you (or the user) can review; call again with dry_run=false to delete. Deletion bypasses durability protections — an explicit erasure request outranks retention — and returns the full list of removed memories as the audit trail.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| dry_run | No | ||
| namespace | No | ||
| min_relevance | No |
TDQS
A4.4/5.0
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.
inspect_memoryInspect memoryARead-only
Inspect one stored memory by id without search, mutation, or embedding exposure.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
TDQS
A4.1/5.0
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.
maintainMaintain memoryADestructive
Run a no-LLM memory-maintenance pass and return the deletion audit.
Bounds storage and keeps recall clean without sending anything to an LLM — the enterprise retention / "right to be forgotten" lever, with a full audit of exactly what was removed:
consolidate_threshold: if > 0, dedup near-duplicate restatements at this cosine (e.g. 0.95).
max_records: if > 0, forget the lowest-value tail until at most this many remain.
min_value: if > 0, forget every (non-durable, unprotected) memory scoring below this value.
ttl: age-based retention, "kind=days" comma list (e.g. "chat=30,note=90"); empty uses the server's MIDAS_MCP_TTL. User-confirmed/standing records and supersession chains never expire. Durable memories (facts/preferences/constraints, high importance) and supersession chains are never dropped. Returns counts and the ids removed (auditable).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | ||
| min_value | No | ||
| max_records | No | ||
| consolidate_threshold | No |
TDQS
A4.8/5.0
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.
memory_conflictsMemory conflictsARead-only
Live beliefs that CONTRADICT each other with neither superseding the other — the multi-agent
failure mode where two clients wrote opposite facts into the shared memory and both stayed live.
Returns ranked candidate pairs (NLI-scored when the local NLI model is enabled, else a same-slot
heuristic: numbers disagree / one side negates). Midas never resolves these silently: verify with
the user, then forget the wrong one or capture the corrected value (which supersedes). No LLM.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| namespace | No |
TDQS
A3.9/5.0
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.
memory_diffMemory diffARead-only
What CHANGED in memory in the last hours: beliefs newly added, and beliefs revised (old -> new).
The 'what's new since our last session' view for resuming long-horizon work without re-reading
everything. Deterministic, no LLM.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| namespace | No |
TDQS
A4.2/5.0
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.
memory_policyMemory policyARead-only
Return the exact MCP-injected memory policy text and guard parameters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
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.
memory_stateMemory stateARead-only
The CURRENT durable state of a project/scope: the live (non-superseded) decisions, constraints,
facts, and preferences, newest first. 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. Not a
similarity search and no LLM. kinds: optional comma list (constraint,fact,preference,mission) to
narrow; empty = all durable kinds.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | ||
| limit | No | ||
| namespace | No |
TDQS
A4.3/5.0
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.
open_loopsOpen loopsARead-only
Unresolved commitments — work someone said WOULD be done and never closed — oldest (most
overdue) first. Continuity is not only facts: check this when resuming so promised work isn't
silently dropped. Record one with remember_commitment; close it with close_loop.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| project | No | ||
| namespace | No |
TDQS
A4.2/5.0
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.
project_stateProject stateARead-only
The current code-state of a project for a coding agent, grouped by code_kind
(architecture_decision, bug_fixed, convention, forbidden_action, dependency_choice, ...). Live
(non-superseded) memories only — call this to ONBOARD into a project, or to see what is decided and
what is forbidden before acting. Deterministic, no LLM. Capture code memories with the SDK's
midas.coding.remember_* helpers (they tag code_kind + project).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| project | Yes |
TDQS
A3.9/5.0
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.
recallRecallARead-only
Retrieve relevant memories with deterministic, source-traceable evidence.
Returns exact stored text plus provenance/source/timestamps and, by default, score components (relevance, importance_norm, recency). No LLM rewrites or rationales are generated. Set hybrid=true to fuse BM25 lexical matching with semantic recall — useful when the query is an exact identifier (an error code, a function name) rather than a paraphrase. as_of: ISO date (YYYY-MM-DD) for a HISTORICAL query — "what did memory say on that date": later records are excluded and revised beliefs resolve to the version valid then.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| pool | No | ||
| as_of | No | ||
| limit | No | ||
| query | Yes | ||
| fusion | No | rrf | |
| hybrid | No | ||
| explain | No | ||
| namespace | No | ||
| min_relevance | No | ||
| min_importance | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
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.
rememberRememberA
Store a memory for later recall.
content: text to remember (a fact, decision, preference, or conversation turn). kind: note | chat | fact | preference | constraint | mission. importance: 1-5 (higher is weighted up in recall and protected from forgetting). 0 = auto-derive from content (no LLM) — concrete facts score higher than chit-chat. session: conversation/thread id used to group related memories. provenance: planning | action | observation | user_confirmation. Use user_confirmation only when the user explicitly confirmed the content; external actions may rely only on that provenance. actor: agent/process that produced the memory (default: MIDAS_MCP_ACTOR). namespace: scope tag (e.g. a project or user id); defaults to MIDAS_MCP_NAMESPACE.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | note | |
| actor | No | ||
| content | Yes | ||
| session | No | default | |
| namespace | No | ||
| importance | No | ||
| provenance | No | observation |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
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.
remember_codeRemember code memoryA
Capture a CODE memory tagged by category + project, for the coding-agent views. code_kind: one of
architecture_decision | dependency_choice | convention | bug_fixed | recurring_failure |
forbidden_action | command_worked | command_failed. Use forbidden_action for rules the agent must not
violate (they gate check_forbidden_action); afterwards project_state shows the live state by
category. No LLM. Set provenance="user_confirmation" only when the user explicitly confirmed it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| project | Yes | ||
| session | No | default | |
| code_kind | Yes | ||
| namespace | No | ||
| importance | No | ||
| provenance | No |
TDQS
A4.1/5.0
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.
remember_commitmentRemember commitmentA
Record a commitment (an OPEN LOOP): work you or the user said WILL be done — a promised fix,
a follow-up, a migration to finish. It stays visible in open_loops/resume until closed with
close_loop, so promises survive across sessions. due: optional free-text deadline.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | ||
| content | Yes | ||
| project | No | ||
| session | No | default | |
| namespace | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
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.
resumeResume sessionARead-only
START OF SESSION: everything needed to pick up where the last session left off, in ONE call —
pinned standing directives, live forbidden rules, what changed in the last hours (default: a
week), the current durable state, open commitments, and unresolved memory conflicts. context is
prompt-ready and token-budgeted; use it silently, then work. Complements build_context (which
needs a query): resume is the query-less session start. Deterministic, no LLM.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| project | No | ||
| namespace | No | ||
| token_budget | No |
TDQS
A4/5.0
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.
statsMemory statsARead-only
Memory stats: total count, breakdown by kind, namespace, and the temporal-tier distribution.
tiers: short (<= 1 day) / medium (<= 1 week) / long (older) — the short/medium/multi-day horizons. Pass namespace to scope the counts to one project/agent scope.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No |
TDQS
A4.4/5.0
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
23 tool updates
v0.1.0- First observed
audit_use - First observed
build_context - First observed
capture - First observed
check_forbidden_action - First observed
check_memory_use - First observed
close_loop - First observed
forget - First observed
forget_all - First observed
forget_matching - First observed
inspect_memory - First observed
maintain - First observed
memory_conflicts - First observed
memory_diff - First observed
memory_policy - First observed
memory_state - First observed
open_loops - First observed
project_state - First observed
recall - First observed
remember - First observed
remember_code - First observed
remember_commitment - First observed
resume - First observed
stats
TDQS
A4.2/5.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.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- memnodeOAuthdev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceLocal-first, file-based memory layer for AI agents — one shared Markdown vault across Claude, Codex, Gemini, Cursor and any MCP client. Provides read/write memory tools with an audit trail, per-agent trust levels, and Git sync; no cloud and no lock-in.2MIT
- AlicenseNot gradedqualityDmaintenanceLocal-first persistent memory for AI agents via MCP, enabling semantic search and memory sharing across agents with zero cloud cost and full privacy.161MIT
- FlicenseNot gradedqualityBmaintenanceLocal-first cross-agent memory for AI coding agents. Persistent, shared memory over MCP — what you tell one agent can be recalled by another — with all data stored in a single local SQLite file, no cloud and no API keys.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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