Loading ToolBench
Local-first MCP memory backend and governance console for coding agents. Provides structured memory storage, rule governance, and agent skill management through MCP protocol.
MemoryGuard exhibits significant quality gaps across naming, descriptions, and parameter documentation. While all 26 tools are explicitly registered with input schemas in src/memoryguard/mcp_server.py, the schemas are sparse and descriptions are often generic or missing actionable context. Tool naming is inconsistent (some follow verb_noun like 'create', 'read', 'update', 'delete', but others use non-standard patterns like 'memoryguard_canonical_status' and 'memoryguard_diagnostics_snapshot' which lack clear action verbs). Parameter descriptions exist but are frequently vague (e.g., 'Agent instance identifier' without explaining what it controls or how to obtain it). Output schemas are not documented in the visible code, forcing LLMs to infer result shapes. Error handling is basic (referenced via 'errorReporting=true' flag but not visible in tool definitions). Critical governance tools (rule_create, atom_create) expose complex policies and scopes without examples or validation guidance. No evidence of idempotency guarantees, dry-run modes for destructive operations, or error recovery paths in the descriptions.
Create a new memory atom with optional evidence linking
Delete a memory atom
List memory atoms with optional filtering by status, kind, or scope
Read a memory atom by ID with optional scope filtering
Update an existing memory atom
Create an agent-group binding for memory sharing
Delete an agent-group binding
Read an agent-group binding configuration
Tool names lack consistent action-verb prefixes. 'memoryguard_canonical_status', 'memoryguard_diagnostics_snapshot', and 'memoryguard_projection_status' use noun-based names that do not clearly signal the action (get_canonical_status, get_diagnostics_snapshot would be clearer). LLMs cannot infer intent from unclear verbs.
Parameter descriptions are generic and lack actionable constraints. E.g., 'Unique identifier for the memory atom' (for memory_id) does not explain the format, maximum length, character restrictions, or how to obtain one. 'Policy for injecting memory (always, on_demand, never)' should be an enum constraint in the schema, not just mentioned in description text. LLMs cannot read schema pattern fields, they rely on descriptions to understand constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Update an agent-group binding
Query canonical rule projection status and health diagnostics
Bootstrap initial agent context and workspace setup
Capture read-only diagnostics snapshot of rule reconciliation jobs and canonical state
Attach evidence to a memory atom or rule
Read evidence linked to a memory atom
Perform SQLite database compaction and optimization (requires trusted context)
Verify database integrity and consistency
Query rule projection state and lag metrics
Install or configure a new agent provider
Create a new governance rule
Delete a governance rule
List governance rules with optional filtering
Read a governance rule by ID
Update an existing governance rule
List active runtime processes and background jobs
Invoke a registered skill with parameters
Register a new agent skill or capability
No output schemas documented. Tool descriptions state what they do (read a rule, list atoms) but do not document what fields the response contains or how to chain results to downstream tools. For example, memoryguard_atom_list does not declare whether it returns total_count, next_cursor, or per-item details needed by update/delete calls. LLMs must infer result shapes, increasing hallucination risk.
Destructive operations (memoryguard_atom_delete, memoryguard_rule_delete, memoryguard_binding_delete) have no dry-run option, confirmation step, or compensation tool documented. Agents make mistakes, no tool offers a clear safety gate. Descriptions must say 'This action is irreversible' and 'Confirm before execution if possible.'
Complex governance parameters (injection_policy, scope, priority, status) exposed without validation guidance in descriptions. 'Policy for injecting memory (always, on_demand, never)' is mentioned inline but should be an explicit enum constraint. 'Status of the atom (active, archived, superseded)' lacks explanation of when each is valid or how state transitions work. LLMs will hallucinate invalid values.
No error recovery guidance. Tool descriptions do not hint at next steps on failure (e.g., 'If memory_id not found, call memoryguard_atom_list to search' or 'Invalid status, must be one of: active, archived, superseded'). Error responses from code are not visible, so assume basic or missing. Agents left to guess on failures.
Opaque IDs forced for lookups (agent_instance_id, share_group_id, project_ref). No tool accepts human-readable names (e.g., agent_name alongside agent_instance_id). Agents must call separate discovery tools just to find IDs, wasting tokens and latency. UX mismatches chat data model.
Maintenance tools (memoryguard_maintenance_compact) expose low-level internals (database file paths, generation numbers, CAS checks) without explaining the normal workflow or safety implications. 'Expected manifest generation for CAS check' is jargon that an LLM cannot reason about. These are likely admin-only, should not be default tools.
Pagination missing from list tools. memoryguard_atom_list, memoryguard_rule_list accept 'limit' but no offset/cursor for continuation. Large result sets will truncate, and the LLM has no way to fetch the next page. Pattern baseline expects pagination support on all list tools.
No idempotency guarantees documented. Tools like memoryguard_atom_create may not be idempotent, calling it twice with the same memory_id could fail or create duplicates. Agents retry on ambiguous failures. Descriptions must state whether tools are safe to retry.