Screenrove
Real product UI captures for design reference, competitor analysis, and coding agents.
| Endpoint | https://screenrove.com/mcp (streamable-http) |
|---|---|
| Registry version | 1.5.0 |
| Now | 22 tools · grade B (83) · pin ts_4618e11342ba4e2c0d513b659caa9fe4 · protocol 2025-06-18 |
| First / last listed | 2026-10-27 02:24 UTC / 2026-10-27 02:24 UTC |
| Grade over time | 2026-10-27: B (83), 22 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: build_handoff build_recipe check_my_ui compare_screens find_related_screens get_design get_flow get_motion get_motion_guidelines get_product get_screen get_screen_image list_flows list_products list_tags name_patterns pick_reference search_logos search_motion search_names search_screens wait_for_pick
build_handoff | Generate a complete build prompt for a coding agent: ordered screens with notes, observed
transitions, links to up to 10 agent-sized images (1x copies and page-section crops, never
taller than 8000px, each with its pixel size), 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 params: referenceId*, goal, stack, screens, includeDesign |
build_recipe | Combine specific screens from different products, plus one visual style, into a single build
brief. Each screen contributes one thing (say what with "id: what to take"); structure comes from
the screens and every visual token comes from the chosen style, so conflicting looks are resolved
instead of mixed. Returns the brief as Markdown with the screenshots attached. When the screens
contain interac params: screens*, style, styleContext, styleNotes, goal, stack |
check_my_ui | 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, a params: description*, screenType, sections, flowSteps, flowType, primaryAction, planCount, kind, product, limit |
compare_screens | 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 pa params: screenA*, screenB, targetDescription, focus |
find_related_screens | 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 result says why it matched.
Use this after finding one good reference, to show the user how other products handle the
same screen, e.g. other empty project lists, other pricing pages with a comp params: screenId*, limit, kind, sameProduct |
get_design | 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. params: productId*, context |
get_flow | 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 params: productId* |
get_motion | Get one motion entry as a build prompt: what moves and how (every property, duration, easing
curve or spring, delay and trigger), why it feels good, what a rebuild must keep, Screenrove's
working vanilla HTML/CSS/JS implementation, and the original source code when its license
allows. Values are marked as exact (from code) or approximate (measured from a recording).
Use the numbers as given and t params: motionId*, code |
get_motion_guidelines | Get house rules for UI motion (durations, which easing for enter and exit, springs, what to
animate, reduced motion) with citations, plus ready-to-use duration and easing tokens, the
motion library's sources and its category and trigger vocabulary.
Read this once before adding animation to an interface, so new motion is consistent. params: none |
get_product | 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. params: productId* |
get_screen | 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. params: screenId* |
get_screen_image | 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. params: screenId*, size |
list_flows | 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. params: flowType |
list_products | 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. params: none |
list_tags | 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 searchScreens or pickReference, e.g. pattern=board-view or state=empty. params: facet |
name_patterns | Summarise how real products are named: each naming pattern with its share and examples, the
commonest TLDs, domain styles, length and syllable distributions, and a per-category table
(top TLD, share on .ai, share on the exact .com, top pattern, average length), with
plain-language highlights such as the share of AI tools on .ai. Takes the same filters as
searchNames, so it can describe one slice ( params: category, pattern, tld, length, startsWith, source |
pick_reference | 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 wai params: q, screens, product, kind, task, pattern, component, state, count, goal, stack |
search_logos | Search the logos of the products in Screenrove's library, as references for designing a
logo or app icon. Each logo is the product's own mark as its site serves it (SVG icon,
apple-touch-icon or large favicon; never redrawn), linked to its collection, with observed
traits: mark type (symbol, lettermark, wordmark, combination), colours sampled from the file
with colour families, shape (square tile, params: q, product, markType, colour, shape, category, lowercase, includeMissing, limit |
search_motion | Search the motion library: polished UI animations and micro-interactions (button presses,
toggles, toasts, number tickers, thinking states, hover effects, interaction sounds) curated
from open-source component libraries and designers' recordings. Each entry has a precise
motion spec (properties, durations, easing curves or spring constants, staggers) and most
have a live demo with vanilla HTML/CSS params: q, category, trigger, source, basis, hasCode, limit |
search_names | Search about 700 real product names - Screenrove's library plus a curated list of products on
Mobbin and Refero - each with its domain and TLD, category and derived traits: naming
pattern (real-word, compound, blend, altered, suffix, prefix, acronym, alphanumeric,
person-place, brand-extension, invented), length, syllables, whether it starts with a vowel,
casing, and domain style (exact, prefixed params: q, pattern, tld, category, length, syllables, startsWith, domainStyle, source, sort, limit |
search_screens | Search the UI reference catalog by design problem and keyword. Every screen is tagged on four
facets: task (what the person is doing), pattern (screen archetype), component (building blocks)
and state (empty, filtered, error...). Filter by any of them; commas mean OR within a facet and
different facets combine with AND, e.g. pattern=list-view,table-view and state=empty. Tags accept
ids, labels or params: q, task, pattern, component, state, scope, product, kind, limit |
wait_for_pick | 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. params: pickId*, wait |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.