Real product UI captures (onboarding, pricing, in-app screens) with design guides for coding agents.
Scored across 13 tools
Each tool targets a distinct action or resource, with clear boundaries. Similar pairs like get_screen vs get_screen_image, get_product vs get_flow, and pick_reference vs wait_for_pick are well-differentiated by their descriptions.
All tool names use consistent snake_case and follow a verb_noun pattern (e.g., get_screen, list_products, build_handoff). The verb variety appropriately reflects different operations without inconsistency.
13 tools is well-scoped for a UI reference catalog, covering exploration, comparison, and action workflows. Each tool has a clear purpose and none seem redundant or missing.
The surface covers the full lifecycle: listing products and flows, searching, getting detailed screen/design/flow data, comparing screens, checking user UI, generating build handoffs, and enabling user picks. No obvious gaps for a read-only reference catalog.
Generate a complete build prompt for a coding agent: ordered screens with notes, observed transitions, full-resolution image URLs, the measured design guide, and an implementation checklist. This is the same prompt as the "Use in agent" button on the site.
Reference IDs: use {product}-onboarding for a product's signup flow, {product}-collection
for all their screens, or any single screen id (like linear-marketing-pricing).
Use this when you want to build UI that follows a real product's patterns. The prompt includes everything an agent needs: screenshots to reference, design tokens to match, and implementation steps to follow.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | What you want to build. Goes at the top of the prompt. | |
| stack | No | Preferred stack, e.g. Next.js and Tailwind. | |
| screens | No | Comma-separated screen ids to keep. Omit to include every screen in the reference. | |
| referenceId | Yes | e.g. linear-onboarding, stripe-collection or vercel-marketing-pricing. | |
| includeDesign | No | Include the observed design guide. Set false to use your project's own design system. |
| Name | Required | Description |
|---|---|---|
| prompt | No | Markdown prompt to follow or paste into an agent. |
| manifest | No | Versioned reference manifest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing exactly what the generated artifact contains (screens, transitions, image URLs, design guide, checklist) and noting the includeDesign toggle's effect on output. It stops short of stating size limits or output format details.
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 and the three paragraphs are logically ordered (what it produces, reference IDs, when to use). Slight redundancy exists: the contents are enumerated in paragraph one and restated as 'screenshots to reference, design tokens to match, and implementation steps to follow' in the closing sentence.
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?
An output schema exists, so the description needn't document return values; annotations cover safety; and the schema fully documents all five parameters. Combined with the reference-ID guidance and the when-to-use statement, an agent has everything needed to invoke this 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. The description goes further by documenting the referenceId naming conventions ({product}-onboarding, {product}-collection, single screen id), which the schema only illustrates with flat examples. It adds real meaning over the structured fields for the required parameter.
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 (generate) and resource (a complete build prompt for a coding agent) and enumerates the concrete contents: screens with notes, transitions, full-resolution image URLs, design guide, and checklist. It distinguishes itself via 'the same prompt as the "Use in agent" button on the site,' though it never explicitly contrasts with siblings like get_design or get_flow.
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 a clear triggering condition: 'Use this when you want to build UI that follows a real product's patterns.' It also explains the reference ID scheme for selecting scope. However, it names no alternatives (e.g. get_design, get_screen) and offers no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the user's UI structure against Screenrove's catalog of real products. Describe what the user has (screen type, sections, flow steps, plan count) and get a report showing the closest real-world references with factual comparisons.
Use only the fields the user provides; leave out personal names, pricing, or customer data. The report includes step counts, section counts, observed actions, and factual comparisons— not recommendations.
Use this when the user wants to validate their UI against real products, understand if their flow has more or fewer steps than competitors, or see how similar screens are structured.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only compare with this kind of capture. | |
| limit | No | How many references to return, 1 to 5. | |
| product | No | Only compare with this product id. | |
| flowType | No | What the flow does, so step counts are only compared with flows of the same kind. Inferred from screenType when omitted. | |
| sections | No | Page sections top to bottom, e.g. ["Hero", "Plan cards", "FAQ"]. | |
| flowSteps | No | For a multi-screen flow, each step's title in order, e.g. ["Sign up", "Verify email", "Create workspace"]. | |
| planCount | No | For pricing screens, how many plans are shown. | |
| screenType | No | What kind of screen it is. | |
| description | Yes | One or two sentences on what the screen is for and how it is laid out, e.g. "Pricing page with three plan cards, a monthly/yearly toggle and a feature table". | |
| primaryAction | No | The main button or action, e.g. "Start free trial". |
| Name | Required | Description |
|---|---|---|
| next | No | |
| report | No | Markdown summary of the comparison. |
| references | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, non-destructive, closed-world profile, so the bar is lower. The description adds genuinely useful behavioral context beyond that: it enforces a privacy constraint ('use only the fields the user provides; leave out personal names, pricing, or customer data') and sets an output boundary ('factual comparisons—not recommendations').
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 short paragraphs, front-loaded with the core action, then the privacy constraint, then usage triggers. Every sentence carries information, though the usage paragraph slightly overlaps the opening.
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 analysis tool with an output schema, the description covers purpose, input-discipline, output boundaries, and usage triggers adequately. Return content need not be explained given the output schema, though the missing sibling differentiation is a residual gap.
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 three parameters carry enums, so the schema already documents every argument's meaning and constraints. The description's parenthetical list (screen type, sections, flow steps, plan count) merely restates fields the schema defines in more detail, adding no syntax or format guidance beyond 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+resource: compare the user's UI structure against Screenrove's catalog of real products and return a report of closest references. Clear enough to act on, though it never explicitly distinguishes itself from the sibling 'compare_screens', which sounds closely related.
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 three concrete when-to-use triggers (validate UI against real products, compare flow step counts to competitors, see how similar screens are structured). No when-not guidance and no mention of when to prefer compare_screens or pick_reference instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two captured screens side by side: layout structure, page sections, observed actions, dimensions, screen types, and design guide differences. Returns a structured comparison with similarities, differences, and factual observations.
Use this when the user wants to understand how two products approach the same problem differently—e.g. comparing Linear's pricing page with Stripe's pricing page, or Vercel's onboarding with Notion's onboarding.
You can also compare one screen against a target description to see how close a reference matches what the user is trying to build.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | What aspects to emphasize in the comparison. | all |
| screenA | Yes | First screen id to compare, e.g. linear-marketing-pricing. | |
| screenB | No | Second screen id to compare. If omitted, provide targetDescription instead. | |
| targetDescription | No | Instead of screenB, describe what you're building to see how screenA matches, e.g. "Pricing page with 3 tiers and a feature comparison table". |
| Name | Required | Description |
|---|---|---|
| report | No | Markdown summary of the comparison between the two screens. |
| screenA | No | Details about the first screen. |
| screenB | No | Details about the second screen (null if comparing against targetDescription). |
| differences | No | How the two screens differ. |
| observations | No | Design observations and takeaways from the comparison. |
| similarities | No | What the two screens have in common. |
| targetDescription | No | The target description if comparing against text instead of screenB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by describing the return shape (similarities, differences, factual observations) and the screen-vs-target alternative mode. It stops short of noting what happens with unregistered screen ids or partial failures.
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 the comparison content and scoping, then usage context. The two worked examples (Linear/Stripe, Vercel/Notion) are illustrative but add length; the description could shed one pair without losing signal.
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 an output schema present, return format need not be spelled out, and the description nonetheless previews it. Purpose, both modes, and usage triggers are complete; the only unaddressed element is what focus controls, which the schema enum covers adequately.
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 screenA, screenB, and targetDescription are already documented inline, including the 'if omitted, provide targetDescription instead' constraint. The description reinforces the dual-mode behavior but adds no format or constraint detail beyond the schema, and never mentions the focus parameter. Baseline 3 applies.
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 (compare) plus resource (two captured screens) with an explicit enumeration of what is compared: layout structure, sections, actions, dimensions, screen types, design guide differences. It is clearly distinguishable from siblings like get_screen or search_screens, which retrieve rather than diff.
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?
Names concrete when-to-use triggers (understanding how two products solve the same problem) with two example pairs, and explicitly covers a second mode—comparing one screen against a target description of what the user is building. Both selection conditions are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the measured design guide for a product: observed font families, color palette, type scale, layout patterns, spacing values, and component observations. Marketing site and product UI are measured separately.
Use this when you want to match a competitor's design system, understand their visual language, or borrow their typography and color choices for your own project.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Which surface to return. Omit for both. | |
| productId | Yes | Product id from listProducts, e.g. linear, stripe or airbnb. |
| Name | Required | Description |
|---|---|---|
| font | No | |
| product | No | |
| summary | No | |
| contexts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the guide is 'measured/observed' and that marketing and product surfaces are measured separately, which is useful context, but return format and granularity are left to the output schema.
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 tight sentences, front-loaded with the concrete deliverable before the usage guidance. The 'measured separately' clause slightly overlaps the already-documented context enum, but nothing is wasted.
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 an output schema present, the description need not document return values, and it still previews the field categories helpfully. Inputs are fully covered by the schema; only a pointer to related tools (e.g., get_product, list_products) 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 100% and both parameters are documented, so the baseline is 3. The description slightly exceeds it by explaining that marketing site and product UI are distinct measured datasets, reinforcing why the 'context' enum exists and what happens when it is omitted.
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 ('Get the measured design guide for a product') and enumerates the concrete contents (font families, palette, type scale, spacing, components), which lets an agent distinguish it from get_product or get_screen. It stops short of explicitly naming the sibling it is not.
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 second sentence gives clear triggering contexts: matching a competitor's design system, understanding visual language, borrowing typography/colors. No exclusions or named alternatives are given, so it falls just short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete onboarding flow for a product: every step in order with titles, notes on what happens, observed transitions (button labels and where they lead), and which steps are alternate branches. Includes the handoff reference id to use with buildHandoff.
Use this to study how a competitor structures their signup and onboarding, what information they collect at each step, and how they guide users to activation.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Product id from listProducts, e.g. linear, stripe or airbnb. |
| Name | Required | Description |
|---|---|---|
| steps | No | |
| captured | No | |
| flowType | No | |
| flowTitle | No | |
| handoffId | No | Use with buildHandoff to get the full prompt. |
| productId | No | |
| productName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds that branch steps are marked as alternates and that the response carries a handoff reference id consumed by buildHandoff — context an agent could not infer from annotations. It does not say what happens for an unknown productId, so it falls short of a 5.
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 short paragraphs, front-loaded with what is returned, followed by the motivating use case; every sentence earns its place. There is mild overlap between the enumerated return fields and the existing output schema, which keeps it from a 5.
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?
Return values are covered by the output schema and safety by annotations, so the description only needs to sell the tool's purpose and linkage — which it does, including the buildHandoff handoff id. The one remaining gap is failure behavior for a bad productId, which matters given how the sibling listProducts is the intended id source.
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 the single productId parameter already carries a description plus concrete examples (linear, stripe, airbnb) pointing at listProducts. The description adds nothing about the parameter, so the baseline 3 for a fully-covered schema 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?
States a specific verb and resource ('Get the complete onboarding flow for a product') and enumerates the payload at a level an agent can act on: ordered steps, titles, notes, observed transitions with button labels and destinations, alternate branches. This clearly distinguishes it from the sibling list_flows (enumeration) and get_screen (single screen), without the agent needing to open a 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?
Explicitly frames the use case: 'Use this to study how a competitor structures their signup and onboarding, what information they collect at each step, and how they guide users to activation.' It also names the downstream tool ('the handoff reference id to use with buildHandoff'), which is an actionable routing hint. It stops short of stating when NOT to use it or naming the sibling to prefer for lighter-weight lookups (e.g. list_flows).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a product's full collection: coverage notes, design summary, and every captured screen grouped into onboarding flow, marketing pages, and in-product screens.
Use this to explore a competitor's complete UI: their signup flow, pricing page, dashboard, settings, and other screens. Each screen has notes and an image URL.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Product id from listProducts, e.g. linear, stripe or airbnb. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| name | No | |
| tags | No | |
| counts | No | |
| source | No | |
| screens | No | |
| captured | No | |
| coverage | No | |
| handoffs | No | |
| flowTitle | No | |
| captureNote | No | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them by disclosing the payload structure (grouped screens, per-screen notes and image URL). It does not mention pagination or limits, but the output schema carries return details.
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 what is returned, then when to use it. The illustrative screen list is mildly verbose but reads as useful scoping rather than 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?
With an output schema, full parameter coverage, and safety annotations in place, the description only needed to convey scope and usage, which it does. An agent has everything required to select and call this 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, fully documented in the schema (100% coverage) including an example format ('linear, stripe or airbnb'). The description adds nothing about productId, so baseline 3 is appropriate since the schema does the work.
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 ('Get a product's full collection') and enumerates the returned artifacts: coverage notes, design summary, and every captured screen grouped by category. This implicitly separates it from get_screen/get_flow (single items), but it never names a sibling tool explicitly, so differentiation requires inference.
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?
'Use this to explore a competitor's complete UI' gives clear context for when to reach for it, reinforced with concrete examples (signup flow, pricing page, dashboard, settings). There are no exclusions or named alternatives, so the agent must guess when get_design or get_screen would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get everything recorded about one screen: notes on what it does and how it's laid out, source URL, image URLs and dimensions, observed actions and where they lead, and page sections for long marketing pages.
Use this to understand a specific UI pattern in detail before building something similar.
| Name | Required | Description | Default |
|---|---|---|---|
| screenId | Yes | Screen id from searchScreens or getProduct, e.g. linear-signup. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| kind | No | flow is an onboarding step, marketing a public web page, product an in-app screen. |
| notes | No | |
| title | No | |
| width | No | |
| branch | No | |
| height | No | |
| source | No | |
| actions | No | |
| product | No | |
| captured | No | |
| imageUrl | No | |
| sections | No | |
| previewUrl | No | |
| productName | No | Present on pick options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful scope context by listing the categories of recorded data an agent can expect, though with an output schema present some of that enumeration is redundant.
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 what is retrieved and followed by the use case. Nothing is padded and every clause carries 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?
With a full output schema, complete parameter documentation and read-only annotations, the description supplies what is needed to call the tool correctly. The only minor gap is the absence of explicit routing to sibling alternatives, which is a usage concern rather than a completeness one.
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 the single screenId parameter is already documented as 'Screen id from searchScreens or getProduct, e.g. linear-signup'. The description adds no syntax or format meaning beyond the schema, so the baseline 3 applies.
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 precise verb+resource ('Get everything recorded about one screen') and enumerates the specific content returned — notes, source URL, image URLs/dimensions, observed actions, page sections. The singular scope ('one screen', keyed by screenId) cleanly separates it from plural siblings like search_screens and compare_screens.
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 context: 'Use this to understand a specific UI pattern in detail before building something similar.' That is a genuine when-to-use signal, but it names no alternative tool (e.g. search_screens for discovery, compare_screens for side-by-side) and no exclusion conditions, so an agent must still infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the actual screenshot so you can see the UI. For marketing pages taller than 4000px, preview returns only the first screen (above the fold); use size=full for the whole page, which can exceed what vision models accept. getScreen lists the page's sections with their y offsets so you know what's below the fold.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | preview (default) keeps images small enough to view; full returns the original capture. | preview |
| screenId | Yes | Screen id from searchScreens or getProduct, e.g. linear-signup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds real operational context the annotations cannot: the vision-model size limit on full-page captures and the above-the-fold truncation behavior of preview. It does not cover failure modes or rate limits, so not a 5.
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 core action and no redundant restatement of the name. The closing clause 'so you can see the UI' is mild filler, keeping it below a 5.
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 exists, so the description carries the return-value burden, and it does so adequately (an image, possibly truncated or oversized). With annotations covering safety and the schema covering params and defaults, only error/edge-case behavior 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 100% so the baseline is 3, but the description goes beyond the schema by explaining the above-the-fold/4000px semantics of preview and the vision-model constraint on full, which the enum description alone does not convey.
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+resource (get the actual screenshot of a screen) and explicitly differentiates from the sibling get_screen, which 'lists the page's sections with their y offsets.' An agent can tell the image-fetch tool apart from the metadata-list tool without opening either 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?
Gives explicit conditions: preview (default) returns only above-the-fold content for tall marketing pages (>4000px), use size=full for the whole page, and route to getScreen when you need to know what is below the fold. When-to-use, when-not, and the alternative are all named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every captured user journey: onboarding flows, signup sequences, checkout processes, booking flows, and marketplace explorations. Shows step counts, flow type, and observed transitions between steps.
Use this to find complete user journey references—not just individual screens—so you can see how products guide users through multi-step processes like signup, onboarding, or checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| flowType | No | Only return flows of this type. |
| Name | Required | Description |
|---|---|---|
| flows | No | |
| total | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds what the results contain (step counts, flow type, observed transitions), but says nothing about pagination, result limits, or ordering. With annotations carrying the behavioral burden, this is adequate but not rich.
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 correctly with the verb and resource, and reasonably brief. However, the second sentence redundantly re-lists the flow types already enumerated in the first ('signup, onboarding, or checkout'), so not every phrase earns its place.
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?
An output schema exists, so return-value detail is a bonus rather than a requirement, and the description still usefully summarizes what comes back. For a single-optional-parameter read-only listing tool this is close to complete; only the relationship to get_flow and any result-count limits are unaddressed.
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 optional parameter exists and schema coverage is 100% with an enum plus a per-value description, so the schema fully defines it. The description's enumeration of flow types loosely mirrors the enum but adds no filtering semantics (e.g. whether omitting it returns all types) beyond what the schema states. Baseline 3 applies.
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 ('List every captured user journey') and enumerates the concrete domains covered (onboarding, signup, checkout, booking, marketplace), matching the enum in the schema. The second paragraph explicitly positions it against single-screen tools ('not just individual screens'), so an agent can distinguish it from get_screen/search_screens without opening either 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?
Gives a clear use case: reach for this when you need complete multi-step journey references rather than individual screens. It does not, however, name the closest sibling (get_flow) or state any exclusion, e.g. when to prefer get_flow for a single journey or search_screens for a screen-level lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every product in the UI reference catalog with its capture date, tags, coverage notes and screen counts. Start here to see what competitor products, design systems, and UI patterns are available.
Products include: Linear, Cursor, Vercel, Airbnb, Stripe, Duolingo, Notion, Raycast, Cal.com, Framer, and Supabase. Each has captured onboarding flows, marketing pages, and/or in-app screens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| products | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the shape of each entry (capture date, tags, coverage notes, screen counts) and the fact that captures cover onboarding flows, marketing pages, and/or in-app screens.
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 first sentence front-loads the action and the returned fields efficiently. The two following sentences are useful orientation but the long enumeration of product names (Linear, Cursor, Vercel, ...) is the least load-bearing part and pushes the definition slightly past what is needed.
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 an output schema present, return values need not be explained, and the annotations cover the safety profile. The description supplies the discovery-tool framing and a preview of catalog contents, leaving nothing an agent needs in order to call a 0-parameter list 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. No parameter guidance is expected or missing.
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 ('List every product in the UI reference catalog') and enumerates the exact attributes returned (capture date, tags, coverage notes, screen counts). An agent can distinguish it from get_product (single product) and list_flows 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Start here to see what ... are available' clearly signals this is the entry-point/discovery tool in the catalog workflow. It gives positive usage context but does not name an alternative or state when NOT to use it (e.g., when you already know the product and should call get_product).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the user several matching UI references side by side in their browser and let them click the one to build from. Returns a URL to open for them.
Prefer this over sending full-page images whenever the user should decide which reference to use. The picker shows real screenshots at scroll depth so they can evaluate long pages.
After calling this, tell them to choose in the picker, then call waitForPick with the pickId to get their choice and a complete build prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search words, e.g. "pricing page", "onboarding", "empty state". The best matches become the options. | |
| goal | No | What the user is building, shown on the page and used in the build prompt, e.g. "NSDR premium upgrade page". | |
| kind | No | Only search this kind of screen. | |
| count | No | How many options to show when searching, 2 to 6. | |
| stack | No | Preferred stack for the build prompt. | |
| product | No | Only search this product id. | |
| screens | No | Comma-separated screen ids to show instead of searching, e.g. from an earlier searchScreens. |
| Name | Required | Description |
|---|---|---|
| url | No | Open this for the user. |
| next | No | What to do next. |
| pickId | No | |
| status | No | |
| options | No | |
| canvasUrl | No | Experimental pan-and-zoom canvas view of the same pick. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=false, destructiveHint=false, and the description is consistent with that (it opens a picker session and returns a URL). It adds useful behavioural context beyond the annotations: the picker renders real screenshots at scroll depth, it opens in the user's browser, and it yields a pickId that must be consumed by waitForPick. It omits session lifetime/expiry and what happens on repeat calls, so it falls short of a 5.
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 short, front-loaded paragraphs: what happens, when to prefer it, and what to do next. Every sentence earns its place with no restatement of the name or title.
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?
An output schema exists, so return values need no explanation, and the description still correctly flags that it returns a URL to open. Combined with the usage rule and the waitForPick handoff, an agent has everything needed to call it and continue the workflow.
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 every parameter is already well documented there, so the baseline is 3. The description adds no parameter-level detail (e.g. the q/count interaction or how screens bypasses searching) and only references pickId, which is an output rather than an input.
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 plus resource ('Show the user several matching UI references side by side') and its effect (a picker the user clicks, returning a URL). It is clearly separable from siblings like get_screen_image, compare_screens and search_screens because it is framed around user selection rather than retrieval.
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?
Explicitly says when to prefer it ('Prefer this over sending full-page images whenever the user should decide which reference to use') and gives the matching follow-up ('call waitForPick with the pickId'). It names both the alternative and the downstream step, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the UI reference catalog by keyword across titles, notes, page sections, and observed actions. Filter by product or kind (flow/marketing/product).
Use this to find design pattern examples like "pricing page", "empty state", "date picker", "onboarding step", "checkout form", "dashboard", "sign-up", "settings", etc. Returns the best matches with screen IDs you can pass to getScreen or getScreenImage.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keywords to match, e.g. "pricing page", "empty state", "onboarding". Omit to list everything that matches the filters. | |
| kind | No | Only return this kind of screen. | |
| limit | No | Maximum results, 1 to 50. | |
| product | No | Only return screens from this product id, e.g. linear, stripe, airbnb. |
| Name | Required | Description |
|---|---|---|
| total | No | |
| screens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive, so safety is covered. The description adds real behavioral context beyond that: the fields matched, the kind/product filter dimension, and the fact that results carry screen IDs consumable by getScreen/getScreenImage.
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: the primary purpose and filter capability come first, followed by example queries and the return-value hook. Slightly redundant in that example queries appear in both the tool description and the q parameter, but there is no wasted framing.
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 an output schema present, the description need not explain return values, and it still describes the crucial ID handoff. Combined with full schema coverage and read-only annotations, an agent has everything needed to invoke this 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 description coverage is 100%, so every parameter is already documented in the schema. The description restates the product/kind filters and query examples but adds no format, syntax, or edge-case detail beyond what the schema provides, so baseline 3 applies.
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 ('Search the UI reference catalog by keyword') and names the exact fields searched (titles, notes, page sections, observed actions). It also points to the follow-up tools getScreen and getScreenImage, making it distinguishable from read-oriented siblings like get_screen.
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?
Explicitly frames the use case with concrete queries ('pricing page', 'empty state', 'date picker'), which tells the agent when to reach for this tool. It stops short of stating when NOT to use it or how it differs from sibling search/list tools such as list_flows or pick_reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the user to choose on the pick page. Long-polls up to 50 seconds—returns as soon as they click, or status "pending" after the wait (call again if so).
Once chosen, returns their reference with its screenshot and a full build prompt, so you can start building from it immediately. If they clicked "None of these fit", status is "dismissed" and you should ask what they want instead.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Seconds to wait for a choice, 0 to 50. | |
| pickId | Yes | The pickId returned by pickReference. |
| Name | Required | Description |
|---|---|---|
| choice | No | |
| pickId | No | |
| prompt | No | Build prompt for the chosen reference. |
| status | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, yet the description goes further and discloses the long-poll duration, the 'pending'/'dismissed' status outcomes, and the fact that a successful call yields a reference, a screenshot, and a full build prompt. This is meaningful behavioral context beyond the annotations, though it omits any mention of rate limits, timeout errors, or what happens if the pick is never answered.
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 tight sentences, front-loaded with the blocking behavior and the timeout, then the success payload, then the dismissed branch. No filler, and each sentence carries distinct 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?
Even though an output schema exists and the description would not need to explain returns, it still summarizes the success payload and the two non-success statuses, and it tells the agent what to do next in each branch. For a two-parameter blocking tool, an agent has everything it needs to call it and act on the result.
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 schema already documents both parameters, and the baseline is 3. The description adds only a loose echo of the wait window ('up to 50 seconds') that does not reconcile with the schema's stated default of 45, so it contributes little beyond what the schema provides.
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 ('Wait for the user to choose on the pick page') and distinguishes itself in practice from the sibling pick_reference, whose returned pickId this tool consumes. The description never names a sibling explicitly, so differentiation relies on the reader inferring the pick_reference → wait_for_pick pairing rather than being told.
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 clear conditional guidance for two of the three outcomes: call again if status is 'pending', and ask what the user wants instead if status is 'dismissed'. It does not spell out prerequisites (that a pickId must first come from pick_reference) or any alternative to waiting, so guidance is strong but not exhaustive.
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.
compare_screenspick_reference1 field changedInput schema / properties / q / descriptionPrevious value: -"Search words, e.g. \"pricing page\". The best matches become the options."New value: +"Search words, e.g. \"pricing page\", \"onboarding\", \"empty state\". The best matches become the options."search_screens2 fields changedInput schema / properties / product / descriptionPrevious value: -"Only return screens from this product id, e.g. linear."New value: +"Only return screens from this product id, e.g. linear, stripe, airbnb."Input schema / properties / q / descriptionPrevious value: -"Keywords to match. Omit to list everything that matches the filters."New value: +"Keywords to match, e.g. \"pricing page\", \"empty state\", \"onboarding\". Omit to list everything that matches the filters."get_flowlist_flowsbuild_handoff1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "manifest": {
+ "description": "Versioned reference manifest",
+ "type": "object"
+ },
+ "prompt": {
+ "description": "Markdown prompt to follow or paste into an agent.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}check_my_ui1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "next": {
+ "type": "string"
+ },
+ "references": {
+ "items": {
+ "properties": {
+ "facts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "screenType": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "why": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "report": {
+ "description": "Markdown summary of the comparison.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_design1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "contexts": {
+ "additionalProperties": {
+ "properties": {
+ "components": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "layout": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "palette": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "theme": {
+ "type": "string"
+ },
+ "type": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "font": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_product1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "captureNote": {
+ "type": "string"
+ },
+ "captured": {
+ "format": "date",
+ "type": "string"
+ },
+ "counts": {
+ "properties": {
+ "flow": {
+ "type": "integer"
+ },
+ "marketing": {
+ "type": "integer"
+ },
+ "product": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "coverage": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "flowTitle": {
+ "type": "string"
+ },
+ "handoffs": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "screens": {
+ "properties": {
+ "flow": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "marketing": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "product": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_screen1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "actions": {
+ "items": {
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "region": {
+ "description": "Hotspot position as percentages of the image.",
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "branch": {
+ "type": "boolean"
+ },
+ "captured": {
+ "format": "date",
+ "type": "string"
+ },
+ "height": {
+ "type": "integer"
+ },
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "sections": {
+ "items": {
+ "properties": {
+ "title": {
+ "type": "string"
+ },
+ "y": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}list_products1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "products": {
+ "items": {
+ "properties": {
+ "captured": {
+ "format": "date",
+ "type": "string"
+ },
+ "counts": {
+ "properties": {
+ "flow": {
+ "type": "integer"
+ },
+ "marketing": {
+ "type": "integer"
+ },
+ "product": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}pick_reference1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "canvasUrl": {
+ "description": "Experimental pan-and-zoom canvas view of the same pick.",
+ "type": "string"
+ },
+ "next": {
+ "description": "What to do next.",
+ "type": "string"
+ },
+ "options": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pickId": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "description": "Open this for the user.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}search_screens1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "screens": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}wait_for_pick1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "choice": {
+ "properties": {
+ "actions": {
+ "items": {
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "region": {
+ "description": "Hotspot position as percentages of the image.",
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "branch": {
+ "type": "boolean"
+ },
+ "captured": {
+ "format": "date",
+ "type": "string"
+ },
+ "height": {
+ "type": "integer"
+ },
+ "id": {
+ "type": "string"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "kind": {
+ "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
+ "enum": [
+ "flow",
+ "marketing",
+ "product"
+ ],
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "previewUrl": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "productName": {
+ "description": "Present on pick options.",
+ "type": "string"
+ },
+ "sections": {
+ "items": {
+ "properties": {
+ "title": {
+ "type": "string"
+ },
+ "y": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "pickId": {
+ "type": "string"
+ },
+ "prompt": {
+ "description": "Build prompt for the chosen reference.",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "chosen",
+ "dismissed"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}build_handoffcheck_my_uiget_designget_productget_screenget_screen_imagelist_productspick_referencesearch_screenswait_for_pickReal UI references for coding agents: iOS app screens, user journeys and website design systems.
Captured web interfaces, screenshots, flows and structured evidence for AI coding agents.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
A design agent in your coding agent's loop: briefs each screen, reviews UX and visual quality.
Add one secure layer between your agents and this server.
