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

Build one product's reference as a complete prompt: ordered screens with notes, observed transitions, links to up to 10 agent-sized images (1x copies and section crops, each with its pixel size), the measured design guide and an implementation checklist; the same prompt as the site's "Use in agent" button. referenceId is `{product}-onboarding` (its flow), `{product}-collection` (everything) or one screen id. To combine screens from several products, use build_recipe.

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.

Compare the user's UI structure with the closest real products. Describe what they have (screen type, sections, flow steps, plan count; no personal names, prices or customer data) and get factual comparisons, not recommendations: plan counts, section order, blocks the references have that theirs lacks, flow length. image=true attaches the closest one's screenshot.

A fact table of 2 to 8 captured pricing pages, for research rather than building: per product, plan names and prices, cheapest paid plan with currency, monthly/yearly toggle and saving, free plan, trial, seat model, enterprise tier, notable limits, captured date and page url, plus a Markdown table. Values are as captured; a field the capture doesn't state is null and listed in missing (trial and seat model are quoted from the notes).

Compare two screens side by side (screen types, page sections, observed actions, dimensions, plan counts), e.g. Linear's pricing page with Stripe's, or one screen against a description of what the user is building (targetDescription).

Find screens from other products that solve the same design problem as this one: same primary pattern first, then shared tasks, states and components (rarer tags count more). At most two per product; each says why it matched, and a dark-theme copy folds into its row as variants. Use it after one good reference, e.g. other empty project lists or other pricing pages with a comparison table.

Get a product's measured design guide: fonts, colour palette, type scale, layout and component observations, measured separately for its marketing site and product UI. Use it for "make it look like <product>" or "trustworthy like <product>": take the tokens from here and the structure from its screens (search_screens with product, then get_screen_image). fonts gives each context's families by role (display, body, mono) with licence, a CSS fallback stack and the closest free alternative plus its <link>; use the free one unless the user has the licensed font.

Get a product's captured flow: every step in order with title, notes, page url, observed transitions (button labels and where they lead) and which steps are alternate branches, plus the handoffId for build_handoff. Use it to study how a product structures signup, onboarding or a task; then get_screen_image on the steps you will copy.

Get one motion entry as a build prompt: what moves and how (every property, duration, easing or spring, delay and trigger), why it feels good, how to adapt it to another size, the accessibility it needs, Screenrove's vanilla HTML/CSS/JS and the original source where its license allows. Values are marked exact (code) or approximate (a recording). Keep the timings; scale distances to your element as the prompt says; translate the code to your stack.

House rules for UI motion (durations, enter and exit easing, springs, reduced motion) with duration and easing tokens and the library's categories and triggers. Read it once before adding animation.

Get one product's collection: what was captured (coverageLabel, coverage, captureNote) and every screen, grouped into flow, marketing and product, one line each (id, title, primary pattern, page url). detail=full adds each screen's notes and tags. Use it to explore a competitor's whole UI; then get_screen_image on the screens you will build from, and get_design to match its look.

Get everything recorded about one screen: notes on what it does and how it's laid out, product, captured date, page url, source URL, dimensions, observed actions and where they lead, and page sections for long marketing pages. The notes are not the screen: call get_screen_image with the same id to see it before building something similar.

See the screen; call it on your top picks before writing UI. preview (default) is 1x, so 1 image px = 1 CSS px (the top of a long page). The text gives its pixel size and a long page's sections: section=N returns one as a 1x crop. size=full is the original (often 2x), refused above 8000 px tall.

List captured user journeys (signup and onboarding, checkout, booking, search, marketplace, and task flows such as building a board) with step counts and flow type, 40 at a time. A flowType marked typeInferred was read from the flow's first steps; flows with no type are left out of a flowType filter and counted in untyped. get_flow gives the steps.

List the 191 products in the catalog, one compact line each: id, name, category, a one-line coverageLabel saying what was captured (signed in or logged out only), screen counts and page url. Paged (50 by default) and filterable by category or q; the first page also counts products per category. To find screens, search_screens is quicker.

List the tag vocabulary for searching by design problem: four facets (task, pattern, component, state), each tag with its definition, aliases and how many screens carry it. Use the ids with search_screens or pick_reference, e.g. pattern=board-view or state=empty.

How real products are named: pattern shares with examples, TLDs, domain styles, length and syllables, a per-category table and highlights such as the share of AI tools on .ai. Takes search_names' filters for one slice. Use it before proposing names.

Show a person 2 to 6 matching references side by side in their browser and let them click the one to build from. Returns a URL to open for them; then call wait_for_pick with the pickId for their choice and a build prompt. Only when a person is there to choose: autonomous agents should use build_recipe.

Logo references for designing a logo or app icon: each library product's own mark as its site serves it (never redrawn) with mark type, colours, shape, letter case, brand font and category, e.g. "lettermarks on a rounded tile", "green symbols". Logos are trademarks of their owners: study them, don't copy them.

Search the motion library: UI animations and micro-interactions (button presses, toggles, toasts, number tickers, check-offs, thinking states, hover effects, sounds) from open-source libraries and designers' recordings, each with an exact spec and most with vanilla code. Any word can match ("habit streak tick" finds check-offs); more matched words rank higher. Use it when an interactive element should feel finished, then get_motion for the spec and code. To audit a whole library: source=<id> fields=brief lists every entry in one call, with counts by category and by the source's own sections, and which code each has (vanilla, react, install, npm). For a whole UI, suggest_polish maps its parts to entries and sounds.

Naming ideas grounded in about 700 real product names, each with domain, TLD, category, naming pattern, length, syllables, casing and domain style (getX.com, Xhq.com…), plus stats for the whole match, e.g. "short invented names for AI tools on .ai". Traits are heuristics; check trademarks and domains before using a new name.

Find screens by design problem and keyword, e.g. "pricing page like Stripe", "settings", "empty project list". Every screen is tagged on four facets: task, pattern (screen archetype), component and state. Commas mean OR within a facet, facets combine with AND, e.g. pattern=list-view,table-view and state=empty; ids, labels or aliases work ("kanban", "zero state"); list_tags has the vocabulary. q matches titles, tags, visual style (dark, serif, editorial, gradient, playful, pastel...), notes, sections and actions; a word that names a tag ranks screens with that tag first. Screens matching more words rank higher; partial=true says none matched all, and a mistyped word is corrected (didYouMean). Each row has productName, captured date and the page url to cite. Results come 10 at a time (offset for more); fields=brief gives one line each. Near-duplicates (the same capture twice, a dark-theme copy) show once with the other ids in variants. Over MCP a small thumbnail of the top result is attached (720 px JPEG, fields=full); images=1 to 3 attaches 1x screenshots instead, images=0 none. Then look before building: get_screen_image for the 1x image of your picks, or build_recipe with 2 to 6 ids to get them as 1x images with measurements in one brief. The next field names the exact call.

Given the parts of a UI (elements, a description, or Screenrove screen ids; from a screenshot, list the parts you see), returns motion entries and sounds that would improve each part, plus new touches it doesn't have yet (additions), not only replacements. Then get_motion each one.

Wait for the person to choose on the pick page. Long-polls up to 50 seconds and returns as soon as they click, or status "pending" (call again). Once chosen: their reference with its screenshot attached and a full build prompt. "dismissed" means none fit: ask what they want. A pick can be collected for 24 hours.