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

Build an agent handoff prompt

build_handoff

Read-only

Build one product's reference as a complete prompt: ordered screens with notes, observed transitions, links to up to 10 agent-sized images (1x copies and section crops, each with its pixel size), the measured design guide and an implementation checklist; the same prompt as the site's "Use in agent" button. referenceId is {product}-onboarding (its flow), {product}-collection (everything) or one screen id. To combine screens from several products, use build_recipe.

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": {
      "referenceId": "<referenceId>"
    },
    "name": "build_handoff"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "manifest": {
-      "description": "Versioned reference manifest",
-      "type": "object"
-    },
-    "prompt": {
-      "description": "Markdown prompt to follow or paste into an agent.",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

Changed1 schema field changedSep 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "manifest": {
+      "description": "Versioned reference manifest",
+      "type": "object"
+    },
+    "prompt": {
+      "description": "Markdown prompt to follow or paste into an agent.",
+      "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 already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower, but the description still adds real context: the output is a ready-to-use prompt, includes up to 10 agent-sized images (1x copies and section crops with pixel sizes), and mirrors the site's 'Use in agent' button. It doesn't mention performance or size limits beyond the 10-image cap.

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?

Two sentences, front-loaded with the operation and its output contents before the sibling routing note. The first sentence is long and list-heavy but every clause carries distinct information; no filler.

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?

With no output schema, the description carries the burden of describing the return value, and it does so concretely (prompt contents, image links and sizes, checklist). The input side is fully documented via schema. Only minor gaps remain around limits and what happens with an invalid referenceId.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: the referenceId naming grammar (`{product}-onboarding` for a flow, `{product}-collection` for everything, or a single screen id). The other params (goal, stack, screens, includeDesign) are left to their schema descriptions.

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?

Specific verb (build) plus resource (a product's reference as a complete prompt) and an enumerated contents list: ordered screens, notes, transitions, image links, design guide, checklist. It also names build_recipe as the sibling it is not, so an agent can route without opening either schema.

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 states the alternative and the condition that selects it ('To combine screens from several products, use build_recipe'), and clarifies the three valid referenceId forms so the caller picks the right scope. The only minor omission is a 'when not to use' exclusion beyond build_recipe.

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?