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

Get a screen's screenshot

get_screen_image

Read-only

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.

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": {
      "screenId": "<screenId>"
    },
    "name": "get_screen_image"
  }
}

Input Schema

Name	Required	Description	Default
`size`	No	preview (1x) or full (the original).	preview
`section`	No	One section of a long page, by number or title words, as a 1x crop.
`screenId`	Yes	Screen id from search_screens or get_product, e.g. linear-signup.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / screenId / description

Previous value: -"Screen id from searchScreens or getProduct, e.g. linear-signup."New value: +"Screen id from search_screens or get_product, e.g. linear-signup."

addedInput schema / properties / section

Added value: +{
+  "description": "One section of a long page, by number or title words, as a 1x crop.",
+  "type": "string"
+}

changedInput schema / properties / size / description

Previous value: -"preview (default) keeps images small enough to view; full returns the original capture."New value: +"preview (1x) or full (the original)."

First observedSep 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish a safe read-only, closed-world operation, and the description adds genuinely new behavior: preview is 1x, full is often 2x, and full is refused above 8000 px tall. The only gap is the return shape (image plus accompanying text) which is only obliquely mentioned.

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

Conciseness4/5

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

The action and the main call-to-action are front-loaded in the first clause, and each following sentence covers scale, size limits, or section cropping without padding. The telegraphic style ("The text gives its pixel size and a long page's sections") is slightly cryptic and costs some readability.

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 three-parameter read tool with full annotations and no output schema, the description covers what is returned (image plus a text block with pixel size and section list), the two size modes, and the hard size limit. Only the exact response structure remains implicit.

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% and the field docs already explain preview/full and section crops. The description adds only the useful interpretive note that 1 image px equals 1 CSS px at preview scale; everything else restates the schema.

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?

"See the screen" plus the tool name makes clear this returns a rendered image of a screen, and the pixel-scale details distinguish it from screenshot-free siblings. It never explicitly contrasts with get_screen, so an agent must infer that this is the visual counterpart to that metadata tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"call it on your top picks before writing UI" gives a concrete usage context and ordering (after picking, before implementing). No exclusions or named alternatives (get_screen, compare_screens) are given, so the routing is inferred rather than explicit.

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?