Skip to main content
Glama
deenesjakoruzh
uxlint-net

uxlint

Official
by uxlint-net
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

uxlint

Prüfen Sie die UX jeder Website so, wie es ein designkundiger Reviewer tun würde: Kontrast, Tap-Ziele, Typografie-Skala, Farbdisziplin, Scan-Muster, Landmarken. Jeder Befund wird mit einer konkreten Lösung geliefert, die ein Agent (oder ein Mensch) direkt anwenden kann. Es ist dafür konzipiert, in der Schleife eines Coding-Agents (MCP) zu sitzen und iteriert zu werden, bis alles grün ist.

Ein Agent prüft eine Preisseite, erhält einen Kontrastfehler und einen Farbkonflikt-Befund mit Lösungen für beide, wendet sie an, prüft die Regel erneut und bewertet die Seite von B auf A

Ein echter Lauf, von Anfang bis Ende: audit_url → Note B, ein Kontrastfehler von 2,39:1 und drei CTAs in drei verschiedenen Akzentfarben → die Lösung → verify_fix → Note A. Jede Zahl darin stammt von den Tools; nur das Warten wurde herausgeschnitten.

Dies ist die CLI: eine kleine, einzelne statische Rust-Binärdatei. Sie steuert ein bereits installiertes Chrome/Chromium über das DevTools-Protokoll (kein Node, kein Playwright, kein Headless-Browser-Download), erfasst, wie eine Seite aussieht und liest, und sendet das an den gehosteten Server von uxlint, der die eigentliche Bewertung vornimmt. Die Regel-Engine, die kalibrierten Schwellenwerte und der LLM-Richter leben alle serverseitig, sodass der Client nie aktualisiert werden muss, wenn sich eine Regel ändert.

┌──────────────────────────┐        POST /v1/audit {snapshots}        ┌──────────────────────────┐
│ uxlint (this binary)     │ ───────────────────────────────────────▶ │ uxlint-server (hosted)    │
│ drives YOUR Chrome (CDP) │ ◀─────────────────────────────────────── │ rules engine + LLM judge  │
└──────────────────────────┘        report {findings + fixes}         └──────────────────────────┘

Installation

curl -fsSL https://uxlint.net/install.sh | sh    # detects OS/arch, verifies checksum

Oder mit mise – sein github-Backend zieht den passenden Build aus GitHub Releases, verifiziert ihn und aktualisiert bei mise up:

mise use -g "github:uxlint-net/uxlint-cli[rename_exe=uxlint]@latest"

oder pinne es in einer mise.toml eines Projekts:

[tools]
"github:uxlint-net/uxlint-cli" = { version = "latest", rename_exe = "uxlint" }

Oder aus dem Quellcode bauen (benötigt eine aktuelle stabile Rust-Toolchain und ein Chrome/Chromium im PATH):

git clone https://github.com/uxlint-net/uxlint-cli && cd uxlint-cli
cargo build --release
./target/release/uxlint --version

Related MCP server: mcp-a11y-service

Schnellstart

uxlint auth login                                        # opens your browser, saves a token
uxlint audit --base https://your-site.com --routes /,/pricing

Zum ersten Mal ein eigenes Projekt prüfen? uxlint init wählt (oder erstellt) eine Site, an die Berichte angehängt werden, und schreibt eine uxlint.toml, sodass jede zukünftige Prüfung in diesem Verzeichnis einfach funktioniert:

uxlint init
uxlint audit --base http://localhost:5173 --routes /,/pricing

Exit-Code 1 bei Befunden über der konfigurierten Schwere → direkt in CI einbinden (siehe .github/workflows/ für eine Vorlage oder die GitHub Action uxlint-net/uxlint-action).

Ausblenden von Elementen aus einem Audit (uxlint-hide)

Einige On-Page-Elemente sind keine Produkt-UI und sollten nicht bewertet werden: ein Dev/Staging-Umgebungsbanner, ein „DEV“-Marker, eine Debug-Symbolleiste, ein Storybook/Vorschau-Element. Fügen Sie die Klasse uxlint-hide zu einem solchen Element hinzu, und das Audit entfernt es – es ist ab dem ersten Rendern display:none, erscheint also nie in einem Screenshot und ist für den Collector unsichtbar (es erzeugt keine Befunde):

