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

List captured products

list_products

Read-only

List the 191 products in the catalog, one compact line each: id, name, category, a one-line coverageLabel saying what was captured (signed in or logged out only), screen counts and page url. Paged (50 by default) and filterable by category or q; the first page also counts products per category. To find screens, search_screens is quicker.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_products"
  }
}

Input Schema

Name	Required	Description	Default
`q`	No	Words in the product's name, category or description.
`limit`	No	Products per page, 1 to 200.
`detail`	No	full adds description, tags and source.	brief
`offset`	No	Results to skip; pass nextOffset from the previous page.
`category`	No	A category or part of one, e.g. "Developer tools" or "finance".

Output Schema

Name	Required	Description	Default
`next`	No
`limit`	No
`notes`	No
`total`	No
`offset`	No
`products`	No
`categories`	No
`nextOffset`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 30, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "A category or part of one, e.g. \"Developer tools\" or \"finance\".",
+  "type": "string"
+}

addedInput schema / properties / detail

Added value: +{
+  "default": "brief",
+  "description": "full adds description, tags and source.",
+  "enum": [
+    "brief",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 50,
+  "description": "Products per page, 1 to 200.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Results to skip; pass nextOffset from the previous page.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / q

Added value: +{
+  "description": "Words in the product's name, category or description.",
+  "type": "string"
+}

addedOutput schema / properties / categories
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / limit
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / next
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / nextOffset
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / notes
```
Added value: +{
+  "type": "array"
+}
```
addedOutput schema / properties / offset
```
Added value: +{
+  "type": "integer"
+}
```

removedOutput schema / properties / products / items

Removed value: -{
-  "properties": {
-    "captured": {
-      "format": "date",
-      "type": "string"
-    },
-    "counts": {
-      "description": "A flow step can show the same screenshot as a product or marketing screen (same id), so the per-kind counts can add up to more than screenshots.",
-      "properties": {
-        "flow": {
-          "type": "integer"
-        },
-        "marketing": {
-          "type": "integer"
-        },
-        "product": {
-          "type": "integer"
-        },
-        "screenshots": {
-          "description": "Distinct screenshots in the collection.",
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "description": {
-      "type": "string"
-    },
-    "id": {
-      "type": "string"
-    },
-    "name": {
-      "type": "string"
-    },
-    "scope": {
-      "description": "What was captured. marketing: logged-out marketing pages only. public-demo: logged out, but real\nproduct surfaces or public demos were used. task-incomplete: signed in, but the journey stops before\nits result. signed-in: signed in, and the journey reaches its result.\n",
-      "enum": [
-        "marketing",
-        "public-demo",
-        "task-incomplete",
-        "signed-in"
-      ],
-      "type": "string"
-    },
-    "scopeLabel": {
-      "description": "Scope in words: Marketing only, Public demo, Task incomplete or Signed in.",
-      "type": "string"
-    },
-    "source": {
-      "type": "string"
-    },
-    "tags": {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "url": {
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

addedOutput schema / properties / total
```
Added value: +{
+  "type": "integer"
+}
```

Changed4 schema fields changedOct 22, 2026

addedOutput schema / properties / products / items / properties / counts / description

Added value: +"A flow step can show the same screenshot as a product or marketing screen (same id), so the per-kind counts can add up to more than screenshots."

addedOutput schema / properties / products / items / properties / counts / properties / screenshots

Added value: +{
+  "description": "Distinct screenshots in the collection.",
+  "type": "integer"
+}

addedOutput schema / properties / products / items / properties / scope

Added value: +{
+  "description": "What was captured. marketing: logged-out marketing pages only. public-demo: logged out, but real\nproduct surfaces or public demos were used. task-incomplete: signed in, but the journey stops before\nits result. signed-in: signed in, and the journey reaches its result.\n",
+  "enum": [
+    "marketing",
+    "public-demo",
+    "task-incomplete",
+    "signed-in"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / products / items / properties / scopeLabel

Added value: +{
+  "description": "Scope in words: Marketing only, Public demo, Task incomplete or Signed in.",
+  "type": "string"
+}

Changed1 schema field changedSep 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "products": {
+      "items": {
+        "properties": {
+          "captured": {
+            "format": "date",
+            "type": "string"
+          },
+          "counts": {
+            "properties": {
+              "flow": {
+                "type": "integer"
+              },
+              "marketing": {
+                "type": "integer"
+              },
+              "product": {
+                "type": "integer"
+              }
+            },
+            "type": "object"
+          },
+          "description": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "tags": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedSep 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: default page size, that the first page carries category counts, and what coverageLabel signifies (signed in vs logged out only). It stops short of stating whether results are cached or how paging terminates beyond the implicit offset.

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?

Three dense sentences, front-loaded with the resource and its count, then output shape, then paging/filtering, then the sibling redirect. Nothing is wasted, though the row-contents enumeration is packed tightly enough to read as a run-on.

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?

For a read-only, zero-required-parameter list tool with a full output schema and 100% schema coverage, the description covers purpose, output shape, paging, filtering and the sibling alternative. Nothing an agent needs in order to call it correctly 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 q, limit, offset, category and the brief/full enum. The description reinforces filtering and the 50-per-page default but adds no syntax or semantics not already in the schema, and it never mentions the detail=full mode. Baseline 3 applies.

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 and resource ("List the 191 products in the catalog") and immediately defines the shape of each row (id, name, category, coverageLabel, screen counts, page url). It also distinguishes itself from search_screens, so an agent can route between them without opening a schema.

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?

Gives clear operating context: paged at 50 by default, filterable by category or q, first page also aggregates per-category counts. It names the alternative (search_screens) for screen discovery, but does not contrast against siblings like get_product or list_flows, so the when-not coverage is partial.

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?