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 二进制文件。它通过 DevTools 协议驱动你已经安装的 Chrome/Chromium（无需 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，一条命令：

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

这会安装 uxlint MCP 服务器，如果 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，因为 CI 没有浏览器）。

五个工具：audit_url（完整审计，带分级结论 + 行动计划）、verify_fix（编辑后在一页上重新检查一条规则，约 2 秒）、get_shot（获取某条发现的带注释截图）、ux_guidance（在构建 UI 之前阅读的最佳实践指南），以及 lint_feedback——默认关闭、需主动选择加入（§ 隐私）——一个工具提供三种信号：某条发现是否有用、uxlint 缺少的 lint 规则、或它无法识别的组件库。代理进行审计、阅读修复建议、编辑并重新审计，直到全绿。

隐私与信任

这个 CLI 在你的机器上运行，并驱动真实浏览器访问真实页面，因此你有权追问它到底捕获了什么、数据去了哪里。我们可以告诉你的是，因为这就是本仓库中代码实际做的事情：

  • 采集器是内置且可读的。 它被编译进这个二进制文件中（include_str! 引入 assets/collector.js），因此 uxlint --version 可以锁定确切的采集代码，服务器在运行时无法注入任何内容。它捕获的一切都是页面几何信息、可见文本、计算样式和截图。对于嵌入的 <iframe>，它只记录 src 的主机名——绝不记录完整的嵌入 URL，因为其查询字符串可能携带会话 ID 和令牌。它从不读取你的源代码或文件系统（uxlint.toml 除外）。它确实会读取少量项目来源信息并随报告一起发送：你当前的 git commit SHA 和分支名（git rev-parse）、机器的主机名，以及在 GitHub Actions 中的仓库/PR/提交链接。设置 UXLINT_RUNNER 可覆盖主机名。

  • 机密与 PII 脱敏是尽力而为，而非保证。 在上传任何内容之前，采集器会遮蔽捕获的页面文本中看起来像令牌、API 密钥、密码或电子邮件地址的文本，并对控制台日志和原生对话框消息中的相同模式进行脱敏。所有通道共享同一份模式列表（assets/redact.js），因此不会出现偏差。截图在捕获前会额外经过一次处理：每个表单字段值都会被遮蔽（密码置空，其他输入替换为圆点），页面文本中匹配模式的机密信息会被擦除，因此输入的数据和显示的密钥不会落入图像。该处理能深入 shadow DOM（包括通过 attachShadow 拦截器处理的封闭根）和同源 iframe，并对跨源 iframe 用不透明色块覆盖，因为其像素无法脱敏。但脱敏基于模式匹配，而截图终究是像素：任何未被模式捕获的任意显示内容（页面上的客户名称、订单数据）、被拆分的值，以及绘制到图像或 <canvas> 中的任何内容仍可能泄露。你通过 --header/--storage/--login-* 传入的凭据只驱动你自己的浏览器，绝不会发送到 uxlint 的服务器。

    由于报告会捕获页面 HTML、文本和截图，因此不可能完全防止敏感内容泄露其中。请使用测试账号，而非真实或生产账号。 对于本地开发，只要数据仅是本地开发数据，风险就很低。当你审计一个持有真实机密或个人数据的已认证站点时，在发送之前请审查将要发送的内容：使用 --dry-run 将确切的载荷（页面文本、来源信息和截图）写入本地文件夹并在不上传的情况下检查。脱敏能减少意外暴露；它不是安全边界，你仍需对将 uxlint 指向何处负责。

  • 导航文本仅出于机密目的进行擦除，这是有意为之。 控件标签、菜单和 <select> 选项、工作区/组织切换器名称会经过相同的机密模式处理，但不会对名称或其他任意内容进行脱敏。原因是目标走查：审计会用 LLM 驱动页面，LLM 正是读取这些文本来找到正确的控件、操作它，并将其选择匹配回 DOM。遮蔽这些文本会破坏走查，因为评审者将无法区分两个选项或点击它选中的那个。因此审计导航所需的标签保持可读，其中附带出现的真实姓名由上述测试账号规则覆盖，而非脱敏。这是一个刻意的权衡：保持目标走查可用比遮蔽测试账号规则已保护的文本更有价值。

  • 无遥测。 这个二进制文件只向你指定的主机发起出站调用：uxlint API 服务器（--server/UXLINT_SERVER，或默认的托管源）、你要求它审计的站点，以及——仅在你明确选择加入时——匿名的规则反馈信号。没有任何单独的 analytics/崩溃报告/回传目的地被内置在任何地方。

  • 反馈默认关闭，需主动选择加入。 uxlint init 会询问一次；只有在你同意时才会向 uxlint.toml 写入 feedback = true，你可以随时改回。

  • 审计浏览器使用临时配置文件。 每次审计都会以全新的、一次性的用户数据目录启动 Chrome，因此你日常浏览的 cookie、历史记录或扩展绝不会加载到被审计的会话中，进程退出后也不会保留任何内容。

  • 你的登录信息留在本地。 uxlint auth login 将令牌存储在 ~/.config/uxlint/credentials，权限为 0600。它永远不会被记录、永远不会被打印（唯一刻意的例外：uxlint signup 会打印一个新铸造的密钥以便你导出），也永远不会被打包进报告。

这不能替代阅读源码。源码很短，而这正是发布它的意义所在。如果你发现与上述描述不符的地方，请提交 issue。

这个 CLI 不是什么

它刻意保持简单：导航、运行内置采集器、上传快照、打印报告。规则、阈值和评审模型不在本仓库中，也永远不会加入。它们才是真正的产品，且仅存在于服务端。没有可对话的 uxlint 服务器（默认是托管的 https://uxlint.net，或你自己的），这个 CLI 的构建版本就毫无用处。

许可证

Apache License 2.0（见 LICENSE）。阅读它、审计它、fork 它、从源码构建它、将其嵌入你自己的工具链——除通常的署名和专利条款外无任何附加条件。

这之前是 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