ZeroWidth

Look at a Napkin interface

napkin_interfaces_view

Read-only

See what an interface LOOKS like and DOES right now: the page RUNS from its current files under the same rules as the live page (no web fonts, no remote pictures), and you get a picture plus anything that went wrong (script errors, failed promises, blocked requests, console errors). Use it after every write and before saying an interface is finished: reading the code tells you what you wrote, not what it renders. size: "phone" looks at it 390px wide — use it for anything meant for a phone, like a mobile app mockup. steps drive the page before and between pictures, so you can check every screen and that buttons work: {click: "Plan"} (by visible text or label, or a CSS selector like "#nav-plan"), {type: {into: "textarea", text: "hi"}}, {press: "Enter"}, {wait: 500}, and {shot: "Plan screen"} for a picture. With no steps you get one picture of the first screen. Check each tab of an app in ONE call: shot, click a tab, shot, click the next, shot. Flows don't run here: a flow call gets a placeholder reply, so you can see the chat send and answer without spending anything; tables and metrics read empty. Look for text that's too small or runs together, stray system fonts, emoji standing in for icons, and anything that doesn't look like the brand.

Input Schema

Name	Required	Description
`size`	No	The window to look through. Default desktop (1280 wide); phone is 390 wide.
`steps`	No	Done in order, with a picture at each `shot` (at most 6). Default: one shot of the first screen.
`workspace`	No	Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
`interfaceId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / size

Added value: +{
+  "description": "The window to look through. Default desktop (1280 wide); phone is 390 wide.",
+  "enum": [
+    "desktop",
+    "phone"
+  ],
+  "type": "string"
+}

addedInput schema / properties / steps

Added value: +{
+  "description": "Done in order, with a picture at each `shot` (at most 6). Default: one shot of the first screen.",
+  "items": {
+    "anyOf": [
+      {
+        "properties": {
+          "click": {
+            "maxLength": 200,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "click"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "type": {
+            "properties": {
+              "into": {
+                "maxLength": 200,
+                "minLength": 1,
+                "type": "string"
+              },
+              "text": {
+                "maxLength": 2000,
+                "type": "string"
+              }
+            },
+            "required": [
+              "into",
+              "text"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "type"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "press": {
+            "maxLength": 20,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "press"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "wait": {
+            "maximum": 3000,
+            "minimum": 0,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "wait"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "shot": {
+            "maxLength": 80,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "shot"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  "maxItems": 20,
+  "type": "array"
+}

First observedOct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only establish that this is a safe, non-open-world read. The description adds substantial behavior beyond that: the page runs from current files under live-page rules with no web fonts or remote images, the result is a picture plus script errors, failed promises, blocked requests and console errors, and flows return a placeholder while tables and metrics read empty. That last detail (what is stubbed out) is exactly the kind of non-obvious behavior an agent cannot infer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what it does and when to use it, and there is little pure filler. It is long and dense across three paragraphs, and the closing list of aesthetic things to look for is helpful but ancillary to invocation, so it is a notch below maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description explains the return shape (a picture plus a consolidated error report), covers all four parameters including the workspace token rule, and warns about stubbed flows/tables. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, and the description compensates by giving semantics the schema does not: click targets resolve "by visible text or label, or a CSS selector like #nav-plan", the steps model is shown as worked examples, and the default single-shot behavior is restated. This is meaningfully more than the anyOf blocks convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (see what a Napkin interface looks like and does by actually rendering it), and explicitly separates itself from the sibling that reads source: "reading the code tells you what you wrote, not what it renders." An agent can distinguish this from napkin_interfaces_get, napkin_interfaces_write, and napkin_boards_view without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit usage rule ("Use it after every write and before saying an interface is finished"), calls out when the phone size applies ("anything meant for a phone, like a mobile app mockup"), and shows the multi-step pattern for checking each tab in one call. It also states the boundary against the alternative of reading code.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ZeroWidth tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?