Loading ToolBench
A local task-and-memory layer for coding agents; MCP server that provides workspace-aware tools for task management, memory recall, and code intelligence
myc is a specialized task-and-memory management server with well-structured tool definitions. All 7 tools have explicit schemas with typed parameters and descriptions. Naming follows verb_noun convention (myc_prime, myc_ready, myc_update, myc_recall, myc_remember, myc_show, myc_link). Descriptions are domain-specific and contextual (avg ~150 chars), explaining WHEN to call each tool. However, many parameter descriptions are terse or missing entirely (e.g., 'ws' param across all tools has minimal guidance; 'kind' and 'tag' arrays lack detail on valid values beyond enums). Error handling is implicit rather than explicit, no recovery guidance in descriptions. Output schemas are not documented in the provided source. Tool composition is strong: tools chain well (myc_ready → myc_update → myc_recall), and operations are idempotent where appropriate.
Create or remove a link between nodes: blocks/blocked-by (dependency), relates-to, duplicates, supersedes, contradicts, replies-to, derived-from, part-of. supersedes and duplicates require a reason — history is not rewritten.
Project start packet: ready queue, work in progress, core and recent decisions. Call ONCE at session start and again right after context compaction — replaces reading the README, plans and task history.
Tasks with no open blockers — what you can take right now. With claim=true it atomically takes the top one (or the one in id) and returns its description, deps and anchors at once — then just work, no extra calls.
Search project memory in your own words: facts, decisions, tasks, episodes. The answer is ranked and cut to the budget — read from the top and stop. WARN/degraded in the answer = part of the index is down, quality is lower than usual.
Record a conclusion, decision or fact so later sessions know it. One claim at a time, concrete, with its reason. No raw code or secrets. A contradiction gets flagged, it does not overwrite the old one.
Output schemas not documented. Tools return structured data but LLMs cannot see field definitions, types, or required fields. This forces agents to infer response structure from examples or trial-and-error.
Parameter descriptions are sparse or generic. 'ws' (workspace) appears in all 7 tools with minimal guidance ('workspace; M0: single, ignored'). 'kind', 'tag', 'layer' arrays lack detail on what values are valid beyond enums. LLMs cannot reason about when to use these filters.
No error recovery guidance. Descriptions do not explain what to do if a call fails (e.g., 'If task not found, try myc_recall to search by name'). Agents have no fallback strategy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Full content of one or more nodes at once: body, deps, links, code anchors. Pass the list of ids in one call, not one by one.
Every task state change in one tool: claim, release, close, reopen, assign, priority, note, extend; confirm/reject a compaction candidate. close, reopen and reject require a reason — it goes into project memory and later sessions see it.
Conditional parameter requirements not documented. myc_update requires 'reason' for close/reopen/reject but this is buried in the schema. myc_link requires 'reason' for supersedes/duplicates. Descriptions should state these dependencies explicitly.
Pagination and result limits not explicit. myc_recall and myc_ready accept 'n' (default 5-6) but descriptions do not explain why results are capped or how to iterate through large result sets. No 'next_cursor' or 'total_count' mentioned.