Skip to main content
Glama
uxlint-net

uxlint

Official
by uxlint-net
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

ux_guidance

Get project design memory and UI guidance from uxlint before building or changing interfaces; covers layout, forms, navigation, content, performance, and money surfaces.

Instructions

Project design memory and best-practice UI guidance to read BEFORE building or changing UI — usability, consistency, and performance patterns distilled from uxlint's audit corpus, so you build idiomatic, DRY, testable components the first time instead of getting audited after. Reads the nearest project’s uxlint.design.json on each call; only explicitly approved versioned decisions guide edits. Never auto-approve or rewrite that contract to silence a lint. Covers whole-row click targets, single-column labelled forms, tabs/radiogroup vs plain buttons, one shared width scale + aligned panels, pagination by scroll length, CLS-safe layout, copy that reads as UI (active voice, honest labels, useful empty/error states), and money surfaces (plans, usage, the cost of an action shown before it runs, failed payments). Each item names the uxlint rule that catches a miss, so the loop is: read the topic, build to it, then audit_url to confirm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNoWhich area to get guidance for: layout, forms, lists, navigation, components, performance, accessibility, content, money (plans, checkout, usage, cost before an action). Omit for the index of topics; "all" for everything. Accepts aliases (copy, nav, a11y, perf, dry, …) and falls back to the index for anything unrecognized.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.46
    • changedInput schema / properties / topic / description
      Previous value: -"Which area to get guidance for: layout, forms, lists, navigation, components, performance,\naccessibility, content. Omit for the index of topics; \"all\" for everything. Accepts aliases\n(copy, nav, a11y, perf, dry, …) and falls back to the index for anything unrecognized."New value: +"Which area to get guidance for: layout, forms, lists, navigation, components, performance,\naccessibility, content, money (plans, checkout, usage, cost before an action). Omit for the\nindex of topics; \"all\" for everything. Accepts aliases\n(copy, nav, a11y, perf, dry, …) and falls back to the index for anything unrecognized."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral load and does so well: it re-reads the nearest project's uxlint.design.json on each call, only approved versioned decisions steer edits, and it never auto-approves or rewrites the contract. The implicit read-only nature is conveyed rather than stated outright, but the governance constraints are unusually explicit for a retrieval tool.

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

Conciseness4/5

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

The governing instruction (read before building) is front-loaded in the first clause, and the closing loop sentence ties usage together. It is on the long side and the enumerated topic catalogue slightly pad it, but every sentence carries operational 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?

No output schema exists, so the description must characterize returns, and it does: guidance items each name the uxlint rule that catches a miss. Combined with the read-before-build workflow and the config source, an agent has enough to invoke and interpret it. Return format granularity (single topic vs index) is only implied by the topic parameter.

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% and the single topic parameter is fully documented in the schema, including the alias and fallback behavior, so the schema does the heavy lifting. The description's topic list largely restates the schema enum values and adds little parameter-level meaning beyond the schema itself. Baseline 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?

States a specific verb+resource (read UI/design guidance before building or changing UI) sourced from uxlint's audit corpus and the project's uxlint.design.json. It also distinguishes itself from siblings by defining the loop that terminates in audit_url. An agent can tell exactly what this tool returns versus audit_url or get_report.

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?

Explicitly says to read BEFORE building or changing UI, names the alternative audit_url as the confirmation step after building, and states the exclusions: only explicitly approved versioned decisions guide edits, and never auto-approve or rewrite the contract. When-to-use, when-not, and the sibling handoff are all present.

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

Deploy Server

Other Tools