Real UI references for coding agents: iOS app screens, user journeys and website design systems.
Scored across 5 tools
Most tools have distinct roles: list_collections vs get_collection vs get_journey are clearly separable. The two search tools, find_ui_materials and find_ui_references, overlap somewhat since both search and both touch website references, but descriptions clarify that one targets design systems and the other targets app screens/journeys.
All five tools follow a clean verb_noun snake_case pattern (find_ui_materials, find_ui_references, get_collection, get_journey, list_collections). findBy/get/list verbs are used consistently for their respective semantics.
Five tools is well-scoped for a design-reference search and retrieval service, with each tool earning its place (two search, two get, one list).
The search-plus-retrieval surface covers the core workflow: discover materials/references, then drill into collections and journeys. Minor gaps exist, such as no way to fetch a single material/reference detail or to save/add items into collections.
Search UXKIN's design systems taken from real websites: colors with their roles, typography and components for every result, and (with full access) the complete DESIGN.md for the top result. To get one site's DESIGN.md, search for its name. Query by industry ("fintech", "dev tools", "e-commerce"), theme ("dark", "light"), brand color ("green", "blue"), style ("minimal black and white", "serif"), font ("Inter") or site name, and combine them ("dark fintech").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many design systems to return (1 to 25). | |
| query | Yes | What to find, e.g. "dark fintech", "green SaaS", "serif editorial", "Inter". |
| Name | Required | Description |
|---|---|---|
| count | Yes | How many design systems were found. |
| query | Yes | The query that was searched. |
| results | Yes | Design systems from real websites, best first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so safety needs no restating. The description adds value beyond that by disclosing an access-tier dependency — full access yields the complete DESIGN.md for the top result — which is a real behavioral constraint an agent should anticipate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and return contents are front-loaded, and the query-grammar sentence is dense but informative. It is two long sentences with little waste, though the facet list plus the DESIGN.md note could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is optional, yet the description still sketches result contents and the access-gated DESIGN.md, and annotations carry the safety profile. The only real gap is sibling routing, which matters given find_ui_references sits alongside it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description earns extra by decomposing 'query' into a facet taxonomy (industry, theme, brand color, style, font, site name) and showing how facets combine, which the schema's short example list does not spell out. The 'limit' parameter is left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource — searching UXKIN's design systems sourced from real websites — and enumerates what each result contains (colors with roles, typography, components, DESIGN.md for the top hit). That is far more concrete than a generic 'search' tool, but it never differentiates itself from the sibling find_ui_references, leaving the agent to infer which retrieval tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operational guidance: query by industry, theme, brand color, style, font, or site name, and combine facets ('dark fintech'), plus the specific trick of searching a site by name to get its DESIGN.md. What is missing is any explicit when-not/when-else routing against find_ui_references or the collection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search UXKIN's library of real iOS app screens, user journeys (ordered multi-screen flows such as "Deleting account" or "Subscribing") and website references. Works best with short queries: a flow or screen type ("cancel subscription", "paywall", "empty state", "settings"), an app category ("meditation app", "expense tracker") or an app name ("Duolingo"). Combine them to narrow down ("onboarding for a meditation app"). Each result has a type (app, journey, screen, web), an image and a link; screens may include context naming the journey or screen type they show. Search a few times with different words rather than one long sentence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return (1 to 50). | |
| query | Yes | What to find, e.g. "delete account", "empty state", "fitness app", "Tinder". | |
| include_images | No | Also attach the screenshots of the top 3 results as images, to look at them. Off by default: search first, then turn it on (or use get_journey) for the ones worth a close look. |
| Name | Required | Description |
|---|---|---|
| count | Yes | How many results were found. |
| query | Yes | The query that was searched. |
| results | Yes | Matches, best first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe, idempotent read, so the bar is lower. The description adds real value beyond them: the shape of each result (type, image, link, and a `context` field on screens) and that include_images is off by default with a recommended search-first workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then query tactics, then result structure. It is somewhat long, but the final sentence on iterating searches earns its place as actionable guidance rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 needn't be spelled out; the description nevertheless summarizes them usefully. Combined with annotations, it covers what an agent needs to call the tool correctly, though the relationship to find_ui_materials is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by prescribing query phrasing (short, facet-combining queries) and explaining the deferred-image workflow, which adds practical meaning over the parameter's terse definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and the concrete resources: real iOS app screens, ordered user journeys, and website references, with examples ('Deleting account', 'paywall'). It names get_journey as a follow-up path but does not differentiate itself from the sibling find_ui_materials, which likely overlaps in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear query-style guidance: use short queries, combine facets, and 'search a few times with different words rather than one long sentence.' It also signals when to reach for get_journey for close inspection. Missing explicit exclusion of when NOT to use it versus find_ui_materials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the items in one of the person's saved collections on uxkin.com (app screens, whole apps and website designs, newest first), with images and links. Pass the collection's name as the person said it (case doesn't matter) or its id from list_collections. Use the items as the references the person chose for the task.
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | The collection's name, e.g. "Checkout ideas", or its id. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| count | Yes | How many items it has. |
| items | Yes | Saved items, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real behavioral context beyond that: results are ordered newest first, items carry images and links, and lookup is case-insensitive whether by name or id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is returned before the how-to-call detail. No filler, though the closing sentence about using items as references is somewhat soft guidance rather than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema and rich annotations, nothing an agent needs is missing: input form, ordering, content type, and the relationship to list_collections are all covered, and the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already has an example, so the baseline is 3. The description earns an extra point by specifying that the name should be passed 'as the person said it' and that casing is irrelevant, which is semantics the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the items in one of the person's saved collections'), names the domain (uxkin.com), and defines the content scope (app screens, whole apps, website designs). It is clearly distinguishable from list_collections, which enumerates collections rather than their contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete selection context ('Use the items as the references the person chose for the task') and points to list_collections as the way to obtain an id. It stops short of an explicit when-not-to-use or a statement of when this beats find_ui_references/find_ui_materials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get every screen of one user journey from UXKIN, in order, with the screenshots attached as images (up to 10): for example all 8 screens of "Deleting account" in one app. Use it after find_ui_references returns a result of type journey, passing that result's id (and its appId when there is one), to study the whole flow (each step, confirmations, the end state) instead of only its first screen.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | No | Optional: the result's appId, e.g. "a_lbNUWzdsYls3". | |
| journey_id | Yes | The journey's id from a find_ui_references result, e.g. "j_kFcZd3I-jm6c". |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| app | Yes | |
| href | Yes | The journey on uxkin.com. |
| name | Yes | What the journey does, e.g. "Deleting account". |
| screens | Yes | The journey's screens, in order. |
| screenCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are ordered and include screenshots as images with a cap of 10. It does not mention pagination or what happens when a journey exceeds 10 screens, which is the only real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence that opens with the concrete outcome (every screen, in order, with images) before the usage instructions. It is dense but every clause carries information; only the nested example adds mild verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary, yet the description still conveys the salient return traits (ordered screens, attached screenshots, 10-item cap). Combined with the full schema coverage and annotations, an agent has everything needed to select and call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented with examples in the schema itself. The description reinforces the provenance of journey_id (from a find_ui_references result) and the optional appId, but adds little syntax or meaning beyond what the schema states, so this lands at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get every screen of one user journey from UXKIN, in order') and adds concrete scope detail (screenshots attached, up to 10 screens, ordered). It is clearly distinguishable from siblings like find_ui_references and get_collection, which deal with references and collections rather than a full journey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the exact trigger ('after find_ui_references returns a result of type journey'), the inputs to pass ('that result's id (and its appId when there is one)'), and the intent ('to study the whole flow ... instead of only its first screen'). That is explicit when-to-use plus an implicit alternative, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the collections the person saved on uxkin.com: each collection's name, id, how many items it has and when it last changed. Use it when the person mentions their saved references, their collections, or one collection by name; then open one with get_collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | How many collections there are. |
| collections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and scope profile is covered. The description adds little beyond that — the field list it provides largely duplicates the output schema — so it earns a solid but unremarkable 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero padding: the first defines the payload, the second defines the trigger and the next step. Front-loaded and every clause carries routing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a present output schema, and annotations covering the safety profile, the description supplies exactly the remaining pieces — what is listed and when to reach for it versus get_collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate and it correctly does not invent parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the collections the person saved on uxkin.com') plus the exact fields returned, which lets an agent distinguish it from find_ui_materials, find_ui_references and get_journey without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when the person mentions their saved references, their collections, or one collection by name') and names the correct follow-up sibling ('then open one with get_collection'), so the list-vs-detail decision is fully resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_ui_materialsfind_ui_referencesget_collectionget_journeylist_collectionsReal product UI captures for design reference, competitor analysis, and coding agents.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Captured web interfaces, screenshots, flows and structured evidence for AI coding agents.
Measured design systems decoded from 588 real products, for coding agents.
Add one secure layer between your agents and this server.