<div class="env-banner uxlint-hide">STAGING</div>

Die Klasse ist auf Ihrer echten Website wirkungslos – sie tut nichts, außer wenn das Audit läuft, weil das Stylesheet, das sie verbirgt (.uxlint-hide { display: none !important; }), nur vom Browser von uxlint injiziert wird, bevor die eigenen Skripte der Seite laufen. Gestalten Sie Ihr Element in der übrigen Zeit, wie Sie möchten. Sie gilt in jedem Erfassungspfad – beim Crawl, bei Goal-Walk-Tests und bei Fix-Vorschauen.

MCP (Verwendung aus einem Coding-Agent)

Claude Code, ein Befehl:

/plugin marketplace add uxlint-net/uxlint-cli
/plugin install uxlint@uxlint

Das installiert den uxlint-MCP-Server und, falls die CLI nicht bereits im PATH ist, lädt er die passende Version einmalig mit demselben prüfsummenverifizierenden Installer wie oben herunter – so aktualisiert /plugin update auch die darunterliegende CLI. Kein Node nötig: Es lädt eine statische Binärdatei herunter (gegen eine veröffentlichte Prüfsumme verifiziert) und steuert das bereits vorhandene Chrome.

Jeder andere Agent – eine Zeile (das npm-Paket lädt die Binärdatei für Ihre Plattform herunter, verifiziert die daneben veröffentlichte Prüfsumme und übergibt sie). Dies ist der einzige Weg, der Node 18+ benötigt, für npx selbst; wenn Sie das nicht möchten, installieren Sie die Binärdatei mit der Zeile oben und registrieren Sie diese:

claude mcp add uxlint -- npx -y @uxlint-net/uxlint mcp

Oder für einen Client, der eine JSON-Konfiguration liest:

{ "mcpServers": { "uxlint": { "command": "npx", "args": ["-y", "@uxlint-net/uxlint", "mcp"] } } }

uxlint ist auch im MCP-Registry als io.github.uxlint-net/uxlint für Clients, die darin stöbern. Haben Sie die CLI bereits? uxlint mcp install registriert sie direkt, ohne npx-Wrapper.

Es gibt kein Token, das zuerst eingerichtet werden muss: Bitten Sie Ihren Agenten, etwas zu prüfen, während Sie abgemeldet sind, und er gibt Ihnen einen Anmeldelink, der das Token für Sie erstellt und speichert (UXLINT_API_KEY ist für CI, das keinen Browser hat).

Fünf Tools: audit_url (vollständiges Audit, bewertetes Urteil + Aktionsplan), verify_fix (eine Regel auf einer Seite nach einer Bearbeitung erneut prüfen, ~2s), get_shot (annotierten Screenshot eines Befunds abrufen), ux_guidance (Best-Practice-Anleitung, die vor dem Erstellen von UI gelesen werden sollte) und lint_feedback – opt-in und standardmäßig deaktiviert (§ Datenschutz) – ein Tool für drei Arten von Signalen: ob ein Befund nützlich war, ein Lint, das uxlint fehlt, oder eine Komponentenbibliothek, die es nicht erkannt hat. Der Agent prüft, liest die Lösungen, bearbeitet und prüft erneut, bis alles grün ist.

Datenschutz & Vertrauen

