Skip to main content
Glama
Sign In
paprika3d

paprika3d

Official
by Keeno-Corp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

look

Capture a screenshot of the live page plus an object-ID image and on-screen inventory to detect models that are mis-scaled, out of view, or never loaded.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
atNoUp 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.
gameNoThe name the game was opened under with the `open` tool, to act on ("main" by default; a subagent uses its own).
saveNoKeep this look's picture as the baseline of this name (letters, digits, - or _), with its frame and page size.
zoomNo[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.
sheetNoUp 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.
cameraNoPicture 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`.
sampleNoPoints [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).
scrollNoScroll 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.
targetNoAn 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.
camerasNoUp 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`.
compareNoA 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.
openingNoPicture 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.
viewportsNoPicture 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools