Kasy MCP

Ask in plain language. The assistant prepares the machine, creates the app, and turns features on without you typing in a terminal.

The Kasy MCP (kasy-mcp) is the main way to use the kit. Instead of typing kasy in a terminal, you talk to your assistant (Cursor, Claude Code, Claude Desktop…) and it calls the right tools.

Think of the MCP as a plug: AI on one side, the kasy CLI on the other. Under the hood it is the same tool (same license, same commands). Only how you talk to it changes.

Have not turned the MCP on yet? Start with Install Kasy. This page covers what it does and what each tool covers.

The idea

Today the MCP already covers the full day-to-day flow: prepare the machine, create a project, run and reset the app, add or remove a feature, update the kit, swap color/splash/icon, read the design system before building a screen, configure credentials (Apple, Facebook, iOS/Android signing, Codemagic, RevenueCat/Sentry/Mixpanel/AdMob...), publish to the stores (iOS and Android, locally or via Codemagic), configure a domain, and check/fix the project.

The product direction goes further: in a few weeks, the MCP should be able to do everything in the Kasy flow from chat, without you having to keep typing commands in a terminal. You ask; the assistant runs it.

The CLI in the terminal still exists. If you prefer typing kasy, use the installer. Both paths use the same kasy-cli under the hood.

What the MCP does (and what it does not)

Does	Does not
Run the real `kasy-cli` on your machine	Reimplement the CLI (zero duplicated logic)
Diagnose and try to fix the environment (`doctor` + install)	Ask for `sudo` or wipe a disk (denylist)
Read the design system of the open project live	Invent a generic color/font/component
Report a resolved issue so `doctor` can improve	Send name, email, license key, or a full path

It runs locally (the installer runs kasy mcp setup for you). There is no Kasy-hosted server in the middle. The kasy-mcp package bundles kasy-cli for the assistant. Details in Install Kasy.

Tools

Each tool is a request the assistant can make. You do not call it by name: you speak in plain language and the model picks.

Prepare and fix the machine

Tool	Under the hood	When to use
`prepare_machine`	`kasy doctor`	"Prepare my machine for Kasy"
`run_setup_command`	one shell command	The assistant installs what is missing (Homebrew, choco, apt, `npm -g`…)

Expected loop: prepare_machine → if something is missing, run_setup_command → prepare_machine again, until it passes. The assistant should not only diagnose and stop.

Create and manage the project

Tool	Under the hood	When to use
`create_project`	`kasy new` (Quick mode)	"Create a Kasy project with Firebase"
`list_features`	`kasy features`	See what exists before adding
`add_feature`	`kasy add <feature>`	"Add drive to my project" (also works for revenuecat, ads, onboarding, sentry, kanban...)
`remove_feature`	`kasy remove <feature>`	"Remove ads from my project"
`check_status`	`kasy status`	Backend, features, and pending credentials
`check_project`	`kasy check`	Push / config diagnostics (`fix` optional)
`configure_status`	`kasy configure --status`	What still needs filling in (read-only)
`update_project`	`kasy update [feature]`	"Update my project to the newest kit"
`deploy_backend`	`kasy deploy`	Firebase deploy (before the first `run_app`)
`kanban`	`kasy kanban <action>`	"What's left to do on this project?" / "Create a task to review checkout"

create_project only covers the Quick (non-interactive) path. If you want step-by-step with every question, use the CLI in a terminal.

After an update_project, if the kit overwrites a file you customized, the assistant should reconcile your change with the new code (not drop it silently).