Diese CLI läuft auf Ihrem Rechner und steuert einen echten Browser gegen echte Seiten, daher ist es berechtigt zu fragen, was genau sie erfasst und wohin es geht. Was wir Ihnen sagen können, weil es das ist, was der Code in diesem Repo tatsächlich tut:

  • Der Collector ist eingebaut und lesbar. Er ist in diese Binärdatei kompiliert (include_str! von assets/collector.js), sodass uxlint --version den genauen Erfassungscode festlegt und der Server zur Laufzeit nichts injizieren kann. Alles, was er erfasst, sind Seitengeometrie, sichtbarer Text, berechnete Stile und Screenshots. Für ein eingebettetes <iframe> zeichnet er nur den Host der src auf – niemals die vollständige Embed-URL, die Session-IDs und Tokens in ihrer Query-String tragen kann. Er liest niemals Ihren Quellcode oder Ihr Dateisystem über uxlint.toml hinaus. Er liest jedoch ein wenig Projekt-Herkunft und sendet sie mit dem Bericht: Ihren aktuellen Git-Commit-SHA und Branch-Namen (git rev-parse), den Hostnamen des Rechners und in GitHub Actions den Repo/PR/Commit-Link. Setzen Sie UXLINT_RUNNER, um den Hostnamen zu überschreiben.

  • Die Schwärzung von Geheimnissen und personenbezogenen Daten ist Best-Effort, keine Garantie. Bevor etwas hochgeladen wird, maskiert der Collector Text, der wie ein Token, API-Schlüssel, Passwort oder eine E-Mail-Adresse aussieht, im erfassten Seitentext und schwärzt dieselben Muster aus Konsolenprotokollen und nativen Dialogmeldungen. Alle Kanäle teilen sich eine Musterliste (assets/redact.js), sodass sie nicht auseinanderdriften können. Screenshots erhalten direkt vor der Erfassung einen zusätzlichen Durchgang: Jeder Formularfeldwert wird maskiert (Passwörter geleert, andere Eingaben durch Punkte ersetzt) und musterbasierte Geheimnisse im On-Page-Text werden entfernt, sodass eingegebene Daten und angezeigte Schlüssel nicht im Bild landen. Dieser Durchgang erreicht auch Shadow-DOM (einschließlich geschlossener Wurzeln über einen attachShadow-Interceptor) und Same-Origin-Iframes und deckt ein Cross-Origin-Iframe mit einer undurchsichtigen Box ab, da dessen Pixel nicht geschwärzt werden können. Aber die Schwärzung ist musterbasiert, und ein Screenshot ist immer noch Pixel: Beliebiger angezeigter Inhalt, den kein Muster erfasst (ein Kundenname auf der Seite, Bestelldaten), aufgeteilte Werte und alles, was in Bilder oder <canvas> gezeichnet wird, kann immer noch durchschlüpfen. Anmeldedaten, die Sie mit --header/--storage/--login-* übergeben, steuern nur Ihren Browser und werden niemals an den Server von uxlint gesendet.

    Da ein Bericht Seiten-HTML, Text und Screenshots erfasst, ist es unmöglich, vollständig zu verhindern, dass sensible Inhalte hinein gelangen. Verwenden Sie TEST-Konten, keine echten oder Produktionskonten. Für die lokale Entwicklung ist das Risiko gering, solange die Daten nur lokale Entwicklungsdaten sind. Wenn Sie eine authentifizierte Site prüfen, die echte Geheimnisse oder personenbezogene Daten enthält, überprüfen Sie, was gesendet wird, bevor Sie es senden: Verwenden Sie --dry-run, um die genaue Nutzlast (Seitentext, Herkunft und Screenshots) in einen lokalen Ordner zu schreiben und sie ohne Hochladen zu inspizieren. Schwärzung reduziert versehentliche Offenlegung; sie ist keine Sicherheitsgrenze, und Sie bleiben verantwortlich für das, worauf Sie uxlint richten.

  • Navigations-Text wird absichtlich nur auf Geheimnisse hin bereinigt. Steuerbeschriftungen, Menü- und <select>-Optionen sowie Namen von Workspace/Org-Umschaltern durchlaufen dieselben Geheimnismuster, werden aber nicht auf Namen oder andere beliebige Inhalte geschwärzt. Der Grund ist der Goal Walk: Ein Audit steuert die Seite mit einem LLM, das genau diesen Text liest, um das richtige Steuerelement zu finden, es zu bedienen und seine Auswahl zurück auf das DOM abzubilden. Das Maskieren würde den Walk zunichtemachen, weil der Richter nicht mehr zwischen zwei Optionen unterscheiden oder die von ihm gewählte anklicken könnte. Die Beschriftungen, die ein Audit zur Navigation benötigt, bleiben also lesbar, und ein echter Name, der in einer von ihnen mitläuft, wird durch die Testkonten-Regel oben abgedeckt und nicht durch Schwärzung. Dies ist ein bewusster Kompromiss: Den Goal Walk funktionsfähig zu halten, ist mehr wert, als Text zu schwärzen, den die Testkonten-Regel bereits schützt.

  • Keine Telemetrie. Diese Binärdatei tätigt ausgehende Aufrufe genau an die Hosts, die Sie ihr vorgeben: den uxlint-API-Server (--server/UXLINT_SERVER oder die standardmäßig gehostete Origin), die Site, die Sie sie prüfen lassen, und nur, wenn Sie explizit zustimmen, anonyme Regel-Feedback-Signale. Es gibt kein separates Analytics-/Crash-Reporting-/Phone-Home-Ziel, das irgendwo eingebaut ist.

  • Feedback ist opt-in, standardmäßig deaktiviert. uxlint init fragt einmal; es schreibt nur dann feedback = true in uxlint.toml, wenn Sie zustimmen, und Sie können es jederzeit wieder umstellen.

  • Der Audit-Browser verwendet ein ephemeres Profil. Jedes Audit startet Chrome mit einem frischen, wegwerfbaren Benutzerdatenverzeichnis, sodass keine Cookies, Verläufe oder Erweiterungen aus Ihrem alltäglichen Browsen jemals in die geprüfte Sitzung geladen werden und nach dem Beenden des Prozesses nichts erhalten bleibt.

  • Ihr Login bleibt lokal. uxlint auth login speichert ein Token unter ~/.config/uxlint/credentials, mit chmod 0600. Es wird nie protokolliert, nie ausgegeben (außer in einem bewussten Fall: uxlint signup gibt einen frisch erstellten Schlüssel aus, damit Sie ihn exportieren können) und nie in einen Bericht eingebunden.

