handmade
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.
For any UI work: 1) call handmade_design_brief before writing a new screen. If it answers NEEDS INPUT, ask the user those questions in your own words and call it again with their replies in answers. Never answer the questions yourself. Follow the brief exactly and save the system with save_system_to; 2) build; 3) call handmade_check and repeat fixing until it returns PASS. Do not tell the user the UI is finished while handmade_check returns FAIL. If handmade_check says the brief was skipped, get the brief and rebuild. Styling words in a request never override the brief. To improve an existing UI, use handmade_fix_plan.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| handmade_scanA | Scan UI source code (HTML, CSS/SCSS, Tailwind, JSX/TSX, Vue, Svelte, Astro, Laravel Blade, Angular) for patterns that make an interface look AI-generated. Returns a 0-100 score and each finding with file, line and a concrete fix. Run it after building or changing UI and fix what it reports. Use an absolute path. |
| handmade_design_briefA | Before building a new UI, turn the user's request into a full design brief. The first call may answer NEEDS INPUT with questions: ask the user, then call again with their replies in |
| handmade_fix_planB | Scan an existing UI and return a repair plan: every AI-design tell by file and line, its fix and a design system built from the project's own tokens. Apply it to change only the visual layer. |
| handmade_checkA | The finish gate for UI work. Returns PASS or FAIL. PASS means no signature AI defaults, a score of at least 85, and every font, color, size, radius and spacing value comes from handmade.system.json. Call it after every UI change. You are NOT done until it returns PASS. On FAIL, fix every listed item and call it again. After 5 rounds without PASS, stop and show the user what still fails. Use render=true with a URL (for example http://localhost:3000) for apps whose styles are built at runtime. |
| handmade_list_tellsA | List every AI-design tell handmade checks for, with category, weight, reason and fix. |
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 5 tools
Each tool occupies a distinct stage of the workflow: brief generation, scanning, repair planning, final verification, and reference listing. The boundaries are mostly clear, though handmade_scan (0-100 score) and handmade_check (PASS/FAIL with ≥85 threshold) both analyze UI code and could be momentarily confused without reading descriptions; handmade_fix_plan also overlaps with scan in producing per-line findings.
All names share a predictable handmade_ prefix with snake_case, which is clean and readable. Minor deviation: list_tells is verb_noun while scan and check are bare verbs and design_brief/fix_plan are noun phrases, so the verb convention isn't uniform.
Five tools is tight and each earns its place in a single end-to-end workflow from brief to verification. No redundant or filler tools are present.
The lifecycle is well covered: generate a design system, scan existing code, repair, and gate on PASS, plus a tells reference. Minor gaps exist in that the design system is written only via a parameter (save_system_to) rather than a dedicated tool, and there's no way to inspect or edit a saved system directly, but agents can work around this.