Skip to main content
Glama
AndreyTsibin

mcp-super-app

by AndreyTsibin

Create website

create_website

Creates a website project with a task tracker. Two flows: scaffold a landing page from a 21-section library, or rebuild an existing site as an original Astro project.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesWhich 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.
nameNoSite name — used in the previewer config label and the report. Optional.
install_depsNolanding only: run `npm install` after scaffolding (default true). Ignored for 'multipage' — there is no Astro project yet.
project_pathYesAbsolute path to the target project directory (must exist).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowYesEntry point of the method — the flow guide or the playbook.
kindYesFlow that was set up.
createdYesPaths that were created (relative to project).
skippedYesPaths left untouched because they already existed.
trackerYesTask tracker: one row = one session.
updatedYesExisting files a block was appended to (.claude/CLAUDE.md).
deps_errorNoWhy `npm install` failed, when it did.
next_stepsYesWhat happens in the next session — task 1 only.
preview_portYesPort the Astro dev server (launch.json) serves on.
skills_failedYesSkills that failed to install — install by hand later.
deps_installedNolanding only: whether `npm install` completed successfully.
skills_installedYesFlow skills installed into the project.
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

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/AndreyTsibin/mcp-super-app-public'

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