Loading ToolBench
A faithful browser re-skin of coding agents (Claude Agent, Codex, Gemini CLI, OpenCode) with generative UI layered on top
Mirafold provides 18 render/emit tools with consistent naming (render_* prefix) and detailed descriptions (avg 180 chars, well within 10-1024 range). All tools have the 'id' parameter for update-in-place semantics, properly described. However, input schemas are severely incomplete: only the 'id' parameter is visible in the provided code; the actual component-specific parameters (e.g., render_card's 'title', 'content'; render_chart's 'type', 'data', 'series') are referenced in descriptions but NOT shown in the schema definitions. This violates the critical rule: 'If a tool has NO input schema at all: its schema score MUST be 0.' Since schemas are inferred rather than explicitly visible, per-tool schema scores are capped at 0. Descriptions are strong (LLM-optimized, action-oriented, include usage guidance), but missing parameter-level documentation for the component-specific fields. No output schemas documented. Error handling is absent, tools are described as side-effect-free emitters, but no guidance on failure modes (invalid component data, rendering errors, etc.).
Render self-contained HTML/CSS/JS in a sandboxed iframe. LAST RESORT: use only when no render_* component can express what's needed (custom visuals, simulations, bespoke interactivity). The sandbox exposes exactly two outward calls: mirafold.prompt(text) sends text as the user's next turn; mirafold.tool(name, args) runs an allowlisted server helper (names: emit_artifact, render_card, render_list, render_table, render_chart, render_links, render_keyvalue, render_progress, render_timeline, render_filetree, render_question, render_diff, render_stat, render_code, render_statuslist, render_console, render_image, render_diagram). Anything else stays inside the sandbox.
Show a card in the output zone: a single highlight, summary, or verdict set off from the prose.
Show a chart in the output zone: line for trends over an ordered axis, bar for category comparisons, pie for a single part-of-whole split (exactly one series; ≤6 slices read best). On bar, stacked=true stacks the series into part-to-whole columns, and horizontal=true lays the category labels down the left — use it when names are long or categories many. For a distribution, pre-bin the values into labeled bar buckets yourself. Use for ANY plot/graph — never hand-write SVG or ASCII charts.
Show a block of code with a filename/language header and a copy button. For a change you made to an existing file, prefer render_diff (before/after). Use render_code to display code that is not a before/after — the contents of a new file you created, a snippet you're explaining, an example, or a config block.
Input schemas incomplete: only 'id' parameter visible; component-specific parameters (title, content, data, series, etc.) referenced in descriptions but not in schema definitions. Violates critical rule: tools with no visible input schema score 0 on schema dimension.
No output schemas documented. LLMs cannot infer what fields render tools return (e.g., does render_card return {id, timestamp}? {id}?). Breaks downstream tool chaining and context planning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Show terminal output you're quoting — a build log excerpt, a failing test's output, a stack trace — as a console block: optional command header, monospace body with ANSI colors rendered, exit-code badge. Quote the RELEVANT excerpt, not a whole log. For code itself use render_code.
Render a mermaid diagram (flowchart, sequenceDiagram, stateDiagram-v2, classDiagram, erDiagram) from its source text. Use for ANY architecture/flow/relationship picture — never ASCII-art diagrams, and never a raw ```mermaid fence (that renders as literal code here). Data plots stay render_chart.
Show a red/green line diff of a code change, made or proposed. Per file, pass the relevant lines as they were (before) and as they are/would be (after) — verbatim code, no +/- prefixes; the client computes the diff. Use instead of hand-written diff code fences.
Show a file/directory tree in the output zone. Use for ANY file-structure picture — never hand-draw ASCII trees.
Show a raster image from the workspace inline: pass the FILE PATH (png/jpeg/gif/webp, ≤2 MB) — e.g. a screenshot you just saved — and the daemon inlines the bytes; never encode them yourself. Use whenever you produce or verify something visual: app screenshots, rendered pages, plots saved to disk.
Show a two-column key/value fact sheet in the output zone. Use for config dumps, environment summaries, or any set of name→value facts.
Show a group of links in the output zone. Use for any collection of URLs worth clicking.
Show a list component in the output zone. Use instead of a markdown bullet/numbered list.
Show a progress bar for long-running work. Re-call with the returned id to advance the bar in place instead of stacking bars.
Ask the user a structured question with 2–6 clickable options. Clicking one sends its text as the user's next turn. Use when the next step is the user's call between concrete alternatives; never for open-ended questions.
Show a single-number stat tile: coverage %, p95, cost, a count — one glanceable KPI with an optional up/down change. Re-call with the returned id to update the number in place as it changes.
Show labeled rows each with a pass/fail/warn/pending/skip status pill. Use for check results — test suites, CI checks, lint rules, health probes — where every row carries a verdict.
Show a table component in the output zone. Use instead of a markdown table.
Show an ordered timeline in the output zone. Use when the sequence of events or stages is itself the point (chronology, plan, release history).
No error handling guidance. Descriptions claim tools are 'side-effect-free emitters' but do not document failure modes (invalid component data, rendering errors, malformed HTML in emit_artifact). LLMs have no recovery path.
emit_artifact 'html' parameter lacks format/length constraints. No guidance on CSP restrictions, sandbox limitations, or what happens if HTML exceeds size limits. LLMs may pass oversized or unsafe payloads.
render_image description mentions 'FILE PATH' but does not specify: absolute vs relative paths, working directory context, or what happens if file does not exist or exceeds 2 MB. Ambiguity invites LLM errors.