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のコントラストエラー、および3つの異なるアクセント色相の3つのCTA → 修正 → verify_fix → グレードA。その中のすべての数値はツールから返ってきたもので、カットされたのは待ち時間だけです。

これはCLIです。単一の静的Rustバイナリの小さなものです。すでにインストールされているChrome/ChromiumをDevToolsプロトコル経由で駆動し（Node不要、Playwright不要、ヘッドレスブラウザのダウンロード不要）、ページの見た目と読み取り内容をキャプチャして、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ツールチェーンとPATH上のChrome/Chromiumが必要です）:

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/、またはuxlint-net/uxlint-action GitHub Actionを参照）。

監査からの要素の非表示（uxlint-hide）

ページ上のクロームの一部は製品UIではなく、判断されるべきではありません。開発/ステージング環境バナー、「DEV」マーカー、デバッグツールバー、Storybook/プレビューのアフォーダンスなどです。そのような要素にクラス**uxlint-hide**を追加すると、監査はそれを削除します — 最初のペイントからdisplay:noneになるため、スクリーンショットに表示されず、コレクターからも見えません（指摘を生成しません）:

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

このクラスは実際のサイトでは不活性です — 監査が実行されている場合を除いて何もしません。なぜなら、それを非表示にするスタイルシート（.uxlint-hide { display: none !important; }）は、ページ自身のスクリプトが実行される前に、uxlintのブラウザによってのみ注入されるからです。それ以外の時間は、要素を好きなようにスタイルできます。これはすべてのキャプチャパス（クロール、ゴールウォークテスト、修正プレビュー）に適用されます。

MCP（コーディングエージェントから使用）

Claude Code、1コマンド:

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

これによりuxlint MCPサーバーがインストールされ、CLIがまだPATHにない場合は、上記と同じチェックサム検証インストーラーで一致するバージョンが一度だけフェッチされます — そのため/plugin updateはその下のCLIも更新します。Nodeは不要です: 1つの静的バイナリ（公開されたチェックサムに対して検証済み）をダウンロードし、すでに持っているChromeを駆動します。

その他のエージェント — 1行（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レジストリにもio.github.uxlint-net/uxlintとして登録されており、それを参照するクライアント向けです。すでにCLIをお持ちですか？ uxlint mcp installでnpxラッパーなしで直接登録できます。

最初に設定するトークンはありません: サインアウトした状態でエージェントに何かを監査させると、トークンを生成して保存するサインインリンクが渡されます（UXLINT_API_KEYはCI用で、ブラウザがありません）。

5つのツール: audit_url（完全な監査、グレード付きの判定+アクションプラン）、verify_fix（編集後に1ページで1つのルールを再チェック、約2秒）、get_shot（指摘の注釈付きスクリーンショットを取得）、ux_guidance（UIを構築する前に読むべきベストプラクティスガイダンス）、そしてlint_feedback — オプトインでデフォルトではオフ（§プライバシー）— 3種類のシグナルのための1つのツール: 指摘が役に立ったかどうか、uxlintが欠落しているlint、認識されなかったコンポーネントライブラリ。エージェントは監査し、修正を読み、編集し、グリーンになるまで再監査します。

プライバシーと信頼

