Screenrove

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Real product UI captures (onboarding, pricing, in-app screens) with design guides for coding agents.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "Screenrove": {
      "url": "https://screenrove.com/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (22)

• build_handoff read-only

  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 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.

  Parameters:

  • referenceId (required) — string — e.g. linear-onboarding, stripe-collection or vercel-marketing-pricing.
  • goal — string — What you want to build. Goes at the top of the prompt.
  • stack — string — Preferred stack, e.g. Next.js and Tailwind.
  • screens — string — Comma-separated screen ids to keep. Omit to include every screen in the reference.
  • includeDesign — boolean — Include the observed design guide. Set false to use your project's own design system.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• build_recipe read-only

  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 interactive components (modals, tabs, toggles, toasts, forms), the brief also lists matching entries from the motion library to fetch with getMotion. Use this when the user wants, say, Linear's issue composer, Vercel's pricing layout and Notion's visual language in one screen. Find screen ids with searchScreens or findRelatedScreens first. For one product's whole flow or collection, use buildHandoff instead.

  Parameters:

  • screens (required) — array — 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"].
  • goal — string — What you want to build. Goes at the top of the brief.
  • stack — string — Preferred stack, e.g. Next.js and Tailwind.
  • style — string — Product id whose measured visual language to use, e.g. linear or stripe. Omit to use the project's own design system.
  • styleNotes — string — Extra visual direction in words, e.g. "our brand green #1a7f37, rounded corners". Used on its own when style is omitted.
  • styleContext — string — Which of the style product's guides to use. Defaults to marketing when most screens are marketing pages, otherwise product.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• check_my_ui read-only

  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.

  Parameters:

  • description (required) — string — 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".
  • kind — string — Only compare with this kind of capture.
  • limit — number — How many references to return, 1 to 5.
  • product — string — Only compare with this product id.
  • flowType — string — What the flow does, so step counts are only compared with flows of the same kind. Inferred from screenType when omitted.
  • sections — array — Page sections top to bottom, e.g. ["Hero", "Plan cards", "FAQ"].
  • flowSteps — array — For a multi-screen flow, each step's title in order, e.g. ["Sign up", "Verify email", "Create workspace"].
  • planCount — number — For pricing screens, how many plans are shown.
  • screenType — string — What kind of screen it is.
  • primaryAction — string — The main button or action, e.g. "Start free trial".

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• compare_screens read-only

  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.

  Parameters:

  • screenA (required) — string — First screen id to compare, e.g. linear-marketing-pricing.
  • focus — string — What aspects to emphasize in the comparison.
  • screenB — string — Second screen id to compare. If omitted, provide targetDescription instead.
  • targetDescription — string — 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".

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• find_related_screens read-only

  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 comparison table, or other create-issue modals.

  Parameters:

  • screenId (required) — string — Screen id from searchScreens or getProduct, e.g. linear-signup.
  • kind — string — Only return this kind of screen.
  • limit — number — Maximum results, 1 to 20.
  • sameProduct — boolean — Also include screens from the same product.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_design read-only

  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.

  Parameters:

  • productId (required) — string — Product id from listProducts, e.g. linear, stripe or airbnb.
  • context — string — Which surface to return. Omit for both.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_flow read-only

  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.

  Parameters:

  • productId (required) — string — Product id from listProducts, e.g. linear, stripe or airbnb.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_motion read-only

  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 translate the code to the project's stack.

  Parameters:

  • motionId (required) — string — Motion entry id from searchMotion, e.g. interior-copy-button.
  • code — string — Which code to include - both, vanilla (Screenrove rebuild), original (source library) or none.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_motion_guidelines read-only

  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.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_product read-only

  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.

  Parameters:

  • productId (required) — string — Product id from listProducts, e.g. linear, stripe or airbnb.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_screen read-only

  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.

  Parameters:

  • screenId (required) — string — Screen id from searchScreens or getProduct, e.g. linear-signup.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• get_screen_image read-only

  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.

  Parameters:

  • screenId (required) — string — Screen id from searchScreens or getProduct, e.g. linear-signup.
  • size — string — preview (default) keeps images small enough to view; full returns the original capture.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• list_flows read-only

  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.

  Parameters:

  • flowType — string — Only return flows of this type.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• list_products read-only

  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.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• list_tags read-only

  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.

  Parameters:

  • facet — string — Only return this facet.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• name_patterns read-only

  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 ("category=Developer tools"). Use this before proposing names, to know what is common (and what would stand out) in the user's category.

  Parameters:

  • tld — string — Comma-separated TLDs (OR).
  • length — string — Letters in the name - a number or a range like 4-6.
  • source — string — library or targets.
  • pattern — string — Comma-separated naming patterns (OR) to summarise.
  • category — string — Comma-separated categories (OR) to summarise, e.g. "AI tools".
  • startsWith — string — Letters the name starts with, or vowel or consonant.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• 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 waitForPick with the pickId to get their choice and a complete build prompt.

  Parameters:

  • q — string — Search words, e.g. "pricing page", "onboarding", "empty state". The best matches become the options. Can be combined with tag filters, or left out when tag filters are given.
  • goal — string — What the user is building, shown on the page and used in the build prompt, e.g. "NSDR premium upgrade page".
  • kind — string — Only search this kind of screen.
  • task — string — Tag filter, as in searchScreens, e.g. create.
  • count — number — How many options to show when searching, 2 to 6.
  • stack — string — Preferred stack for the build prompt.
  • state — string — Tag filter, as in searchScreens, e.g. empty.
  • pattern — string — Tag filter, as in searchScreens, e.g. pricing-page.
  • product — string — Only search this product id.
  • screens — string — Comma-separated screen ids to show instead of searching, e.g. from an earlier searchScreens.
  • component — string — Tag filter, as in searchScreens, e.g. comparison-table.

  Hints: read-only no · destructive no · idempotent no · open-world no

• search_logos read-only

  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, rounded tile, circle, freeform), whether its letters are lowercase, the brand font and accent from the product's measured design guide, and its category. Use this for logo references: "lettermarks on a rounded tile", "green symbols", "how do developer tools' icons look". Logos are trademarks of their owners: study them, don't copy them.

  Parameters:

  • q — string — Keywords matched against product name, id, category and brand font.
  • limit — number — Maximum results, 1 to 169.
  • shape — string — Comma-separated shapes (OR) - square tile, rounded tile, circle, freeform.
  • colour — string — Comma-separated colour families (OR) - red, orange, yellow, green, teal, blue, purple, pink, brown, black, white, grey, or mono for single-colour glyphs that carry no colour.
  • product — string — Comma-separated product ids or names, e.g. linear,stripe.
  • category — string — Comma-separated categories (OR), e.g. "Developer tools", or "ai" for both AI categories.
  • markType — string — Comma-separated mark types (OR) - symbol, lettermark, wordmark, combination.
  • lowercase — boolean — Only letter-based marks whose letters are lowercase (true) or capitals (false).
  • includeMissing — boolean — Also list the library products that have no logo in the directory yet.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• search_motion read-only

  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/JS code. Use this whenever you build or polish an interactive element and want it to feel finished: "a satisfying copy button", "toast stack", "AI thinking indicator", "tab underline that slides". Then call getMotion for the spec, code and a build prompt.

  Parameters:

  • q — string — Keywords, e.g. "copy button", "toast", "number ticker", "thinking shimmer".
  • basis — string — Where the numbers come from - code (exact, read from source), video (measured from a recording) or rebuild.
  • limit — number — Maximum results, 1 to 50.
  • source — string — Comma-separated source ids, as listed by getMotionGuidelines.
  • hasCode — boolean — Only entries with working code (a vanilla rebuild or original source).
  • trigger — string — Comma-separated triggers (OR) - hover, press, click, focus, load, scroll, drag, state-change, loop, type.
  • category — string — Comma-separated categories (OR): button, toggle, input, list, card, navigation, overlay, toast, loader, text, number, chat-ai, cursor, scroll, transition, icon, feedback, media, sound, other.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• search_names read-only

  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 like getX.com, suffixed like Xhq.com, domain-hack, subdomain, partial, different). Returns stats for the whole matching set too. Use this for naming ideas grounded in real product names: "short invented names for AI tools on .ai", "two-syllable real-word names", "compound names in finance". Traits are heuristics with hand-checked overrides; check trademarks and domains before using a new name.

  Parameters:

  • q — string — Words matched against the name, domain and the product's own one-line description.
  • tld — string — Comma-separated TLDs (OR), e.g. ai,io or .com.
  • sort — string — Order of results - name, length or syllables (shortest first).
  • limit — number — Maximum names, 1 to 500.
  • length — string — Letters in the name (spaces and punctuation not counted) - a number or a range like 4-6, -6 or 8-.
  • source — string — library (products Screenrove has captured) or targets (the Mobbin/Refero list).
  • pattern — string — Comma-separated naming patterns (OR) - real-word, compound, blend, altered, suffix, prefix, acronym, alphanumeric, person-place, brand-extension, invented.
  • category — string — Comma-separated categories (OR), e.g. "AI tools", "Developer tools" or "finance".
  • syllables — string — Syllables - a number or a range like 1-2.
  • startsWith — string — Letters the name starts with, or vowel or consonant.
  • domainStyle — string — Comma-separated domain styles (OR) - exact, prefixed, suffixed, domain-hack, subdomain, partial, different.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• search_screens read-only

  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 aliases ("kanban", "zero state"); listTags shows the vocabulary. q matches titles, tags, notes, page sections and observed actions; every word must match, or the closest partial matches come back with partial=true. Filter by product, kind or scope too. Use this to find design pattern examples like empty states, pricing pages, kanban boards, onboarding steps, settings or create forms. Results carry each screen's tags; refine lists the most common other tags among the results so you can narrow down. Pass a result's id to getScreenImage to see it, or findRelatedScreens for the same problem in other products. When the user wants screens combined, or a brief or spec built from several references, call buildRecipe with the chosen screen ids.

  Parameters:

  • q — string — Keywords to match, e.g. "pricing page", "empty state", "onboarding". Omit to list everything that matches the filters.
  • kind — string — Only return this kind of screen.
  • task — string — What the person is trying to do, comma-separated for any of them, e.g. create, choose-plan, invite.
  • limit — number — Maximum results, 1 to 50.
  • scope — string — Only screens from collections with this capture scope.
  • state — string — Data or interaction state, comma-separated for any of them, e.g. empty, first-run, filtered, error.
  • pattern — string — Screen archetype, comma-separated for any of them, e.g. pricing-page, list-view, board-view, settings.
  • product — string — Only return screens from this product id, e.g. linear, stripe, airbnb.
  • component — string — Building blocks on the screen, comma-separated for any of them, e.g. modal, date-picker, comparison-table.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

• wait_for_pick read-only

  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.

  Parameters:

  • pickId (required) — string — The pickId returned by pickReference.
  • wait — number — Seconds to wait for a choice, 0 to 50.

  Hints: read-only yes · destructive no · idempotent not declared · open-world no

Publisher website

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.