paprika3d turns a coding agent into a game studio for three.js/WebGL pages — it opens the page in headless Chrome on a paused clock, sees it, plays it, measures it, fixes it, finds or builds models, and can publish it.
Open & reload a page (open): serves a file, folder, URL or dev-server command in headless Chrome or Firefox at a set size, DPR and network, and reports failed asset fetches, canvas sizing and page text.
See what's on screen (look): screenshot plus an ID image and a list of visible/invisible objects with sizes and boxes; modes for camera angles, object turntables, device viewports, scroll stops, up to 9-moment sheets, zoom, pixel sampling, opening-seconds capture, baselines and diffs; flags lighting and z-fighting faults.
Inspect the scene (observe, eval): read game state and renderer counts, or run arbitrary JS against scene, camera, renderer — including per-mesh triangles, bounds, volume, genus — and save results to files.
Play it (interact): keyboard, mouse, touch, wheel, scroll and resize frame by frame, with state diffs, traces, expectations, hover diffs and optional real-time GIF recording.
Keep plays as checks (test): save a play with expect and rerun all checks from a fresh reload after every edit.
Measure game feel (feel): detect camera shake, scale pops, teleports, colour flashes, particles, spawned objects, HUD ticks and sounds after an event.
Speed it up (perf, optimize): time frames against desktop/mobile/quest/site budgets, find costly groups with variants, and apply runtime switches that keep the picture unchanged.
Match references (reference): read a picture at full resolution with crop, grid and colour sampling, then compare the page against it region by region.
Find models (asset_search): search 57k models, 3.5k PBR textures and 1.4k HDRIs by words or image, and pick one into the project with loading code and credits.
Build models (model_run, model_look): code a model in a persistent modelling scene with Manifold booleans and save it as a .glb, then view it true to size from four sides.
Check & shrink models (model_audit): audit .glb/.gltf/USD files for size, triangles and textures with a site or Shopify verdict, and rewrite them smaller.
Publish (publish) the finished project to <slug>.paprika3d.app, and send feedback (send_feedback) about the harness itself.
Supports React Three Fiber pages the same way as plain three.js: opens the app (including via a dev-server command), inspects the scene graph and named objects, drives interactions frame by frame, evaluates expressions against scene/camera/renderer, and performance-checks and optimizes the rendered result.
Opens, inspects, drives and optimizes three.js scenes: reports every named object on screen and those never visible (with size and framing cause), runs JavaScript against the live scene/camera/renderer for mesh stats (triangles, bounds, closed edges, volume, genus), steps a paused seeded clock frame by frame while sending keys and mouse input, measures frame time, draw calls and triangles against a desktop/mobile/Quest budget, and applies runtime optimizations (resolution scaling, instancing, LOD, disposal) that do not change the picture. Also builds procedural geometry via booleans, hull, extrude, revolve and seeded scatter.
Works inside any WebGL page without changes to it: opens it in headless Chrome, enumerates what is rendered and what never appears, sends frame-exact inputs on a seeded clock, evaluates JavaScript in the page, profiles frame time and asset size against a performance budget, and verifies game rules through a contract with per-keypoint checks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@paprika3d open index.html, look at the scene, and check if the car is visible"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
It takes a three.js game from references on the web to a look and character sheets, a design doc with the creative calls left to you, the build, then loops that keep improving it, all in one lean package of tools. Along the way your agent plays the game, measures every frame and finds or builds the models. That is how the game gets good: it finds the invisible model, the file that never loaded and the flickering faces, and fixes them before it tells you it is done.
In Claude Code the whole flow is two commands, /paprika3d:paprika-make <request> and /paprika3d:paprika-loop <request> for <time>. Codex, Gemini CLI, Cursor and other MCP clients get the same tools, and the skills with npx skills add paprika3d/paprika3d.
The main result: with paprika3d, Sonnet 5.5 made 86% of its 3D objects pass every check, against 66% without it: +20 points (95% interval +11 to +29), over 150 runs in each arm. The checks are no flickering, see-through or inside-out faces, code that runs, and a budget. The checks come from 3JSBench by General Context Labs. All results, each with its run count.
Needs Google Chrome and Node 20.11 or later; the Claude Code plugin needs Claude Code 2.1.118 or later.
Agent | Install |
Claude Code |
|
Codex CLI |
|
Gemini CLI |
|
Cursor, VS Code, Windsurf |
|
Skill only (any agent) |
|
Then, in Claude Code, type /paprika3d:paprika-make <request> to make a game or 3D page from one request. In any agent, ask it to use paprika3d to playtest a page you already have.
Cursor (.cursor/mcp.json), Windsurf and any other MCP client take this entry; VS Code's .vscode/mcp.json takes the same entry under servers instead of mcpServers:
{
"mcpServers": {
"paprika": {
"command": "npx",
"args": ["-y", "paprika3d", "serve"]
}
}
}Related MCP server: Blender MCP
/paprika3d:paprika-make <request> works in this order, with a few rounds of questions for the calls that are yours. The first three stages each write a file you can read and change; how it works has each stage's files, questions and keys.
Stage | What happens | Tools and files |
1. References | Your pictures, or a subagent's picks from Wikimedia Commons and Openverse with each licence and source, numbered on one picture for you to keep or drop. If you say yes, a search of the web, YouTube included, for study references and free models; these stay in |
|
2. Look and characters | A style sheet ( |
|
3. Design doc | For a game, |
|
4. Build | Where each key model comes from: the library, a free CC0 or CC BY model from the web, a model generated with your own fal, Meshy or Tripo key, or code. Then the whole page in one pass, opened, played, measured and fixed against the brief, with a critic listing what still looks wrong |
|
5. Loops |
|
|
A one-line request takes about four rounds of questions and spends nothing on your keys unasked. sheet names which image and 3D model keys are set, never their values; set one with /plugin configure paprika3d or the provider's usual variable, such as FAL_KEY. The loop starts only when you type it; each round is two Claude Code sessions, billed as such, and it needs claude and git on PATH. To publish, join the waitlist at https://paprika3d.com/waitlist and set PAPRIKA3D_PUBLISH_INVITE to your code; what a publish uploads and records.
The full flow runs in Claude Code. In other agents the tools below work the same, and npx skills add paprika3d/paprika3d adds the skills.
From the first draft on, every stage runs on these tools. Your agent opens its page in headless Chrome on a clock it controls, reads which objects are on screen and which never appear, plays inputs on exact frames and times each frame. They work on any three.js, React Three Fiber or WebGL page, WebGPURenderer included: games, product viewers and configurators, scroll sites, simulations, shader and post-processing demos. Your page needs no changes.
Part | What your agent does | Tools |
See it | Sees what is on screen, what never appears and why (behind the camera, outside the view, too small), which files failed to load, and which lighting and surface faults show |
|
Play it | Presses keys, clicks, touches and scrolls on exact frames of a paused, seeded clock, reads the state after each input, keeps a play as a check that reruns after every edit, and measures how a hit or pickup shows on screen |
|
Ask it | Runs any JavaScript against |
|
Speed it | Times the frame against a desktop, mobile, Quest or site budget, finds what costs it, and keeps only the speed-ups that leave the picture unchanged |
|
Match a picture | Reads a picture the page should match (a crop with a pixel grid, colours at points), and puts the page beside it with the differences by region |
|
Find models | Finds a ready-made model, PBR texture or HDRI sky in a hosted library (57,732 models, 3,545 textures, 1,430 skies), by words or by a crop of a picture; |
|
Build models | Builds a model in code, in a modelling scene kept between calls (three.js and Manifold: booleans, hull, extrude, revolve), shows it true to size from four sides, and saves a .glb the page loads |
|
Check models | Checks .glb, .gltf and USD files for size, triangles, textures and compression, with a site or Shopify verdict; |
|
open also puts two helper files in the project, geo.js (procedural geometry) and fx.js (sound, textures, particles, a lighting setup), and the skill can add game-state, which keeps game state in typed arrays and runs Rapier physics in a worker. send_feedback sends the team a report when a reply was wrong. Every tool, with when to reach for it, the skills, the hooks and the files: what the plugin adds.
Every reply is short text with the numbers that fix the problem. Part of one look reply, on a test page with a start line laid flat on a road:
Surfaces: "road" and "startDecal" share a face plane (y = 0.00) over 2.6 × 16 units: they flicker as the camera moves (z-fighting). Move one at least 0.00054 units off the plane (what the depth buffer can tell apart at 21 units from this camera), give the top one material.polygonOffset = true with polygonOffsetFactor -1, or remove the hidden face.
On screen (4):
road 44% [0, 307, 1279, 799] 500 × 18 units, along the view
grass 17% [0, 307, 1279, 587] 600 × 400 units
startDecal 0.46% [366, 427, 915, 440] 16 × 2.6 units, across the view
board4 0.075% [553, 286, 587, 307] 8 × 5 units
Never visible: none3JSBench by General Context Labs checks the 3D objects a model builds from one-line requests. In our run of its checks, more objects pass with paprika3d:
3JSBench | Without paprika3d | With paprika3d | Difference (95% interval) | Runs |
Sonnet 5.5: objects that pass every check | 66% | 86% | +20 points (+11 to +29) | 150 per arm (50 objects, 3 runs each) |
Opus 5.5: objects that pass every check | 63% | 78% | +15 points (+4 to +26) | 150 per arm (50 objects, 3 runs each) |
Sonnet 5.5: objects with no flickering (z-fighting) faces | 68% | 88% | +20 points (+11 to +29) | 150 per arm (50 objects, 3 runs each) |
Opus 5.5: objects with no flickering (z-fighting) faces | 69% | 89% | +21 points (+11 to +31) | 150 per arm (50 objects, 3 runs each) |
Imported models show up, at the right size. Sonnet 5.5 building three.js pages that each load a glTF model. The paprika3d runs had a one-time reminder to open the page after the first edit; the plugin's after-edit hook now says once that a page the agent wrote has not been opened.
Imported models | Without paprika3d | With paprika3d | Runs |
Model loaded and shown at the right size | 1 of 11 runs | 9 of 11 runs | 11 per arm, a small sample |
Draco-compressed model loaded | 0 of 3 runs | 3 of 3 runs | 3 per arm, a small sample |
On a mini golf page the agent loaded a toy car so small it never showed up, and the screenshot looked fine. look named it: Never visible: ToyCar (0.0338 units, in view).
Finding flickering faces in finished objects. An agent was shown 133 finished objects, one run each, and asked for their defects. With Sonnet 5.5, paprika3d found 75% of the flickering faces and Playwright MCP with a written QA skill and a measuring script found 44%; paprika3d passed 80% of the clean objects and Playwright 66%. With Opus 5.5 the two were close: 40% and 35% of the flickering faces found.
Heavy physics leaves the main thread free. With game-state, a scene of about 2,000 crates spent 1.3 to 2.0 ms of each frame on the main thread instead of 7 to 11 ms, and passed 18 of 18 game checks either way. Opus 5.5, 2 runs per arm, a small sample; both arms had paprika3d, the difference is game-state.
paprika3d is built for one job: an agent making a three.js game or 3D page, end to end.
paprika3d | Playwright MCP | Blender MCP | |
Sees the three.js scene graph (named objects, sizes, what never appears) | Yes | No | No |
Paused, seeded clock: the same inputs give the same frames | Yes | Not built in | No |
Input on an exact frame, with the game's state back | Yes | No | No |
Frame time against a budget, and an optimizer | Yes | No | No |
Lighting and z-fighting faults named | Yes | No | No |
References, a style sheet, a design doc, a build and an unattended loop in one flow | Yes | No | No |
Any page works as it is. Add window.__game (describe, observe, act and setState) once the page has loaded, and your agent reads and sets the game's exact state: the convention.
paprika3d/runs/<time>/: one folder per open. Each open deletes the pictures and clips (.png, .gif, .mp4) of all but the newest 10 run folders, keeping run.json, last-test.json and every other file; a folder written to in the last hour is left whole. Saved baselines live in paprika3d/baselines/. Add paprika3d/ to the project's .gitignore.
geo.js and fx.js are written on the first open and replaced only when the plugin's copy changes; leave them in place.
look and interact, when the project has no matching three.js installed, have Chrome fetch that three.js version from cdn.jsdelivr.net.
asset_search sends your agent's searches (the words, or the crop of a picture it searches by) and what it picks to the asset library at assets.keeno.dev.
send_feedback, only when the agent calls it, sends its text, the last tool call's name, option names and error, the plugin version, OS and Node version, a random install id (kept in ~/.paprika3d/telemetry/id) and a per-run id. DO_NOT_TRACK=1 or PAPRIKA3D_TELEMETRY=0 turns it off.
Once per install and per update, the MCP server sends the same install id, the plugin version, OS and Node version and your MCP client's name and version, so the team can count installs; nothing about your project. The same switches turn it off.
/paprika3d:paprika-make's reference search sends words from your request to Wikimedia Commons and Openverse, and, after you say yes, to a web and YouTube search.
sheet, with your own key, when a sheet or model is asked for: the prompt and the reference pictures it is made from, to the provider you chose (fal, OpenAI or Gemini for pictures; fal, Meshy or Tripo for models), billed to your key.
publish, only when you ask: the built project, to host it.
The tool names and their inputs, the skill names, the paprika3d serve command and the environment variables in server.json change only in a minor release before 1.0, and only with a note in CHANGELOG.md, which lists each release; a patch release never changes them. The previews may change in any minor release: publish, sheet, model_run and model_look, asset_search, and open's browser: "firefox".
Requirements and limits (Chrome's location, Firefox, running with no GPU, headless Chrome): the install page.
Each release ships the readable TypeScript it was built from, in source/. Contributions are welcome as a patch in an issue or a pull request, each commit signed off for the Developer Certificate of Origin (git commit -s); see CONTRIBUTING.md. Issues: https://github.com/paprika3d/paprika3d/issues.
Apache License 2.0 (LICENSE). The packages each build bundles keep their own licences, listed in THIRD_PARTY_NOTICES.md.
Searches the hosted paprika3d asset library over the network (assets.keeno.dev) for a ready-made model (57k, CC BY or CC0, as GLB and some as USD), PBR texture or HDRI sky, and puts the one you pick in the project with its loading code. A search answers one numbered line per hit (id, name, size, licence, preview image) and a contact sheet: the hits' thumbnails in one row, numbered as the lines are. pick an id from it (or its start, when no other hit shown in this project starts so) to download the file into assets/ (public/assets/ with vite) and get the code that loads it, a model at real size (or height units tall) and credited in CREDITS.md. not lists ids that missed, which the library learns from, and searches again without them; more searches the same query again for the next hits. image (a picture in the project, with crop to cut one thing out of it) ranks models by how alike they look, for the thing a reference picture shows that words miss. The library logs model searches, picks and rejections with the agent's name.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| not | No | Ids from the last search to reject. | |
| crop | No | With image: [left, top, right, bottom] in the picture's pixels, as `reference` reads them: the one thing to find, cut out of the scene. | |
| kind | No | model by default. | |
| more | No | With the same query: the next hits, past every one it has shown, none of them rejected. | |
| pick | No | An id to download, or the start of one that no other hit shown in this project (in any session) starts with. | |
| type | No | Models only. | |
| image | No | Models only: a picture under cwd (refs/01.jpg) or a look baseline's name, to rank models by how alike they look to it (with query, by both); the reply shows the image searched with. | |
| model | No | Optional: your own model name, e.g. "claude-opus-5-5", sent with model searches and picks only, so the library can learn which agents its picks suit; nothing else about the session. | |
| query | No | What you need, e.g. "wooden barrel", "mossy cobblestone", "sunset sky". | |
| sheet | No | false leaves out the contact sheet, the picture of the shown hits' thumbnails in one row, numbered as the lines are (on by default). | |
| style | No | Models only. | |
| format | No | Models only. In a search, only models with a file of this format; with pick, the file to download: a model with both is saved as its GLB unless this is usd, and one with only a USD file (.usdz) as that, loaded with three's USDLoader (r183 or later). | |
| height | No | With pick: scale a model to this many units tall. | |
| rigged | No | ||
| maxTris | No | ||
| animated | No | ||
| textures | No | With pick: false saves a model's geometry only, every texture dropped (for a model you colour or texture yourself). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: network search against assets.keeno.dev, numbered result lines plus a contact sheet, downloading into assets/ (or public/assets/ with vite), generating loading code, scaling to real size or `height`, and writing credits to CREDITS.md. It also mentions logging of searches, picks, and rejections with the agent's name, but does not cover error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but it is front-loaded with the core purpose and every sentence contributes operational detail for an 18-parameter tool. It could be more scannable with lists or line breaks, but there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description explains the return format (one numbered line per hit with id, name, size, licence, preview image, plus a numbered contact sheet). It covers the main workflows and side effects, though it omits failure modes and the precise side effects of some filter parameters like `rigged`, `animated`, and `maxTris`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the baseline is 3, but the description adds meaningful semantics beyond the schema: `kind` defaults to model, `more` searches past every hit already shown, `not` rejects ids that the library learns from, `pick` accepts an id or unambiguous prefix, and `format` has nuanced download behavior (GLB preferred unless `usd`, USDLoader for USD-only). It also clarifies that `model` is sent only with model searches and picks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (searches the hosted paprika3d asset library over the network) and names the exact asset types covered (model, PBR texture, HDRI sky). It also explains the pick side effect (putting the chosen asset in the project with loading code), which distinguishes it from sibling tools like reference or look.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains when to use specific modes: `image` for matching a reference picture when words miss, `more` to continue the same query, `not` to reject ids and re-search without them, and `pick` to download and integrate a hit. It does not explicitly name sibling tools as alternatives, but the mode-level guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs JavaScript in the open page and returns what it returns, as JSON, then up to 5 lines it logged (console.log, warn, info) and up to 5 console errors. In scope: scene, camera, renderer, find(name), stats(target) (vertices, triangles, bounds, closed, volume, genus per mesh), realNow(), window, and THREE on a page that loads three through an import map. performance.now, Date and timers run on the harness's paused clock (code that awaits a timer or frame steps it until done), so to time code here use realNow() (real milliseconds), and end GPU work before reading it (a 1-pixel gl.readPixels; on WebGPU, await renderer.backend.device.queue.onSubmittedWorkDone()). Use it to inspect the scene, try a change before writing it into the source, measure an imported model, or check procedural geometry with stats after each step; changes vanish on reload. A thrown error names where it threw: a line of this code or of the page's own files. Code that keeps the page busy for 30 s (longer on a busy host) is stopped and the page kept: split long work across calls, or await a 0 ms timer every few hundred iterations.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The body of an async function; return the value to see. | |
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| save | No | Write what the code returns (an ArrayBuffer, typed array, Blob, canvas or data URL) to this path under cwd, e.g. assets/baked.glb or data/mask.png, and reply with its size instead of the bytes: baked geometry, a painted canvas, measured tables. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so: return shape (JSON value, up to 5 log lines, <5 errors), the 30 s runaway guard and 'page kept' outcome, and the requirement to split long work or yield with a 0 ms timer. It also discloses non-obvious clock semantics (performance.now/Date/timers on a paused clock, use realNow()) and that GPU work must be drained before reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the tool returns, then scope, then timing caveats, then limits — a sensible order with no filler sentences. It is a dense, clause-heavy block that would scan faster as short lines, but nearly every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, yet the description covers return format, error reporting, timeouts, clock behavior, GPU synchronization, and the available globals — everything an agent needs to invoke it without surprises. Nothing material is deferred to structured fields that don't exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three params are already documented; the description nonetheless adds real meaning to `code` by describing it as an async body, explaining that awaiting a timer or frame steps the paused clock, and warning that thrown errors report a line. It says nothing extra about `game` or `save`, which the schema handles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: runs JavaScript in the open page and returns the result as JSON plus bounded console output. The scope list (scene, camera, renderer, stats, realNow, THREE) and the 'inspect the scene / try a change / measure a model' phrasing make it unmistakable against siblings like observe or model_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives four concrete use cases (inspect the scene, prototype a change, measure an imported model, check procedural geometry with stats) and notes changes vanish on reload, which frames it as a scratch/test tool. It falls short of explicitly naming when NOT to use it or which sibling to prefer for read-only observation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measures game feel, how the page reacts to an event: on a fresh reload, sends the steps, then watches the next frames for camera shake or one camera move out and back (a hit's lurch), scale pops, smooth moves versus teleports, colour flashes, particles (a Points pool's or an InstancedMesh's count), spawned objects, HUD text ticks and sounds, each with the watched frame it came on. Leading { state } steps set the scene up (the player next to the coin), and nothing is measured until they and one frame have run; what moved during the other steps is listed as a fact on its own line, and teleports are jumps between two watched frames, so a setup or a walk in the steps is never one. It shows whether each event a feel brief names (hits, clears, explosions, pickups, deaths, wins) reacts on screen, and whether anything teleports. It measures and saves nothing: to keep the play as a check, send the same steps to interact with expect and save.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| steps | Yes | Steps as for `interact`: a { state } setup, then the inputs that cause the event. | |
| frames | No | Frames to watch after the steps (default 45). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses important traits: it measures but does not save, setup steps are not measured until they and one frame have run, and movements during other steps are reported separately as facts. It does not cover permissions, error behavior, or performance limits, so it stops short of fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the content is dense with relevant detail, but the description is long and runs several ideas together in extended clauses. It could be tightened without losing meaning, especially around the `interact` alternative and measurement timing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex measurement tool with no annotations and no output schema, the description provides substantial context about what is measured, when measurement starts, and what is not saved. It still does not describe the exact return shape or error conditions, leaving some gaps for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning about how `steps` work as setup plus inputs and how `frames` controls the watched window. It also clarifies the default frame count behavior in context, though it does not add much beyond the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it measures game feel by watching how the page reacts to events, including camera shake, scale pops, teleports, particles, HUD ticks, and sounds. It also distinguishes itself from `interact` by explaining that `feel` measures and saves nothing, while `interact` with `expect` and `save` is used to keep the play as a check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains exactly when and how to use it: leading `{ state }` steps set the scene, measurement begins only after those steps and one frame have run, and teleports are defined as jumps between two watched frames. It also names the alternative workflow explicitly, sending the same steps to `interact` when the goal is to save or check the play.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plays the open page: keyboard, mouse, touch, wheel, scroll, resize and clock steps sent frame by frame (steps lists the kinds), and returns what changed in the state (its new values; the whole state when nothing changed), the console log/warn/info lines and errors the steps raised, a Motion line when the subject (window.__game.subject, or where the state puts its player) turned, or stopped while a key was still held, a Sound line with how many sounds the steps started on a page that makes sound, and with look: true look's picture and list after the steps, in the same reply. Every mouse and touch step says which named object in the scene is under it, and its distance. Use it to play an interaction the request names and read the state it leaves, to set a moment up ({ state }) and step to it ({ until }), or to keep a play as a check (save).
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| look | No | Also return `look`'s picture after the steps. | |
| save | No | Save this call (its steps and `expect`, which it needs) as a check of this name in game-tests.json when every Expect entry holds. A call with `save` plays its steps from a fresh reload, as `test` and the after-edit hook will rerun them: leading state steps become its setup. | |
| hover | No | After the steps, move the mouse to each named object's centre on screen and return what changed there after `frames`, one diff per name. | |
| steps | No | Steps, in order. { key, frames? } presses the key, holds it `frames` frames (default 1) and releases it; { key, down: true } holds it across steps until { key, down: false }; { mouse: click|dblclick|down|up|move, x, y }; { mouse: move, relative: [dx, dy] } (mouse look under pointer lock); { wheel: deltaY, x?, y? }; { resize: [w, h] }; { scroll: px | { progress: 0..1 } | { to: "#section" } } (scrolls the window; the reply says where, and the progress of Lenis, ScrollTrigger or drei ScrollControls when found); { touch: start|move|end|tap, x, y }; { wait: frames, draw? }; { action, ...args } for window.__game.act; { state: {...} } (sets observe()'s keys through window.__game.setState, then draws a frame: set the scene up first, as { state: { player: { x: 2, z: 0 } } }); { until: {...}, max? } (steps one frame at a time until the state holds, at most `max` frames, 600 by default, and says the frame or what it saw; its values as `expect`'s); { clock: { timescale?, paused? } } (sets the clock's time scale, or resumes (paused: false) or pauses real-time play; the clock reads 60 s at frame 0 on purpose, past any boot, so a page's own time starts there). A step's frames run without drawing except its last (an until draws none); draw: true on a step draws every frame, for a picture that builds up over frames (trails, progressive rendering). Each other step advances `frames` (default 1); `frames: 0` sends it on the same frame as the next step (two keys down at once, for a diagonal). | |
| trace | No | Up to 6 dotted paths into observe() read every frame of the steps (after leading state steps): one line per path with its first and last value, its peak or low and their frames, and the first frame it changed, as `player.y: 0 → peak 2.04 at frame 22 → 0 at frame 44; first changed at frame 2`. Tune by numbers: jump height and airtime, stopping distance, frames from key to motion. Read for the first 600 frames of the steps; a longer run keeps those. | |
| expect | No | Checked against the state after the steps, in this reply: { score: 1, "player.x": [2.9, 3.1] } gives `Expect: score 1 ✓ · player.x 2.97 ✗ expected 2.9 to 3.1`. A value is a number, string or boolean (equal), [min, max] (a range; two numbers are always a range), a list of other values (one of them, as ["banana", "star"]) or null (exists), keyed by dotted paths into observe() ("coins.0.x" for lists). | |
| frames | No | Frames to wait at each hovered object (default 1). | |
| record | No | true: play the steps (after leading { state } steps) in real time, each frame 1/60 s, and record them: a GIF in the run folder (480 px, each frame shown for its real time, HTML over the canvas included) and four moments of it in the reply, with the game's real frame intervals at a 60 Hz pace (median, p95, max; a slower frame reads as its own time, not a 60 Hz screen's 33 ms) on the GPU named; with look: true, look's picture too. 15 s at most; the clock is paused again after. Evidence of real-time play for an agent or a judge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: it discloses frame defaults, that a step's frames run without drawing except its last, that `until` draws none, that `save` replays from a fresh reload, the 60 s clock offset at frame 0, trace's 600-frame read window, and record's 15 s cap and post-recording clock pause. It omits failure semantics — whether a failing step or a broken `expect` aborts the run or how errors in steps are reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is a ~150-word run-on with deeply nested parentheses, hard to parse before the agent reaches the actual usage clause at the end. Substantial content duplicates the per-parameter schema descriptions (the full step-type enumeration, frames defaults), so it is over-long rather than front-loaded and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, nested, annotation-free tool with no output schema, the description explains the reply shape in detail: state diff, console log/warn/info and errors, Motion and Sound lines, and `look` output on request. That covers what an agent needs to interpret results; only error/abort behavior is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already carries a long schema-side description, so the baseline is 3. The top-level text adds some framing (`steps` lists the kinds, `until` takes expect-style values, `save` requires `expect`), but most of its content restates what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource: it plays the open page with keyboard/mouse/touch/wheel/scroll/resize/clock steps and returns the changed state, console lines, and motion/sound/look results. It references related tools (`open`, `look`, `test`, `observe()`) but never draws a clean line against siblings like `feel` or `eval`, so the boundary with those is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete when-to-use cases: play an interaction the request names, set a moment up with `{ state }`, step to it with `{ until }`, or persist a play as a check via `save`, plus `record` as real-time evidence. It does not state when NOT to use it (e.g., a bare picture should go to `look`, a state read without input to `observe`), so routing to alternatives is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screenshot of the open page, returned in the reply (no file to read), with an ID image saved beside it (one colour per object, the picture's path with -ids before .png), and a list of what is on screen and the named objects no look has seen, with their size and where they are: it catches a model at the wrong scale, out of view or never loaded, which a screenshot alone misses. One mode per field: cameras, target, sheet, zoom, at, opening, viewports, scroll, save and compare, camera; on a software renderer (no GPU) each sheet cell reloads and replays the page at roughly a second per drawn frame. Each look ends with the lines the skill's references/lighting.md explains: the subject and whether it stands out, depth, hues, the Lighting: and Surfaces: setup faults, the largest surface's texture, the canvas size, what shows through a transparent canvas, and the HTML over the canvas with the ones that overlap or are cut off by the screen edge. Use it to see what a viewer sees. A page drawn in passes (post-processing) is pictured as it drew its last frame, so state set since then shows after a step.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Up to 8 points [x, y] in the live page's pixels, as the look lists boxes: the objects drawn at each, nearest first, found by the page's own shaders (a part a shader discards is skipped and named), each with its distance from the camera, a line of text per point and no picture; from `camera` when given. What is under a crosshair, why a click misses, which layer covers a product. | |
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| save | No | Keep this look's picture as the baseline of this name (letters, digits, - or _), with its frame and page size. | |
| zoom | No | [left, top, right, bottom] in the live page's pixels, as the plain look lists boxes (a sheet's cells are other pictures), enlarged up to 4× for detail too small to judge: an edge, text, a distant object; from `camera` when given. | |
| sheet | No | Up to 9 moments in one labelled grid, each on a freshly reloaded page set with `state`, played with `steps` (as `interact`) and `frames`: stages, levels or views compared at once instead of a screenshot script. | |
| camera | No | Picture from this position (looking at lookAt) for this look only, or a camera by name: a picture's file name in refs/cameras.json, or a label given to `cameras`. | |
| sample | No | Points [x, y] in the live page's pixels, as the look lists boxes (with zoom, inside its box), whose colour to return (the mean of 5 × 5 pixels). | |
| scroll | No | Scroll stops as shares of the page's scroll range (0 to 1), each pictured on a fresh reload in one labelled grid, with the camera's position and look direction and the objects on screen at each. | |
| target | No | An object in the main scene, pictured alone from the front, right, top and a three-quarter angle, framed to its size, in one picture: a model or procedural shape checked from every side. | |
| cameras | No | Up to 9 cameras, each { position, lookAt, label } or a camera's name (a picture's file name in refs/cameras.json, or a label given here before), pictured at this same moment with no reload in one labelled grid: a scene from several angles in one call. A labelled camera is kept, so later calls name it as `camera`. | |
| compare | No | A saved baseline's name: pictures the game at its frame (reloading to it), says what share of pixels differ and adds a diff picture (differences in red), so an edit's effect needs no diff script. | |
| opening | No | Picture the first 5 s after load in real time, as a viewer meets them (`open` pauses at frame 0): a loading screen or dim intro still up at 2 s is what a viewer sees first. | |
| viewports | No | Picture the page at each size in one labelled grid, each on a fresh reload: phone (390 × 844 at DPR 3), tablet (820 × 1180 at 2), laptop (1440 × 900 at 2), desktop (1920 × 1080 at 1), or [width, height, dpr]. Each cell's line gives the subject's share, the objects on screen and whether the canvas is sized right. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the screenshot is returned in the reply (no file to read), that an ID image is saved with a specific naming convention, that software rendering is slow (roughly a second per frame), and that post-processing shows the last drawn frame. It also explains the appended lighting lines. It misses some details like permissions or exact return shape but is quite thorough overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but it becomes a dense, semicolon-heavy paragraph with many clauses. Some details, like the full list of modes and the lighting.md reference, could be more structured or trimmed. It is informative but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description provides a solid picture of what the tool returns (screenshot in reply, saved ID image, object list, lighting lines) and its performance characteristics. It does not fully document every return value or edge case, but it is largely complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a detailed description. The description adds only a summary list of modes ('cameras, target, sheet, zoom, at, opening, viewports, scroll, save and compare, camera') and the concept of one mode per field, which is marginally helpful. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: taking a screenshot of the open page, returning it in the reply, saving an ID image, and listing objects on screen. It is specific about the resource and verb, and the phrase 'which a screenshot alone misses' hints at a unique value. It does not explicitly name sibling alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use it to see what a viewer sees' and describes scenarios like catching a model at the wrong scale or out of view, which implies when to use it. However, it gives no explicit when-not-to-use or named alternatives among siblings (e.g., observe, model_look). Usage is inferable but not sharply guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspects 3D model files (.glb, .gltf, and USD: .usd, .usda, .usdc, .usdz): megabytes, triangles, materials, each texture's size and format, and whether it uses Draco, meshopt and KTX2, for one file or every one under a folder (path, relative to cwd; the whole project when left out), read from the file itself with no decoder, so Draco and meshopt files report too. Then a one-line verdict on what a website or a Shopify listing judges a model on, against target: site (the site budget: 4 MB of assets, 200,000 triangles, 2048 px textures by area) or shopify (a GLB of about 4 MB with textures at most 2048 px on a side). shrink rewrites one .glb or .gltf smaller, without its textures or with each capped at a size (WebP), and replies with before and after (a USD file is converted to GLB first); a failing file gets the shrink call that fixes it: save a look first (look save), shrink, point the page at the new file, then look compare.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| path | No | A .glb, .gltf or USD file, or a folder to report every one under, relative to cwd. | |
| shrink | No | Rewrite the file smaller: textures false drops them all (geometry only), a number caps each texture's longer side at that many pixels (WebP); out is the new file (<name>-opt.glb by default). Replies with before and after. | |
| target | No | What to judge the files against (site by default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does the heavy lifting: it discloses that metrics are read from the file itself with no decoder (so Draco/meshopt files still report), that USD is converted to GLB before shrinking, that `out` defaults to <name>-opt.glb, and that shrink replies with before/after. It never explicitly confirms the original file is left untouched on shrink, which is the one behavioral gap an agent would care about.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is one dense, run-on paragraph that folds three distinct capabilities plus a workflow into a single wall of text. Information is front-loaded (audit first, shrink last), but the packing into long clauses hurts scanability even though little is truly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param tool with a nested `shrink` object and no output schema, the description covers the return content reasonably (metrics list, one-line verdict, before/after on shrink) and the non-obvious preconditions (no decoder needed, USD→GLB conversion). Some output detail (e.g. exact verdict format or what counts as failing) is still implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so 3 is the floor. The description earns above that by adding meaning the schema lacks: the concrete budget numbers behind `target` (4 MB / 200k triangles / 2048 px for site; ~4 MB GLB, 2048 px per side for Shopify) and the semantics of `shrink.textures` (false drops all, a number caps the longer side as WebP).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Inspects 3D model files') and enumerates exactly what it reports (megabytes, triangles, materials, per-texture size/format, Draco/meshopt/KTX2), plus the verdict and shrink capabilities. An agent can tell what this tool does without opening the schema, and it names the concrete ecosystems (website/Shopify) it judges against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: audit one file or a whole folder, judge against 'site' or 'shopify', and it walks the remediation flow ('save a look first (look save), shrink, point the page at the new file, then look compare'). What's missing is an explicit boundary against siblings like model_run or optimize — it never says when *not* to reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the modelling scene that model_run builds: one picture of it (or of object) from the front, right and top (orthographic, so sizes read true against the grid) and a three-quarter view, under a neutral studio light with a ground grid whose step it states, and one line per object: name, type, place, turn and scale, material (colour, roughness, metalness) and, for a mesh, triangles, size, whether it is closed, its volume and genus. With object, that object in full; with cameras, those views instead of the four.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| size | No | The picture's side in pixels (1024 by default, at most 1568). | |
| object | No | The name of an object in the modelling scene: frame the picture to it and list it in full. | |
| cameras | No | Up to 9 views in place of the four, each { label, position, lookAt } in the scene's metres (lookAt defaults to the middle of what is framed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and describes the rendered output in detail (lighting, grid, orthographic projections, object listing fields). It does not explicitly state that the operation is read-only or mention any side effects, but 'Shows' strongly implies a safe inspection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one long, dense sentence plus a short second sentence. It is front-loaded with the core action and every detail seems purposeful, though the structure could be clearer with punctuation or bullets for such a feature-rich tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully explains what the tool returns: pictures and a textual per-object listing. It covers the effect of each optional parameter and the default view set, leaving no major gaps for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning: `object` frames and lists that object in full, and `cameras` replaces the default four views with custom ones. The `size` parameter is not elaborated, but the schema already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (shows) and resource (the modelling scene built by model_run), including what is returned: orthographic views, a three-quarter view, and a per-object listing. It is immediately distinguishable from siblings like model_audit or model_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies usage after model_run builds the scene, and explains how the `object` and `cameras` parameters change the view. It does not explicitly exclude alternatives or state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs JavaScript against the modelling scene: a three.js scene this server keeps between calls, apart from any page, for building a model in code as in Blender, then saving it as a .glb the page loads. The code is an async function body with THREE, scene, geo (Manifold, started: geo.Manifold, geo.CrossSection, geo.toGeometry(manifold), geo.toManifold(geometry), geo.boolean(op, a, ...b)), scatter, find(name), stats(target) (vertices, triangles, bounds, closed, volume, genus per mesh), load(path) (a .glb from the project, an asset_search pick included, added to the scene and returned), save(path, object = scene) (a GLB under cwd; replies with its size and the line that loads it) and clear() in scope, and returns what it returns, as JSON, with up to 5 lines it logged. What it adds to scene stays for the next call and is saved to paprika3d/model/scene.glb after each run that changed it, so a restart loads it back; variables (a Manifold) do not last between calls. Manifold works in metres with Z up and angles in degrees; three is Y up. Name every object you make: model_look lists them by name.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| code | Yes | An async function body, e.g. `const { Manifold, toGeometry } = geo; const m = Manifold.cube([1, 1, 1], true).subtract(Manifold.sphere(0.65, 48)); const mesh = new THREE.Mesh(toGeometry(m), new THREE.MeshStandardMaterial({ color: 0xb08050 })); mesh.name = "block"; scene.add(mesh); return stats(mesh)`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the persistent scene, automatic saving to paprika3d/model/scene.glb after changing runs, non-persistence of variables, JSON return behavior, and the five-line log limit. It also states coordinate and unit conventions for Manifold versus three.js.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every sentence contains operational information needed to call the tool correctly. However, the long run-on sentence with nested parenthetical scope lists makes it denser and harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must be self-contained, and it is: it covers execution context, available globals, persistence semantics, return format, logging limits, save path, and unit conventions. An agent has enough information to invoke and interpret the tool without additional structured hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema by explaining the async function body environment, available scope objects, and return behavior. It adds less about cwd beyond the fact that saved GLBs go under it, so it falls short of a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it runs JavaScript against the server's persistent three.js modelling scene to build and save models. It also distinguishes the scene from page context and names model_look for listing created objects, so the tool's role is clear against siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: build a model in code as in Blender, then save it as a .glb the page loads. It references model_look for naming/listing objects, but it does not explicitly state when not to use this tool versus alternatives such as model_audit or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the open page's state as JSON (window.__game.observe(), or its named three.js objects), renderer counts, new console errors and what changed since the last observe.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full load, and it does disclose non-obvious traits: the call is a read (non-mutating), it returns diff-style output relative to the previous call (making it stateful/history-dependent), and it surfaces only *new* console errors. That statefulness is real behavioral context an agent cannot infer from the schema. It stops short of 5 because payload size, cost, and whether the diff baseline resets are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the core action front-loaded and every clause contributing distinct return-content information. The parenthetical of implementation identifiers is slightly heavier than an agent strictly needs but still earns its place by grounding what 'state' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of return-value information, and it enumerates the payload contents well enough to set expectations. The remaining gap is that it doesn't say how the 'since the last observe' baseline is established or reset, which matters for a diff-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already explains `game`, including the 'main' default and subagent scoping. The description adds nothing about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Reads') plus a precisely scoped resource ('the open page's state') and an enumeration of what comes back: state JSON, three.js object names, renderer counts, new console errors, and deltas. An agent can tell this is a state-inspection tool. It never names or contrasts against siblings like `look`, `eval`, or `perf`, which likely overlap on page inspection, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'what changed since the last observe' hints at a poll/verify loop after making changes, but there is no explicit when-to-use, when-not-to-use, or 'use X instead of this' routing. With `look`, `eval`, and `perf` as siblings, an agent must guess which observation tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a three.js, React Three Fiber or WebGL page (a game, viewer, configurator, simulation or shader demo) in headless Chrome (or the browser given) on a paused, seeded clock, closing any page already open under the same game name, and lists the asset files (models, textures, sounds) it fetched and any fetch that failed, what a dev-server command printed as an error or warning, a canvas with no height, and the page's text outside the canvas. Open once: after an edit, the next interact, look, observe, eval or feel reloads the page by itself. Use it when such a page has been written or changed. Give a file or folder to serve (url, relative to cwd), an http URL, or a dev-server command run in cwd. Up to 4 games can be open at once, each under its own game name: a subagent opens its own (game: "tester") and passes that name to every call.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| dpr | No | Device pixel ratio, 1 by default. `look` boxes stay in CSS pixels. | |
| url | No | A file or folder to serve (relative to cwd), an http URL, or, with `command`, the path and query to open on the server it starts (its origin is the one the command prints). | |
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| size | No | The page's width and height in CSS pixels until the next open, 1280 × 800 by default, as [1920, 1080]. | |
| window | No | Show the browser's window. | |
| browser | No | The browser engine the page runs in, chrome by default. firefox is Firefox. Every tool works in each; network (here and in `perf`), `perf`'s throttle and its main-thread time are chrome only. | |
| command | No | A dev-server command run in cwd, as `npx vite --port 0`; the first localhost URL it prints is the page. Closing or reopening this game stops it; an `open` with a url on its origin restarts it on that url. | |
| network | No | Also time a first visit on this network (Chrome DevTools' presets), in real time with no cache: when the first scene frame came, which bytes came before it by kind (as sent: the harness's own server does not compress, a CDN does) and when an overlay over the canvas went. | |
| reducedMotion | No | The page gets prefers-reduced-motion: reduce; `look` then says how much of the picture changed since the last look. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does: it discloses the paused seeded clock, that it closes any page already open under the same game name (a destructive side effect), the 4-game concurrency limit, and what it reports (fetched assets, failed fetches, dev-server errors/warnings, zero-height canvas, off-canvas text). This is unusually rich behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two long, dense sentences that front-load the core action and the 'open once' workflow rule. Every clause carries information, though the run-on style makes it harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no annotations and no output schema, the description explains the return content (assets, errors, canvas height, text), the workflow (open once, then interact/look), and the multi-game naming convention. An agent has what it needs to invoke this correctly without reading the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are detailed, so the baseline is 3. The description restates the url/command relationship and the game-name convention, which adds little that the schema does not already document in more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Opens a three.js, React Three Fiber or WebGL page') and is immediately distinguishable from siblings like interact, look, or observe, which act on an already-open page. The enumeration of page types (game, viewer, configurator, simulation, shader demo) removes ambiguity about what qualifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('Use it when such a page has been written or changed') and an implicit when-not ('Open once: after an edit, the next interact, look, observe, eval or feel reloads the page by itself'), plus subagent guidance about naming a game. It doesn't explicitly name an alternative tool for opening, but none of the siblings do that, so the guidance is largely complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Speeds up the open page: measures the frame time (no perf needed first), tries the @paprika3d/three-runtime switches, keeps those that help without changing the picture, writes game-runtime.json, and ends with the final test of game-tests.json when the project has one. It is for a frame a reply reports over budget, or a user who asks about performance.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| switches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: it measures, applies switches that help, preserves visuals, writes game-runtime.json, and runs the final project test. Gaps remain on whether switch changes persist across sessions, how writes are scoped, and what is reported back, so it is solid but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the outcome ('Speeds up the open page'), and each clause carries information. The first sentence is long and dense but no clause is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and two params, the description covers the pipeline, side effects (file write, switch application), visual-invariance guarantee, and final test step. It could say more about what results are surfaced after running, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the `game` param is documented in-schema and the description reinforces that it targets the open page. The `switches` enum values (resolution, defaults, instancing, lod, dispose) are never explained in either schema or description; 'tries the @paprika3d/three-runtime switches' only hints at meaning, so the description doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Speeds up the open page') and enumerates the concrete actions: measuring frame time, trying three-runtime switches, writing game-runtime.json, and running test. It implicitly separates itself from perf ('no perf needed first') and test, though it never crisply names a sibling as the alternative to use instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions – 'a frame a reply reports over budget, or a user who asks about performance' – and clarifies the relationship to perf. It stops short of stating when *not* to use it or naming an alternative tool, so it falls just short of the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measures the open page's frame time (fps), draw calls, triangles and asset size against a budget (desktop by default): it is for a frame a reply reports over budget, or a user who asks about performance (stutter, low fps). To find what costs the frame, give variants: each is measured on a fresh page against the baseline, in this one call, with named objects hidden, a pixel ratio, code run with renderer and scene (shadows or antialias off, a material swapped), or a query the page loads with ("noshadow&pr=0.5", for switches the game reads at load); no reopening or reload code needed. Sampling waits until no element covers the canvas (a loading screen), up to 5 s of the page running, and the load line says what it waited for or sampled under.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| costs | No | Also list the main scene's visible content by named group (an object goes by its nearest named ancestor, as `look` names it): triangles, those casting shadows, draw calls and texture MB, the 12 groups with the most triangles and the rest in one line. Counted, not timed, with no frustum culling; `variants` with `hide` times a group. | |
| budget | No | desktop, mobile, quest, site (a 3D website: first scene frame within 3 s on fast-4g unless `network` says otherwise, 1 MB of script, 4 MB of assets), or limits to override: { frameMs, assetMB, triangles, drawCalls, textureMax, pixelRatioMax, firstSceneFrameMs, scriptMB }. | |
| network | No | Also time a first visit on this network (Chrome DevTools' presets), in real time with no cache: when the first scene frame came, which bytes came before it by kind (as sent: the harness's own server does not compress, a CDN does) and when an overlay over the canvas went. CPU `throttle` is separate. | |
| throttle | No | Slow the page's JavaScript this many times, as on a weak laptop (4 is a typical one); GPU work is not slowed. | |
| variants | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and mostly does: it discloses that sampling waits up to 5 s for a covering element (loading screen) to clear, that variants run on a fresh page against the baseline within the same call, and that the load line reports what was waited for. It does not say what a failed/throttled sample returns or how a budget breach is signalled in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, which is right, but the body is a run-on block with stacked parentheticals and colons — the `variants` explanation alone is one ~80-word sentence with five parallel clauses. The content mostly earns its place, yet readability suffers; a short bulleted breakdown of variant knobs would preserve the information at much lower parsing cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter, zero-annotation, no-output-schema tool, the description covers the hard parts: what is measured, the budget model, variant isolation, sampling preconditions, and network emulation semantics. The remaining gap is the return shape — the agent is told only that a "load line" reports what was waited for, without knowing what the overall reply contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 83%, so baseline is 3; the description nonetheless adds real meaning to the least-documented parameter, `variants` — fresh page per variant, baseline comparison, `code` receiving `renderer` and `scene`, and `query` being read at page load with the concrete example "noshadow&pr=0.5". It also clarifies that `throttle` is CPU-only and separate from `network`'s DevTools presets, which the schema does not say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and an explicit list of measurements (frame time/fps, draw calls, triangles, asset size) plus the budget framing with the desktop default. It does not name a sibling tool it is not, but it does implicitly distinguish itself from `look` by referencing how `look` names groups. An agent can tell what it does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"it is for a frame a reply reports over budget, or a user who asks about performance (stutter, low fps)" gives a concrete trigger condition with user-facing symptoms. It also routes within-tool: use `variants` "to find what costs the frame", and `costs` is described in the schema as the counted counterpart. No explicit exclusions versus siblings like `optimize` or `test` are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publishes the project at https://.paprika3d.app (public; preview, invite-only), only when the person asks; never for another host. Never read or print ~/.config/paprika3d/credentials.json: this tool reads the key.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| slug | No | Subdomain (default: project name). | |
| model | No | Your model id. | |
| rotate | No | Only replace this install's key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the visibility model (public vs. preview/invite-only) and the fact that publishing reads a credential key from ~/.config/paprika3d/credentials.json — valuable security context. It says nothing about reversibility, idempotency when the slug already exists, whether publishing overwrites a live deployment, or what the response contains, which are material gaps for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The action and its destination are front-loaded, and every clause carries information (destination, visibility, permission gate, host restriction, credential warning). The semicolon-joined, parenthetical-heavy style makes it slightly dense but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the definition covers the destination, visibility modes, and auth handling well, but leaves out failure behavior, idempotency/redeploy semantics, and any indication of what a successful call returns beyond the implied URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (cwd, slug, model, rotate) are already documented in the schema and the baseline of 3 applies. The description adds no parameter-level detail; notably the 'rotate' semantics and slug-collision behavior are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Publishes the project') plus the exact resulting URL pattern and the two visibility modes it can produce, so the agent knows precisely what action it takes. It does not name or differentiate itself from any sibling (e.g. 'open', 'model_run'), which keeps it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('only when the person asks') and an explicit exclusion ('never for another host'), which is unusually strong when-to-use guidance for a mutation tool. It stops short of a 5 because it names no alternative tool or fallback for the excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a reference picture the page should match (a photo, artwork, mockup or screenshot in the project, e.g. refs/01.jpg) at full resolution, in one call and with no page open: crop [left, top, right, bottom] in the picture's pixels, enlarged up to 4× to fit 1280 px, with grid lines every N px labelled in the picture's own pixel coordinates (positions read off it go straight into the next call or the scene), and sample points, each answered as #rrggbb. With the page open, compare: true puts the picture, the page's look (from camera when given) and a difference picture side by side and says what share of pixels differ, overall and in a grid of regions (cells per side, 4 by default), with each sample point's colour on both, or that the canvas aspect is not the picture's. Use it to read a picture the page should match and to check the page against it.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | The game project's folder. | |
| crop | No | [left, top, right, bottom] in the picture's pixels ([x, y, width, height] is read as such when right < left or bottom < top), trimmed to the picture; the whole picture when left out. With compare: that region of the picture and the same region of the page, enlarged side by side with their differences. | |
| file | Yes | The picture's path, relative to cwd, or the name of a baseline saved with look { save } (compare the page with its earlier look). | |
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). | |
| grid | No | Gridline spacing in the picture's pixels (100 on a whole picture, 10 to 50 on a crop); none when left out. | |
| cells | No | Regions per side for compare's differing-share grid (4 by default). | |
| camera | No | For compare: the page's look from this position (looking at lookAt) or from a camera by name, as `look`'s camera; left out, the picture's entry in refs/cameras.json when there is one, else the page's own camera. | |
| sample | No | Points [x, y] in the picture's pixels whose colour to return (the mean of 5 × 5 pixels); with compare, the page's colour at the same point too. | |
| compare | No | Put the open page's look beside the picture with their differences; needs `open` first, and a canvas with the picture's aspect for the pixel comparison. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses substantial behavior: full-resolution reading, one-call/no-page-open operation, crop enlargement up to 4× to fit 1280 px, grid lines labeled in the picture's own pixel coordinates, sample points answered as #rrggbb, and compare output including differing-pixel share and aspect-mismatch reporting. It does not explicitly state that the tool is read-only or describe error behavior, but the reading-oriented behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, and every clause is relevant to using the tool. However, it is a dense run-on with deeply nested parentheticals, making it harder to scan than a more structured presentation would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex nine-parameter tool with no output schema and no annotations, and the description covers the important modes, return information for sample and compare, prerequisites, and limitations such as aspect mismatch. It is largely complete, though it could be clearer about file formats or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all nine parameters are already well documented in the schema. The description adds some useful context, such as the 4× enlargement limit and the fact that grid coordinates feed directly into later calls or the scene, but most parameter semantics are restated from the schema rather than adding new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it reads a reference picture the page should match, at full resolution. It distinguishes this from reading the page itself by describing the picture as the thing the page should match, but it never names close siblings such as look, observe, or model_look to make the routing explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage context: use it to read a picture the page should match and to check the page against it. It also states the condition for compare mode (the page must be open and the canvas must have the picture's aspect), but it does not name alternatives or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends the paprika3d team a bug, feedback or criticism about the harness itself (not about the user's page): a reply that was wrong or unclear, a tool that hung, errored or got in your way, a check you disagree with, or something you needed and no tool gave. It attaches the last tool call's name, options and error, never the page's code or files. One line back; carry on with the task after it.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| text | Yes | What happened and what you expected, in a few sentences (2,000 characters at most). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does: it discloses exactly what is transmitted ('last tool call's name, options and error, never the page's code or files'), what comes back ('one line back'), and that it is non-blocking ('carry on with the task after it'). Data-privacy and side-effect profile are both covered, which is unusually complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and recipient, then the use cases, then the side-effect profile. Every clause earns its place — including the privacy carve-out and the 'carry on' reassurance, both of which change agent behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still covers return shape ('one line back'), automatic attachment of context, and post-call continuation. For a simple two-parameter report tool, nothing an agent needs in order to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — `kind` is an undescribed enum and only `text` carries a schema description. The tool description compensates by pinning down what the payload should be about (harness-level problems, not page code/files), which is genuinely new information a caller needs to fill `text` correctly, though it does not characterize the bug/feedback/criticism distinction among enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and recipient ('Sends the paprika3d team a bug, feedback or criticism') and immediately scopes the subject ('about the harness itself (not about the user's page)'). That negative scoping is what lets an agent distinguish this from the surrounding task tools like observe, interact or eval without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Enumerates concrete triggers: a reply that was wrong or unclear, a tool that hung/errored/got in your way, a check you disagree with, or a missing capability. It also gives an explicit exclusion ('not about the user's page'), so the when-not is as clear as the when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reruns every check saved with interact save (game-tests.json), each from a fresh reload at frame 0, one line each: ✓ pickup or ✗ jump: player.y 1.4, expected ≥ 2. Use it after an edit that could break earlier features.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | The name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behavior: each check runs from a fresh reload at frame 0, all checks run, and output is one line per check with pass/fail syntax. It does not mention runtime cost, whether failures abort the run, or whether any game state is persisted, but the core execution model is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and followed by the usage condition. Output examples are embedded inline without padding, and every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description explains the test source, execution model, output shape, and intended timing. It could be slightly more complete by stating that the game must already be open or by noting whether failures produce a nonzero result, but it is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the `game` parameter is already well documented in the schema. The description does not add meaning about how the optional `game` argument affects check selection, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Reruns every check saved with `interact` `save`'. It ties the tool to a sibling and makes clear this is a saved-regression-test runner, not an ad-hoc eval, so an agent can distinguish it from `eval` or `perf` without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete trigger: 'Use it after an edit that could break earlier features.' That is clear when-to-use guidance, but there is no explicit when-not or direct alternative comparison (e.g. use `eval` for one-off checks instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1asset_searchevalfeelinteractlookmodel_auditmodel_lookmodel_runobserveopenoptimizeperfpublishreferencesend_feedbacktestScored across 16 tools
Several tools have overlapping boundaries: perf and optimize both target performance, interact and feel both replay input steps, and look and reference compare both handle visual comparison. The descriptions explain the distinctions, but an agent could still misselect when deciding whether to measure or optimize, or whether to use interact versus feel.
Names are all lowercase snake_case, but the conventions are mixed: single verbs or nouns such as open, look, feel, eval, perf, and test sit alongside compound names like model_audit, asset_search, and send_feedback. The names remain readable, but there is no predictable verb_noun pattern throughout.
Sixteen tools is slightly above the typical 3-15 range, but the server covers a broad 3D game-development harness from opening pages to modelling, testing, asset search, and publishing. Each tool mostly earns its place, though a few overlaps make the surface feel larger than necessary.
The set covers a strong lifecycle: opening pages, inspecting and interacting, visual checks, performance measurement and optimization, model creation and audit, tests, reference comparison, asset search, and publishing. Minor gaps exist, such as no explicit close/list management for open pages, but core workflows are well covered.
See the rendered web: design tokens, fonts, animation timings, WebGL shaders and 3D from any URL.
Give AI agents a real cloud Chrome: open sessions, navigate, read pages, click, type and screenshot.
Headless browser primitives for AI agents when sites need real JS rendering.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.