Dies ist kein Ersatz für das Lesen des Quellcodes. Er ist kurz, und genau darum geht es bei der Veröffentlichung. Wenn Sie etwas finden, das nicht dieser Beschreibung entspricht, eröffnen Sie bitte ein Issue.

Was diese CLI nicht ist

Sie ist bewusst dumm: navigieren, den eingebauten Collector ausführen, den Schnappschuss hochladen, den Bericht ausgeben. Die Regeln, Schwellenwerte und das Richtermodell sind nicht in diesem Repo und werden es nie sein. Sie sind das eigentliche Produkt und leben nur serverseitig. Ein Build dieser CLI ist ohne einen uxlint-Server, mit dem er sprechen kann, nutzlos (standardmäßig der gehostete unter https://uxlint.net oder Ihr eigener).

Lizenz

Apache-Lizenz 2.0 (siehe LICENSE). Lesen Sie sie, prüfen Sie sie, forken Sie sie, bauen Sie sie aus dem Quellcode, liefern Sie sie in Ihren eigenen Tools aus – keine Bedingungen über die üblichen Namensnennungs- und Patentbestimmungen hinaus.

Dies war früher die Business Source License, die an einem Änderungsdatum im Jahr 2030 in Apache-2.0 umgewandelt wurde; wir sind einfach früher angekommen. Die Einschränkung, die sie trug – kein konkurrierender gehosteter „Audit my site“-Dienst, der auf diesem Code basiert – schützte das Falsche: Was wertvoll ist, sind die Regeln, die kalibrierten Schwellenwerte und der Richter, und die sind serverseitig und nicht in diesem Repo. Was HIER ist, ist ein Client, der einen uxlint-Server benötigt, um überhaupt etwas wert zu sein, und ein Client ist genau das Stück, das reibungslos zu installieren, zu lesen und zu vertreiben sein sollte.

Releases bis einschließlich v0.1.30 wurden unter BUSL-1.1 veröffentlicht; ab v0.1.31 gelten Apache-2.0.

Available Tools

4 tools
audit_urlA

Audit a website's UX/design: contrast, tap targets, type scale, colour discipline, copy clarity, scan patterns. Each finding returns its RULE name (pass it to verify_fix), a SOURCE file:line hint (for local audits, grepped from the project you're in), the SELECTOR, the concrete FIX, and — for copy issues — the exact text EDIT (replace X with Y).

