Loading ToolBench
Model Context Protocol server that exposes AgentUI tools for rendering interactive UI components (forms, tables, plots, diffs, confirmations, containers, applets) and handling user interactions
AgentUI MCP provides 10 well-structured UI tools with complete JSON Schema definitions and clear, purpose-driven descriptions. All tools have explicit input schemas with typed parameters and required fields. Descriptions are concise (50 - 200 chars) and explain WHEN to use each tool. However, parameter descriptions are sparse or missing entirely, most parameters lack explanatory text beyond their type. Output schemas are not documented. Error handling and recovery guidance are absent. Tool names follow a consistent ui.* namespace but lack action verbs (e.g., 'ui.form' vs 'show_form' or 'collect_form_input'). No tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles (ui.view.replace is WRITE; others are READ_ONLY).
Use only for custom spatial or stateful mini-applications that need executable local behavior beyond ordinary AgentUI widgets, such as small games, diagram canvases, simulations, drawing tools, node graphs, or timeline editors. Prefer text for explanations and declarative AgentUI widgets for normal forms, tables, choices, plots, diffs, and confirmations. Applets run locally; ordinary pointer, keyboard, and frame events do not go to the model. Only semantic applet events escape back to AgentUI.
Open the prebuilt Pong WASM applet. Use only when the user explicitly asks to play or open the Pong game demo. This is not a generic applet loader; it always opens the bundled Pong applet.
Use when the user needs to choose one or more options before the task can continue.
Use when a consequential action requires explicit user approval.
Use when multiple UI elements must be shown together in one response, such as three tables or a table plus explanatory text. Do not call ui.table repeatedly for a multi-table result; instead put all tables/widgets in this single container so the whole group is rendered as one current UI.
Parameter descriptions are missing or minimal. Most parameters (viewId, title, fields, options, etc.) lack explanatory text. LLMs cannot infer parameter semantics from names alone, 'viewId' is opaque without context explaining what it identifies or how to obtain it.
Tool names lack action verbs. All tools use the ui.* namespace (ui.form, ui.choice, ui.table) rather than verb_noun patterns (show_form, collect_choice, render_table). This makes it harder for LLMs to infer intent from the name alone before reading the description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Use when the user needs to review proposed text or code changes.
Use when several related inputs or choices need to be collected from the user.
Use to display numeric 2D data on an auto-ranged graph. Provide points as [{ x: number, y: number }]. mode='points' draws circles, mode='lines' connects consecutive points, and mode='bars' draws vertical bars from the X axis (y=0) to each point.
Use when structured records are easier to scan as rows and columns. Each column.key must exactly match a property name in every row object. Use name for the table caption row displayed above column headers. For submitted form values, prefer rows like { field: 'environment', value: 'staging' } with columns [{ key: 'field', label: 'Field' }, { key: 'value', label: 'Value' }]. If multiple tables must be shown together, use ui.container with several table widgets instead of calling ui.table repeatedly; each nested table should set name.
Replace a complete renderer-independent view. Use as an escape hatch for custom widget trees.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. ui.view.replace is marked WRITE but lacks destructiveHint annotation. Others are READ_ONLY but lack readOnlyHint. Annotations enable agents to reason about safety and retry semantics.
Output schemas are not documented. Tool descriptions do not explain what fields are returned or what structure the response has. LLMs cannot plan downstream tool calls or extract data without knowing the response shape.
No error handling or recovery guidance. Tool descriptions do not explain what errors can occur, how to interpret them, or what the LLM should do next. A failed form submission or invalid applet module URL provides no actionable recovery path.