このCLIはあなたのマシンで実行され、実際のページに対して実際のブラウザを駆動するため、正確に何をキャプチャしてどこに送信するのかを尋ねるのは当然です。私たちが伝えられることは、このリポジトリのコードが実際に行うことだからです:

  • コレクターは組み込まれており、読み取り可能です。 このバイナリにコンパイルされています（assets/collector.jsのinclude_str!）ので、uxlint --versionは正確なキャプチャコードを固定し、サーバーは実行時に何も注入できません。キャプチャするものはすべて、ページのジオメトリ、表示テキスト、計算済みスタイル、スクリーンショットです。埋め込まれた<iframe>については、srcのホストのみを記録します — クエリ文字列にセッションIDやトークンを含む可能性のある完全な埋め込みURLは決して記録しません。ソースコードやuxlint.toml以外のファイルシステムを読み取ることはありません。少しのプロジェクトの来歴を読み取り、レポートとともに送信します: 現在のgitコミットSHAとブランチ名（git rev-parse）、マシンのホスト名、そしてGitHub Actionsではリポジトリ/PR/コミットリンク。UXLINT_RUNNERを設定してホスト名を上書きできます。

  • シークレットとPIIの編集はベストエフォートであり、保証ではありません。 何かをアップロードする前に、コレクターはキャプチャされたページテキスト内のトークン、APIキー、パスワード、メールアドレスのように見えるテキストをマスクし、コンソールログとネイティブダイアログメッセージから同じパターンを編集します。すべてのチャネルが1つのパターンリスト（assets/redact.js）を共有するため、ドリフトできません。スクリーンショットはキャプチャの直前に追加のパスを受けます: すべてのフォームフィールド値がマスクされ（パスワードはブランク、その他の入力はドットに置換）、ページ上のテキスト内のパターンマッチするシークレットがスクラブされるため、入力されたデータと表示されたキーが画像に含まれません。そのパスはシャドウDOM（attachShadowインターセプターによるクローズドルートを含む）と同一オリジンのiframeに到達し、クロスオリジンのiframeはそのピクセルを編集できないため不透明なボックスで覆われます。しかし、編集はパターンベースであり、スクリーンショットは依然としてピクセルです: パターンが捕捉しない任意の表示コンテンツ（ページ上の顧客名、注文データ）、分割された値、画像や<canvas>に描画されたものはすり抜ける可能性があります。--header/--storage/--login-*で渡す資格情報はあなたのブラウザのみを駆動し、uxlintのサーバーには決して送信されません。

    レポートはページのHTML、テキスト、スクリーンショットをキャプチャするため、機密コンテンツがレポートに漏れるのを完全に防ぐことは不可能です。実際のアカウントや本番アカウントではなく、テストアカウントを使用してください。 ローカル開発では、データがローカル開発データのみである限り、リスクは低いです。実際のシークレットや個人データを保持する認証済みサイトを監査する場合は、送信する前に何が送信されるかを確認してください: --dry-runを使用して正確なペイロード（ページテキスト、来歴、スクリーンショット）をローカルフォルダに書き込み、アップロードせずに検査します。編集は偶発的な露出を減らしますが、セキュリティ境界ではなく、uxlintを向ける対象に対してあなたが責任を負います。

  • ナビゲーションテキストは意図的にシークレットのみスクラブされます。 コントロールラベル、メニューと<select>のオプション、ワークスペース/組織スイッチャー名は同じシークレットパターンを通過しますが、名前やその他の任意のコンテンツに対しては編集されません。その理由はゴールウォークです: 監査はLLMでページを駆動し、LLMは正確にこのテキストを読んで正しいコントロールを見つけ、操作し、その選択をDOMにマッチさせます。マスキングするとウォークが機能しなくなります。なぜなら、ジャッジが2つのオプションを区別したり、選択したものをクリックしたりできなくなるからです。したがって、監査がナビゲートするために必要なラベルは読み取り可能なままであり、その1つに含まれる実際の名前は、編集ではなく上記のテストアカウントルールでカバーされます。これは意図的なトレードオフです: ゴールウォークを機能させ続けることは、テストアカウントルールがすでに保護しているテキストをブランクにするよりも価値があります。

  • テレメトリはありません。 このバイナリは、あなたが指示したホストにのみアウトバウンドコールを行います: uxlint APIサーバー（--server/UXLINT_SERVER、またはデフォルトのホスト型オリジン）、監査を依頼したサイト、そして明示的にオプトインした場合のみ、匿名のルールフィードバックシグナル。別の分析/クラッシュレポート/電話ホーム先はどこにも組み込まれていません。

  • フィードバックはオプトインで、デフォルトではオフです。 uxlint initは一度だけ尋ねます。feedback = trueをuxlint.tomlに書き込むのは、あなたが「はい」と言った場合のみで、いつでも戻せます。

  • 監査ブラウザは一時的なプロファイルを使用します。 各監査はChromeを新しい使い捨てのユーザーデータディレクトリで起動するため、日常のブラウジングからのCookie、履歴、拡張機能が監査セッションに読み込まれることはなく、プロセス終了後に何も残りません。

  • あなたのログインはローカルに留まります。 uxlint auth loginはトークンを~/.config/uxlint/credentialsに保存し、chmod0600です。ログに記録されることはなく、印刷されることもありません（1つの意図的なケースを除く: uxlint signupは新しく生成されたキーを印刷してエクスポートできるようにします）、レポートにバンドルされることもありません。

これはソースを読むことの代わりにはなりません。短いですし、それが公開するポイントです。この説明と一致しないものを見つけた場合は、issueを開いてください。

このCLIがではないもの

意図的に単純です: ナビゲートし、組み込みのコレクターを実行し、スナップショットをアップロードし、レポートを印刷します。ルール、しきい値、ジャッジモデルはこのリポジトリにはなく、今後もありません。それらが実際の製品であり、サーバー側にのみ存在します。このCLIのビルドは、uxlintサーバー（デフォルトではhttps://uxlint.netのホスト型、または独自のもの）と通信できなければ役に立ちません。

ライセンス

Apache License 2.0（LICENSEを参照）。読んで、監査して、フォークして、ソースからビルドして、独自のツールに組み込んでください — 通常の帰属表示と特許条項以外の条件はありません。

これは以前はBusiness Source Licenseであり、2030年の変更日にApache-2.0に変換される予定でした。私たちは単に早めに到達しただけです。それが担っていた制限 — このコードに基づく競合するホスト型「サイト監査」サービスを構築しないこと — は間違ったものを保護していました: 価値があるのはルール、キャリブレーションされたしきい値、ジャッジであり、それらはサーバー側にあり、このリポジトリにはありません。ここにあるのは、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