Loading ToolBench
Collaborative text exploration with base model completions via MCP
Loom provides 8 tools with mostly complete schemas and reasonable descriptions, but falls short of production-grade quality. Schemas are present and typed, but descriptions vary significantly in quality and actionability. Several tools lack the depth needed for LLM-driven selection. Error handling and recovery guidance are minimal. Tool composition is reasonable (each tool does one thing), but parameter documentation could be more explicit about constraints and expected formats. The server demonstrates understanding of MCP structure but lacks polish in prompt-engineering descriptions and edge-case handling.
Focus on node_id, then generate N new branches from it. Returns context + all new branches with IDs. Use n=8 for more options when exploring.
Delete a node and all its descendants.
Edit a node
This guide
Add custom text as child
Create new tree with seed text, then generate N branches. Returns seed + all generated branches with IDs.
Guide on writing good seeds
Parameter constraint documentation is inconsistent and partially absent from JSON Schema. Tools document 'n must be 1-8' in descriptions but JSON Schema lacks minItems/maxItems or minimum/maximum constraints. LLMs cannot read descriptions reliably, they need formal constraints.
node_id parameter handling is underdocumented. loom_branch notes 'first 8 chars ok' but this is not stated consistently in loom_edit, loom_delete, or loom_insert parameter descriptions. This ambiguity forces LLMs to guess whether to pass full IDs or prefixes, risking tool failures.
Destructive tools (loom_delete) lack confirmation/dry-run support. The description warns it cascades to descendants, but there is no mechanism for LLMs to preview what will be deleted before committing. This risks unintended data loss, especially in multi-turn agent scenarios.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
View tree structure and full context from root to focused node.
Output schemas are not documented in tool definitions. For example, loom_view, loom_seed, and loom_branch return complex nested structures (tree nodes, context, branch lists), but tool descriptions do not specify the response format (JSON fields, types, structure). This forces LLMs to guess at response shapes and plan follow-up calls blindly.
Discovery tools (loom_guide, loom_seeds) have weak descriptions. 'This guide' and 'Guide on writing good seeds' do not prompt-engineer the tool into the LLM's selection process. Descriptions should state WHEN to use them (e.g., 'Call this first to understand workflows') and how they relate to other tools.
Error handling is not visible in tool definitions or documentation. What happens when node_id is invalid? When n exceeds limits? When API calls fail? Tool descriptions contain no recovery guidance (e.g., 'If the node is not found, call loom_view() to list valid node IDs'). LLMs will have no strategy for handling failures.
Parameter relationships are not documented. For instance, parent_id in loom_insert 'defaults to focused node', but this is not stated in the parameter description, only in the guide. If focused_node_id is None, what happens? LLMs need explicit dependency documentation.
Tool descriptions lack actionable context for LLM decision-making. For example, loom_seed and loom_branch both generate branches, but descriptions do not clarify when to use one vs. the other. loom_seed creates a root; loom_branch extends from an existing node, but this distinction is not stated in description text.