get_user_flow
Get one user flow with its ordered steps, each including full screen metadata and image_url. Returns an error dict if the flow is not found.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Mozaika
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the error dict behavior on missing flows and the content of the response (ordered steps, screen metadata, image_url). However, it does not mention authentication, rate limits, or side effects, though the read-only nature is inferable from 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word contributes. It provides essential information without redundancy or fluff.
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 simple single-get tool, the description covers what is returned (ordered steps with screen metadata and image_url), the error case, and the resource. It does not explicitly state that the slug parameter is required or the exact format, but given the one-param schema and descriptive tool name, the context is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'slug' parameter beyond its name, and the schema provides no coverage (0%). The agent must infer that slug is the identifier for the flow, but the description adds no meaning beyond simply restating the resource type.
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?
The description clearly specifies that the tool retrieves a single user flow, including its ordered steps with full screen metadata and image_url. It also notes the error dict behavior on missing flows, distinguishing it from sibling getters by naming the specific resource and its unique structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like list_user_flows for multiple flows or other get_* tools. The usage is only implied by the description's focus on a single flow, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation3/5
The compare_* / get_* / search_* family creates real overlap: compare_components, get_component, get_recipe, and search_screens(kind="component") can all answer similar component questions, and the drift family (get_design_drift, get_design_history, list_design_changes) requires careful reading to pick the right one. However, the detailed descriptions mostly draw clear lines between cross-product comparison, single-spec retrieval, and corpus-level search.
Naming Consistency4/5
The server mostly follows a clean verb_noun convention: get_*, compare_*, list_*, search_*, validate_design, generate_asset. The pattern is highly consistent, though a few names differ slightly in style (audit_code vs validate_design vs get_score), and pluralization varies in tools like compare_components and compare_sections.
Tool Count3/5
At 23 tools this is on the heavy side, and several calls overlap in scope enough to feel redundant. That said, the server's broad purpose suggests a design system reference plus audit platform, so the count is justifiable; it could be consolidated into a tighter 15-18 set.
Completeness4/5
The surface covers design system retrieval, component/section/recipe specs, screens and flows, search, audit/tools, icon assets, and drift/history of measured design tokens, leaving few cap gaps for the declared domain. Minor gaps remain around some metadata like direct screenshot banding by product, but no major dead-end workflow is apparent.