Loading ToolBench
Local-first MCP memory for long-running agents: compact reasoning, recover context, and export audit/SFT traces.
Loom-MCP has well-structured tool definitions with clear naming (verb_noun pattern: loom_weave_block, loom_list_threads, etc.) and comprehensive descriptions (100-200 chars, well above the 10-char minimum). All 5 tools have input schemas with type definitions and parameter descriptions. However, output schemas are not formally documented in the tool registration, responses are returned as JSON via jsonToolResult() helper, but the schema structure is not declared in the tool definition. Error handling is present (toolError helper with code, message, next_step guidance) but inconsistently applied across tools. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared, despite clear risk profiles (loom_delete_thread is destructive, loom_list_threads and loom_view_tapestry are read-only). Parameter validation is strong (Zod schemas with min/max constraints, regex patterns for thread_id), but some edge cases lack explicit guidance (e.g., what happens if a thread_id does not exist when calling loom_weave_block?).
Deletes all blocks for a thread. Use for cleanup/archival after confirming the thread is no longer needed.
Finalizes the session. Aggregates all blocks into the Memento research format: <think><|block_start|>...<|block_end|><|summary_start|>...<|summary_end|></think>. Exports to a versioned .jsonl file for fine-tuning purposes.
Lists all known reasoning threads and their block counts so you can manage long-term storage.
Retrieves the sequential list of all previous 'Warp' summaries for the current thread. Use this to maintain context without re-reading massive reasoning blocks.
Call this when your current analytical step is complete. It saves your raw reasoning ('The Weft') and a mandatory concise summary ('The Warp'). This clears your cognitive load for the next step.
Output schemas not formally documented in tool definitions. Responses are returned as JSON objects via jsonToolResult() helper, but the schema structure (fields, types, required properties) is not declared in the tool registration. LLMs cannot plan downstream operations or validate response structure.
Tool annotations missing. loom_delete_thread is destructive (requires confirm flag) but has no destructiveHint annotation. loom_list_threads and loom_view_tapestry are read-only but lack readOnlyHint. loom_weave_block is idempotent (same inputs produce same block) but lacks idempotentHint. Annotations guide LLM behavior (retry logic, confirmation prompts).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Error handling inconsistency. loom_weave_block returns success JSON but does not document failure cases (e.g., invalid thread_id, database write failure). loom_delete_thread has a confirm flag but no guidance on what happens if confirm=false. Error responses should include next_step guidance per pattern:recovery-guide.
Parameter descriptions lack format/constraint details. thread_id has regex validation (no null bytes, newlines) but description does not state this. raw_reasoning and summary have max length constraints (200k, 20k chars) but descriptions do not mention limits or guidance on compression. LLMs cannot self-correct without explicit constraints in descriptions.
No pagination or result limits documented for loom_list_threads. If many threads exist, the response could grow unbounded. Baseline pattern requires limit/offset and total count. loom_view_tapestry similarly lacks guidance on maximum tapestry size.