Begin the App Factory workflow for a new app. Provide the user's raw description verbatim. Returns the project id and the first step of the guided workflow (intake -> interview -> design -> blueprint -> build -> audit -> deploy).

Full state of an App Factory project: phase, interview answers, design choices, work packages, recent audits, and exactly what to do next. Call this whenever unsure how to proceed.

List all App Factory projects with their current phase.

Persist a fact for future sessions. Use scope 'global' for lasting user preferences (favorite styles, fonts, stacks, deploy targets) and scope 'project' for project-specific facts. Global memories personalize every future project.

Search stored memories. Call with no arguments to list recent memories, or filter by query text, scope, and projectId. Always recall global memories at the start of a new project.

Phase 1 of the App Factory workflow. Analyzes the project description against the 'everything an app needs' checklist, returns a structured master prompt skeleton plus a gap list of topics the description does not cover, and advances the project to the interview phase.

Phase 2 of the App Factory workflow. Returns the next batch of unanswered planning questions. Present them to the USER (ideally as multiple-choice where options are given), then save each reply with record_answer. When no questions remain the project advances to the design phase. The USER may answer 'skip' or 'use your judgment' - record that verbatim.

Save the USER's answer to a planning interview question. Record the user's actual words; if they said 'skip' or 'you decide', record that so the blueprint marks it as an agent decision.

A library of the design languages of ~100 of the world's most famous apps (palette directions and publicly observable UI patterns). Use it to offer the USER broader design directions than the gallery presets, to answer 'make it look like X', or to build a custom theme: pick an inspiration, derive design tokens from its palette/traits, and confirm with the user. IMPORTANT: palettes and layout patterns are fair inspiration; never copy logos, trademarks, brand assets or exact trade dress. Filter by query (name/traits) and/or category: social, communication, entertainment, music, productivity, dev tools, design, travel, commerce, food, finance, education, health, utilities.

