Screenrove: UI Design Reference & Screenshots (free Mobbin alternative)

Build a reference recipe

build_recipe

Read-only

The best way to build from references, with or without a person: pass 2 to 6 screen ids from search_screens (each "id: what to take from it") and get one Markdown brief with the screenshots attached at 1x (section crops for long pages), measured component sizes, the page structure and what to take from each. Up to 6 images are attached (one per reference, then extra section crops); the brief's first line lists them and names a get_screen_image call for any left out. Structure comes from the screens and every visual token from one style product, so conflicting looks are resolved instead of mixed. Interactive parts get matching motion entries to fetch with get_motion. E.g. Linear's issue composer, Vercel's pricing layout and Notion's look in one screen.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "screens": "<screens>"
    },
    "name": "build_recipe"
  }
}

Input Schema

Name	Required	Description
`goal`	No	What you want to build. Goes at the top of the brief.
`stack`	No	Preferred stack, e.g. Next.js and Tailwind.
`style`	No	Product id whose measured visual language to use, e.g. linear or stripe. Omit to use the project's own design system.
`screens`	Yes	1 to 6 screen ids, each optionally followed by ": what to take from it", e.g. ["linear-product-new-issue: issue composer modal", "vercel-marketing-pricing: plan cards and FAQ"].
`styleNotes`	No	Extra visual direction in words, e.g. "our brand green #1a7f37, rounded corners". Used on its own when style is omitted.
`styleContext`	No	Which of the style product's guides to use. Defaults to marketing when most screens are marketing pages, otherwise product.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "images": {
-      "description": "Preview URLs of up to four references",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "manifest": {
-      "description": "Machine-readable version of the brief",
-      "type": "object"
-    },
-    "prompt": {
-      "description": "Markdown brief to follow or paste into an agent.",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

AddedOct 22, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no output schema, the description carries the return-format burden well: one Markdown brief, screenshots at 1x with section crops for long pages, max 6 images, first line lists attachments and names a get_screen_image call for anything omitted. It also explains that structure comes from the screens while visual tokens come from a single style product, resolving conflicting looks. Minor gap: no sense of latency or limits beyond image count.

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

Conciseness5/5

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

Front-loaded with the core action and input contract, then the output shape, then the style-token rule, ending with a concrete worked example. The one soft spot is the ambiguous 'with or without a person', but length is justified by the number of behaviors it must convey.

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?

For a 6-parameter composite tool with no output schema this covers the essentials: input format, image budget, overflow handling, style vs styleNotes fallback, and the motion follow-up. The only real defect is the 2-to-6 versus 1-to-6 screen-count mismatch, which leaves the minimum call under a minor ambiguity.

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%, so the baseline is 3; the description reinforces the 'id: what to take from it' convention but adds little beyond the schema's own wording. It does introduce friction by saying 'pass 2 to 6 screen ids' while the schema says 1 to 6, which could make an agent drop a single-screen call that is actually valid.

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 gives a specific verb and artifact ('build from references' → 'one Markdown brief') and names the prerequisite sibling (search_screens) plus follow-ups (get_screen_image, get_motion). It is clearly a distinct build/brief-generation tool, though it only hints at how it differs from build_handoff with the vague 'best way to build from references'.

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?

Usage is implied rather than stated: you must first call search_screens to obtain ids, and interactive parts should be fetched with get_motion. There is no explicit when-not guidance and no comparison to build_handoff or compare_screens, so the agent must infer which build flow to pick.

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

All Screenrove: UI Design Reference & Screenshots (free Mobbin alternative) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?