kanban reads and edits the project's board (the same one the app's Kanban screen shows) without any new login: on Firebase it uses your own gcloud session, on Supabase it uses the linked project's service_role_key. Firebase and Supabase only — a custom API REST backend isn't supported (there's no generic admin credential to assume). See Kanban.

Run and reset the app

Tool	Under the hood	When to use
`run_app`	`kasy run` (background)	"Run the app"
`reload_app`	dev bridge (`/dev/reload` or `/dev/restart`)	After Dart edits while `kasy run --web` is running (hot reload/restart)
`clear_web_storage`	`kasy clear-web`	"Clear the browser" / test onboarding again on web
`stop_app`	stops the mcp-run pid	"Stop the app"
`reset_app`	`kasy reset`	Test onboarding/push from zero (simulator or web)

When you ask to "run the app", the assistant asks:

Platform: iOS, Android, or web
If web:
- Default: only return http://localhost:5555
- openBrowser=true: open in the system default browser (--open-browser)
- flutterChrome=true: isolated Flutter Chrome (--open)
- freshStorage=true: clear localStorage, sessionStorage, and IndexedDB on open (--fresh, includes Firebase Auth session). Combine with openBrowser and device preview on an iOS/Android/iPad tab to test onboarding as a first visit

If the app is already running: clear_web_storage or reset_app with platform=web.

Do not use run_kasy_command for kasy run. That tool waits for the process to exit and would kill the session.

Branding (Personalization)

Tool	Under the hood	When to use
`set_primary_color`	`kasy color`	"Change the primary color to #0553B1"
`set_icon`	`kasy icon --image`	"Change the app icon"
`set_splash`	`kasy splash --light/--dark`	"Change the splash logos"
`set_favicon`	`kasy favicon --image`	"Change the favicon"

Credentials and integrations

Tool	Under the hood	When to use
`configure_apple_web`	`kasy apple-web`	Turns on web Sign in with Apple (Firebase)
`configure_facebook_login`	`kasy facebook`	Configures Facebook Login (native + backend)
`set_notification_texts`	`kasy notifications text`	Changes the demo notification and reminder copy
`configure_ios_signing`	`kasy ios configure`	Installs the App Store Connect API key (Key ID + Issuer ID + `.p8`)
`configure_android_signing`	`kasy android configure`	Writes `android/key.properties` from an existing keystore
`configure_codemagic`	`kasy codemagic configure`	Links the Codemagic token and the project's app ID
`configure_project_keys`	`kasy configure --set`	Fills in credentials (RevenueCat, Sentry, Mixpanel, AdMob, Stripe, App Store ID…), one or many at once
`configure_license`	`kasy license <key>`	Saves and validates your Kasy license key — without this tool, `create_project`/`add_feature`/etc. fail asking for it

These seven used to be stuck in the terminal because MCP closes stdin (no answering prompts one by one). What made it work: the assistant asks for the values in chat first, then calls the tool once with everything — nothing waits on an answer mid-process. None of them generate a new credential (keystore, API key, Meta/Apple/Codemagic app): that stays manual, done once in the respective consoles. configure_license is the exception: the key itself arrives by email at purchase time from kasy.dev, the tool doesn't generate it.

Publish (stores and web)

Tool	Under the hood	When to use
`release_ios`	`kasy ios release`	"Publish iOS" (Mac, configure + Xcode already done)
`build_ios`	`kasy ios build`	IPA without upload
`clean_ios`	`kasy ios clean`	Clean iOS build
`release_android`	`kasy android release`	Signed AAB locally + opens Play Console
`build_aab`	`kasy android build-aab`	AAB only, no console
`build_apk_signed`	`kasy android build-apk-signed`	Signed release APK — sideloading, alternative stores (Amazon, Samsung, F-Droid)
`build_apk`	`kasy android build-apk`	Unsigned debug APK — quick test on a phone
`codemagic_release`	`kasy codemagic release`	"Publish with Codemagic" (iOS and/or Android)
`codemagic_status`	`kasy codemagic status <id>`	Follow the cloud build
`manage_domain`	`kasy domain list\|add\|remove`	Auth authorized domains (web)
`set_release_version`	`kasy release-version`	Live store version / force update

Fix the project (Reference)

Tool	Under the hood	When to use
`fix_project`	`kasy fix pub-get\|pods\|clean`	"Run pub get" / "reinstall pods" / "clean"

Design system and screens

Tool	Under the hood	When to use
`list_components`	reads `lib/components/` live	Before creating or editing any screen

The list comes from the current project, not a cache. After a rebrand or kasy update, the set can change. The assistant should not invent raw Material (Scaffold, AlertDialog, TextField…) when a Kasy equivalent exists.

Validate in the browser (Browser QA)

Tool	Under the hood	When to use
`browser_qa_guide`	checks the project's semantics bridge + returns the validation checklist	After implementing or changing a screen, before calling it done

Flutter Web paints to a canvas — without the semantics tree turned on, a browser agent (Cursor, Claude, Playwright) can't see a button or a field, only pixels. The kit already enables this in debug/profile (see the Web Guide); browser_qa_guide confirms the bridge in lib/main.dart and returns docs/agent-browser-qa.md. Full AI file map: AI guidance.

Important: the MCP is a headless process, it doesn't open a browser itself. The tool only returns the checklist; the agent's own browser (Claude Code's Browser pane, Cursor's browser, etc.) is what actually runs it.

Any other CLI command

Tool	Under the hood	When to use
`list_commands`	`kasy --help` / `kasy <cmd> --help`	Discover flags before running
`run_kasy_command`	`kasy <command> <args>`	prepare, license, and other rare flags
`read_kasy_docs`	fetches `kasy.dev/docs` live	Read the official docs for any page before guessing a step

Prefer the dedicated tool when it exists. run_kasy_command is the Swiss army knife: it only runs the kasy binary, never arbitrary shell. Never use it for kasy run.

read_kasy_docs fetches the published docs (not training data, which can be stale) as clean markdown, in pt/en/es. Use it to confirm a rare flag, read a feature's full setup guide (e.g. funcionalidades/stripe) before configuring it, or check referencia/troubleshooting when something fails in an unfamiliar way.

Telemetry (the assistant calls it, not you)

Tool	Under the hood	When to use
`report_issue`	POST to a Kasy edge function	After actually trying to fix something

Fixing is required; reporting alone does not fix anything for you. The normal path is resolved: true with the exact command that worked. That becomes an improvement in kasy doctor. No PII: no name, email, key, or full path.

Resources

Besides tools, the MCP exposes two resources the assistant reads on its own:

URI	What it is
`kasy://design-system-guide`	This project's `DESIGN_SYSTEM.md`, `AGENTS.md`, and (if present) `docs/figma-workflow.md`
`kasy://architecture`	Feature-first convention: `api → repository → provider → ui`

No hardcoded color or font in the MCP package. After a rebrand, the source of truth stays the project on disk.

Typical asks

With the MCP on, you can say things like:

Prepare my machine for Kasy

Create a project called my-app with Firebase, quick mode

Add revenuecat to my project

Publish iOS

Publish Android on Codemagic and check the status

Add app.mydomain.com to the authorized domains

The assistant picks the tool (prepare_machine, create_project, run_app, release_ios, codemagic_release…). You do not need to remember the name.

Known limitation (v1)

Tools and resources without an explicit directory resolve relative to the MCP process working directory.

Cursor / Claude Code: reliable (cwd = the open project).
Claude Desktop: no "open project" concept. After create_project, the assistant should pass an explicit directory to list_components, check_status, and so on.

Kasy MCP vs third-party MCPs

These are different things:

MCP	What for
Kasy (`kasy-mcp`)	Create/manage the Flutter app the kit generates
RevenueCat	Build the catalog (products, entitlements, offerings) in their dashboard
Stripe	Create the product and prices in the Stripe account

You can use all three together: the Kasy MCP turns the feature on in code; Stripe/RevenueCat build the catalog in their dashboard.

Next step

Last updated on 08/02/2026

On this page