mcp-super-app is a local MCP server for Claude Code that bundles routine project setup, design, image, and icon tooling into one set of callable tools.
bootstrap_project – scaffold a new project skeleton (.gitignore, .claude/, docs, auto-memory, profiles S/M/L) and install the global destructive-command guard if missing.
install_skill – install personal skills (frontend-design, fullstack-architect, humanizer-ru, image, ui-ux-pro-max, emil-design-skills) into a project.
create_website – set up an Astro landing site from a 21-section generator, or a multipage redesign playbook for existing sites; writes a session tracker and installs flow skills.
install_guard – install a PreToolUse hook that protects against destructive commands (rm, find -delete, git reset --hard, etc.) globally or per project.
create_image – generate or edit images via OpenRouter (Seedream/Gemini models), save files locally, return them in chat, and report cost; requires a prompt made with the image skill.
optimize_images – production image processing with sharp: resize, convert to webp/jpeg/avif, EXIF rotation, and optional srcset variants.
search_icons – search lucide and simple-icons sets by English keyword/concept.
get_icon – fetch raw SVG markup for a specific icon by exact name/set.
update_server – self-update the server via git pull, dependency install, and rebuild.
Startup checks – detect outdated builds, available updates, and missing required .env keys.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-super-app Scaffold a new landing page project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-сервер для Claude Code: собирает рутинные setup-действия (каркас проекта, скиллы, среда сборки лендинга, guard-хук, картинки, иконки) в одну точку входа. Подключил сервер → все инструменты доступны из любого чата обычными tool-вызовами.
Стек: TypeScript + @modelcontextprotocol/sdk, транспорт stdio (локальный сервер,
никуда ничего не отправляет, кроме OpenRouter при генерации картинок).
Пошаговая инструкция — в INSTALL.md. Она из двух частей: сначала три шага для человека (создать пустую папку и открыть её в Claude Code), потом готовый текст, который копируется в чат целиком. Дальше агент делает всё сам — определяет систему (macOS или Windows), проверяет окружение, скачивает и собирает сервер, подключает его к Claude Code и чинит ошибки по дороге. Разбираться в коде не нужно.
Если сервер уже стоял и нужно просто переустановить — можно короче, одной фразой:
Установи MCP-сервер по инструкции: https://github.com/AndreyTsibin/mcp-super-app-public/blob/main/INSTALL.mdЧто делать, если что-то пошло не так, — там же, раздел «Что делать, если не заработало».
Что умеет сервер целиком — девять инструментов, каталог скиллов, цены на генерацию картинок и типовые маршруты работы — в карте инструментов.
Related MCP server: claudecode-mcp
Node.js ≥ 20.
Ключ OpenRouter — только для create_image. Остальные инструменты работают без ключа.
Ключ у каждого свой: https://openrouter.ai/keys.
Инструмент | Что делает |
| Разворачивает каркас нового проекта одним вызовом: |
| Ставит скилл в проект: bundled → копия в |
| Единая точка входа для сайтов, режим выбирается параметром |
| Ставит PreToolUse-хук защиты от деструктивных команд ( |
| Единая точка входа для картинок: генерация и редактирование через OpenRouter. Возвращает картинку в чат + сохраняет файл в проект ( |
| Готовит картинки к продакшену (sharp): ресайз до |
| Ищет иконку по английскому слову/концепту в двух наборах: lucide (~2000 generic UI-иконок — wrench, shield, clock…) и simple-icons (~3400 лого брендов — GitHub, HP, Telegram…). Возвращает точные |
| Отдаёт сырой SVG иконки по точному |
| Обновляет сам сервер: |
Меню точек входа живёт в глобальном скилле mcp-super-app — сервер ставит и обновляет
его сам, при каждом старте и после update_server. Вписывать правило в личный CLAUDE.md
не нужно: скилл едет вместе с сервером и одинаков у всех. MCP instructions при этом ужаты
до указателя на скилл плюс короткий фолбэк на случай, когда клиент скилл ещё не подхватил.
Туда же при старте попадают самопроверки: сборка устарела (src/ новее запущенного
dist/ — правки не применились), доступно обновление (в репозитории вышла версия свежее
установленной; проверка через git ls-remote, кэш на сутки, при отсутствии сети молча
пропускается) и не хватает обязательных ключей в .env. Когда обновление есть, оно
становится дополнительным пунктом того же меню точек входа.
Нужен, только если будешь генерировать картинки.
cp .env.example .env
# впиши свой ключ: OPENROUTER_API_KEY=sk-or-v1-....env игнорируется git (см. .gitignore). Ключ берётся из .env в корне пакета —
сервер грузит его сам при старте, передавать через конфиг не нужно.
Если по какой-то причине не сработал автоматический путь из INSTALL.md.
Сервер подключается глобально, для всех проектов сразу. Регистрация на одну папку — самая частая причина «инструменты были и пропали».
1. CLI (-s user = во всех проектах):
claude mcp add mcp-super-app -s user -- node /абсолютный/путь/к/mcp-super-app/dist/index.js2. Нет команды claude? Так бывает, когда стоит десктопное приложение: оно не кладёт
CLI в PATH. Тогда добавь сервер в корневой ключ mcpServers файла .claude.json в
домашней папке. Этот файл хранит состояние клиента — не перезаписывай его целиком, сними
копию и допиши:
{
"mcpServers": {
"mcp-super-app": {
"command": "node",
"args": ["/абсолютный/путь/к/mcp-super-app/dist/index.js"]
}
}
}Путь обязательно абсолютный — ~ и относительные не разворачиваются, конфиг
глобальный. На Windows это C:\\Users\\Имя\\mcp-super-app\\dist\\index.js
(в JSON обратные слэши экранируются, как здесь).
Домашнюю папку узнавай командой node -e "console.log(require('os').homedir())", а не по
~: на Windows с рабочим или доменным профилем домашняя папка часто лежит на сетевом
диске, и конфиг, записанный по ~, ложится мимо приложения. Ту же запись внутри ключа
projects клиент применит только к одной папке — как и файл .mcp.json в корне проекта.
Проверить, что получилось: claude mcp list — сервер должен быть в списке и подключён.
Обновления — через агента, в консоль лезть не нужно. Сервер при старте сам смотрит,
не ушла ли ветка в origin вперёд, и если ушла — говорит об этом в начале сессии. Дальше
достаточно сказать Claude Code «обнови сервер»: тул update_server сделает git pull,
при необходимости переустановит зависимости, пересоберёт и попросит перезапустить
приложение. Руками то же самое: git pull && npm install && npm run build в папке
репозитория + перезапуск.
Что сервер проверяет при старте. Три вещи, и о каждой он молчит, пока всё в порядке:
вышло ли обновление — сравнивает твою копию с origin по свежему тегу версии;
собран ли он из текущих исходников — если обновиться руками (git pull) и забыть
npm run build, сервер продолжит работать по старому коду, а правки будут выглядеть
как «не применились»;
заданы ли в .env обязательные ключи — обновление может добавить новый ключ, и без
этой проверки ты бы упёрся в ошибку инструмента, которая выглядит как его поломка.
Какие ключи обязательны, написано в .env.example: обязателен каждый, у которого нет
пометки # optional.
Проверки безопасны и результат обновления кэшируется на сутки: нет сети, git или файлов —
сервер просто стартует молча. update_server отказывается работать, если в папке сервера
есть незакоммиченные правки — чужую работу он не трогает.
После подключения перезапусти Claude Code.
npm install
npm run build # компиляция TS → dist/
npm run dev # tsx watch — запуск из src/ без сборки
npm run typecheck # tsc --noEmit
npx @modelcontextprotocol/inspector node dist/index.js # ручная проверка туловТочка запуска сервера — dist/index.js (stdio).
src/
├── index.ts # точка входа: регистрация tools + stdio transport, загрузка .env
├── lib/ # общая инфра: openrouter, scaffold, project-slug, errors, settings-merge, …
└── tools/ # по модулю на инструмент
assets/ # статические шаблоны: skills/, bootstrap/, landing/, guard/
docs/ # спеки и стандарты (архитектура, API)Договорённости и рабочий метод — в .claude/CLAUDE.md.
Этот репозиторий — зеркало. Разработка идёт в приватной копии, а сюда src/, assets/
и docs/ приезжают побайтово при каждом релизе, вместе с удалением лишнего. Поэтому
любая правка, сделанная здесь напрямую — коммитом в main или мержем pull request, —
живёт до следующего релиза и затем молча исчезает.
Что это значит на практике:
Нашёл баг — заведи issue. Это рабочий канал, читается.
Pull request тоже можно — он полезен как баг-репорт с готовым патчем, и разбирать его так и будут. Но смержен он не будет: правка переносится в приватную копию, выходит релизом, а PR закрывается со ссылкой на версию, в которой она приехала. Это не отказ, просто иначе она не выживет.
Ставить сервер форком не нужно — обновления приходят через update_server, ему нужен
обычный клон.
Materialize a new project skeleton in one call: .gitignore, .editorconfig, .claude/ (settings, hook, CLAUDE.md, HANDOFF), docs/ by profile (S/M/L), and Auto-memory (work-protocol, product-vision, docs-protocol, MEMORY.md). On M/L profiles also installs the fullstack-architect skill (idea → PRD/ARCHITECTURE/PLANNING/TASKS); S skips it and goes straight to code. The report's next_steps then hands you the remaining skill catalog (frontend-design, humanizer-ru, image, ui-ux-pro-max, emil-design-skills) with a one-line description each — judge from the brief's stack/vision which ones this project actually needs, and offer that pick via AskUserQuestion (mark your recommendations) rather than installing the whole catalog by default. Also checks for the global destructive-command guard (~/.claude, same as install_guard target=user) and installs it only if missing — idempotent, never calls install_guard again once it's there. Idempotent: existing files are never overwritten. Collect the brief (name/stack/profile/vision) in chat first, then call. Note: .claude/ settings/hooks and installed skills load only at session start — if working inside the new project right away, ask the user to restart the session.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name (used in titles and memory). | |
| stack | Yes | Free-text stack, e.g. 'Next.js fullstack' or 'static HTML/CSS/JS'. Drives .gitignore and permissions. | |
| vision | Yes | 1–2 sentences: what we're building and for whom. | |
| profile | Yes | Skeleton depth: S = simple landing/script, M = app, L = full product. | |
| project_path | Yes | Absolute path to the target project directory. |
| Name | Required | Description |
|---|---|---|
| guard | Yes | Global destructive-command guard (~/.claude, install_guard target=user): checked first, only installed if missing. |
| created | Yes | Paths that were created. |
| skipped | Yes | Paths left untouched because they already existed. |
| memory_dir | Yes | Auto-memory directory for this project. |
| next_steps | Yes | Manual follow-ups left to the agent/user. |
| skills_failed | Yes | Skills that failed to install (e.g. proxied CLI offline) — install by hand later. |
| skills_installed | Yes | Skills installed by default for this profile (fullstack-architect on M/L). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: idempotency ('existing files are never overwritten'), conditional install of the destructive-command guard only if missing, the fact that skills load only at session start, and the 'never calls install_guard again once it's there' behavior. This is rich, non-obvious context beyond what any schema could encode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but every sentence adds a unique behavioral or usage fact. It front-loads the main action and then covers edge cases (guard idempotence, session restart). Slightly long, but the complexity of the tool warrants it; no filler words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, profiles, skill installation, guard checks, session note) and the presence of an output schema, the description covers all necessary context: it explains the next_steps output, preconditions (collect brief in chat), and post-conditions (restart required). It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds behavioral mapping beyond the schema: profile determines docs/ and skill installation (S vs M/L), stack drives .gitignore and permissions, and vision is used in the brief. This clarifies how parameters influence outcomes, though it doesn't add syntax details. The extra value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Materialize a new project skeleton in one call' and enumerates concrete artifacts (.gitignore, .editorconfig, .claude/, docs/, Auto-memory). It clearly distinguishes this from siblings like create_website or install_skill by framing it as a one-call project bootstrapper that also installs skills and a guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Collect the brief (name/stack/profile/vision) in chat first, then call.' It also explains when to use the S profile vs M/L ('S skips it and goes straight to code'), instructs to offer skill picks via AskUserQuestion rather than installing the whole catalog, and notes the session restart requirement for new projects. This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate or edit image(s) via OpenRouter and save them into the project, returning the image inline in chat plus the saved paths and the measured cost. MANDATORY FIRST STEP: the prompt must be written with the bundled 'image' skill — each model needs its own prompt syntax, and Seedream in particular treats comma-separated tags as an anti-pattern. The tool refuses to generate when the skill is missing from the project (it installs it and tells you to read .claude/skills/image/SKILL.md from disk, then call again) or when prompt_source is empty. Default model is Seedream 4.5: $0.04 flat, up to 7.5MP, best prompt adherence — control framing with aspect_ratio and do NOT pass size (that only lowers the resolution for the same price). Seedream covers essentially every task; read the model description before picking anything else, it carries a measured decision table. EDITING: pass the source image via reference_images (local paths or URLs) plus an instruction in the prompt ('remove the sign', 'make the background lighter'); every image model here accepts image input. Name what must stay unchanged explicitly ('keeping its pose unchanged') — that is the vendor-documented way to avoid drift. Mask-based inpainting is NOT supported by this endpoint. Sizing is model-specific: Seedream takes aspect_ratio alone; Gemini needs aspect_ratio + resolution:'2K'. Files land in save_dir (default ./generated, relative to the project). AFTER GENERATING: raw output here is full-resolution and the wrong format for production — run optimize_images on save_dir before shipping (resize/webp/srcset). In a landing build (create_website kind='landing') this is the mandatory last step of the image stage: generate the whole series first (hero → reference_images for the rest, same 'photoshoot'), then one optimize_images call on assets/img at the end — never optimize between individual generations. Requires OPENROUTER_API_KEY in the server .env.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of images (default 1). Not every model supports n>1. | |
| seed | No | Seed for reproducible output (provider-dependent). | |
| size | No | Explicit pixel size, '<width>x<height>'. Seedream only, and ONLY when an exact pixel size is genuinely required — it costs $0.04 either way, so passing 'size' just LOWERS what you get (e.g. '2560x1440' = 3.7MP vs 7.5MP with aspect_ratio alone). Prefer aspect_ratio. Minimum 3686400 px; the model rejects anything smaller. | |
| model | No | OpenRouter image model. All numbers below are MEASURED usage.cost and measured pixels, not estimates. DEFAULT — bytedance-seed/seedream-4.5: use it unless a rule below says otherwise. $0.04 flat at ANY size, best prompt adherence, best editing consistency, best $/MP. Sizing: pass aspect_ratio and DO NOT pass 'size' — without 'size' it returns its maximum (3642x2048 = 7.5MP at 16:9; 2048x2048 = 4.2MP at 1:1) for the same $0.04. That is ~$0.005/MP. Passing 'size' only ever LOWERS the resolution for the same price. This list is cost guidance, not a capability map: every model here handles any subject competently, and seedream's 7.5MP already exceeds any web/screen need. Each rule below names the one edge where that model beats seedream by enough to justify costing 2.5-3.4x more per frame — no edge in the frame, no reason to pay the premium. An explicit user request for a specific model overrides these rules. • Close-up skin texture where pores/hairs genuinely carry the shot → google/gemini-3.1-flash-image with resolution:'2K' ($0.101, 2752x1536 = 4.2MP). Best skin fidelity of any model here; seedream is cleaner but its skin reads slightly 'rendered'. Also the ONLY model with banner-strip ratios (1:4, 4:1, 1:8, 8:1). • Hardest scenes only (many interacting subjects, tricky physics) → google/gemini-3-pro-image with resolution:'2K' ($0.137). ~6x seedream per pixel — not a general 'better' button. ALWAYS pass resolution:'2K' on either Gemini. Omitting it silently defaults to '1K' (1376x768 = 1.1MP for $0.069 on flash) — the worst $/MP of any option here. On gemini-3-pro-image '1K' and '2K' cost the SAME ($0.135 vs $0.137, both 1120 image tokens), so asking pro for '1K' is a pure loss. '4K' exists on both Gemini models (5504x3072 = 16.9MP) but costs 50-75% more ($0.153 flash / $0.242 pro). 16.9MP is print territory — do NOT use it for web work. Deliberately not listed: OpenAI image models and google/gemini-3.1-flash-lite-image — both failed our quality tests. | |
| prompt | Yes | What to generate. ОБЯЗАТЕЛЬНО собери его скиллом 'image' — у каждой модели свой синтаксис промпта. Тул откажет, если скилла нет в проекте или не заполнен prompt_source. | |
| filename | No | Base filename (extension added automatically). Default: slug of the prompt + timestamp. | |
| save_dir | No | Where to save (absolute, or relative to the project cwd). Default: ./generated. | |
| resolution | No | Resolution tier: '2K' (use this) or '4K' (print only — 50-75% dearer for pixels web can't use). Gemini only; do not pass it with Seedream, which has no tiers and always returns its max. MANDATORY on Gemini — omitting it defaults to '1K', which is the worst $/MP on every model that offers it (flash: 1.1MP for $0.069; and on gemini-3-pro-image '1K' costs the same as '2K' for a quarter of the pixels). | |
| aspect_ratio | No | Aspect ratio, e.g. '16:9', '1:1', '9:16'. Works on every listed model, including Seedream. This is the PREFERRED way to control framing — on Seedream it also maximises resolution for free (16:9 -> 7.5MP vs 4.2MP for 1:1, same $0.04). | |
| project_path | No | Project root where the 'image' prompt skill is checked/installed. Default: the server cwd. | |
| output_format | No | Output format. Provider-dependent; default is the model's own. | |
| prompt_source | Yes | ОБЯЗАТЕЛЬНО. Какой раздел скилла 'image' использован при составлении промпта — например 'SKILL.md → Seedream' или 'references/gemini.md'. Заполняй только если ты действительно прочитал гайд и собрал промпт по нему: промпт «из головы» здесь не принимается — у каждой модели свой синтаксис, и без гайда кадр выходит шаблонным, а деньги тратятся впустую. | |
| reference_images | No | Reference images for image-to-image / style anchoring: local file paths (png/jpg/webp; absolute or relative to the project) or http(s) URLs. E.g. pass an approved hero image to keep a series stylistically consistent. Max 16 (provider-dependent). |
| Name | Required | Description |
|---|---|---|
| cost | No | Total cost in USD, when reported. |
| count | Yes | |
| model | Yes | The model that ran. |
| paths | Yes | Absolute paths of the saved image files. |
| save_dir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses failure modes (refuses when skill missing or prompt_source empty; installs the skill and directs to SKILL.md), requirements (OPENROUTER_API_KEY in server .env), limitations (mask-based inpainting not supported), data output (searching paths, measured cost), and warns that raw output is full-resolution and the wrong format for production, mandating optimize_images. It also explains the silent behavior of omitting resolution on Gemini (defaults to '1K', worst $/MP).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with labeled sections (MANDATORY FIRST STEP, EDITING, AFTER GENERATING, etc.) and front-loads the primary purpose. However, some information is duplicated from the schema's parameter descriptions, such as model pricing and size rules, which makes it longer than strictly necessary. Every sentence carries useful information, but a bit of trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a tool with 13 parameters and an output schema: it covers prerequisites, failure conditions, model decision table, sizing, editing, post-processing, and integration with the landing build workflow. It even states return values (inline image, saved paths, measured cost), and the output schema covers the detailed return structure, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds significant cross-parameter meaning: it defines the relationship between size and aspect_ratio for Seedream ('do NOT pass size... it just LOWERS what you get'), mandates resolution:'2K' for Gemini, and clarifies how to satisfy the required prompt_source by using the 'image' skill. It also extends parameter usage to the editing workflow via reference_images and naming what must stay unchanged.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase: 'Generate or edit image(s) via OpenRouter and save them into the project, returning the image inline in chat plus the saved paths and the measured cost.' This clearly identifies the tool's action, resource, and outputs, and distinguishes it from sibling tools like optimize_images, which is explicitly contrasted as a separate post-processing step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: it states when to use this tool in a landing build ('mandatory last step of the image stage... generate the whole series first... then one optimize_images call on assets/img at the end') and names optimize_images as the alternative for resizing/format conversion. It also instructs on model selection ('Seedream covers essentially every task; read the model description before picking anything else'), making clear when to use which model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a website project and hand back a task tracker. One entry point, two flows — pick with kind:
• kind='landing' — build from the bundled generator: an Astro project with a 21-section library (Hero, Problems, Steps, Benefits, Cases, Prices, Reviews, FAQ, Contacts… each with layout variants), a token contract (styles/tokens.css) split from project values (styles/theme.css), a theme picker (/themes) and a section playground (/kit), niche-free page skeletons whose copy is [[…]] markers telling the agent what to write, a privacy page, lead-capture templates (public/send.php + public/assets/lead-form.js), docs/ standards and a machine validator (.claude/check-landing.mjs). Runs npm install. Use for a new site with no reference — one page or several.
• kind='multipage' — rebuild an existing third-party site (donor) as an original project: ships the redesign playbook (donor research, single-source-of-truth data, design tokens, the mandatory redesign delta that keeps the result out of duplicate-content filters, routing, acceptance), battle-tested lead-capture code (send.php + lead-form.js, honeypot, consent, server-side IP, rate limit) plus a tracker seeded with the two research sessions. Deliberately ships NO Astro skeleton and NO template: the donor's structure and stack are unknown until session 1 has looked at it, so the skeleton is raised in session 3. Use when the user points at a site to copy/redo.
Both flows install the same five skills the design work leans on (ui-ux-pro-max, frontend-design, humanizer-ru, image, emil-design-skills), write docs/_dev/tracker.md and append a one-task-per-session protocol to the project's .claude/CLAUDE.md. Skill installs are best-effort — a proxied installer with no network lands in skills_failed while the scaffold still succeeds, so read that field: when it is non-empty, next_steps opens with a fix-it-first step and you install those by hand before starting task 1. Idempotent: existing files are never overwritten; the CLAUDE.md block is appended once.
IMPORTANT — kind is the user's decision. If they only said «сделай сайт» without naming a reference site, ask via AskUserQuestion («лендинг с нуля» / «переделать существующий сайт») before calling.
IMPORTANT — after the call, STOP. Installed skills load only at session start: ask the user to restart the Claude Code app/session, and start work from tracker task 1 in the new session. Do not begin building the site in the same session, and do not run the tracker end to end — one task per session is the point.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which flow to set up. 'landing' — a site built from the bundled 21-section Astro library (one page or a few, no reference site). 'multipage' — rebuild an existing third-party site (donor) as an original Astro project: research first, no template. Ask the user which one when they haven't said; don't guess. | |
| name | No | Site name — used in the previewer config label and the report. Optional. | |
| install_deps | No | landing only: run `npm install` after scaffolding (default true). Ignored for 'multipage' — there is no Astro project yet. | |
| project_path | Yes | Absolute path to the target project directory (must exist). |
| Name | Required | Description |
|---|---|---|
| flow | Yes | Entry point of the method — the flow guide or the playbook. |
| kind | Yes | Flow that was set up. |
| created | Yes | Paths that were created (relative to project). |
| skipped | Yes | Paths left untouched because they already existed. |
| tracker | Yes | Task tracker: one row = one session. |
| updated | Yes | Existing files a block was appended to (.claude/CLAUDE.md). |
| deps_error | No | Why `npm install` failed, when it did. |
| next_steps | Yes | What happens in the next session — task 1 only. |
| preview_port | Yes | Port the Astro dev server (launch.json) serves on. |
| skills_failed | Yes | Skills that failed to install — install by hand later. |
| deps_installed | No | landing only: whether `npm install` completed successfully. |
| skills_installed | Yes | Flow skills installed into the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses best-effort skill installation with failure handling, idempotency (existing files never overwritten), the deliberate absence of a template for multipage, and the critical need to stop after the call and restart the session for skills to load.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points, bolded keywords, and explicit 'IMPORTANT' flags. Every sentence contributes unique information about flows, files, failure modes, and post-conditions. It is appropriately sized for the tool's complexity and front-loads the key decision point ('pick with kind').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex two-flow nature of the tool, the description covers purpose, usage conditions, side effects, failure handling, and next steps comprehensively. It references the output schema (task tracker, report, skills_failed field) and does not need to explain return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are already detailed. The description adds significant value by elaborating on the 'kind' parameter (detailing what each flow generates) and clarifying 'install_deps' behavior for multipage (ignored). This goes beyond the schema, though some enrichment is redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set up a website project and hand back a task tracker.' It distinguishes between two distinct flows (landing and multipage), each with a specific use case, making it clear how it differs from generic tools like bootstrap_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'Use for a new site with no reference' for landing and 'Use when the user points at a site to copy/redo' for multipage. It also instructs the agent to ask via AskUserQuestion when kind is ambiguous, and provides post-call steps (stop, restart session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one icon's raw SVG markup by exact name from lucide (generic UI icons) or simple-icons (brand logos). Use search_icons first if the exact name/set isn't already known.
| Name | Required | Description | Default |
|---|---|---|---|
| set | Yes | Which icon set `name` belongs to. | |
| name | Yes | Exact icon identifier: lucide kebab-case name (e.g. 'wrench') or simple-icons slug/title (e.g. 'github', 'GitHub'). | |
| size | No | Width/height in px (square). Default: the set's own size. | |
| color | No | CSS color (hex, 'currentColor', …). lucide defaults to currentColor already; simple-icons defaults to its official brand hex when set. |
| Name | Required | Description |
|---|---|---|
| hex | No | Official brand color (simple-icons only). |
| set | Yes | |
| svg | Yes | Raw <svg>…</svg> markup, ready to inline. |
| name | Yes | |
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns 'raw SVG markup' and requires an 'exact name', adding some behavioral context. However, it does not mention error handling, case sensitivity, or what happens when an icon is not found, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary action, and contains no unnecessary words. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the schema fully documents all parameters and an output schema exists, the description's brevity is acceptable. It clearly conveys the tool's purpose and usage, and the remaining unknowns (such as precise error behavior) are minor for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the schema already documents each parameter. The description adds meaningful semantic context by explaining that lucide is for 'generic UI icons' and simple-icons for 'brand logos', and by emphasizing 'exact name' for the name parameter. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Fetch one icon's raw SVG markup by exact name' from two specific icon sets. It distinctly differentiates itself from the sibling tool search_icons by focusing on exact-name retrieval of one icon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Use search_icons first if the exact name/set isn't already known,' providing clear guidance on when to use this tool versus the alternative. This is a direct and useful usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install the destructive-command guard (a PreToolUse/Bash hook) globally into ~/.claude (target=user, default) or into a project's .claude (target=project). Copies destructive-guard.sh into .claude/hooks/ and merges the hook into settings.json WITHOUT clobbering existing keys or hooks (idempotent — safe to re-run). The guard blocks irreversible commands (rm, find -delete, truncate/shred, git reset --hard / clean -f / push --force) while allowing safe variants (git rm, --force-with-lease). Requires jq. Restart the Claude Code session to activate. Note: bootstrap_project already checks for the global (target=user) guard and installs it if missing — you normally only need this tool directly for target='project' or to re-check after a manual jq install.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Where to install: 'user' → ~/.claude (global, default), 'project' → <project_path>/.claude. | |
| project_path | No | Absolute project path. Required when target='project'. |
| Name | Required | Description |
|---|---|---|
| target | Yes | |
| protects | Yes | What the guard blocks. |
| warnings | Yes | Non-fatal issues (e.g. jq missing). |
| hook_status | Yes | Result of merging the hook into settings.json. |
| script_path | Yes | Where the guard script was installed. |
| script_status | Yes | Whether the script was newly written or already present. |
| settings_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It richly covers the safety implications: idempotency, no clobbering of existing settings, required jq dependency, session restart need, and the specific commands guarded. This is far beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but each sentence earns its place: purpose, mechanics, safety guarantees, prerequisites, activation, and usage guidance. It is front-loaded with the core verb and resource, and the structure is logical, moving from what it does to when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description is remarkably complete. It covers installation targets, idempotency, command blocking rules, prerequisite (jq), activation requirement, and the relationship to a sibling tool. This leaves no obvious gaps in understanding what the tool does and how to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters, including the default for target and the requirement for project_path when target='project'. The tool description mostly paraphrases this information, adding no new semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Install the destructive-command guard.' It specifies scope (global vs. project) and differentiates itself from the sibling tool bootstrap_project, which is the primary alternative. This is specific and immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool directly ('target="project" or to re-check after a manual jq install') and when not to ('bootstrap_project already checks for the global guard and installs it if missing'). It also names the alternative tool, making the decision tree obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a personal skill into a project. Bundled skills are copied into .claude/skills// (idempotent, existing files kept); proxied skills are installed by running their official CLI in the project. IMPORTANT: skills load only at session start — after installing, STOP and ask the user to restart the Claude Code app/session before invoking the skill. Note: .claude/skills/ is gitignored by bootstrap_project — skills are tooling, not project code. manual_only applies to bundled skills only.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Skill id — the enum values are the valid ids. Catalog: • frontend-design (bundled) — Frontend Design: Distinctive, production-grade frontend UI that avoids generic AI aesthetics. • fullstack-architect (bundled) — Full-Stack Architect: Turn ideas into production docs: PRD → ARCHITECTURE → PLANNING → TASKS. Wizard/Expert modes. • humanizer-ru (bundled) — Humanizer (RU): Strip AI-writing tells from Russian copy — канцелярит, genitive chains, «является», calques, dash-as-connector. Hybrid of blader/humanizer + humanizer-ru (MIT). Russian only: the id is language-scoped so it can't collide with an English `humanizer` installed globally. • image (bundled) — Image Prompting: Writes model-specific image prompts for Seedream 4.5 and Gemini 3, plus the sizing args to pass — feed the result to create_image. Prompt syntax follows each vendor's official guide. Parts derive from smixs/visual-skills (MIT). • ui-ux-pro-max (proxied, runs `npx --yes ui-ux-pro-max-cli@latest init --ai claude`) — UI/UX Pro Max: Macro-design intelligence: styles, palettes, font pairings, stacks. Installs via its own CLI. • emil-design-skills (proxied, runs `npx --yes skills@latest add emilkowalski/skills`) — Emil Design Skills: Micro-design: animation timing, motion physics, Apple principles. Complements ui-ux-pro-max. bundled = copied from the server's frozen payload; proxied = installed by running the third-party CLI shown above in the project, so the user gets its current release. | |
| manual_only | No | Bundled only: install as manual-only (/name), 0 tokens at rest. Default false. | |
| project_path | Yes | Absolute path to the target project directory. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| skill | Yes | |
| invoke | Yes | How to trigger the skill once installed. |
| output | No | Proxied: tail of the installer output. |
| command | No | Proxied: the CLI command that ran. |
| created | No | |
| skipped | No | |
| gitignored | Yes | Patterns newly added to .gitignore (empty if already covered). |
| manual_only | No | |
| install_path | No | Bundled: where the skill was copied (relative to project). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses idempotency (existing files kept), execution of third-party CLIs for proxied skills, the session-start timing issue, the gitignore behavior relative to bootstrap_project, and the scoping of manual_only. This is exceptionally transparent about side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence carries essential information: installation method, restart warning, gitignore note, and manual_only scope. It is not minimal, but the complexity (two installation modes, session caveat) justifies the length. Mildly verbose but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two distinct install methods and a session-restart caveat, the description covers all critical context: mechanics, side effects, idle-token behavior for manual_only, and integration with existing project tooling. An output schema exists, so omitting return format is appropriate. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by clarifying that manual_only only applies to bundled skills, that proxied skills run an official CLI, and that .claude/skills/ is gitignored. These enrich parameter understanding beyond the schema's own field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Install a personal skill into a project.' Clearly differentiates between bundled and proxied installation methods, and the tool name itself disambiguates from sibling tools like bootstrap_project or install_guard. Purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when and how to use: explains bundled vs. proxied mechanics, and the critical instruction to ask the user to restart after installing. However, it does not explicitly mention alternatives or say 'use this tool when the user wants to install a skill and not for X.' Lacks an explicit exclusion statement, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize and re-encode images for production web use via sharp: downscale to max_width (default 1920, never upscales), convert to webp (default; jpeg/avif available), auto-apply EXIF rotation, optionally emit extra srcset variants (widths → name-.webp). By default the source file is replaced by the optimized output so heavy originals don't leak into production; keep_originals: true preserves them. Accepts files or directories. Returns final dimensions (use them for width/height) and sizes before/after. Typical landing use: generate images into assets/img, then optimize the whole directory in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Image files and/or directories (absolute, or relative to the project cwd). A directory takes every supported image at its top level (png/jpg/webp/avif/tiff). | |
| format | No | Output format. Default: webp (best size/support balance for the web). | |
| widths | No | Extra downsized variants for srcset, e.g. [800] → name-800.webp next to the main file. Variants wider than the source are skipped. | |
| quality | No | Encode quality. Defaults: webp/jpeg 80, avif 60. | |
| max_width | No | Resize down to this width, keeping aspect ratio; never upscales. Default: 1920. | |
| keep_originals | No | Keep source files after conversion. Default false: the source is replaced by the optimized output (prevents heavy originals leaking into production). |
| Name | Required | Description |
|---|---|---|
| files | Yes | Optimized files with their output variants (sizes for <img> width/height). |
| skipped | Yes | Inputs that could not be processed. |
| total_kb_after | Yes | Total size of main outputs (srcset variants excluded). |
| total_kb_before | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive default: 'the source file is replaced by the optimized output' and explicitly notes how to preserve originals. It also discloses other behavioral traits like never upscaling, auto-applying EXIF rotation, and returning final dimensions for <img> tags — all beyond what any annotation would provide. It does not mention error handling or permission requirements, but the core behavioral risks are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core operation (resize/re-encode) before detailing optional behavior and usage guidance. Each sentence earns its place, covering defaults, side effects, and a concrete use case. Slightly long but every part is functional; the final 'Typical landing use' sentence is actionable rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description thoroughly compensates: it explains the destructive default, the returned dimensions and sizes, directory support, and the typical workflow. The output schema exists, so the description correctly avoids detailing return fields further. The only gap is the absence of mention of required permissions or error scenarios, but for a local file-processing tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat every parameter definition. It adds semantic context for key parameters like max_width (default 1920, never upscales), format (webp default; jpeg/avif available), widths (srcset variants, wider variants skipped), and keep_originals (default false meaning replacement). This adds value beyond the schema while staying within the baseline-3 expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resizes and re-encodes images for production web use via sharp, listing specific operations (downscale, convert to webp, EXIF rotation, srcset variants) and distinguishing its scope from siblings like create_image or create_website. It names the resource (images) and the verb (optimize/resize/re-encode), making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('Typical landing use: generate images into assets/img, then optimize the whole directory in one call') and implies alternatives by contrast ('heavy originals don't leak into production', 'keep_originals: true preserves them'). It provides clear context for accepting files or directories and notes default vs. optional behaviors, giving the agent enough guidance for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search two local icon sets by English keyword/concept: lucide (~2000 generic UI icons — wrench, shield, clock, printer…) and simple-icons (~3400 brand/company logos — GitHub, HP, Telegram…). Use this before get_icon to find the exact name/set to fetch — exact slugs aren't always guessable.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Restrict to one icon set, or search both (default). | all |
| limit | No | Max results per set. | |
| query | Yes | English keyword or concept, e.g. 'wrench', 'repair', 'github'. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Matches, best score first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the icon sets are local, their sizes and content types, and that exact slugs are unpredictable. It does not explicitly state read-only behavior, but 'search' implies it, and the description adds meaningful context about what the search covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with no redundancy. It front-loads the core action and set details, then the usage guidance. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are covered. The description provides all necessary context: what sets exist, why search is needed, and how it relates to get_icon. For a search tool with three params, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by giving concrete query examples ('wrench', 'repair', 'github') and the concept of 'English keyword/concept', which clarifies the query parameter's semantics beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Search two local icon sets by English keyword/concept', clearly naming both icon sets with sizes and examples. It distinguishes itself from the sibling get_icon by stating this tool is for finding the exact name/set to fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use this before get_icon' and explains why: 'exact slugs aren't always guessable.' This tells the agent when to use this tool versus the obvious alternative and provides the rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0bootstrap_projectcreate_imagecreate_websiteget_iconinstall_guardinstall_skilloptimize_imagessearch_iconsScored across 8 tools
Most tools target distinct resources/actions: project scaffolding, skill/guard installation, image generation/optimization, and icon search/fetch. The only notable overlap is between bootstrap_project and create_website, but their detailed descriptions and specific use cases (generic skeleton vs. landing/multipage website) make them distinguishable.
All tool names follow a consistent verb_noun snake_case pattern: create_image, bootstrap_project, install_skill, create_website, install_guard, optimize_images, search_icons, get_icon. No mixed conventions or stylistic deviations.
With 8 tools, the server is well-scoped. Each tool covers a distinct part of the web development workflow—project setup, skill/guard installation, image creation/optimization, and icon management—without redundancy or bloat.
Core workflows are well covered: project scaffolding (generic and website-specific), skill/guard installation, image generation/editing plus optimization, and icon search/retrieval. Minor gaps include no uninstall/update tools for skills, guard, or projects, but these can be worked around via direct file edits.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
