Skip to main content
Glama
deenesjakoruzh
uxlint-net

uxlint

Official
by uxlint-net
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

uxlint

Audit any website's UX the way a design-literate reviewer would: contrast, tap targets, type scale, colour discipline, scan patterns, landmarks. Every finding comes with a prescriptive fix an agent (or a human) can apply directly. It's designed to sit in a coding agent's loop (MCP) and be iterated against until green.

An agent audits a pricing page, gets a contrast error and a colour-clash finding with fixes for each, applies them, re-checks the rule, and re-grades the page from B to A

A real run, start to finish: audit_url → Grade B, a 2.39:1 contrast error and three CTAs in three different accent hues → the fix → verify_fix → Grade A. Every number in it came back from the tools; only the waiting was cut.

This is the CLI: a small, single static Rust binary. It drives a Chrome/Chromium you already have installed over the DevTools protocol (no Node, no Playwright, no headless-browser download), captures what a page looks and reads like, and sends that to uxlint's hosted server, which does the actual grading. The rules engine, the calibrated thresholds, and the LLM judge all live server-side, so the client never needs updating when a rule changes.

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

Install

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

Or with mise — its github backend pulls the matching build from GitHub Releases, verifies it, and updates on mise up:

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

or pin it in a project's mise.toml:

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

