Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
UXLINT_RUNNERNoOverrides the hostname sent as part of project provenance for the audit report.
UXLINT_SERVERNoThe URL of the uxlint server. Defaults to https://uxlint.net.
UXLINT_API_KEYNoAPI key for CI or headless environments. If not set, the MCP server will initiate a sign-in flow and save the token.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
acknowledge_findingA

Mark ONE finding as a known false positive for this site, so later audits stop counting it — it moves out of the findings, the counts and the grade into the report's acknowledged list, where it stays visible with your reason. Use it only after you've checked the finding is wrong on this page (the rule misread it), never to silence a real problem you'd rather not fix. Pass the report (URL or id), the rule and the selector exactly as the finding gives them, and a reason. undo=true puts it back. Works on reports filed under a site.

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. A finding you've checked and found WRONG on this page (the rule misread it)? acknowledge_finding marks it a known false positive for the site, so it stops coming back and stops counting against the grade — it stays visible in the report, with your reason. 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.

get_reportA

Read an EXISTING report's findings — one the user started from the dashboard, a run whose audit_url call you lost, or one that TIMED OUT (it keeps whatever it found before the cap, and says so). Pass the report's URL as the user sees it (…/r/) or its id. Returns the same thing audit_url does: the grade, what moved since the last run, and every finding with its rule, location, source hint, fix and screenshot_url — so you can act on it and confirm each fix with verify_fix. Reports are private; this reads them with your uxlint login.

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.

ux_guidanceA

Project design memory and 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. Reads the nearest project’s uxlint.design.json on each call; only explicitly approved versioned decisions guide edits. Never auto-approve or rewrite that contract to silence a lint. 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, copy that reads as UI (active voice, honest labels, useful empty/error states), and money surfaces (plans, usage, the cost of an action shown before it runs, failed payments). 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.

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). Returns status passed, failed, not_evaluated or inconclusive. A pass requires explicit server evidence for the requested route and both viewports. Currently supported passing checks: page-title-missing, html-lang-missing, horizontal-overflow. Other rules can report observed failures but cannot pass without execution evidence; re-run audit_url for judge, interaction and site checks. Unknown rules and missing evidence never clear. A cleared finding is not a user endorsement of the fix.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct role in the audit workflow: running audits, reading reports, viewing screenshots, verifying fixes, acknowledging findings, and getting design guidance. While audit_url and get_report both surface findings, one initiates a run and the other retrieves an existing one, and the descriptions make this boundary clear. No two tools appear interchangeable.

Naming Consistency4/5

Most tools follow a verb_noun pattern (acknowledge_finding, get_report, get_shot, verify_fix), with audit_url fitting the same style. The sole deviation is ux_guidance, a noun phrase with a ux_ prefix, which breaks the pattern slightly but remains readable and unambiguous.

Tool Count5/5

Six tools cleanly cover the core loop of guidance, audit, inspect, verify, and acknowledge. Nothing feels redundant or missing at this scale, and the set is well-scoped for a focused UX linting server.

Completeness4/5

The surface covers the main lifecycle: read guidance, run an audit, retrieve reports, view evidence, verify individual fixes, and acknowledge false positives. A list_reports tool for discovering existing report IDs without already having a URL is a minor missing convenience, but most workflows are fully supported.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive