Search Screens
search_screensSearch Mobbin for UI screens using natural language. Returns matching screens with inline images and metadata. Examine the returned images to understand each screen's actual content — do not describe or summarize screens based solely on metadata. Each screen has a mobbin_url — the canonical Mobbin link for that screen. When you present results to the user, ALWAYS cite each screen you mention as a markdown link to its mobbin_url so the user can open it on Mobbin. Inline images are low-res previews for you to read, not for the user. Each result's image_url is the high-resolution image. Whenever the user wants to save, export, embed, or paste a result (files, Figma, Notion, docs, slides), download it from image_url instead of reusing the inline preview. Image URLs expire after 30 days, so download the file rather than linking to it; link to mobbin_url when citing. If the result contains ai_usage_notice, show its text markdown to the user word for word, as its own block after the results, keeping its formatting and line breaks. Do not paraphrase, shorten, or merge it with other text. On hosts that support MCP Apps, also renders an interactive gallery of the results.
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": {
"platform": "<platform>",
"query": "<query>"
},
"name": "search_screens"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Search mode. "standard" returns results with low latency. "deep" uses an AI-powered pipeline that interprets intent and scores each candidate for relevance, keeping the strong matches — ideal for nuanced queries. "fast" is a deprecated alias for "standard" and will be removed in a future version — use "standard" instead. | deep |
| limit | No | Maximum number of screens to return. Higher number of screens returned causes increased context usage. | |
| query | Yes | Describe one screen in plain language: what kind of screen it is ("paywall", "settings screen"), with the kind of app when the user names one ("social app", "banking app"). The kind of app is part of the request, so include it in the query. Add a state or UI element only when the user asked for it or their problem depends on it: each one narrows the results. Good: "social app profile screen", "checkout page with promo code field and Apple Pay button". Avoid: combining multiple screens/intents (search separately), parts the user didn't ask for ("social app profile screen with avatar and follower counts"), vague style words ("modern", "clean"), disconnected keyword lists. Name a specific app to filter results to it (e.g. "Spotify now-playing screen"). Do not include platform (ios/web) — use the dedicated parameter. | |
| platform | Yes | Platform to search | |
| output_tool | No | The product the results go into next, not a later step, if known, e.g. Figma, Paper, Notion. Product name only. When the results go into more than one product, name the one the user asked for first. Not the search source: Mobbin only when the results go back to Mobbin. Omit when unknown. MUST be the same across all calls for the same task. | |
| task_intent | No | One short sentence summarizing the user's overall task. Helps return more relevant results. Write it in English even when the conversation is in another language. MUST be the same across all calls for the same task. Do NOT include verbatim user messages, conversation history, file contents, or personal data. | |
| image_format | No | Image format. Use jpg if your client does not support webp. | webp |
| exclude_screen_ids | No | Screen IDs to exclude from results | |
| output_destination | No | What you will do with the results after this call. Choose by what gets made with the results, not by the search itself. When the request does not say, go by where you are running: a coding agent in a repository means `code`, a design tool means `design_tool`, a plain chat host means `chat`. Helps return results in the form the workflow needs. `code`: implement or change UI in a codebase or coded prototype, also when looking up examples to base it on first, e.g. React, Swift, HTML/CSS, v0, Lovable. `design_tool`: recreate or put results on a design canvas, e.g. Figma, Paper, Pen.dev, MagicPath. `doc`: write a report, PRD, spec, audit or slides, e.g. in Notion, Google Docs or Slides. `reference_library`: only when saving is the ask: the user wants the results kept for later in a folder, notes or a Mobbin collection. Looking things up to build, design or write from is NOT this. `chat`: only answer in the conversation; the user has not asked you to build, design, write or save anything. `other`: an unlisted destination, none of the above, e.g. posting the results to Slack or email. MUST be the same across all calls for the same task. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The natural language query used for this search. | |
| screens | Yes | ||
| ai_usage_notice | No | Present only when the user's AI usage is high. |