Loading ToolBench
A live layered dependency map for bottom-up development — MCP server + terminal pane. Ghost the design first, then light nodes up from the bottom as they are built and verified.
mellos-mapping demonstrates strong definition quality with well-structured schemas, comprehensive parameter descriptions, and clear semantic intent. All 8 tools have explicit descriptions and fully typed input schemas. Tool names follow verb_noun conventions clearly (mmap_declare, mmap_update, mmap_remove, mmap_view, mmap_read, mmap_batch, mmap_setup, mmap_open). Descriptions are detailed (400-800 chars each), exceeding the 10-1024 char baseline and the 194 char average for production tools. Parameters consistently include type definitions, descriptions, and constraints. Output schemas are partially documented through tool semantics but lack explicit return-type JSON Schema in the definitions file. Error handling mentions CONFLICT returns but lacks comprehensive recovery guidance. Tool composition is excellent, each tool has a single clear responsibility, and together they form a coherent dependency-mapping domain. The main limitation is that output schemas are not formally defined in JSON Schema format alongside inputs, which prevents LLMs from reasoning about response structure before calling.
One-page mixed transactions validated against the final graph. Submit declare, update, and remove operations in sequence, each governed by the same validation as mmap_declare, mmap_update, and mmap_remove applied separately. All succeed or all fail together (ACID transaction), keeping the map consistent even when the batch is large.
Grow the Mellos map: set the title and diagram kind, add layer bands, lanes and groups (labeled subsystems within ONE band — declare them when a single band grows crowded, roughly five or more nodes in that band; a group must be a strict subset of its band, and a map spread thin across many bands needs none), add nodes, add dependency edges. Declare the missing design after reading existing pages with mmap_read; reuse verified nodes. Edges must point strictly downward (a node may only use nodes on lower layers); the batch is all-or-nothing. Title and kind can also be changed with mmap_update; this legacy form remains supported. Revising what already exists (moving, renaming, relabeling, clearing) is mmap_update.
Put the map on the user's screen — the one tool that reaches outside the store, by running the same launcher a human runs. Terminal pane opens on the user's machine (requires a terminal connection); web preview opens in the browser (works headless and cloud). The launcher is asynchronous; success means the command started, not that the pane is visible.
Bounded structured reads, revisions and source checks. Read the whole ledger (use mmap_batch to revise it), list the project's pages, and verify source files against their recorded SHA256 baselines without rescanning the repository. Every response includes the page's revision, used by the mutating calls to enforce conflict detection.
Output schemas not formally defined in JSON Schema. Tools document input schemas thoroughly but do not publish return-type schemas, preventing LLMs from reasoning about response structure before calling tools.
Error handling lacks recovery guidance for common failure modes. CONFLICT errors are mentioned but no actionable next-step guidance provided.
mmap_batch 'data' field lacks explicit nested schema. The 'data' object in operations references declare/update/remove semantics but does not embed or reference their schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2025-06-18+ | v2 |
Take things off the map (edges, nodes, groups, lanes, bands) — and whole PAGES, file and all. Removing a page also removes all references to it as a submap in other pages.
Get/set the mapping policy (when maps open). User-wide by default and per-project where a project must differ. The policy controls whether the pane opens on a user's screen (local and SSH development) or generates a web preview (headless and cloud environments); a project can override the user's choice when the repository has special needs.
Record progress AND revise: update node status and evidence, design notes, positions, renames, relabel subsystems, change diagram kind, reorganize lanes. Revising what already exists (moving, renaming, relabeling, clearing) is mmap_update. Title and kind can also be set with mmap_declare; this form also handles them.
Render the map as text, and name the project's pages. Output is a picture meant for human reading only: mmap_read and mmap_batch are the data surfaces.
Tool descriptions reference domain concepts (band, group, lane, node, layer) that are defined in detail but could benefit from a glossary or inline expansion for first-time users.