Skip to main content
Glama
HalidSaglam

saglitzdesign-mcp

by HalidSaglam

Audit Generic Design

audit_generic_design
Read-onlyIdempotent

Audit web projects for generic design defaults: stock Tailwind gradients, common typefaces, emoji icons, repeated card recipes. Receive factual findings with fixes and a score.

Instructions

Audits a web project or snippet for the specific defaults generated interfaces reach for: the stock Tailwind indigo/violet/purple gradient (as classes, hex, or OKLCH), Inter/Roboto/Open Sans/DM Sans/Plus Jakarta Sans as the only declared typeface on a brand surface, emoji standing in for icons, the rounded-2xl + shadow-lg + border card recipe repeated across a page, gradient-filled heading text, an eyebrow label over every heading, the backdrop-blur + white/10 glassmorphism recipe, three or more animate-pulse or animate-shimmer placeholders, stock hype-opener copy ('unlock the power of', 'say goodbye to', …), stacked filler adverbs ('seamlessly', 'effortlessly', …), and a page whose every call to action is drawn from the stock set ('Get Started', 'Learn More'). Every finding is a fact about the source text — a class name, a phrase, a repeated structure — never a judgement about whether the result is good design; it reports facts, not taste, so pair it with design_review_checklist or get_design_doc("design-critique-scoring") for actual critique. It reads source and does not measure anything: it makes no network request, renders nothing, and no finding is or can be a rendered-output or aesthetic judgement. Returns markdown plus structured output: findings (rule, severity, message, fix, doc, file, line), a severity summary, a machine-readable notVisible list of what it could not check, and a 0-100 score itemised to the same rule, weight and evidence the markdown prints — each rule counts once no matter how many times it fires, so a long page never scores higher purely for its length. In directory mode it does not read story, test or fixture files (.stories., .story., .spec., .test., fixtures/, mocks/), whose job is to demonstrate a component rather than ship a surface; it reports how many it skipped. The copy rules match English only, so a page in another language is scored by the visual rules alone. A missing or non-directory path is returned as an error result, not as an empty audit. Pair with audit_project for design drift and design_review_checklist for critique.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoA single snippet to audit instead of a directory.
pathNoDirectory to audit. Absolute paths are strongly preferred.
filenameNoFilename for the snippet, e.g. 'page.html' or 'Page.tsx'. Some rules — the typeface check in particular — use it to tell a landing page from a dashboard.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scanNoPresent only in directory mode: what the scan actually reached. The markdown's "Stopped at the file cap" sentence has no other counterpart in structuredContent — `findings`, `summary` and `score` all look identical for a clean project and a truncated one that never opened its worst file — so a caller reading only structuredContent must check this before trusting a clean score or an absent finding.
scoreYesThe generic-design score, itemised. Not a quality judgement — it counts documented defaults that were left unchanged.
summaryYesCounts by severity. Always agrees with `findings` — it is derived from the same list.
findingsYesEvery finding, in the order the markdown report lists them.
notVisibleYesWhat this audit structurally could not check, one limitation per entry. Read it as a peer of `findings`: silence on a subject named here is this tool's reach, not a clean result. Nothing any of these tools reports is measured.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.28.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnly, idempotent, and non-destructive, and the description reinforces this with concrete behavior: 'it makes no network request, renders nothing,' and no finding is or can be a rendered-output or aesthetic judgement. It discloses non-obvious scoring semantics ('each rule counts once no matter how many times it fires'), directory-mode exclusions of story/test/fixture files, and reports how many files it skipped. This adds substantial behavioral context beyond what the annotations alone convey, with no contradiction.

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?

Dense but well-segmented: it moves from the audited pattern list to the reporting stance, output format, edge cases, and finally sibling pairings, with no filler phrases. It runs long (~280 words), and some output-format detail (findings fields) overlaps with the existing output schema, so a small trim was possible; still, nearly every clause carries non-redundant operational information.

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?

For a 3-param, 0-required tool with annotations and an output schema already present, the description covers everything an agent needs: detailed scope, output shape, scoring semantics, file exclusions, language limitation, error behavior, and sibling pairings. Because the output schema already defines return values, the description correctly focuses on behavior and selection criteria instead of restating structure.

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%, with each parameter (code, path, filename) already documented, including the filename nuance that the typeface check uses it to tell a landing page from a dashboard. The description adds behavioral context around the path parameter (directory-mode exclusions) and the error result, but the schema already carries the parameter definitions, so the description reinforces rather than compensates. Baseline 3 is appropriate since the structured data does the heavy lifting.

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 and resource: 'Audits a web project or snippet' for a precisely enumerated set of generic-design defaults (stock Tailwind gradients, default typefaces, emoji icons, card recipes, hype copy). It further distinguishes itself by its factual stance — 'reports facts, not taste' — and explicitly positions itself against siblings like audit_project and design_review_checklist, so an agent can tell it apart without opening schemas.

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?

Gives explicit pairing guidance: use design_review_checklist or get_design_doc for actual critique, audit_project for design drift, and this tool for factual generic-default detection. It also documents when to pass a snippet (code) vs a directory (path), states the English-only copy-rule limitation, and defines the error result for missing paths — leaving no ambiguity about when to invoke it.

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

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/HalidSaglam/saglitzdesign-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server