Skip to main content
Glama
deenesjakoruzh
uxlint-net

uxlint

Official
by uxlint-net
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

uxlint

Проверяйте UX любого сайта так, как это сделал бы разбирающийся в дизайне рецензент: контраст, области нажатия, типографическая шкала, дисциплина цвета, паттерны сканирования, ориентиры. Каждое замечание сопровождается конкретным исправлением, которое агент (или человек) может применить напрямую. Инструмент создан для работы в цикле кодинг-агента (MCP) и итераций до получения зелёного результата.

Агент проверяет страницу с ценами, получает ошибку контраста и замечание о цветовом конфликте с исправлениями для каждого, применяет их, перепроверяет правило и повышает оценку страницы с B до A

Реальный прогон от начала до конца: audit_url → оценка B, ошибка контраста 2.39:1 и три CTA в трёх разных акцентных оттенках → исправление → verify_fix → оценка A. Каждое число в нём получено от инструментов; вырезано только ожидание.

Это CLI: небольшой единый статический Rust-бинарник. Он управляет Chrome/Chromium, который у вас уже установлен, через протокол DevTools (без Node, без Playwright, без загрузки headless-браузера), собирает то, как страница выглядит и читается, и отправляет это на хостируемый сервер uxlint, который и выполняет фактическую оценку. Движок правил, калиброванные пороги и LLM-судья живут на стороне сервера, поэтому клиенту никогда не требуется обновление при изменении правил.

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

Установка

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

Или через mise — его бэкенд github подтягивает подходящую сборку из GitHub Releases, проверяет её и обновляет по mise up:

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

или закрепите его в mise.toml проекта:

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