Or build from source (needs a recent stable Rust toolchain and a Chrome/Chromium on 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

Quickstart

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

First time auditing your own project? uxlint init picks (or creates) a site to attach reports to and writes a uxlint.toml so every future audit in this directory just works:

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

Exit code 1 on findings above the configured severity → drop it straight into CI (see .github/workflows/ for a template, or the uxlint-net/uxlint-action GitHub Action).

Hiding elements from an audit (uxlint-hide)

Some on-page chrome isn't product UI and shouldn't be judged: a dev/staging environment banner, a "DEV" marker, a debug toolbar, a Storybook/preview affordance. Add the class uxlint-hide to any such element and the audit removes it — it's display:none from first paint, so it never appears in a screenshot and is invisible to the collector (it seeds no findings):

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

The class is inert on your real site — it does nothing unless the audit is running, because the stylesheet that hides it (.uxlint-hide { display: none !important; }) is injected only by uxlint's browser, before the page's own scripts run. Style your element however you like the rest of the time. It applies in every capture path — the crawl, goal-walk tests, and fix previews.

MCP (use it from a coding agent)

Claude Code, one command:

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

That installs the uxlint MCP server and, if the CLI isn't already on your PATH, fetches the matching version once with the same checksum-verifying installer as above — so /plugin update updates the CLI underneath it too. No Node needed: it downloads one static binary (verified against a published checksum) and drives the Chrome you already have.

Any other agent — one line (the npm package fetches the binary for your platform, verifies the checksum published beside it, and hands over). This is the only route that needs Node 18+, for npx itself; if you'd rather not, install the binary with the line at the top and register that:

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

Or, for a client that reads a JSON config:

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

uxlint is also in the MCP Registry as io.github.uxlint-net/uxlint, for clients that browse it. Already have the CLI? uxlint mcp install registers it directly, no npx wrapper.

There is no token to set up first: ask your agent to audit something while signed out and it hands you a sign-in link that mints and saves the token for you (UXLINT_API_KEY is for CI, which has no browser).

Five tools: audit_url (full audit, graded verdict + action plan), verify_fix (recheck one rule on one page after an edit), get_shot (fetch a finding's annotated screenshot), ux_guidance (best-practice guidance to read before building UI), and lint_feedback — opt-in and off by default (§ Privacy) — one tool for three kinds of signal: whether a finding was useful, a lint uxlint is missing, or a component library it didn't recognise. The agent audits, reads the fixes, edits, and re-audits until green.

Privacy & trust

This CLI runs on your machine and drives a real browser against real pages, so it's fair to ask exactly what it captures and where it goes. What we can tell you, because it's what the code in this repo actually does:

  • The collector is baked in and readable. It's compiled into this binary (include_str! of assets/collector.js), so uxlint --version pins the exact capture code and the server can't inject anything at run time. Everything it captures is page geometry, visible text, computed styles, and screenshots. For an embedded <iframe> it records the src's host only — never the full embed URL, which can carry session ids and tokens in its query string. It never reads your source code or your filesystem beyond uxlint.toml. It does read a little project provenance and send it with the report: your current git commit sha and branch name (git rev-parse), the machine's hostname, and, in GitHub Actions, the repo/PR/commit link. Set UXLINT_RUNNER to override the hostname.

  • Secret & PII redaction is best-effort, not a guarantee. Before anything is uploaded, the collector masks text that looks like a token, API key, password, or email address in captured page text, and redacts the same patterns from console logs and native dialog messages. All channels share one pattern list (assets/redact.js), so they can't drift. Screenshots get an extra pass right before capture: every form field value is masked (passwords blanked, other inputs replaced with dots) and pattern-matched secrets in on-page text are scrubbed, so typed data and displayed keys don't land in the image. That pass reaches into shadow DOM (including closed roots, via an attachShadow interceptor) and same-origin iframes, and covers a cross-origin iframe with an opaque box since its pixels can't be redacted. But redaction is pattern-based, and a screenshot is still pixels: arbitrary displayed content that no pattern catches (a customer name on the page, order data), split-up values, and anything drawn into images or <canvas> can still slip through. Credentials you pass with --header/--storage/--login-* drive your browser only and are never sent to uxlint's server.

    Because a report captures page HTML, text, and screenshots, it is impossible to fully guard against sensitive content leaking into it. Use TEST accounts, not real or production ones. For local development the risk is low, as long as the data is only local development data. When you audit an authenticated site that holds real secrets or personal data, review what gets sent before you send it: use --dry-run to write the exact payload (page text, provenance, and screenshots) to a local folder and inspect it without uploading. Redaction reduces accidental exposure; it is not a security boundary, and you remain responsible for what you point uxlint at.

  • Navigational text is scrubbed for secrets only, on purpose. Control labels, menu and <select> options, and workspace/org switcher names run through the same secret patterns, but they are not redacted for names or other arbitrary content. The reason is the goal walk: an audit drives the page with an LLM that reads exactly this text to find the right control, operate it, and match its choice back to the DOM. Masking it would defeat the walk, because the judge could no longer tell two options apart or click the one it picked. So the labels an audit needs to navigate stay readable, and a real name that rides along in one of them is covered by the test-accounts rule above rather than by redaction. This is a deliberate trade: keeping the goal walk working is worth more than blanking text the test-accounts rule already protects.

  • No telemetry. This binary makes outbound calls to exactly the hosts you tell it to: the uxlint API server (--server/UXLINT_SERVER, or the default hosted origin), the site you ask it to audit, and, only if you explicitly opt in, anonymous rule-feedback signals. There is no separate analytics/crash-reporting/phone-home destination baked in anywhere.

  • Feedback is opt-in, off by default. uxlint init asks once; it only ever writes feedback = true to uxlint.toml if you say yes, and you can flip it back at any time.

  • The audit browser uses an ephemeral profile. Each audit launches Chrome with a fresh, throwaway user-data directory, so no cookies, history, or extensions from your everyday browsing are ever loaded into the audited session, and nothing persists after the process exits.

  • Your login stays local. uxlint auth login stores a token at ~/.config/uxlint/credentials, chmod'd 0600. It's never logged, never printed (except the one deliberate case: uxlint signup prints a freshly minted key so you can export it), and never bundled into a report.

This isn't a substitute for reading the source. It's short, and that's rather the point of publishing it. If you find something that doesn't match this description, please open an issue.

What this CLI is not

It's deliberately dumb: navigate, run the baked-in collector, upload the snapshot, print the report. The rules, thresholds, and judge model are not in this repo and never will be. They're the actual product, and they live server-side only. A build of this CLI is useless without a uxlint server to talk to (the hosted one at https://uxlint.net by default, or your own).

License

Apache License 2.0 (see LICENSE). Read it, audit it, fork it, build it from source, ship it inside your own tooling — no conditions beyond the usual attribution and patent terms.

This used to be the Business Source License, which converted to Apache-2.0 on a Change Date in 2030; we've simply arrived early. The restriction it carried — no competing hosted "audit my site" service built on this code — was protecting the wrong thing: what's valuable is the rules, the calibrated thresholds and the judge, and those are server-side and not in this repo. What IS here is a client that needs a uxlint server to be worth anything, and a client is exactly the piece that should be frictionless to install, read and vendor.

Releases up to and including v0.1.30 were published under BUSL-1.1; v0.1.31 onward are 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