Skip to main content
Glama
uxlint-net

uxlint

Official
by uxlint-net
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

audit_url

Audit a website's UX/design and get actionable results: each finding includes the rule, source file line, selector, and concrete fix, plus exact text edits for copy issues.

Instructions

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: interaction probes navigate, read, and click candidate menu/disclosure/dialog controls. Discovery skips recognised action words — delete, remove, accept, leave, revoke, pay, publish, add, create, save — using the full label. Labels cannot guarantee a click has no side effects; use an environment you control with disposable data. the write probes (which click Add/Create, and Delete through its confirm dialog) need the CLI's own --allow-mutation flag, which is not reachable from here. Declared tests are the exception and the only one: if the project's uxlint.toml declares tests that sign in as a persona, running them will SUBMIT forms and may DELETE items — that's what a test does, and 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.

Input Schema

TableJSON 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.
detailNo`full` for every finding's fix, best practice, rect and screenshot URL in the structured result. Default is compact: every finding, with each rule's fix said once — the full form can run past a client's output limit on a big site.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.41
    • addedInput schema / properties / detail
      Added value: +{
+  "default": null,
+  "description": "`full` for every finding's fix, best practice, rect and screenshot URL in the structured\nresult. Default is compact: every finding, with each rule's fix said once — the full form can\nrun past a client's output limit on a big site.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it delivers: SAFETY discloses that probes navigate/read/click controls, skips destructive labels, requires --allow-mutation for write probes, and that declared tests will SUBMIT/DELETE data. SETUP and AUTH additionally disclose what happens with missing config (returns setup instructions) and how credentials are handled (via uxlint.toml [personas], nothing touches the transcript). This is exceptionally transparent for an unannotated tool.

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 bold section headers (WORKFLOW, SAFETY, SETUP, AUTH) and a front-loaded opening that states purpose and result shape. Some redundancy remains — the disposable-environment warning repeats in SAFETY and the final sentence — but every section earns its place given the zero annotations and complex safety profile.

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?

The combination of seven schema-covered parameters, no annotations, and no output schema would typically leave gaps, but the description covers the result format per finding, the required pre/post steps (ux_guidance, verify_fix, lint_feedback), setup behavior, login-wall behavior, and auth handling. An agent given this text has everything needed to invoke audit_url correctly and interpret its findings.

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 coverage is 100%, so the schema already fully documents all seven parameters (base, crawl, judge, tests, detail, routes, states), including types, defaults, and edge cases like 'base must be an ORIGIN, not a path'. The description adds contextual workflow around the parameters (e.g., base in setup config) but no new parameter-semantic meaning, so the baseline of 3 applies.

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?

States a specific verb (Audit) and resource (website's UX/design) with explicit dimensions (contrast, tap targets, type scale, colour discipline, copy clarity, scan patterns). The opening sentence also describes the result shape (RULE, SOURCE, SELECTOR, FIX, EDIT), separating it from siblings like get_shot and get_report, which handle visuals and report display rather than auditing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WORKFLOW section explicitly tells the agent to call ux_guidance before making changes and verify_fix after each fix, and names the exact iteration loop. It also instructs to send a verdict to lint_feedback when present, and to write the config file if none exists. It does not define explicit exclusion conditions for get_shot or get_report, but the sequencing of audit → guidance → verify is clear.

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

Deploy Server

Other Tools