Loading ToolBench
Persistent memory layer for engineering agents. Stores and retrieves engineering decisions, invariants, gotchas, bugs, and other memory items with conflict detection and evidence tracking.
Totem MCP demonstrates solid foundational quality with comprehensive tool coverage (16 tools) and well-structured schemas. All tools have descriptions (avg ~100 chars) and input parameters with types. However, several patterns are underutilized: no tool annotations (readOnlyHint/destructiveHint), limited error guidance, and output schemas not explicitly documented. Parameter descriptions are present but often terse (avg ~50 chars). The memory system is well-designed with proper validation (confidence/importance ranges, tag normalization), but error responses lack recovery guidance. Naming is clear and verb-driven (memory_create, memory_get, memory_update, memory_delete, memory_list, memory_search, etc.), following the verb_noun convention well. No critical security issues detected, no secrets in parameters, proper validation of enums (memory types, statuses). Composition is sound: tools are single-responsibility and chainable (e.g., memory_create returns ID for use in memory_get). Main gaps: output schemas not documented in tool definitions, error messages not shown in source, and missing tool annotations for destructive operations.
Get engineering context for specified file paths.
List command outcome memories (gotchas tagged with cmd:*).
Create a new memory item.
Soft-delete a memory item. Reason is required.
Export all memories and conflicts as a portable dict.
Retrieve a memory item by ID with staleness check.
Import memories and conflicts from a portable dict.
Output schemas not documented in tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing return structure (e.g., memory_create returns {id, status, warnings, conflicts} but this is not declared in the tool schema).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Destructive tools like memory_delete_tool and memory_import_tool should be marked with destructiveHint=true to signal to agents that these operations are irreversible.
Error handling and recovery guidance not visible in source. Tools validate inputs (e.g., confidence in [0,1], tags required) but error responses are not shown. LLMs need actionable error messages like 'Invalid confidence: must be 0-1. Try again with a value between 0 and 1.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List memory items with optional filters.
List most recently created memories.
Hybrid tag + full-text search.
List in-progress task memories (tagged with task:*).
Update a memory item. Reason is optional but strongly recommended.
Register what was learned from reading a file.
Register what was changed in a file.
Mark a conflict as resolved.
Initialize totem for a project. Creates .totem/ directory and DB if missing.
Parameter descriptions are terse (avg ~50 chars). Examples: 'Filter by type' (13 chars), 'Filter by tags' (14 chars), 'Filter by status' (16 chars). Expand to explain WHEN to use each filter and what values are valid, e.g., 'Filter by memory type (decision, invariant, gotcha, rejected_idea, assumption, open_question, ambiguity, contract, constraint, hypothesis, observation, bug, architecture, implementation). Omit to return all types.'
memory_commands_tool definition location unclear (listed as .opencode/plugins/totem-enforce.js, not src/totem_mcp/server.py). If this tool is not registered in the main MCP server, it may not be discoverable. Verify all 16 tools are registered in the fastmcp server definition.