Loading ToolBench
Human-AI collaborative development framework — MCP server for Claude Code with companion web UI. Enables structured artifact presentation, feedback collection, and cross-project philosophy tracking for pair programming workflows.
18 tools with mixed quality. Naming is strong (verb-first, clear intent). Descriptions are present but often verbose and lack LLM-optimized brevity (many exceed 200 chars). Input schemas visible for most tools but lack granular parameter descriptions and type constraints. Output schemas largely undocumented. Error handling guidance is minimal. Tool composition is reasonable but some tools conflate multiple concerns (e.g., present_* tools bundle validation + UI presentation). No evidence of idempotency guarantees or rate-limiting guidance.
Ask the human a question via the companion UI and wait for their response. Used for clarifications during the development workflow.
Poll the companion UI for human feedback on a presented artifact. Returns the human's decision (approved/rejected/revised) and any comments. Blocks until feedback is available or timeout.
Export the current session as a JSON file containing all artifacts, feedback, and metadata for archival or external analysis.
Get the URL of the companion web UI. Returns the localhost URL where the companion interface is running.
Log reasoning and internal monologue. Persists to the session artifact ledger for cross-project philosophy tracking and concept naming.
Post a code review on a pull request. Attaches findings, options, and feedback to an external PR for collaborative review.
Descriptions exceed LLM-optimized range (10 - 200 chars). present_findings, present_options, present_spec, present_plan descriptions are 250 - 400+ chars, burying key intent in verbose prose. Baseline: 194 chars avg, p90=392.
Parameter descriptions missing or minimal. Input schemas show parameter names (findings, options, requirements, etc.) but lack per-parameter descriptions explaining what each field controls, valid ranges, or constraints. Baseline: 100% of A+ tools have param descriptions.
Output schemas undocumented. No visible documentation of what check_feedback, export_session, recall, or answer_question return. LLMs cannot plan downstream calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2025-06-18+ | v2 |
Present a changeset artifact — a collection of related code changes, file modifications, and refactorings. Used for larger, multi-file modifications that need coordinated review.
Present a code change artifact with before/after diffs, file paths, and optional reasoning. Used to propose code modifications for human review.
Present a debrief artifact — a summary of work completed, decisions made, and lessons learned. Used to document the outcome of a development session.
Present an explainer artifact — a walkthrough or explanation of existing code, architecture, or concepts. Used to document and teach about the codebase.
Present research findings as a structured artifact in the companion UI. Each finding carries evidence, category, significance, severity, a `concept`, and optional `visuals[]`. Schema note: `findings` is an array of objects (NOT a string). Required per-finding: category, detail, significance. Name each finding's `concept` ({name, oneLineExplanation?}) — the PREFERRED place to name a pattern (ahead of log_reasoning). Non-code passages (no file:line) anchor via a `locator`. INPUT_VALIDATION_FAILED on mismatch (bad path + example). Workflow: SINGLE REVIEW SURFACE — the companion UI is the only review surface. Don't paste findings in chat; call check_feedback for the verdict.
Present 2–4 options with pros/cons/effort/risk for the human to choose. Y5: each option SHOULD include `concept` ({name, oneLineExplanation?}) — the underlying pattern (e.g. 'external cache service'). Concepts make rejections compound across projects via the philosophy ledger. Schema note: `options` is an array of 2–4 objects. `concept` optional but strongly preferred. INPUT_VALIDATION_FAILED on mismatch. Workflow: SINGLE REVIEW SURFACE — human selects in the companion UI; don't list options in chat. Call check_feedback for the selection. Set stakes='high' on hard-to-reverse calls (schema/auth/infra) — the UI weights those decisions visually.
Present an implementation plan as steps with file changes and before/after previews. Schema note: `steps` needs `description` + `reasoning` each. VISUALS (encouraged): attach `visuals[]` so the human reviews a picture — each a stable `id` (keep across revisions), a `kind` (diagram/file_map/doc_map/prototype/annotated_code; see inputSchema), and `title`. INPUT_VALIDATION_FAILED on mismatch. Workflow: SINGLE REVIEW SURFACE — this REPLACES Claude Code's native plan-approval flow. Do NOT call ExitPlanMode after present_plan. The companion UI is the only approval surface; call check_feedback for the verdict.
Present a feature spec — objective, requirements (each with rationale + acceptance criteria), optional design notes and tasks. For non-trivial work that'd otherwise skip straight to code without agreement on what's being built. Schema note: `requirements` is a non-empty array of objects with `id`, `statement`, `rationale`, `acceptanceCriteria`. VISUALS (encouraged): attach `visuals[]` — each a stable `id`, a `kind` (diagram/file_map/doc_map/prototype/annotated_code; see inputSchema), and `title`. INPUT_VALIDATION_FAILED on mismatch. Workflow: SINGLE REVIEW SURFACE — the companion UI is where the human reviews requirements. Don't re-paste in chat. Call check_feedback for the verdict.
Query the cross-project philosophy ledger for prior stances, rejected approaches, and approved patterns. Returns relevant concepts and decisions from other projects to inform current decisions.
Revise an existing artifact (findings, options, spec, plan, code change, changeset, debrief, or explainer) with updated content. Maintains revision history and triggers re-validation against team preferences.
Update the progress of an implementation plan step. Marks steps as in-progress, completed, or blocked with optional notes.
Withdraw (delete) an artifact from the session. Removes it from the companion UI and marks it as withdrawn in the ledger.
Error handling guidance absent. No tool documents what errors can occur, how to recover, or what the LLM should do next. E.g., present_findings mentions INPUT_VALIDATION_FAILED but provides no recovery path.
Tool composition concern: present_* tools bundle validation + UI presentation + artifact creation. Splitting validation (validate_findings) from presentation (present_findings) would allow reuse and clearer error handling.