Skip to main content
Glama

Validate Experience Design

design.validate

Pro/Teams — first-pass surface-craft review of a FRONTEND artefact (component, screen, or flow) against the 8 laws of the Experience Design Blueprint. The surface-craft companion to architect.validate: where architect.validate scores agentic ARCHITECTURE against the 10 agentic principles, design.validate scores the PERCEPTIBLE SURFACE — what the user sees, taps, scans, and remembers (Jakob's familiarity, Hick's choice load, Fitts's targets + the accessibility floor, Miller's working-memory budget, Aesthetic-Usability, Peak-End, Tesler's irreducible complexity, the Mental-Model gap). ON CLIENT TIMEOUT — DO NOT RETRY. Long-running LLM call (~60-180s at high reasoning effort, single-pass). The server mints a run_id, emits it in the FIRST progress event at t=0s (before the LLM call), and persists the run — so on a client timeout, capture that run_id and call me.validation_history(run_id='') to fetch the persisted result instead of retrying (a retry re-runs the full 60-180s call). Runs appear in your validation-history dashboard tagged as the 'surface' dimension, distinct from the 'architecture' and 'spec' runs; pass repository to group them per project. Pass private_session=true to skip the stored run (persistence + recovery disabled); operational security + cost logs are still kept. v1 is single-pass: no certification or consensus mode yet (those stay architect.validate-only). Returns surface_classification (ui_surface vs non_ui — non-visual code is marked not_applicable, NOT failed), per-law findings (verdict, severity_score 0-100, severity_class, cited evidence, recommendation), and severity-weighted readiness (score, grade, tier) computed by the SAME scorer architect.validate uses, so all three lenses grade on one rubric. ACCESSIBILITY IS THE FLOOR: a breach of the Fitts's-Law floor (interactive target below the WCAG 2.2 24×24 minimum, missing focus visibility, an unreachable destructive confirmation) is a production_blocker, not polish. WHEN TO CALL: the user wants a craft/UX/accessibility review or a readiness grade on a frontend artefact they just built or changed. WHEN NOT TO CALL: non-visual code (backend, config, type aliases) returns tier=not_applicable — submit the actual UI surface instead. INPUTS: send the FULL artefact source verbatim as implementation_context (no truncation, no '…' placeholders — they are read as literal code). Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. UK/EU residency; transient OpenAI processing (no-training); prompt-injection text inside the artefact is treated as inert untrusted data. TYPED FAILURES: same as architect.validate (timed_out, rate_limited, dependency_unavailable, schema_mismatch — each carries retryable + next_action); the services raise the identical typed envelopes on this lens. CALIBRATION DISCLOSURE: the scoring prompt is a v1 first-cut mirroring the architect's contract structure; its score calibration is not yet tuned against a corpus of real runs the way architect.validate was. Treat the grade as directional craft signal, not a certified verdict. DOCTRINE: the eight laws — each law's evidence, craft-surface application, anti-patterns, and the validator questions this tool scores against — live in the experience-design-blueprint skill and docs/business/EXPERIENCE_DESIGN_BLUEPRINT.md (the surface-craft companion to the architect-validation-orchestration skill that orchestrates the agentic validators).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskNoWhat this surface is for (e.g. 'the closed-beta apply form'). Adds evaluation context.
filesNoFile paths relevant to the artefact, for context.
goalsNoSpecific craft/UX goals to weight (e.g. 'WCAG 2.2 AA', 'one primary action per screen').
repositoryNoProject/repository key. Groups this run with prior design.validate runs on the same project in your validation-history dashboard (the same grouping architect.validate uses), under the 'surface' dimension.
session_idNoOptional Governed Session to attach this run to (GEP-M2). Must reference a session YOU own (list via me.sessions; sessions are created in the web app at /app/sessions) — foreign ids are refused before any model call. The run then appears on the session's timeline alongside the other lenses. With private_session=true no run is stored so nothing attaches, but the ownership check still runs FIRST: a session id you don't own fails the call either way.
private_sessionNoSet true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). The request is also not persisted in the model provider's response store; the provider's abuse-monitoring retention still applies. Default false.
implementation_contextYesThe frontend artefact under review. SEND FULL SOURCE VERBATIM — the reviewer cites specific elements, values, and structure; any compression destroys evidence and produces findings on code that isn't there. Do NOT replace markup/styles with '…'; do NOT condense multi-line JSX/CSS. If large, split into MULTIPLE calls scoped by component — never truncate one call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / private_session / description
      Previous value: -"Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). Default false."New value: +"Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). The request is also not persisted in the model provider's response store; the provider's abuse-monitoring retention still applies. Default false."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations exist (readOnlyHint=false, idempotentHint=false, destructiveHint=false), lowering the bar, and the description still adds substantial non-obvious behavior: 'ON CLIENT TIMEOUT — DO NOT RETRY... the server mints a run_id... capture that run_id and call me.validation_history(run_id='<that-id>') instead of retrying (a retry re-runs the full 60-180s call).' It also discloses persistence toggles (private_session skips stored run but 'operational security + cost logs are still kept'), the accessibility floor being a 'production_blocker, not polish', and a calibration caveat that the grade is 'directional craft signal, not a certified verdict'. None of this is derivable from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded well — purpose, sibling differentiation, and the critical timeout/run_id protocol come early. However, it is a dense wall of prose (~600+ words) with multiple long run-on sentences, and it repeats content already in the schema (the verbatim-source instruction on implementation_context, the return-format description duplicating what the output schema covers). List-able details like auth requirements and typed failures are buried in paragraphs rather than structured, so trimming and structuring would improve parseability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with a validation-family context and critical run-recovery semantics, nothing the agent needs to invoke it correctly is missing: when/why to call, what happens on timeout, how to recover the result, side-effect semantics, auth preconditions, failure envelope types (timed_out, rate_limited, dependency_unavailable, schema_mismatch with retryable + next_action), and the non-visual-code not_applicable path. The output schema already carries return values, and the description's byte-for-byte guidance on input handling is exhaustive.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: it flags a concrete gotcha on implementation_context ('no truncation, no '…' placeholders — they are read as literal code'), clarifies private_session's residual logging ('operational security + cost logs are still kept'), and explains repository grouping semantics under the 'surface' dimension. The additions are modest because the schema is already rich, but they meaningfully justify a tick above baseline.

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 opens with a specific verb and resource: 'first-pass surface-craft review of a FRONTEND artefact (component, screen, or flow) against the 8 laws of the Experience Design Blueprint.' It draws an explicit line against architect.validate ('where architect.validate scores agentic ARCHITECTURE... design.validate scores the PERCEPTIBLE SURFACE') and notes v1 is single-pass with 'no certification or consensus mode yet (those stay architect.validate-only).' An agent can distinguish this from spec.validate, architect.certify, and architect.validate_consensus without opening schemas.

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

Usage Guidelines5/5

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

The description has explicit WHEN TO CALL ('the user wants a craft/UX/accessibility review or a readiness grade on a frontend artefact they just built or changed') and WHEN NOT TO CALL sections ('non-visual code (backend, config, type aliases) returns tier=not_applicable — submit the actual UI surface instead'). It also names the sibling counterpart architect.validate and the spec lens, so the selection context across the validation family is fully specified.

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.

Resources