Phase 3 of the App Factory workflow. Starts a local web page (and opens the user's browser) showing live UI style mockups, font pairings, icon sets and animation levels. The USER clicks their choices there. After telling the user to make their picks, call get_design_choices to collect them. If the browser did not open, give the USER the returned url.

Reads the selections the USER made in the design gallery. If the user has not finished choosing, returns waiting=true - ask the user to finish in the browser, then call again. When all four choices exist the project advances to the blueprint phase.

Fallback for when the browser gallery cannot be used (e.g. headless environment) or the USER stated their preference in chat. Sets one design category choice directly. Valid choiceIds: uiStyle: clean-minimal | bold-vibrant | dark-professional | soft-organic | paper-workspace | player-dark | purple-glass | fintech-gradient | travel-coral | chat-blurple | cinema-dark | messenger-fresh | playful-learning | frosted-premium | material-you | fintech-mint. fontPairing: modern-neutral | elegant-editorial | techy-grotesk | friendly-rounded | startup-modern | material-friendly | luxe-editorial | terminal-dev. iconSet: lucide | heroicons-solid | phosphor-light | tabler | phosphor-duotone | material-symbols. animation: none | subtle | smooth | playful. cardStyle (optional): flat | outlined | elevated | glass. background (optional): solid | subtle-gradient | vivid-gradient | aurora. For categories 'colors' or 'layout' pass the value as JSON in customValue instead of choiceId (colors: {"primary":"#hex","gradient":bool,"second":"#hex"}; layout: {"grid":[12,8],"items":[{"type":"Navbar","x":0,"y":0,"w":12,"h":1}]}).

Phase 4 of the App Factory workflow. Compiles the description, interview answers and design choices into a build blueprint with parallelizable work packages. Launch one parallel subagent per work package within the same parallelGroup (group 0 first, then 1, then 2), passing each subagent the full spec from get_work_package. Advances the project to the build phase.

Returns the full spec for one work package: instructions, done criteria, relevant interview answers, design choices, and the scaffold template (for the foundation package). Give this spec verbatim to the subagent responsible for the package.

Mark a work package complete with a short summary of what was built. When every package is done the project advances to the audit phase.

Phase 5 of the App Factory workflow. Runs the full audit pipeline against the app: typecheck, lint, tests, dependency vulnerability scan, secret scan, semgrep static security analysis (if installed) and Lighthouse (if a running app url is provided). Returns a scored report with a concrete fix list. Fix EVERYTHING in fixList and re-run until passed=true (score >= minScore, default 80, with zero critical findings) - only then does the project advance to deploy. Also self-verify the manualChecklist items the tools cannot measure. This tool can also audit any codebase standalone: pass appPath without projectId.

Phase 6 of the App Factory workflow. Lists deployment targets with requirements and steps. Present the relevant options to the USER (respecting their interview answer about deployment) and ask which they want, then call deploy.

Deploys the finished app. With execute=false it only generates deployment config files (Dockerfile/compose for docker) and returns the exact commands. With execute=true it runs the deployment. Only available once the audit has passed. Marks the project done on success.

Shortcut flow for creating a website fast from available data. Skips the deep planning interview: answers are auto-filled from the description and remembered user preferences. Opens the design gallery immediately for the USER to pick a look, then continue with get_design_choices -> generate_blueprint -> build -> run_audit -> deploy as usual. Pass all content the user provided (business info, texts, links, images) in the description.

Search the internet (DuckDuckGo) for documentation, libraries, best practices or current information needed while planning or building. Returns result titles, URLs and snippets.

Fetch a URL and return its readable text content (HTML stripped). Use for reading documentation pages, API references or content the user linked.

Write to App Factory's journal (its brain). Use it for things worth remembering mid-build: decisions ('chose Postgres over SQLite because...'), problems ('build fails on Windows paths'), milestones ('frontend package complete'), or notes ('user prefers fewer questions'). Tool calls are journaled automatically - log the reasoning and events between them.

Reconstructs context: what is happening, what has happened, and what to do next. With a projectId: the project's full state plus its journal timeline (tool calls, decisions, problems, milestones) and related memories. Without: a global recap of all projects and recent activity. Call this at the START of any session that continues earlier work, after context loss, or whenever unsure what already happened.

The self-improvement loop (inspired by continual-harness agents). Call it in two steps. Step 1 - call WITHOUT lessons: it returns review material (recent errors, open problems, failed audits, repeated tool patterns, existing lessons). Study it and distill what should be done differently next time. Step 2 - call WITH lessons: each lesson must be small, actionable and evidence-backed (cite the journal events that prove it). Lessons are injected into future get_context recaps and work packages, so they actually change behavior. Use scope 'global' for lessons that apply to all future projects (e.g. 'Windows needs taskkill for process trees'), project scope for project-specific ones. Do NOT record duplicates of existing lessons. Good moments to refine: after a failed audit was fixed, after a tricky bug, at project completion.

Keep an objective and its success criteria active across sessions until done (inspired by long-running-agent design). Set one at the start of substantial work, e.g. goal: 'Ship the recipe app to Vercel', criteria: 'audit >= 80, deployed URL responds, user confirmed design'. get_context and get_project_state surface active goals, so any future session knows what 'done' means. Update progress with update_goal as work advances.

Record progress on a goal ('3 of 5 packages built, audit pending') or change its status: 'done' when ALL success criteria are verifiably met, 'paused' if the user shelves it, 'active' to resume. Update progress at meaningful milestones so a fresh session can pick up instantly.

Understand an existing app: detects frameworks, language, dependencies, capabilities (tests, auth, database, payments, PWA, CI, error tracking...), folder structure and issues. Use this FIRST when asked to understand, improve, fix or extend an app that already exists. Complements (does not replace) reading the actual source code.

Adopt an already-built app as an App Factory project in maintenance mode: analyzes the codebase, creates the project (phase=audit) and journals the baseline. From there the improve/fix loop is: suggest_improvements -> make changes -> test_app -> run_audit -> deploy. All brain/journal/memory tools work on it like any other project.

One-step app verification: runs the test suite (if any), the production build (if any), then starts the app and checks it actually responds over HTTP without server errors, and cleanly stops it. Use after building or changing an app. For visual/UX verification, follow up by opening the returned URL with browser tools while running the dev server yourself.

Generates improvement suggestions on two levels: the APP (missing capabilities, quality gaps, UX, performance, retention) and the IDEA (positioning, differentiation, monetization). Works with a projectId (uses stored context), an appPath (analyzes the codebase), or both. Present the relevant suggestions to the USER as a menu - never implement them unasked. Treat the returned ideas as a starting point and ADD your own suggestions specific to this app's domain.

Search GitHub for libraries, starter kits, components or reference implementations that can support the app being built (e.g. 'react drag and drop kanban', 'nextjs stripe subscription starter'). Returns repos sorted by stars with license and maintenance signals. Prefer permissive licenses (MIT/Apache-2.0/BSD/ISC) for code you'll incorporate; flag anything GPL to the user before using it. Set GITHUB_TOKEN in the MCP env to raise the rate limit.

Generates tailored legal document templates (Privacy Policy, Terms of Service, Cookie Policy) plus a region-aware compliance checklist (GDPR, CCPA/CPRA, DPDP, COPPA, PCI-DSS). Ask the USER for the inputs first - especially regions and what personal data the app collects. Write the returned documents into the app as /privacy, /terms (and /cookies) pages and implement the compliance checklist items. Always tell the user these are templates, not legal advice.