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

Compare two screens

compare_screens

Read-only

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

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": {
      "screenA": "<screenA>"
    },
    "name": "compare_screens"
  }
}

Input Schema

Name	Required	Description	Default
`focus`	No	What aspects to emphasize in the comparison.	all
`screenA`	Yes	First screen id to compare, e.g. linear-marketing-pricing.
`screenB`	No	Second screen id to compare. If omitted, provide targetDescription instead.
`targetDescription`	No	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".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "differences": {
-      "description": "How the two screens differ.",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "observations": {
-      "description": "Design observations and takeaways from the comparison.",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "report": {
-      "description": "Markdown summary of the comparison between the two screens.",
-      "type": "string"
-    },
-    "screenA": {
-      "description": "Details about the first screen.",
-      "properties": {
-        "actionCount": {
-          "type": "integer"
-        },
-        "height": {
-          "type": "integer"
-        },
-        "id": {
-          "type": "string"
-        },
-        "imageUrl": {
-          "type": "string"
-        },
-        "kind": {
-          "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
-          "enum": [
-            "flow",
-            "marketing",
-            "product"
-          ],
-          "type": "string"
-        },
-        "previewUrl": {
-          "type": "string"
-        },
-        "product": {
-          "type": "string"
-        },
-        "productName": {
-          "type": "string"
-        },
-        "screenType": {
-          "type": "string"
-        },
-        "sectionCount": {
-          "type": "integer"
-        },
-        "title": {
-          "type": "string"
-        },
-        "width": {
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "screenB": {
-      "description": "Details about the second screen (null if comparing against targetDescription).",
-      "nullable": true,
-      "properties": {
-        "actionCount": {
-          "type": "integer"
-        },
-        "height": {
-          "type": "integer"
-        },
-        "id": {
-          "type": "string"
-        },
-        "imageUrl": {
-          "type": "string"
-        },
-        "kind": {
-          "description": "flow is an onboarding step, marketing a public web page, product an in-app screen.",
-          "enum": [
-            "flow",
-            "marketing",
-            "product"
-          ],
-          "type": "string"
-        },
-        "previewUrl": {
-          "type": "string"
-        },
-        "product": {
-          "type": "string"
-        },
-        "productName": {
-          "type": "string"
-        },
-        "screenType": {
-          "type": "string"
-        },
-        "sectionCount": {
-          "type": "integer"
-        },
-        "title": {
-          "type": "string"
-        },
-        "width": {
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "similarities": {
-      "description": "What the two screens have in common.",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "targetDescription": {
-      "description": "The target description if comparing against text instead of screenB.",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

AddedSep 30, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the informational scope of the comparison but says nothing about cost, latency, or result shape; it is a safe read with no surprises, so a 3 is appropriate.

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?

A single sentence, front-loaded with the verb and resource, with the parenthetical list and examples earning their place by defining comparison scope. Slightly dense but free of boilerplate or repetition.

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?

There is no output schema, so the description must convey what the comparison yields; the enumeration of compared facets (types, sections, actions, dimensions, plan counts) does that adequately. The dual input mode is also covered, leaving little an agent needs that is missing.

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 description coverage is 100%, so the schema already documents all four parameters including the enum and the screenB/targetDescription alternation. The description's examples reinforce those semantics but add nothing new beyond what the schema states, so baseline 3 applies.

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?

Names a specific verb+resource ('compare two screens side by side') and enumerates exactly what is compared (screen types, sections, actions, dimensions, plan counts). The two concrete examples clarify the scope, though it never names a sibling such as get_screen or find_related_screens to differentiate itself explicitly.

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?

The two worked examples (Linear pricing vs Stripe pricing; screenA vs a targetDescription) imply when the tool is appropriate, and the screenB-vs-targetDescription split hints at two modes. But there is no explicit when-not guidance and no pointer to alternative sibling tools, so usage must be inferred.

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?