Loading ToolBench
MCP server providing growing-memory context management, task tracking, and knowledge preservation for Claude Code and Codex environments. Includes session bootstrap, context recovery, task completion feedback, and pre-compaction memory preservation hooks.
Melxis Toolkit presents a well-structured domain model with 21 tools covering hive (project) management, mels (memory entries), tasks, and guides. Tool naming follows verb_noun conventions consistently (hive_search, mel_create, task_update). Descriptions are present and domain-specific (10 - 200 chars), explaining WHAT each tool does and WHEN to use it. Input schemas are visible with typed parameters and descriptions. However, output schemas are not documented in the provided source, critical for LLM planning. Error handling guidance is minimal; tools lack recovery hints. Parameter constraints (enums, ranges) are sparse. The domain is coherent but lacks production-grade polish in error messaging and output documentation.
Write the first version of a hive guide. Records how work should be done in this hive from the user's stated purpose.
Retrieve the guide for a hive (what belongs in this hive, where each kind of thing goes, how to work in it).
Update an existing hive guide with changes to how work is done in this hive.
Retrieve hive context including guide (what belongs in this hive, where each kind of thing goes, how to work in it) and pointed-at mels. Only works for own anchor hives.
Create a new hive (project container). Asks the user for confirmation even under auto write policy. Suggest a name (the project's own, e.g. the repo) and a one-line description.
Search for hives (project containers) by inferred project name. Returns hive metadata including own/writable status and owner_account_id.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does hive_search return? Does it include owner_account_id for chaining?). Critical for tool composition.
Error handling lacks recovery guidance. Tools do not specify what to do on failure (e.g., 'mel not found, try mel_search() first'). Agents cannot self-correct.
Parameter constraints missing. 'sort' in task_search lacks enum values (e.g., 'recency', 'priority'). 'kind' in task_note lacks enum (note|question|blocker). Free-form strings invite hallucinated values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Create a new mel (memory entry) for a durable insight, decision, root cause, or reusable procedure. Subject to write policy (auto/smart/confirm).
Delete a mel. Currently hard delete; soft/bi-temporal invalidation planned. Subject to write policy.
Retrieve a specific mel by ID.
Create a link between mels with a reason (e.g. 'supersedes', 'extracted-from-task'). Links connect mels; justify each link in a sentence.
Delete a link between mels. Subject to write policy.
Patch an existing mel to correct or sharpen it. Preferred over mel_update for incremental refinements.
Search for mels (memory entries) by query. Supports cross-hive search when hive_ids and owner_account_ids are unset.
Update an existing mel with new content. Prefer over mel_create when refining existing memory.
Create a new task to anchor multi-step work. Subject to write policy.
Delete a task. Subject to write policy.
Retrieve a specific task by ID, including its timeline (task history in time order, newest 50 entries by default) and current description.
Add a note to a task's timeline. One entry per event with kind note/question/blocker. Notes are read only through the task's timeline, never found by search.
Patch a task with incremental updates.
Search for tasks within a hive for handoff recovery. Returns recent tasks sorted by recency. Tasks are private to each account.
Update an existing task with new description, status, priority, tags, or related_mel_ids. Read-modify-write; arrays replace.
Patch tools (mel_patch, task_patch, guide_patch) lack documentation of valid patch object structure. LLMs cannot know which fields are patchable or what format to use.
Write policy ('auto/smart/confirm') mentioned in descriptions but not exposed as a parameter. Agents cannot control confirmation behavior; unclear how policy is determined.