Или соберите из исходников (нужен свежий стабильный Rust-тулчейн и Chrome/Chromium в 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

Быстрый старт

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

Впервые проверяете собственный проект? uxlint init выбирает (или создаёт) сайт, к которому будут привязываться отчёты, и записывает uxlint.toml, чтобы каждая будущая проверка в этой директории просто работала:

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

Код выхода 1 при замечаниях выше заданного уровня серьёзности → встраивается прямо в CI (см. .github/workflows/ для шаблона или GitHub Action uxlint-net/uxlint-action).

Скрытие элементов из проверки (uxlint-hide)

Некоторые элементы страницы не являются UI продукта и не должны оцениваться: баннер dev/staging-окружения, маркер «DEV», отладочная панель, аффорданс Storybook/предпросмотра. Добавьте класс uxlint-hide любому такому элементу, и проверка его удалит — он получает display:none с первой отрисовки, поэтому никогда не появляется на скриншоте и невидим для коллектора (он не порождает замечаний):

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

Класс инертен на вашем реальном сайте — он ничего не делает, пока не запущена проверка, потому что таблица стилей, которая его скрывает (.uxlint-hide { display: none !important; }), внедряется только браузером uxlint, до выполнения собственных скриптов страницы. В остальное время стилизуйте элемент как угодно. Он применяется во всех путях захвата — при обходе, в goal-walk-тестах и в предпросмотрах исправлений.

MCP (использование из кодинг-агента)

Claude Code, одна команда:

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

Это устанавливает MCP-сервер uxlint и, если CLI ещё нет в PATH, один раз загружает подходящую версию тем же установщиком с проверкой контрольной суммы, что и выше — так что /plugin update обновляет и CLI под ним. Node не нужен: загружается один статический бинарник (проверенный по опубликованной контрольной сумме) и управляется уже имеющийся Chrome.

Любой другой агент — одна строка (npm-пакет загружает бинарник для вашей платформы, проверяет контрольную сумму, опубликованную рядом, и передаёт управление). Это единственный путь, которому нужен Node 18+, для самого npx; если не хотите, установите бинарник командой вверху и зарегистрируйте его:

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

Или для клиента, который читает JSON-конфиг:

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

uxlint также есть в MCP Registry как io.github.uxlint-net/uxlint, для клиентов, которые его просматривают. Уже есть CLI? uxlint mcp install регистрирует его напрямую, без npx-обёртки.

Настраивать токен заранее не нужно: попросите агента проверить что-нибудь в состоянии выхода из аккаунта, и он выдаст вам ссылку для входа, которая создаст и сохранит токен за вас (UXLINT_API_KEY — для CI, где нет браузера).

Пять инструментов: audit_url (полная проверка, оценка с вердиктом + план действий), verify_fix (перепроверка одного правила на одной странице после правки, ~2 с), get_shot (получение аннотированного скриншота замечания), ux_guidance (рекомендации по лучшим практикам для чтения до создания UI) и lint_feedback — опциональный и по умолчанию выключенный (§ Конфиденциальность) — один инструмент для трёх видов сигналов: было ли замечание полезным, какое правило uxlint упускает, или какую библиотеку компонентов он не распознал. Агент проверяет, читает исправления, правит и перепроверяет, пока не станет зелёным.

Конфиденциальность и доверие

Этот CLI работает на вашей машине и управляет настоящим браузером против настоящих страниц, поэтому справедливо спросить, что именно он захватывает и куда это уходит. Что мы можем сказать, потому что именно это делает код в этом репозитории:

  • Коллектор встроен и читаем. Он скомпилирован в этот бинарник (include_str! из assets/collector.js), так что uxlint --version фиксирует точный код захвата, и сервер не может ничего внедрить во время выполнения. Всё, что он захватывает, — это геометрия страницы, видимый текст, вычисленные стили и скриншоты. Для встроенного <iframe> он записывает только хост src — никогда полный URL встраивания, который может нести идентификаторы сессий и токены в строке запроса. Он никогда не читает ваш исходный код или файловую систему, кроме uxlint.toml. Он читает немного провенанса проекта и отправляет его с отчётом: текущий git-коммит sha и имя ветки (git rev-parse), имя хоста машины и, в GitHub Actions, ссылку на репозиторий/PR/коммит. Установите UXLINT_RUNNER, чтобы переопределить имя хоста.

  • Редактирование секретов и PII — best-effort, а не гарантия. Перед загрузкой чего-либо коллектор маскирует текст, который выглядит как токен, API-ключ, пароль или email-адрес в захваченном тексте страницы, и редактирует те же паттерны в логах консоли и сообщениях нативных диалогов. Все каналы используют один список паттернов (assets/redact.js), чтобы они не расходились. Скриншоты получают дополнительный проход прямо перед захватом: каждое значение поля формы маскируется (пароли затираются, другие поля заменяются точками), а совпавшие с паттернами секреты в тексте страницы вычищаются, чтобы введённые данные и отображаемые ключи не попали в изображение. Этот проход проникает в shadow DOM (включая закрытые корни, через перехватчик attachShadow) и same-origin iframe, а cross-origin iframe закрывается непрозрачным прямоугольником, так как его пиксели нельзя отредактировать. Но редактирование основано на паттернах, а скриншот — это всё же пиксели: произвольный отображаемый контент, который не ловится ни одним паттерном (имя клиента на странице, данные заказа), разбитые значения и всё, что нарисовано в изображениях или <canvas>, всё равно может проскочить. Учётные данные, которые вы передаёте через --header/--storage/--login-*, управляют вашим браузером и никогда не отправляются на сервер uxlint.

    Поскольку отчёт захватывает HTML страницы, текст и скриншоты, невозможно полностью защититься от утечки чувствительного контента в него. Используйте ТЕСТОВЫЕ аккаунты, а не реальные или продакшн. Для локальной разработки риск низок, если данные — только локальные данные разработки. Когда вы проверяете аутентифицированный сайт с реальными секретами или персональными данными, просмотрите, что отправляется, перед отправкой: используйте --dry-run, чтобы записать точный payload (текст страницы, провенанс и скриншоты) в локальную папку и просмотреть его без загрузки. Редактирование снижает случайное раскрытие; это не граница безопасности, и вы несёте ответственность за то, на что направляете uxlint.

  • Навигационный текст вычищается только от секретов, намеренно. Метки элементов управления, пункты меню и <select>, имена переключателей workspace/org проходят через те же паттерны секретов, но не редактируются от имён или другого произвольного контента. Причина — goal walk: проверка управляет страницей с помощью LLM, который читает именно этот текст, чтобы найти нужный элемент управления, оперировать им и сопоставить свой выбор с DOM. Маскировка сломала бы walk, потому что судья больше не смог бы отличить два варианта или кликнуть по выбранному. Поэтому метки, которые нужны проверке для навигации, остаются читаемыми, а реальное имя, которое попадает в одну из них, покрывается правилом тестовых аккаунтов выше, а не редактированием. Это осознанный компромисс: сохранить goal walk работающим важнее, чем затереть текст, который правило тестовых аккаунтов уже защищает.

  • Никакой телеметрии. Этот бинарник совершает исходящие вызовы только на те хосты, которые вы ему указываете: API-сервер uxlint (--server/UXLINT_SERVER, или хостинг по умолчанию), сайт, который вы просите проверить, и, только если вы явно согласились, анонимные сигналы обратной связи по правилам. Никакого отдельного analytics/crash-reporting/phone-home назначения нигде не встроено.

  • Обратная связь — opt-in, по умолчанию выключена. uxlint init спрашивает один раз; он записывает feedback = true в uxlint.toml только если вы согласились, и вы можете переключить обратно в любой момент.

  • Браузер проверки использует эфемерный профиль. Каждая проверка запускает Chrome со свежей, одноразовой директорией user-data, поэтому никакие cookies, история или расширения из вашего повседневного браузинга никогда не загружаются в проверяемую сессию, и ничего не сохраняется после завершения процесса.

  • Ваш логин остаётся локальным. uxlint auth login хранит токен в ~/.config/uxlint/credentials, с chmod 0600. Он никогда не логируется, не печатается (кроме одного намеренного случая: uxlint signup печатает свежесозданный ключ, чтобы вы могли его экспортировать) и никогда не включается в отчёт.

Это не замена чтению исходников. Он короткий, и в этом суть публикации. Если вы найдёте что-то, что не соответствует этому описанию, пожалуйста, откройте issue.

Что этот CLI не делает

Он намеренно тупой: навигация, запуск встроенного коллектора, загрузка снимка, печать отчёта. Правила, пороги и модель судьи не в этом репозитории и никогда не будут. Это и есть настоящий продукт, и они живут только на стороне сервера. Сборка этого CLI бесполезна без сервера uxlint, с которым можно говорить (хостинг по умолчанию https://uxlint.net или ваш собственный).

Лицензия

Apache License 2.0 (см. LICENSE). Читайте, проверяйте, форкайте, собирайте из исходников, встраивайте в свои инструменты — без условий, кроме обычных атрибуции и патентных условий.

Раньше это была Business Source License, которая конвертировалась в Apache-2.0 на Change Date в 2030 году; мы просто пришли раньше. Ограничение, которое она несла — никакого конкурирующего хостинг-сервиса «проверь мой сайт», построенного на этом коде — защищало не то: ценность в правилах, калиброванных порогах и судье, а они на стороне сервера и не в этом репозитории. Здесь — клиент, который без сервера uxlint ничего не стоит, а клиент — это именно та часть, которая должна быть без трения устанавливаться, читаться и встраиваться.

Релизы до v0.1.30 включительно были опубликованы под BUSL-1.1; v0.1.31 и далее — 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