# tool-ui: React Components for Rendering AI Tool Calls > tool-ui is an open-source library from assistant-ui that replaces raw JSON tool payloads in AI chat interfaces with interactive React widgets. The repository is archived; the last push was on 2026-08-31. **assistant-ui/tool-ui** — UI components for AI interfaces - Repository: https://github.com/assistant-ui/tool-ui - Website: https://tool-ui.com - Stars: 779 · Forks: 30 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/assistant-ui-tool-ui ## Raw JSON in the Chat Thread: The Problem tool-ui Addresses When an AI model calls a tool and returns a payload, most applications either hide the operation entirely or dump the raw JSON directly into the conversation thread. Raw JSON is unreadable for non-technical users and offers them no way to interact with the result. tool-ui is a React component library built to close this gap. It provides prebuilt widgets that render tool payloads as human-readable, interactive interface elements: approval cards, option lists, data tables, weather widgets, charts, code blocks, and more. The library targets React developers building AI chat interfaces on models that support tool calling. If your application uses tool calling to fetch data, present choices, or trigger confirmations, tool-ui provides components to surface those operations to users without building custom rendering code for each one. The project belongs to the assistant-ui organisation, which also maintains the assistant-ui conversation framework. tool-ui is focused narrowly on the rendering layer and does not manage model API calls, tool routing, or conversation state. Those remain in your own code or in whichever AI SDK you use. ## The Copy-Paste Distribution Model and Its Trade-offs tool-ui follows the same distribution approach as shadcn/ui: components are not published as an installable npm package. Instead, you copy component source files directly into your project and own them from that point forward. There is no versioned package to pin or upgrade in your dependency tree. This model has concrete trade-offs. Because you own the code immediately, an upstream breaking change cannot land silently through a package update. The cost is that you also receive no automatic bug fixes. If a component has a defect, you fix it yourself or compare the upstream source with your local copy and merge the change by hand. For a project that is now archived, the second option is limited to what exists in the repository as of 2026-08-31. The components are built on Radix UI primitives and styled with Tailwind CSS. They integrate with shadcn/ui themes and expect that design system's conventions to be present in the project. If your project uses Material UI, Ant Design, or another component framework, you cannot use these components without rewriting the styling layer. The Radix primitives are embedded throughout the component structure, not only in the visual output. For developers who want to run the documentation site locally and browse the component gallery before copying anything, the root package.json provides a pnpm script: ```bash pnpm dev ``` This starts the documentation application locally. ## Component Categories: From Confirmation Flows to Media Rendering The library organises its components into five categories. Progress components include Plan and Progress Tracker. Input components cover Option List, Parameter Slider, Preferences Panel, and Question Flow. The Question Flow component handles multi-step guided questions with branching, which the README describes as its specific purpose for conversational decision trees. Display components handle Citation, Geo Map, Item Carousel, Link Preview, Stats Display, Terminal, and Weather Widget. Artifact components include Chart, Code Block, Code Diff, Data Table, and social post renderers for Instagram, LinkedIn, X, and Message Draft. Confirmation components are Approval Card and Order Summary. Media components cover Audio, Image, Image Gallery, and Video. Each component ships with a Zod schema that defines the expected payload structure. When your code receives a tool call result, it parses the payload against the schema before rendering. If the payload is malformed or missing required fields, the component fails gracefully rather than crashing the interface. The README describes this validation as the ability to "fail safely when not" valid, which is an important property for interfaces that depend on models producing consistent output. The gallery at tool-ui.com shows every component rendered with realistic example data using bundled presets. This gives a direct preview of what each component looks like before copying it into a project. ## Interactive Choices and the Receipt Pattern Several input components, particularly Option List and Question Flow, are designed to capture user selections and return them to the assistant in the next conversation turn. This is a different contract from a passive display widget. When a user selects an option or completes a question flow, the chosen value flows back into the conversation so the model can branch its next response accordingly. The library describes persisted selections as "receipts". Once a user has made a choice, the component switches from an input state to a receipt display, showing what was selected rather than re-presenting the input controls. This prevents the same prompt from appearing again if the conversation is re-rendered and gives a visible record of decisions made during the session. The architecture assumes that the host application will pass the selected value back to the model. How that callback is wired depends on the AI SDK and conversation state management your application uses. tool-ui provides the UI side of this interaction only; the routing of the chosen value back to the model is the application's responsibility. ## Limitations: Archive Status, Design System Coupling, and No Release History The repository is archived. No new components, bug fixes, or schema updates will come from the upstream maintainers. Any issue found in a copied component is the adopter's responsibility to fix. The archive also means that if the Zod schema for a component does not match your model's actual output format, there is no upstream channel to report and resolve the mismatch. The Radix UI and Tailwind CSS dependency is a hard constraint rather than a soft preference. Styling these components for a different design system requires rewriting their structure, not only swapping CSS class names. Projects that do not already use Tailwind CSS will need to add it before any component renders correctly. The library is written in TypeScript. Plain JavaScript projects can copy and use the components, but the TypeScript type definitions and Zod schema types become optional extras unless TypeScript tooling is added. The repository has no GitHub releases and no per-component changelog. There is no audit trail of what changed between any two states of the component source, which makes it difficult to understand what you received when you copy at a given point in time. ## Alternatives: Vercel AI SDK Generative UI and Custom Rendering The most direct alternative is using the Vercel AI SDK's generative UI support, which provides hooks and streaming primitives that let you map each tool name to a React component written by your team. This approach involves more upfront work per component but places no constraints on your design system or dependency choices. Building tool call renderers from scratch using plain React is the other option, giving complete control over the output but requiring validation, error handling, and the receipt pattern to be written separately for each component type. tool-ui's practical advantage over both approaches is the breadth of the existing catalogue. If the components in that catalogue match what your tools produce, the copy-paste approach delivers a working interface faster than building from scratch. If your tools produce payloads that do not fit any existing component shape, the library offers nothing beyond a structural pattern to follow. ## Conclusion tool-ui suits React developers building AI chat interfaces on top of tool-calling models who need a working set of interactive widgets without writing them from scratch. Teams using a design system other than shadcn/ui should expect significant restyling work before any component is usable. Before copying a component, confirm that its Zod schema matches the payload shape your model actually returns: the archive means no upstream correction will arrive if it does not. ## FAQ ### Does tool-ui work with any AI SDK or model? tool-ui is a rendering library only. It does not include an AI SDK, conversation management, or tool call routing. You supply the tool call payloads from whichever AI SDK your application uses and parse them against the component's Zod schema before passing them to the component. ### Can I use tool-ui without Tailwind CSS? The components are built on Radix UI primitives and styled with Tailwind CSS. The README does not document a path for using them without Tailwind; removing it would require rewriting the styling for every component you copy. ### Is tool-ui still receiving updates? The repository is archived. The last push was on 2026-08-31, and no further changes are expected from the maintainers. Any component you copy is frozen at that state unless you modify it yourself. ## Sources - [assistant-ui/tool-ui on GitHub](https://github.com/assistant-ui/tool-ui) - [Issues](https://github.com/assistant-ui/tool-ui/issues) - [License: MIT](https://github.com/assistant-ui/tool-ui/blob/main/LICENSE) - [Project website](https://tool-ui.com) - [README](https://github.com/assistant-ui/tool-ui/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/assistant-ui-tool-ui