Loading ToolBench
A local-first visual architecture handoff and review workbench for coding agents and humans.
Strong architectural patterns with clear governance intent. All 11 tools have descriptions (194 - 1024 chars, well above 10-char minimum). Input schemas present with Zod validation and type definitions. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) correctly applied. Key gaps: artifact/evidenceManifest parameters (tools 5 - 7) lack detailed schema documentation; output schemas not formally documented in code; error handling guidance minimal (generic errorResult wrapper). Naming is verb-forward and clear (get_, create_, submit_, read_, list_). Composition is sound, tools chain logically (create_agent_run → submit_* → get_run_status). No secrets exposed as parameters.
Create a traceable run and lock its published baseline plus any active draft ID/revision. Use one architecture patch per discovery or change-plan run, then create a new run from the updated compact draft for the next patch. Implementation runs additionally lock the exact executable published target, contract, and document hashes.
Read the human-published executable architecture baseline for a diagram. Returns the approved target revision, contract ID, and document set hash for implementation reconciliation.
Read a current or target architecture lane as compact published and active-draft semantic graphs. A target draft includes its compact unpublished development contract and stable acceptance-criterion IDs; it is never presented as an approved target.
Read the viewer project, diagram catalog, selected published baseline and execution status, contract invalidation reason, document index, and human-governance boundaries before inspecting or planning.
Read the status, evidence trail, and acceptance claims of a run. Returns the run metadata, submitted artifacts, evidence manifest, and any server-computed gates or contract invalidation.
Three submit_* tools (submit_architecture_snapshot, submit_change_proposal, submit_implementation_report) accept 'artifact' and 'evidenceManifest' as generic objects with only type:'object' and description. No nested schema, field names, or constraints visible. LLMs cannot infer required fields or structure.
Output schemas not documented in tool definitions. Callers cannot predict response structure (e.g., what fields does get_project_context return? Is it paginated?). Forces LLMs to guess or make discovery calls.
Error handling uses generic errorResult() wrapper returning only code, message, and optional details. No recovery guidance (e.g., 'Try search_users() first' or 'Retry in 30s'). Errors are not categorized as retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
List available workspace files that can be used as architecture evidence. Returns file paths, types, and metadata for code facts and design documents.
Read a workspace file as architecture evidence. The viewer enforces path safety, file type validation, and size limits.
Read one registered Markdown document, optionally narrowed to an exact heading. The viewer enforces the project document root, size limits, section matching, and returns content hashes; this is target-design context, not code-fact proof.
Submit a code-fact-backed current architecture snapshot. In an architecture-discovery run, the server applies its additive stable-ID semantic diff directly to the exact locked current draft; stale writes are rejected, and this never publishes or records human approval. In an implementation-reconcile run, the snapshot remains reconciliation evidence only, must come before the report, and never writes the current draft. Discussion and design intent cannot prove implementation.
Submit a stable-ID semantic patch backed by user confirmation, design documents, code facts, or labeled agent inference. The server validates the patch against the locked draft, applies it if valid, and records the evidence trail.
Submit an implementation report with acceptance criteria satisfaction claims. The server validates the report against the locked published target, contract, and document hashes; records the claim; and returns the acceptance status.
read_project_document accepts 'section' parameter but no guidance on how to discover valid section headings. LLMs must guess or make trial calls. Missing discovery tool or list_project_document_sections.
No pagination parameters (limit, offset, cursor) on list_analysis_sources. If workspace has hundreds of files, response could explode context window. Baseline: paginated tools should accept page/offset + limit and return total count.