site-kit
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| review_siteA | Read every page and stylesheet in a folder and return an annotated critique. Each finding carries: WHAT was found with the evidence, WHY it matters, what it is teaching, WHO says so with a confidence tag and that source's caveat, WHERE the line is drawn, and the better MOVE. Findings are ordered by how fast a visitor would notice them and annotated the way a chess game is: ?? clocked in five seconds, ? felt but not named, ?! a habit worth dropping. Rules that could not run are listed as prominently as the ones that failed, with the reason each one could not run. They are never counted as passes. Use explain_rule with any rule id from the output to read the full teaching note, every source, every caveat, and what that rule measured across the corpus it was built from. |
| explain_ruleA | Given a rule id from a review — the part in square brackets — return the whole note: the exact trigger condition and where that number came from, why it matters, what it is teaching, the better move with its code, every source with its own caveat, and what the rule measured across the corpus the rulebook was built from. Call it with no id to list the rulebook. Pass a tier, a category, or a search term to narrow it. |
| learning_pathA | Ten stops, in the order a beginner needs them — which is NOT the order the critique uses. review_site sorts by how fast a visitor notices a fault. That is right for a critique and wrong for learning. This sorts by what you need first: make it work, then make it not look broken, then make it not look generic, then make it honest, then understand why the escape routes keep closing. Every stop is built from the rulebook itself and names the rule ids that carry its reasoning, so it cannot drift away from what the tool actually checks. Pass a stop number to read one at a time. |
| init_siteB | Write index.html, styles.css and NOTES.md into a folder. The page is built to come back clean from review_site: three theme states, neutrals that carry a trace of the anchor hue, press feedback with a hover guard, 48px touch targets, 16px inputs, minmax(0, 1fr) grid tracks, overflow-x: clip, no animation above the fold, no eyebrow, no emoji icons, no side stripes, no backdrop blur. The structure is chosen from a local ledger of what was scaffolded last, so two consecutive sites differ in their SECTIONS, not only in their colours. That is the axis the research ranks highest and recolouring the axis it ranks lowest. Every unwritten field is a visible, labelled hole rather than filler. Nothing is invented: no testimonials, no ratings, no counts, no press. |
| palette_from_subjectA | Builds a complete two-state palette from one anchor hue, in OKLCH, and emits hex. It cannot return one of the ten banned Tailwind indigos or the emerald that replaced them, cannot return pure black or pure white, holds every neutral at 0.005-0.015 chroma of the anchor hue so the greys belong to the same page as the accent, never shifts the hue between light and dark, and returns a WCAG contrast matrix for every pair a page actually puts together — so an unreadable pair cannot be chosen by accident. It also tells you where the hue came from. If the subject names something real, it names the object. If it does not, it says the hue came from a hash of the words — which is not the same thing, and palette_from_image on a photograph is the stronger move. |
| palette_from_imageA | Quantises an image with median cut or k-means and returns a small, considered palette: the colours the subject is actually made of, with how much of the image each one covers. Returns a full WCAG 2.1 contrast matrix alongside the colours, computed from relative luminance, so an unreadable pair cannot be chosen by accident. Also returns a ready-made token set for both theme states, which can be passed straight to init_site. Reads PNG and JPEG (.png, .jpg, .jpeg). Everything is done locally; nothing is uploaded. |
| check_responsiveA | Loads each page in a real headless Chromium at a set of widths and asserts that document.documentElement.scrollWidth does not exceed window.innerWidth. Reports the actual numbers at every width, pass or fail, and names the specific elements whose edge crosses the line. Requires Playwright, which is NOT installed with this kit. If it is missing this tool returns status "skipped" with the one command that installs it. It never reports a pass it did not measure. |
| check_copyA | Run the copy and honesty rules over a folder, or over a block of text pasted straight in. Benefit-speak, the "not just X, it's Y" cadence, em dashes in short interface copy, fabricated precision, invented proof, unverified attributions, and claims that cannot be true or false. Pass either |
| check_honestyA | Scans a site for content that claims something nobody earned: testimonials, star ratings, "as seen in", customer counts, lorem ipsum, placeholder brand names and contact details, and quotations that carry an attribution. The attribution check is the one a generic linter misses. A name set on its own line under a quotation is an attribution even with no "said" and no dash, and a misattributed quote is a false statement about a real person. Report it, find a source, and record the source in .honesty.json to silence it. An entry with no source silences nothing. Reports file:line for everything. status is "fail" only when there are errors; warnings are things to verify, not things that are definitely wrong. |
| check_assetsA | Follows every image, stylesheet, script, icon and internal link in the site and confirms the file is really there. Reports file:line for anything that is not. Catches the case-sensitivity trap specifically: a file that resolves on a Mac because macOS ignores capitalisation, and 404s the moment the site is published to a Linux host. That one cannot be found by looking at the site in a browser on the machine that built it. Also audits the stylesheet theme contract, because var(--token) is a reference too. A custom property defined only inside @media (prefers-color-scheme: dark) has no value in the state most visitors are in. |
| check_single_sourceA | Scans for values that look like a fact a visitor can act on — prices, email addresses, phone numbers, times, product codes — and reports every one that appears in more than one file. A second copy of a value is a second value. It has not disagreed yet. The storefront this kit was built from advertised one price and charged another, because the number was typed into three files and only one of them was updated. Pass source_of_truth to enforce the strict form: the value may appear in that one file, and anywhere else is a copy. Preset patterns: price, email, phone, sku, time, percentage, dimension. Anything else is treated as a regular expression. |
| doctorA | Checks Node, the optional headless browser, and whether Codex has this server registered. For anything missing it prints the literal command to paste. Nothing here is a suggestion to "check your configuration": every failure comes with the line that fixes it. Run this first whenever something does not work. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
The tool families are well separated by target, and each checker addresses a distinct concern. The only real overlap is between check_copy and check_honesty, both of which claim some honesty/attribution territory, and review_site naturally overlaps with the individual checkers. The detailed descriptions make selection feasible, so this is not a serious weakness.
There is a strong check_* family and a clear palette_from_* pair, but the set mixes verb-first names like review_site and explain_rule, noun phrases like learning_path and palette_from_subject, and a single bare verb in doctor. The names are all lowercase and readable, but the overall convention is mixed rather than uniform.
12 tools is squarely in the well-scoped range for a site review and scaffolding kit. Each checker targets a separate concern, and the supporting tools for explanation, learning, scaffolding, palette generation, and diagnostics all earn their place.
The set covers the full workflow: scaffold a site, generate palettes, run a full critique, run targeted checks, explain findings, and diagnose the environment. There are no obvious dead ends or missing operations that would block an agent from completing a meaningful task.