Search 2,000+ real iOS app interactions in plain language, read the motion anatomy behind each one (trigger, timing, easing, spring) and get starter SwiftUI tuned to the real timing.
Scored across 6 tools
Each tool targets a distinct stage of the workflow: search/related for discovery, get_shot for details, motion_breakdown/motion_code for motion recreation. Descriptions explicitly cross-reference and clarify boundaries (e.g., search vs related, get_shot vs breakdown). No overlapping purposes remain ambiguous.
All tool names follow a consistent pattern: 60fps_ prefix plus snake_case verb_noun. The convention is predictable and readable throughout.
Six tools cover discovery, retrieval, filtering, motion analysis, and code generation without redundancy. The count is well-scoped for an iOS interaction reference library.
The surface covers the full read-only lifecycle: finding shots via search and related, inspecting details, listing filters, and recreating motion with breakdowns and starter code. No critical operations are missing for the stated domain.
Get the structured motion anatomy of a shot: the gesture/trigger that starts it, the motion behaviors involved, the start → transition → end states plus why it works, and keyframe images (frames sampled from the video at 1s intervals) to line up with each state. Use this after picking a shot, to understand or recreate how it moves; to judge what a shot is, 60fps_get_shot is enough. Counts toward a daily limit shared with 60fps_get_motion_code, so call it for shots you will actually use. An unknown slug returns the closest matches.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The shot's slug | |
| response_format | No | Output text format: 'markdown' (human-readable, default) or 'json' (raw). structuredContent (machine-readable JSON) is always returned regardless. | markdown |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| title | Yes | |
| appName | Yes | |
| end_state | Yes | |
| keyframes | Yes | Frames sampled from the shot's video at 1s intervals. Line them up with the start/transition/end states to see the motion. Empty if the shot has no video. |
| storyboard | No | Hand-made frame-by-frame breakdown, when one exists. Trust it over the generated fields. |
| transition | Yes | |
| start_state | Yes | |
| why_it_works | Yes | |
| motion_params | No | Coarse recreate-the-feel hints (categorical estimates from the video). Absent on pre-v3 records. |
| motion_behavior | Yes | |
| gesture_or_trigger | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds concrete traits beyond them: a daily quota shared with 60fps_get_motion_code and the fallback behavior that an unknown slug returns the closest matches. This is genuinely useful operational context that annotations do not convey.
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-loads the return anatomy, then usage/alternative, then the quota warning, ending with the error behavior. Every sentence carries distinct information with no redundancy.
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 detail is not strictly required, yet the description still summarizes the anatomy. Combined with usage routing, quota disclosure, and error behavior, an agent has everything needed to decide and invoke 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 the schema already documents both parameters; the baseline is 3. The description adds meaning to the slug parameter by disclosing that an unknown slug yields closest matches (fuzzy resolution), which is a semantic beyond the schema's 'The shot's slug'.
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 (get) and resource (motion breakdown) and enumerates the exact contents returned: the gesture/trigger, motion behaviors, start→transition→end states plus rationale, and sampled keyframe images. It explicitly distinguishes itself from 60fps_get_shot ('to judge what a shot is, 60fps_get_shot is enough'), so an agent can pick it 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 triggering condition ('after picking a shot, to understand or recreate how it moves') and names the alternative with the condition that selects it (60fps_get_shot for merely judging a shot). It also warns to call it only for shots you will actually use because of the shared daily limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get starter SwiftUI code to recreate a shot's motion, tuned by its motion_params (timing/easing/springiness/stagger become real SwiftUI Animation values). Returns the matching pattern recipe(s) for the shot's motion behaviors. Pair with 60fps_get_motion_breakdown (the start/transition/end states) and the keyframe images (the look). Recreate the MOTION, write your own original content, never the app's copy, brand, or assets. Use it last, when the user wants to build the motion; it counts toward the same daily limit as 60fps_get_motion_breakdown. When generated is present it is a complete, compile-checked file: SHOW IT TO THE USER IN FULL in a swift code block. Summarising it instead of printing it is not what was asked for.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The shot's slug | |
| framework | No | Target framework (v1: swiftui) | |
| response_format | No | Output text format: 'markdown' (human-readable, default) or 'json' (raw). structuredContent (machine-readable JSON) is always returned regardless. | markdown |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| title | Yes | |
| source | Yes | generated = bespoke compile-checked view for this shot; recipes = starter patterns |
| recipes | Yes | Matching pattern recipe(s) for the shot's motion behaviors, with this shot's params injected |
| guidance | Yes | |
| animation | Yes | SwiftUI Animation expression tuned to this shot's params |
| framework | Yes | |
| generated | No | Full SwiftUI that recreates this interaction (present when source=generated) |
| motion_params | No | Coarse recreate-the-feel hints (categorical estimates from the video). Absent on pre-v3 records. |
| stagger_delay | Yes | Per-element stagger delay in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real operational context: it shares a daily quota with 60fps_get_motion_breakdown, and it specifies that a present `generated` value is a complete compile-checked file that must be printed in full rather than summarized — an output-handling rule the annotations do not convey.
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?
Purpose and the key reconstruction constraint are front-loaded, and the pairing/quota guidance is compact. It runs slightly long, and the closing reprimand about summarizing rather than printing carries some redundancy, but each sentence still carries usable instruction.
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 need not be re-explained, yet the description usefully characterizes the `generated` payload. Combined with the sequencing, quota, and sibling-pairing guidance, an agent has everything needed to call this correctly last in the workflow.
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 slug, framework, and response_format are already fully documented in the schema; the baseline is 3. The description mentions motion_params, but that is a property of the shot data rather than a call parameter, so it adds no invocation guidance beyond 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?
States a specific verb+resource ('Get starter SwiftUI code to recreate a shot's motion') and explains the transformation applied (motion_params become real SwiftUI Animation values). It explicitly names and differentiates from the sibling 60fps_get_motion_breakdown, telling the agent which artifact each provides.
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 explicit sequencing ('Use it last, when the user wants to build the motion'), names the complementary sibling to pair with, states the daily-limit cost, and adds a clear when-not condition by redirecting recreation of motion rather than copy/brand/assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full detail for one shot by its slug: app, platform, URLs, keyframe images (frames sampled from the video at 1s intervals), and the complete AI description (summary, detailed description, interaction pattern, gesture/trigger, motion behavior, UI elements, visual style, product context, intensity, mood, search keywords, assigned filters). Use it to judge whether a shot fits or to describe it to the user. It does not include the motion breakdown (states, timing, easing, why it works): get that from 60fps_get_motion_breakdown, and SwiftUI from 60fps_get_motion_code. Get slugs from 60fps_search_shots or 60fps_get_related_shots; an unknown slug returns the closest matches.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The shot's URL slug (60fps.design/shots/{slug}) | |
| response_format | No | Output text format: 'markdown' (human-readable, default) or 'json' (raw). structuredContent (machine-readable JSON) is always returned regardless. | markdown |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| slug | Yes | |
| title | Yes | |
| appName | Yes | |
| appSlug | Yes | |
| shotUrl | Yes | |
| platform | Yes | |
| videoUrl | Yes | |
| keyframes | Yes | Frames sampled from the shot's video at 1s intervals. Line them up with the start/transition/end states to see the motion. Empty if the shot has no video. |
| posterUrl | Yes | |
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the 1s keyframe sampling interval, the exact boundary of what is excluded, and the fallback that 'an unknown slug returns the closest matches' rather than erroring. It doesn't mention pagination or rate limits, but for a single-record lookup that is minor.
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 the core purpose and exclusions first, then acquisition guidance. The long parenthetical field list is dense but earns its place by advertising the payload contents. Slightly heavy for a two-sentence tool, but nothing is wasted.
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. Combined with annotations covering safety and the description covering scope, exclusions, slug sourcing, and fallback behavior, an agent has everything needed to select and invoke it 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 coverage is 100%, so the baseline is 3. The description goes further by documenting the origin of the slug value (search_shots / get_related_shots) and the unknown-slug behavior, which the schema does not state. It adds nothing about response_format, but the schema's own enum description already covers that.
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?
Opens with a specific verb+resource+scope ('Fetch the full detail for one shot by its slug') and enumerates exactly what the payload contains (app, platform, URLs, keyframes, AI description fields). It explicitly carves out what it does NOT return, cleanly separating it from 60fps_get_motion_breakdown and 60fps_get_motion_code.
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?
States the use case ('judge whether a shot fits or to describe it to the user'), names the two sibling tools to use for the missing data, and tells the agent where slugs come from (60fps_search_shots or 60fps_get_related_shots). When-to-use and alternatives are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filters the library uses, each with its category (Patterns, Elements, Effects, Gestures, Product) and how many shots carry it. Use it to get exact slugs for the filters argument of 60fps_search_shots, or to see what kinds of interaction the library covers. It is a catalogue, not a search: to find shots, use 60fps_search_shots. Free, with no daily limit.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only this category: Patterns, Elements, Effects, Gestures or Product | |
| response_format | No | Output text format: 'markdown' (human-readable, default) or 'json' (raw). structuredContent (machine-readable JSON) is always returned regardless. | markdown |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| filters | Yes | |
| category | 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 profile is covered. The description adds non-annotation context by stating it is 'Free, with no daily limit', which tells an agent it can call this freely without quota budgeting. It does not describe result ordering or pagination, keeping it just short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each doing distinct work: what is returned, why to use it, and what it is not. The most decision-relevant fact (catalogue vs. search) is front-loaded in the second sentence with zero 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?
With an output schema present, the description need not explain return values, and it correctly avoids doing so. For a zero-required-parameter read-only list tool, the description supplies purpose, usage, anti-usage, and cost information, leaving no gap an agent needs to fill before calling 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 description coverage is 100%, so both parameters are already documented, making 3 the baseline. The description restates the category values (Patterns, Elements, Effects, Gestures, Product) and implies the category filter narrows results, but adds no syntax or semantics for `response_format` beyond what the schema provides.
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 filters the library uses') plus the exact shape of each entry (category and shot count). It clearly distinguishes itself from sibling 60fps_search_shots by framing itself as a catalogue of metadata rather than a shot search.
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 two concrete use cases ('get exact slugs for the `filters` argument of 60fps_search_shots', 'see what kinds of interaction the library covers') and an explicit exclusion: 'It is a catalogue, not a search: to find shots, use 60fps_search_shots.' The alternative and the condition selecting it are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over the 60fps library of mobile interaction reference clips. Start here when you have the interaction in words. When the user names one shot and wants more like it ("I like the Flighty connection assistant sheet, find similar shots"), use this only to find that shot's slug, then call 60fps_get_related_shots with it: search results include the named shot itself and are ranked against the words, not against the shot. Returns the best-matching shots (title, app, one-line summary, motion behavior, filters, intensity, mood, and video/poster/page URLs). Use natural language, e.g. 'springy bottom sheet for checkout' or 'calm premium onboarding'. Optionally narrow by filter slugs, app (slug or name), or platform. Filters are exact and results must have ALL of them, so an unknown slug returns nothing: leave filters empty unless you took the slugs from a result's filters. An app that is not in the library is ignored and flagged in notice. Read-only; results capped at 20. total is how many shots were searched, not a match count: results are the closest by meaning, so always judge them on their own merits rather than assuming a high count means a good match. DO NOT CALL for: Android, Material Design, Flutter or web, since this library is iOS only and will still return iOS shots; generating or critiquing a design (icons, colour palettes, logos, brand), since this searches recordings of shipped apps and cannot design anything; or performance, profiling and frame-rate debugging, which share the name 60fps and nothing else. For any of those, answer directly and do not call this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Restrict to one app (slug or display name) | |
| limit | No | Max results to return (default 10, max 20) | |
| query | Yes | Natural-language description of the interaction to find | |
| filters | No | Exact filter slugs that results must ALL have. Use only slugs seen in a result's `filters`; an unknown slug returns no results | |
| platform | No | Restrict to a platform (60fps is iOS-only; watch is derived) | |
| response_format | No | Output text format: 'markdown' (human-readable, default) or 'json' (raw). structuredContent (machine-readable JSON) is always returned regardless. | markdown |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of results in this response |
| query | Yes | |
| total | Yes | How many shots were searched after filters, not a match count. Results are the closest, ranked by relevance |
| results | Yes | |
| has_more | Yes | Whether more candidates exist beyond `limit` |
| truncated | No | True if results were dropped to fit the size limit |
| truncation_message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, so safety is covered. The description adds valuable semantics beyond that: unknown filter slugs return nothing, unknown apps are ignored and flagged in notice, results are capped at 20, and total is the searched corpus size not a match count. This substantially enriches what the structured fields alone convey.
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 the core purpose and workflow, then examples, parameter guidance, output summary, and a DO NOT CALL section. It is fairly long but every block earns its place; slightly more telescoping could tighten it further.
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?
Covers purpose, sibling routing, parameter gotchas, output fields, result caps, the total-vs-match-count warning, and edge cases for out-of-scope calls. With an output schema present, the description need not explain return values in depth and is complete for correct invocation.
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 schema already documents all six parameters, setting a baseline of 3. The description goes beyond by explaining filter AND-semantics, the slug-provenance rule, and the app-ignored-and-flagged behavior, which are not fully captured in the schema and materially affect correct invocation.
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 the specific verb and resource ('semantic search over the 60fps library of mobile interaction reference clips') and precisely defines its scope. It explicitly distinguishes itself from sibling 60fps_get_related_shots by describing the named-shot workflow, and even pre-empts a naming collision with performance tooling.
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 explicit when-to-use ('start here when you have the interaction in words'), a conditional routing rule to a sibling tool for named-shot similarity, and a thorough DO NOT CALL list with reasons for Android/Material/Flutter/web, design generation, and performance debugging.
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.
60fps_list_filters60fps_search_shots1 field changedInput schema / properties / filters / descriptionPrevious value: -"Filter slugs that results must ALL have (from the 89-slug taxonomy)"New value: +"Exact filter slugs that results must ALL have. Use only slugs seen in a result's `filters`; an unknown slug returns no results"60fps_get_motion_breakdown60fps_get_motion_code60fps_get_related_shots60fps_get_shot60fps_search_shotsSearch 300k+ real app screens, flows, and UX microcopy from 1,500+ shipped products.
Search curated design styles, real product screens, and user flows for evidence-based design work.
150+ React Native animation recipes, scene authoring, phone preview via QR, Reanimated v4 codegen
Research mobile apps, onboarding, paywalls, and competitors with real screens, flows, and reviews.
Add one secure layer between your agents and this server.
