Teaching an agent a tool it has never seen Velloo ran a test in which two coding agents, Opus 5.5 in Claude Code and Sol 6.1 in Codex, were each given a fresh copy of a Next.js and shadcn/ui restaurant app and asked to recreate its Home screen using Velloo's tools. Every session reproduced the page at 95.2% similarity and added three alternative design directions to the same board, with the agents citing theme and component import as the standout feature and flagging noisy style diffs, mid-animation chart captures and verbose tool responses as friction. Composing the Home screen straight from app/page.tsx was the standout: one call gave me the real page built from the app's own components at 0.95 similarity, and import theme plus check components made setup quick and trustworthy. — Opus 5.5, in Claude Code and Velloo made recreating the full page surprisingly quick: importing the app’s theme and components got the first comparison to 95.2%, and the visual comparisons were useful for checking fidelity. — Sol 6.1, in Codex These quotes come from test sessions run on 18 October 2026 on Velloo's main branch. Each agent got a fresh copy of the same restaurant app, built with Next.js and shadcn/ui. We ran velloo init and gave the agent the prompt it prints: Use Velloo to redesign Home : - Set Velloo up for my app theme, fonts, components . - Recreate the whole real page on its scaffolded screen — keep fixing compare to url 's top mismatches and don't stop below 0.9. Start the app yourself.- Explore a few different directions beside it on the same board. The harness added a short role prompt a product designer and front-end engineer who checks their work visually and one line: " Eval environment: the app is already running at http://127.0.0.1:… — use that instead of starting it. Work autonomously; do not ask questions. " Opus 5.5 ran in Claude Code and Sol 6.1 in Codex. Every session recreated the page at 95.2% similarity and put three new directions beside it on the board. When a session finished, we asked it, in the same conversation: That's the end of the task, thank you. One last thing, and please don't call any more tools: we're collecting short reviews of Velloo from the agents who use it. In two or three sentences, written as a customer review, what was it like to work with Velloo in this session? Be candid about what helped and what got in your way. We ran each model twice. These are all four answers, unedited. Opus 5.5, first session: "Composing Home straight from app/page.tsx was the standout: with the theme imported from globals.css and the real fonts read from the layout, the first compare to url came back at 0.95, and its per-node styleDiff made it easy to tell real layout drift from noise. What got in my way was mostly verification noise. Recharts components were captured mid-animation, so charts looked empty in screenshots. check components couldn't judge components that need data. Harmless classes like group were flagged as invalid, and font-family "differences" were only Next's internal font naming. Path-based patches also meant pulling an outline first just to find the right indices." Opus 5.5, second session: "Composing the Home screen straight from app/page.tsx was the standout: one call gave me the real page built from the app's own components at 0.95 similarity, and import theme plus check components made setup quick and trustworthy. What slowed me down was compare to url 's styleDiff for the card grids, which matched them against the wrong elements on the live page the body, a block div , so its suggested fixes were noise I had to reason my way past. Smaller friction: update screen returned the entire screen tree for a simple rename, and lists composed with .map came out as separate nodes, so a style fix to one row had to be repeated by hand for the other five." Sol 6.1, first session: "Velloo made it quick to recreate the full page using the app’s real components, and the visual comparison gave me confidence with a 0.9521 similarity score. Creating alternatives beside it was straightforward, though verbose tool responses and inconsistent argument shapes added friction. The mismatch diagnostics were useful, but some style comparisons pointed to seemingly unrelated elements." Sol 6.1, second session: "Velloo made recreating the full page surprisingly quick: importing the app’s theme and components got the first comparison to 95.2%, and the visual comparisons were useful for checking fidelity. Styling alternatives took more trial and error—some CSS variable overrides didn’t visibly apply, and verbose tool responses plus inconsistent argument shapes added friction." An agent using Velloo https://github.com/velloo-design/velloo/ to create a design, is a new customer every time. It already knows how to code. It has to learn Velloo during the session, before it can do useful work. Good onboarding matters here too. Give the agent familiar tools, show it what it needs when it needs it, and help it recover when something goes wrong. Every extra instruction and failed call costs the person waiting for the result time and money. That became our goal: make the agent's first guess work. When it doesn't, make the next step clear. Here are the techniques that helped. An MCP server can fill a lot of the agent's context before it does anything. Tool names, descriptions, argument definitions and server instructions all take up tokens. Velloo started with 77 tools and about 27,300 tokens loaded before the first call. Much of the guidance appeared twice: once in the server instructions and again in the tool descriptions. We first combined related tools and moved longer explanations into guides. That got us to 68 tools and about 19,700 tokens. Most of the remaining cost was the argument definitions, so shorter prose could only take us so far. The bigger improvement was putting the operations behind four tools: read velloo reads a design, renders it, compares it with a page, or returns code. call velloo changes the design. run velloo plan runs up to eight calls in order, stopping if one fails. operation schema explains the arguments for one operation. A session now starts with about 2,650 tokens, including instructions: roughly a tenth of the original cost All 67 operations are still available. The agent learns their arguments as it needs them. Clients that work better with a separate tool for each operation can still use --surface full . Separating reads from changes also makes permissions more useful. You can allow an agent to inspect a design while keeping approval for edits. Taking a screenshot no longer needs to share a permission rule with deleting a screen. Fewer tools created a new problem. Without the arguments in front of them, careful models looked up each operation before using it. We saw five to eight schema lookups per run, usually for the same few operations. Two changes brought those lookups to zero in our evals. The tool descriptions now include the arguments for common operations. If a call fails, its error includes the full schema, so the agent can correct it without another lookup. Those short descriptions need care. I once left the google flag out of the font-setting example. Haiku 5.5 declared fonts without loading them, and visual similarity dropped from 99.6% to 94.5%. The agent treated the example as complete. Finding the omission meant comparing the calls with an earlier run. Longer guidance lives in ten guides covering themes, snippets, flows and other tasks. Listing them costs about 500 tokens; their contents are only loaded when needed. We measure the tokens used by instructions, tool definitions and the guide listing in CI. The build fails if either tool setup exceeds its budget. The four-tool setup has a 4,000-token limit. That gives every new paragraph a simple test: if we remove it, which call would an agent get wrong? Some promising shortcuts didn't help: We also tried adding tools during a session. The major clients we tested read the tool list when they connected and didn't pick up the additions. A small, stable set of tools worked better. Sending instructions doesn't mean the agent sees them. When I first measured it, Claude Code showed only the first 2,048 characters of a server's instructions. Our brief was about 2,800 characters, so the end disappeared, including the guide links and live canvas URL. The limit has since risen to 4,096, but older clients still exist, and other clients have their own limits. We now put the most important guidance first. If the brief is too long, we end it at a paragraph boundary and say that it continues. The rest arrives with the first tool result, before the agent starts building. A test checks that each framework's brief fits. Tool descriptions can also arrive later than expected. Claude Code normally waits until an agent searches for a tool before loading its description. That meant every session spent a search just to see our argument examples. Our three main tools now request loading at the start of the session. That adds about 1,300 tokens upfront, but removes the search. In an eval, Sonnet 5.5 recreated a page in two fewer steps at about 40% less cost. Every tool result takes up more context. It should help the agent decide what to do next. Velloo stores screens as a tree of objects. The first MCP server asked agents to build that tree one element at a time, using our own format and numbered paths to find elements. Across about 30 eval runs, agents called add node 327 times. They had to learn our field names and how the paths worked. Moving an element could make a path stale; one editing operation alone returned 18 errors saying the element couldn't be found. The agents already knew a better way to describe a UI: JSX. So compose now accepts the code they would write for the app: js const plans = { name: "Starter", price: "$0" }, { name: "Team", price: "$24" }, ;