Overview

Why a block library needs to be legible to coding agents, and the three ways Toro UI makes itself legible.

An agent asked to "build a pricing page" will happily write one from scratch. It will be structurally fine and visually generic, because the model has no idea your project has a pricing block sitting three directories away.

Toro UI ships three things to close that gap.

llms.txt

A plain-text manifest of the whole catalogue.

MCP server

Tool calls for searching and fetching blocks.

Agent skills

Conventions an agent should follow when editing blocks.

The failure mode

Left alone, an agent tends to:

  • invent component names that do not exist in Chakra v3
  • reach for v2 APIs it saw more often in training data
  • hard-code hex colours, breaking dark mode and Theme Config
  • rebuild a section that already exists in the catalogue

Every one of those is a discovery problem, not a capability problem. Give the model an index and the behaviour changes.

What good looks like

With the manifest loaded, a request like "add a testimonials section" resolves to a lookup rather than a generation: the agent finds marketing/testimonial-grid, reads its source, and pastes it with your copy substituted. The result matches the rest of your site because it is the rest of your site.

None of this is Toro-specific magic. It is a manifest, a server and a conventions file — the same three pieces any component library can ship.