Screenrove

Let the user pick a reference

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.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Search words, e.g. "pricing page", "onboarding", "empty state". The best matches become the options.
`goal`	No	What the user is building, shown on the page and used in the build prompt, e.g. "NSDR premium upgrade page".
`kind`	No	Only search this kind of screen.
`count`	No	How many options to show when searching, 2 to 6.
`stack`	No	Preferred stack for the build prompt.
`product`	No	Only search this product id.
`screens`	No	Comma-separated screen ids to show instead of searching, e.g. from an earlier searchScreens.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No	Open this for the user.
`next`	No	What to do next.
`pickId`	No
`status`	No
`options`	No
`canvasUrl`	No	Experimental pan-and-zoom canvas view of the same pick.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / q / description

Previous value: -"Search words, e.g. \"pricing page\". The best matches become the options."New value: +"Search words, e.g. \"pricing page\", \"onboarding\", \"empty state\". The best matches become the options."

Changed1 schema field changedSep 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "canvasUrl": {
+      "description": "Experimental pan-and-zoom canvas view of the same pick.",
+      "type": "string"
+    },
+    "next": {
+      "description": "What to do next.",
+      "type": "string"
+    },
+    "options": {
+      "items": {
+        "properties": {
+          "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"
+          },
+          "notes": {
+            "type": "string"
+          },
+          "previewUrl": {
+            "description": "Screen-sized preview (the top of long pages). Present on pick options.",
+            "type": "string"
+          },
+          "product": {
+            "type": "string"
+          },
+          "productName": {
+            "description": "Present on pick options.",
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pickId": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "pending"
+      ],
+      "type": "string"
+    },
+    "url": {
+      "description": "Open this for the user.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=false, destructiveHint=false, and the description is consistent with that (it opens a picker session and returns a URL). It adds useful behavioural context beyond the annotations: the picker renders real screenshots at scroll depth, it opens in the user's browser, and it yields a pickId that must be consumed by waitForPick. It omits session lifetime/expiry and what happens on repeat calls, so it falls short of a 5.

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

Conciseness5/5

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

Three short, front-loaded paragraphs: what happens, when to prefer it, and what to do next. Every sentence earns its place with no restatement of the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description still correctly flags that it returns a URL to open. Combined with the usage rule and the waitForPick handoff, an agent has everything needed to call it and continue the workflow.

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% and every parameter is already well documented there, so the baseline is 3. The description adds no parameter-level detail (e.g. the q/count interaction or how screens bypasses searching) and only references pickId, which is an output rather than an input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb plus resource ('Show the user several matching UI references side by side') and its effect (a picker the user clicks, returning a URL). It is clearly separable from siblings like get_screen_image, compare_screens and search_screens because it is framed around user selection rather than retrieval.

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

Usage Guidelines5/5

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

Explicitly says when to prefer it ('Prefer this over sending full-page images whenever the user should decide which reference to use') and gives the matching follow-up ('call waitForPick with the pickId'). It names both the alternative and the downstream step, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Screenrove tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?