WORKFLOW: (1) Before you change anything, call ux_guidance for the area(s) the findings touch (forms, lists, layout, copy, …) so you fix toward the idiomatic, DRY pattern — not a one-off patch. If the result names a STYLEGUIDE, open it first and build to the components/tokens it shows. (2) Open the source line and apply the SMALLEST fix that reuses the project's existing components/tokens and voice (don't add a new one-off to silence the finding) without regressing the quality floor — responsive, visible keyboard focus, reduced motion, no new layout shift — then verify_fix. (3) Iterate until green. If a lint_feedback tool is in your tool list, also send a verdict for each finding you act on — it's how rules get kept, tuned or retired. It is absent unless the project set feedback = true (via uxlint init), so don't go looking for it: this result tells you when it's there.

SAFETY: with no test plan declared, audit_url only NAVIGATES and READS. If the project's uxlint.toml declares tests that sign in as a persona, running them may SUBMIT forms and DELETE items on the target — that's what a test does (it exercises create/delete flows on your own app). Point it only at an app you own / a throwaway env, never a site you don't control.

SETUP: in a project with no uxlint.toml, this returns the exact config to write first (org/site/base/routes) — write that file, check it in, then call again. Without it a local target can't be audited at all and a public one files its report under a site nobody chose.

AUTH: for a logged-in site, DON'T pass secrets here — credentials come from the project's uxlint.toml [personas] (the local client replays them; nothing touches this tool call or the transcript). If the audit hits a login wall, this tool returns the exact setup instructions.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseNoBase URL to audit — an ORIGIN like http://localhost:5173, NOT a path (a path gets appended to every route and mis-crawls). Optional: omit to use the `base` in the project's uxlint.toml.
crawlNoMax routes to discover and audit from the seeds (default 12). Set 0 to audit only the given routes.
judgeNoRun the AI copy/design judge (prose quality, test-run navigation). ON by default; set false for a fast, deterministic-only pass while iterating.
testsNoRun the site's declared tests (whole-site reachability). ON by default; auto-scoped to crawling audits. Set false to skip for speed. Tests are a paid-plan feature — on a free plan, tests declared but not run print a one-line skip warning instead.
routesNoComma-separated routes (default /)
statesNoDrive hover/focus/keyboard interaction states — catches dead hover styles, hover-only content unreachable by touch/keyboard, illogical focus order, keyboard traps, form-validation gaps. ON by default; set false to skip it (faster) on large public crawls.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and fully satisfies it: it states default read-only behavior, warns about potential form submission and deletion when tests run, explains setup/config requirements, and clarifies auth handling (no secrets passed). It also discloses the return of setup instructions when uxlint.toml is missing.

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 description is long but well-structured with clear sections (WORKFLOW, SAFETY, SETUP, AUTH) and front-loaded with the core purpose. Some redundancy exists (e.g., verify_fix mentioned multiple times), but the detail is justified given the tool's complexity and absence of annotations.

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?

Given the tool's complexity, lack of annotations, and no output schema, the description is exceptionally complete. It covers what it does, what findings return, sequenced workflow, safety and auth behaviors, setup requirements, and integration with other tools, leaving no critical gaps for an agent to understand and invoke correctly.

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?

