01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 3%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
27.2 / 30
03Economics
18.8 / 20
04Discoverability
16.0 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
7 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
project_init |
no_return_description |
Create a new UXLoom project file (uxloom.project.json). Run once per product. Returns the created project file's path as confirmation once it is written. |
brief_answer |
no_return_description |
Submit answers for the design brief started with brief_start, using the same prompt. Unanswered fields take researched defaults and are recorded in the assumption ledger (auditable, reversible). Returns the resulting brief, including any defaulted answers and ledger entries. |
journey_define |
no_return_description |
Add or replace a journey (a state machine: states reference screens, events move between states). Screens referenced here must be registered via screen_register before project_validate passes. Returns confirmation that the journey was added or replaced. |
screen_register |
no_return_description |
Add or replace a screen: its intent, requiredStates (the contract), designedStates (progress), and components with colors/labels/target sizes for the critics. Returns confirmation that the screen was added or replaced. |
project_import |
no_return_description |
Replace the whole project in one call: journeys and screens together. Prefer this over many journey_define/screen_register calls when registering a complete or large design. Validates the full document; unknown fields are rejected. Returns the validation outcome for the imported document, including any errors or findings. |
palette_check |
params_unexplained |
Check a design system's color pairs against WCAG 2.2 AA (4.5:1) before any screens exist. pairs is a non-empty array of named color pairs, each with a human-readable name and foreground/background hex colors (fg, bg). Reports each pair's exact ratio, pass/fail, and thin-margin passes (under 5.0:1) that one shade lighter would break. |
screen_critique |
params_unexplained |
Run the design critics for one registered screen: screenId selects which screen to critique. Use during iteration on a single screen. Returns the findings scoped to that screen, with fixes. |
Selection evidence
Confusable tool pairs.
4 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
brief_start |
brief_answer |
medium | Both belong to a single two-step 'design brief' workflow and share the 'brief' token; a task like 'answer the design brief for this PRD' or 'fill in the brief' could make an agent jump straight to brief_answer (which requires answers it never obtained) or stop at brief_start's questionnaire without submitting, since neither description makes the ordering unambiguous for a user who just says 'complete the brief'. |
project_audit |
project_validate |
medium | Both are project-wide checks that 'return findings with fixes' and have near-identical surface behavior and no required arguments; a loose task such as 'check my project for problems' or 'run a quality review on the project' fits both equally, and only a task that explicitly mentions implementation/source-drift (audit) or design critics like contrast/touch targets (validate) disambiguates them. |
project_init |
project_import |
medium | Both initialize or load project data into the workspace; a task like 'set up the new project from this full spec' could be read as creating the shell file (project_init, name+platforms) or ingesting a complete project document including journeys and screens (project_import), and the import description explicitly frames itself as the preferred bulk-registration entry point, so either pick is defensible. |
screen_register |
screen_critique |
medium | Both operate on a single screen and share the 'screen' token; a task like 'handle my login screen' or 'review/tune this screen' is ambiguous between adding or updating the screen definition (screen_register) and getting findings scoped to one screen (screen_critique), especially since it takes an optional screenId while register describes the screen as input for 'the critics'. |
Compare the field