Design review as MCP tools: critique, states, journeys, UI copy, PRD assumptions. BYOK or hosted.
Scored across 6 tools
Each tool targets a fairly distinct UX-review activity (copy, terminology, design critique, assumptions, state matrix, journeys). The only real overlap is between audit_copy and critique_experience, since copy is also one axis of the broader design critique, but the per-string vs whole-design framing mostly separates them.
All six tools follow a clean verb_noun snake_case pattern (audit_copy, check_terminology, critique_experience, find_assumptions, generate_state_matrix, map_journey). No mixed conventions or vague single-word names.
Six tools is well-scoped for a design/UX critique server, with each tool clearly earning its place and no redundant filler. The count is neither thin nor bloated.
The surface covers a strong range of critique angles: copy, terminology drift, design health, assumptions, state coverage, and journeys. Minor gaps exist (e.g. no accessibility-specific lens or tool to persist/compare findings across reviews), but an agent could work around these.
Per-string critique of interface copy: buttons, errors, empty states, confirmations, notifications. Each string comes back with the problem and a fix, or nothing if it already works. Call it before shipping UI strings.
| Name | Required | Description | Default |
|---|---|---|---|
| strings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine behavioral value by disclosing the return contract: each string yields a problem plus a fix, or nothing if it already passes. It omits the 60-item batch limit.
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?
Three tight sentences: what it critiques, what comes back, when to call it. No filler, and the core purpose is front-loaded.
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?
There is no output schema, so the description carries the burden of explaining returns — and it does, describing the problem/fix-or-nothing result. For a read-only batch audit tool that is nearly complete; only the batch limit is undisclosed.
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?
With 0% schema description coverage and one structured parameter, the description does compensate partially by enumerating the context categories that correspond to the schema enum. However, it never states that input is a list of text+context pairs or mentions the maxItems=60 cap, so the nesting and array shape are left to the schema.
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?
States a specific verb (critique) and resource (interface copy), and enumerates the string categories covered (buttons, errors, empty states, confirmations, notifications). It is clearly distinguishable from siblings like check_terminology and critique_experience, though it never names an alternative explicitly.
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?
"Call it before shipping UI strings" gives a concrete trigger point for invocation, which is real usage guidance. There is no when-not-to-use guidance or routing to sibling 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.
Finds concepts that carry different names across surfaces (UI strings, docs, API reference, support macros) and flags drift. Pass the text from each surface; nothing needs connecting.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful context that the tool is purely textual (no source connection needed) and that it reports name drift, but says nothing about limits such as the 12-source cap or what the flagged output includes.
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?
Two tight sentences, front-loaded with the purpose and followed by the single invocation instruction. No filler; every clause earns its place.
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 read-only analysis tool with no output schema, the description should ideally hint at what 'flags drift' returns and note the source limit. Annotations cover safety, but the result format and the 12-item cap remain unexplained.
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?
With 0% schema description coverage, the description must carry parameter meaning; it explains that the input is text from each surface, which clarifies the 'sources' array intent. It does not explain the required 'label' field or the maxItems=12 constraint, so it only partially compensates.
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?
States a specific verb and resource ('finds concepts that carry different names across surfaces... flags drift') and enumerates the surfaces it compares, which is concrete enough to distinguish it from siblings like audit_copy or critique_experience. It does not explicitly name a sibling it is not, so it falls short of a 5.
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?
'Pass the text from each surface; nothing needs connecting' gives invocation context and reassures the agent that no upstream wiring is required. However, it gives no when-to-use versus alternatives (e.g. audit_copy) and no exclusions or prerequisites, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adversarial critique of a design, given as a description or a screenshot URL, with an optional PRD. Returns findings ranked by severity covering hierarchy, density, affordance, composition, copy, and the first-use / 500th-use / zero-data / huge-data / no-permission / irreversible questions. Call it before presenting a design to a human or handing it to engineering.
| Name | Required | Description | Default |
|---|---|---|---|
| prd | No | Optional brief or PRD. Without one, the review judges against general principles. | |
| context | No | Optional: audience, the single most important action, viewport. | |
| artifact | Yes | The design under review. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive operation, and the description is consistent with that. It adds real context beyond the annotations: findings are returned ranked by severity, span six named dimensions, and probe specific stress cases (first-use, 500th-use, zero-data, huge-data, no-permission, irreversible).
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?
Two sentences, with the core action and accepted input forms front-loaded and the return shape immediately after. The long enumeration of dimensions and stress questions is dense but each item is load-bearing for set-versus-sibling comparisons, so little is wasted.
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?
With no output schema, the description carries the burden of describing results and does so (severity-ranked findings across named dimensions). For a single-required-param, nested-object tool this is nearly complete; only the exact finding format and any length/scope limits are left implicit.
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 three parameters including the artifact's type/value structure and the prd fallback behavior. The description restates only that the PRD is optional and the artifact may be a description or URL, adding no syntax or format detail beyond the schema.
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?
States a specific verb (adversarial critique) and resource (a design given as description or screenshot URL), then enumerates the exact review dimensions it covers. That enumeration cleanly separates it from the narrower siblings (audit_copy, check_terminology, find_assumptions), which each cover one slice of this broader review.
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?
"Call it before presenting a design to a human or handing it to engineering" gives an explicit trigger point in the workflow. It does not name when to prefer a narrower sibling (e.g., audit_copy) over this tool, so the routing guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a PRD or design brief and extracts the unverified assumptions inside it, ranked by risk, each turned into a research question that could change a decision. Never simulates user answers.
| Name | Required | Description | Default |
|---|---|---|---|
| prd_text | Yes | The PRD, brief or proposal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world. The description adds genuine behavioral context beyond them: output is ranked by risk, each assumption is reformulated as a research question, and the tool refuses to simulate user answers. That last constraint is a meaningful behavioral trait not visible in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded, followed immediately by the output shape and the boundary constraint. Zero filler.
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?
No output schema exists, so the description usefully sketches the return shape (risk-ranked assumptions, each as a research question). For a single-parameter read-only tool that is largely complete, though it could say more about input expectations or output format details.
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?
Only one parameter with 100% schema description coverage, so the schema already documents prd_text. The description restates the input as 'a PRD or design brief' but adds no format, length, or structural guidance beyond what the schema provides.
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?
States a precise verb+resource chain: reads a PRD or design brief and extracts unverified assumptions, ranked by risk, converted into decision-relevant research questions. The scope boundary 'Never simulates user answers' sharply distinguishes it from sibling critique/audit tools that evaluate rather than surface assumptions.
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?
Implies usage (call it when you have a PRD or brief and want unverified assumptions surfaced), and the negative scope 'never simulates user answers' tells the agent what it will not do. However, it never explicitly says when to prefer this over siblings like critique_experience or audit_copy, and doesn't state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates the state space for a feature, form or screen across data, loading, permission, network, account, content, time, concurrency, outside dependencies, money, consistency and people, and lists the gaps most likely to cause real harm. Call it when a feature is described and you want to know what nobody drew.
| Name | Required | Description | Default |
|---|---|---|---|
| known_dimensions | No | Optional: dimensions you already cover, so they are skipped. | |
| feature_description | Yes | The feature, form or screen, in prose or as a spec. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the twelve-dimension scope and the fact that gaps are ranked by likely harm, but says nothing about output format, depth or cost despite there being no output schema.
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?
It is front-loaded with the verb and stays to two sentences. The twelve-item dimension list is long but earns its place by defining scope, though the first sentence runs on without punctuation breaks.
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?
With no output schema, the description carries the burden of describing the return, and it does so at a high level ('generates the state space... and lists the gaps most likely to cause real harm'). An agent knows what it will get and when to call it, though output granularity remains unspecified.
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% and both parameters are documented in the schema, including known_dimensions' skip behavior. The description adds no format, syntax or constraint detail beyond what the schema already provides, so the baseline of 3 applies.
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 names a specific verb+resource ('Generates the state space for a feature, form or screen') and enumerates the exact dimensions covered, which makes its output shape concrete. It does not, however, differentiate itself from the closest sibling, find_assumptions, leaving the agent to infer the boundary between the two.
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?
'Call it when a feature is described and you want to know what nobody drew' gives a clear trigger condition an agent can act on. There are no stated exclusions or named alternatives, so the agent gets a positive cue but no routing guidance against the five siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Breaks a user objective into the stages of a real journey and flags entry points and exit paths that have no designed arrival or recovery. Optionally focuses on one user maturity (first use, occasional, habitual, expert). Describes behavior, not screens.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | What the person is trying to accomplish, in their words. | |
| user_maturity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe, side-effect-free profile is fully covered. The description adds a useful scope constraint ("Describes behavior, not screens") and sketches what it reports, but gives no detail on output shape, limitations, or prerequisites beyond that.
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?
Three tight sentences, front-loaded with the core action and result before the optional parameter note. Every sentence carries information; the middle sentence is the least load-bearing but still short.
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 two-parameter analytical tool with no output schema, the description covers what it does, the nature of its output, and the optional scoping mode. An agent has enough to call it correctly, though a bit more on output structure would help.
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 coverage is 50% and the objective parameter is already well documented in the schema. The description clarifies that user_maturity is an optional focus, but it mostly restates the four enum values (first use, occasional, habitual, expert) that the schema already supplies, adding little interpretation.
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?
States a specific verb and resource ("Breaks a user objective into the stages of a real journey") plus a concrete analytical result ("flags entry points and exit paths that have no designed arrival or recovery"). The purpose is clear, but it never references siblings such as critique_experience or find_assumptions, so an agent gets no explicit differentiation help.
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?
Usage is implied rather than stated: "Optionally focuses on one user maturity" signals the optional scoping mode, but there is no when-to-use, when-not, or alternative routing among the sibling UX-analysis tools. Adequate but leaves selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
audit_copycheck_terminologycritique_experiencefind_assumptionsgenerate_state_matrixmap_journeyHuman-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
Paid remote MCP for AI Studio Workspace approval gate MCP, structured receipts, audit logs, and revi
Hosted MCP for denial, prior auth, reimbursement, workflow validation, batch scoring, and feedback.
Paid remote MCP for synthetic user testing, UX validation, analytics, checkout, and readiness.
Add one secure layer between your agents and this server.