The input schema already provides comprehensive descriptions for all 6 parameters (100% coverage), so the baseline is 3. The tool description adds only indirect context (e.g., workflow references base and crawl) without significantly expanding parameter semantics beyond the schema.

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 ('Audit a website's UX/design') and enumerates concrete audit dimensions (contrast, tap targets, type scale, etc.). It clearly distinguishes itself from sibling tools like get_shot, ux_guidance, and verify_fix by focusing on the full audit and its findings.

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 WORKFLOW section explicitly prescribes when to use this tool and how to sequence it with ux_guidance and verify_fix. It also includes safety guidance (only point at owned apps) and notes when lint_feedback exists, covering both when and when not to use certain behaviors.

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

get_shotA

View a report's annotated screenshot — the flagged element boxed on its page. Reports are PRIVATE, so a finding's screenshot_url can't be fetched with a plain GET; this tool fetches it with your uxlint login. Pass the finding's screenshot_url (from audit_url / verify_fix). Returns the image inline (if your client renders MCP images) and always writes it to a local file whose path you can open/Read.

ParametersJSON Schema
NameRequiredDescriptionDefault
screenshot_urlYesThe `screenshot_url` from an audit_url / verify_fix finding — the annotated shot with the flagged element boxed. A full URL or a `/r/…` path on your uxlint server.

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that reports are PRIVATE, reads requires the user's uxlint login, returns image inline (if client supports MCP images), and always writes to a local file. This adds significant behavioral context beyond what an annotation might provide, such as side effects (writing a file) and authentication requirements. The only minor gap is not detailing the exact file path or cleanup behavior, but the description is quite transparent.

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 concise (about 3 sentences) and front-loads the core action. Every sentence provides essential information: purpose, why it's needed, what to pass, and what happens. No fluff or redundancy. The structure is logical: what, why, how, outcome.

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?

Given that there is only one parameter, no output schema, and no annotations, the description is complete. It covers the tool's purpose, usage, parameter source, return behavior (inline and local file), and the limitation about private reports. This is sufficient for an agent to select and correctly invoke the tool.

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% and it already explains the screenshot_url parameter clearly. The description adds contextual meaning by tying the parameter to the finding's screenshot_url and specifying the source (audit_url/verify_fix). It also clarifies that the URL can be a full URL or a /r/… path. This adds value beyond the schema, so a slightly above baseline score is warranted.

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 clearly states the tool's purpose: to view a report's annotated screenshot, with the flagged element boxed. It also distinguishes it from siblings by explaining why a plain GET won't work and that it requires the finding's screenshot_url. The verb 'View' and specific resource 'report's annotated screenshot' are precise.

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 explicitly explains when to use this tool (to fetch a screenshot_url from audit_url/verify_fix findings) and why it's necessary (reports are private, plain GET won't work). It also provides context that the screenshot URL comes from specific sources, serving as an alternative to direct fetching. This is exactly the kind of usage guidance expected.

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

ux_guidanceA

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. 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, and copy that reads as UI (active voice, honest labels, useful empty/error states). 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicNoWhich area to get guidance for: layout, forms, lists, navigation, components, performance, accessibility, content. 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.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It fully explains the tool is a read-only reference, details its fallback behavior for unrecognized topics, and notes it returns guidance content without side effects. No hidden be­havioral traits remain undisclosed.

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 description is long but well-structured; it opens with the main use case, specifies the covered patterns, and clarifies the auditing feedback loop. While it includes additional detail than strictly necessary, that extra context is valuable for guiding topic selection and instrumental in avoiding misunderstandings.

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?

Given the tool's simplicity (one parameter, no output schema), the description is complete. It explains the purpose, usage flow, content scope, behavior with invalid input, and connection to sibling tool. No significant information is missing for an agent to invoke and interpret the tool correctly.

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?

The schema description already fully explains the topic parameter (available values, aliases, fallback). The description adds illustrative examples (layout, forms, etc.) and mentions specific patterns but does not contribute new semantic meaning beyond what the schema already provides. Given the high schema description coverage (100%), a baseline score 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 clearly states the tool provides best-practice UI guidance to read before building or changing UI, specifying the resource ('guidance') and the action ('read'). It distinguishes itself from sibling tools like audit_url and get_shot by focusing on pre-empting audit findings rather than auditing screenshots.

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 explicitly couples the guidance with a workflow: read the topic before building, then confirm with audit_url. This clearly contrasts with the sibling options for when to use this tool, providing practical 'when to use' and 'when not to use' context.

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

verify_fixA

