Generate a new screen from a prompt while reusing a saved design context to keep the output visually consistent.
Generates a new screen using a previously extracted design context for visual consistency.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of the new screen to generate. | |
| projectId | Yes | The project ID. | |
| deviceType | No | Target device type. | MOBILE |
| designContext | Yes | The design context from extract_design_context. |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it only restates the core operation already visible in the schema ('Generates a new screen') and adds minimal context ('for visual consistency'). It does not disclose side effects, output format, failure behavior, or any constraints such as whether an existing screen is modified or a new project must exist.
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 description is a single, focused sentence that is front-loaded and contains no filler. Every word supports the tool's purpose and key constraint.
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 tool with no annotations and no output schema, the description is too thin. It omits what the function returns, any required sequencing beyond 'previously extracted', and how it differs operationally from similar generation tools. An agent would need to open the schema or infer from the name to fully understand 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 description coverage is 100%, so the schema already documents all parameters. The description adds little beyond the schema, though it does reinforce that designContext should come from a previous extraction step. Baseline 3 is appropriate given the high schema coverage.
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 states a specific verb ('Generates') and resource ('a new screen') and clearly ties the tool to a design context, distinguishing it from generic generation tools like generate_screen_from_text. It does not name the sibling tool directly, but the phrase 'previously extracted design context' is a strong differentiator.
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?
The phrase 'previously extracted design context' implies a prerequisite and suggests the tool is for visual consistency, but there is no explicit statement of when to use this tool versus alternatives like generate_screen_from_text or apply_design_system. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.