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

Search the logo directory

search_logos

Read-only

Logo references for designing a logo or app icon: each library product's own mark as its site serves it (never redrawn) with mark type, colours, shape, letter case, brand font and category, e.g. "lettermarks on a rounded tile", "green symbols". Logos are trademarks of their owners: study them, don't copy them.

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": "search_logos"
  }
}

Input Schema

Name	Required	Description
`q`	No	Words matched against product name, id, category and brand font; any word can match. More matched words rank first, then a name or category match above a font match, and rarer words above common ones.
`limit`	No	Maximum results, 1 to 169.
`shape`	No	Comma-separated shapes (OR) - square tile, rounded tile, circle, freeform.
`colour`	No	Comma-separated colour families (OR) - red, orange, yellow, green, teal, blue, purple, pink, brown, black, white, grey, or mono for single-colour glyphs that carry no colour.
`product`	No	Comma-separated product ids or names, e.g. linear,stripe.
`category`	No	Comma-separated categories (OR), e.g. "Developer tools", or "ai" for both AI categories.
`markType`	No	Comma-separated mark types (OR) - symbol, lettermark, wordmark, combination.
`lowercase`	No	Only letter-based marks whose letters are lowercase (true) or capitals (false).
`includeMissing`	No	Also list the library products that have no logo in the directory yet.

Output Schema

Name	Required	Description	Default
`note`	No
`logos`	No
`total`	No
`counts`	No
`filters`	No
`message`	No
`missing`	No
`directory`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / q / description

Previous value: -"Words matched against product name, id, category and brand font; any word can match, more matches rank first."New value: +"Words matched against product name, id, category and brand font; any word can match. More matched words rank first, then a name or category match above a font match, and rarer words above common ones."

Changed7 schema fields changedOct 30, 2026

addedInput schema / properties / limit / maximum
```
Added value: +169
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

changedInput schema / properties / q / description

Previous value: -"Keywords matched against product name, id, category and brand font."New value: +"Words matched against product name, id, category and brand font; any word can match, more matches rank first."

removedOutput schema / properties / counts / description
```
Removed value: -"Matches by markType"
```

removedOutput schema / properties / logos / items

Removed value: -{
-  "properties": {
-    "accent": {
-      "nullable": true,
-      "type": "string"
-    },
-    "category": {
-      "type": "string"
-    },
-    "collectionUrl": {
-      "type": "string"
-    },
-    "colours": {
-      "items": {
-        "properties": {
-          "family": {
-            "type": "string"
-          },
-          "hex": {
-            "type": "string"
-          },
-          "share": {
-            "type": "number"
-          }
-        },
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "families": {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "font": {
-      "description": "Brand font from the product's design guide.",
-      "type": "string"
-    },
-    "format": {
-      "enum": [
-        "svg",
-        "png"
-      ],
-      "type": "string"
-    },
-    "id": {
-      "description": "Collection id.",
-      "type": "string"
-    },
-    "logoUrl": {
-      "description": "The logo file (SVG or PNG).",
-      "type": "string"
-    },
-    "lowercase": {
-      "description": "For letter-based marks",
-      "nullable": true,
-      "type": "boolean"
-    },
-    "mark": {
-      "enum": [
-        "symbol",
-        "lettermark",
-        "wordmark",
-        "combination"
-      ],
-      "type": "string"
-    },
-    "name": {
-      "type": "string"
-    },
-    "primary": {
-      "description": "The first colour that isn't black",
-      "nullable": true,
-      "type": "string"
-    },
-    "shape": {
-      "enum": [
-        "square tile",
-        "rounded tile",
-        "circle",
-        "freeform"
-      ],
-      "type": "string"
-    },
-    "source": {
-      "description": "Where the file was fetched from.",
-      "nullable": true,
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

removedOutput schema / properties / missing / items
```
Removed value: -{
-  "type": "object"
-}
```

AddedOct 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld=false/non-destructive, so the description is freed to add provenance and legal context: marks are served as the site serves them and never redrawn, plus an explicit trademark restriction on reuse. That is real information beyond the structured fields; only the absence of any result/pagination behavior keeps it from 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.

Conciseness4/5

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

Two sentences, front-loaded with purpose and closed with the licensing constraint; every clause carries information. The first sentence is dense with stacked parentheticals, which costs it a point on 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 nine-parameter search tool, the annotations, a fully described schema, and an output schema together cover safety and return format, and the description supplies the domain framing and legal constraint. The remaining gap is sibling routing, which is scored under usage guidelines.

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 the q parameter's ranking rules are fully documented there. The description's quoted phrases ("lettermarks on a rounded tile", "green symbols") are illustrative of output, not of how to combine the nine parameters, so it adds little over the schema and the 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?

The description states a specific resource (logo references, one per library product's own mark) and enumerates the attached attributes (mark type, colours, shape, letter case, brand font, category), which clearly separates it from siblings like search_screens or search_motion. It does not explicitly name or contrast those siblings, so it falls short of a 5.

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?

"For designing a logo or app icon" implies the use case, but there is no explicit when-to-use versus when-not, and no alternative tool is referenced even though pick_reference and search_screens appear to be adjacent choices. The trademark caveat guides downstream use rather than tool selection.

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?