After editing to fix a finding, re-check ONE rule on ONE page — the 'did my fix land?' loop, far quicker than a full re-audit (one route, no crawl, no judge). Returns whether the rule still fires, AND names any OTHER deterministic findings now on that page (the regression guard — so a fix that clears your rule but breaks something else here doesn't read as all-clear). It's a fast deterministic pass: for the whole-page picture incl. judge/state checks, re-run audit_url. SCOPE: a clear verdict covers the ONE page it loads. A rule whose input is the whole site — a component inventory, the link graph, cross-page consistency — can pass here and still fire in a full audit, so confirm those with audit_url before calling them done.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseNoBase URL — an ORIGIN like http://localhost:5173, NOT a path. Optional: omit to use the `base` in the project's uxlint.toml.
ruleYesThe rule to verify is gone, e.g. contrast, tap-target, unlabelled-field
routeNoThe route to check, e.g. /pricing (default /)
statesNoDrive interaction states (needed for state/form/interaction rules)

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that this is fast, deterministic, has no crawl and no judge, returns whether the rule still fires plus other deterministic findings, and warns that whole-site rules can pass here but still fail a full audit. The scope limitation ('clear verdict covers the ONE page it loads') is clearly stated.

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 longer than average but every sentence earns its place: purpose, return behavior, regression-guard semantics, alternative tool routing, and scope caveats. The most decision-relevant info is front-loaded, and the caveats are deliberately packaged at the end.

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?

Despite having no output schema and no annotations, the description is complete for an agent to select and invoke the tool correctly: it states what triggers usage, what is returned, what the tool does not do, and when to fall back to audit_url. No critical decision or invocation detail is missing.

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 description coverage is 100%, so the schema already fully documents base, rule, route, and states. The description reinforces the conceptual 'one rule on one page' model but adds no parameter-level meaning beyond the schema, so the 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?

The description states a specific verb (re-check/verify), resource (ONE rule on ONE page), and the exact workflow context ('After editing to fix a finding'). It explicitly distinguishes itself from a full re-audit and from the sibling audit_url, making the tool's purpose unmistakable.

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 says exactly when to use it (the 'did my fix land?' loop after an edit) and when not to use it (for whole-page pictures, judge/state checks, or whole-site rules, re-run audit_url). This is explicit, actionable routing guidance that names the alternative tool and the condition that selects it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updates
    • First observedaudit_url
    • First observedget_shot
    • First observedux_guidance
    • First observedverify_fix
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool occupies a distinct step in the workflow: audit_url runs the audit, ux_guidance provides upfront guidance, get_shot shows a report's screenshot, and verify_fix re-checks a single rule. The descriptions clearly separate the full audit from the single-rule verification loop, so there is no realistic confusion between them.

Naming Consistency4/5

Three tools are verb-first snake_case names (audit_url, get_shot, verify_fix), but ux_guidance is a noun phrase and does not start with a verb. The naming is still consistent in style and readable, despite this one deviation.

Tool Count5/5

Four tools is a well-scoped set for the server's purpose: every tool maps directly to one stage of the UX audit workflow. There are no redundant or too many tools, and none feel trivial.

Completeness4/5

The set covers the core workflow: guidance, audit, screenshot inspection, and fix verification. The only minor gap is the absence of a tool to list previously generated private reports without re-running an audit, but the documented workflow can still be completed.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • polaris-audit

    cnohall
    A
    license
    A
    quality
    D
    maintenance
    Audit any website for privacy, security, accessibility, and performance issues — with scores, grades, and actionable fix instructions. No account required.
    3
    13
    MIT

  • mcp-a11y-service

    alan-ho
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables automated WCAG 2.2 AA accessibility audits of Figma designs and webpages. Generates detailed markdown reports with severity-grouped violations, specific criterion references, and concrete fix recommendations.
    -
  • Prufa by prufa-dev

    Prufaofficial

    prufa-dev
    A
    license
    A
    quality
    A
    maintenance
    Point your coding agent at a URL and get a real-browser QA audit: broken signup/login/checkout flows, JS console errors, missing analytics, consent + security headers, mobile tap targets, and accessibility — returned as machine-verified findings graded A-F.
    44
    2
    Apache 2.0

  • Designesy

    LE-VAI
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to score live URLs against a 40-check design contract, validate DTCG tokens and Lottie animations, audit accessibility, and retrieve design-system contracts, catalogs, and review rubrics.
    35
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uxlint-net/uxlint-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server