RC Engine

design_challenge

Stress-test design options against five lenses: ICP alignment, copy quality, justification, conversion flow, and accessibility. Returns severity-ranked findings with specific fixes.

Instructions

Stress-test design options against 5 lenses: ICP alignment, copy quality, design justification, conversion flow, and accessibility. Call after ux_design generates options. Returns findings by severity with specific fixes. After success: present findings to user, then proceed to design_select or design_iterate.

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": {
      "project_path": "<project_path>"
    },
    "name": "design_challenge"
  }
}

Input Schema

Name	Required	Description	Default
`project_path`	Yes	Absolute path to the project directory
`screen_descriptions`	No	Optional text descriptions of screens if wireframes are not available

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 9, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the evaluation process (5 lenses), the output structure (findings by severity with fixes), and the expected post-success actions. It does not explicitly state whether the tool is read-only or if it modifies state, which is a minor gap, but the disclosed behavior is substantially informative.

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 four short sentences, each with a distinct purpose: stating the core function, specifying when to call, describing the output, and outlining follow-up steps. There is no redundancy or filler; every sentence adds necessary information.

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?

The description covers the tool's purpose, timing, output, and next steps, which is fairly complete given the simple schema and lack of output schema. It does not mention error conditions or side effects, but for an analysis/evaluation tool embedded in a clear workflow, the provided context is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters already described in the schema. The tool description does not add any new detail about the parameters themselves; it focuses on the tool's behavior and workflow. Since the schema fully documents the parameters, the baseline of 3 is appropriate.

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 uses a specific verb 'Stress-test design options' and enumerates five distinct lenses, making it clear what the tool evaluates. It also distinguishes itself from siblings by naming the exact workflow position (after ux_design, before design_select/design_iterate) and its unique output ('findings by severity with specific fixes').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to call it ('Call after ux_design generates options') and what to do after success ('present findings to user, then proceed to design_select or design_iterate'). It provides clear workflow context but does not mention when not to use it or any alternative tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.