Kasy MCP

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.

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)

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

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

Create and manage the project

create_project only covers the Quick (non-interactive) path. Before asking anything, the assistant should offer the choice between Quick (here, a few questions) and Advanced (step-by-step with every question, terminal-only via kasy new). It recommends Quick, but either way you can add or remove features later (kasy add/kasy remove, or add_feature/remove_feature in chat).

On Supabase/API, the assistant asks push only (no separate Google question; Google is ON by default): no push = no Firebase companion (Google in the scaffold; provider Enabled on Supabase Auth; credentials later via configure_google_login); with push = free Firebase companion project (FCM) and Google OAuth can be configured automatically in that step.

To avoid a giant numbered list in chat:

• Cursor / Claude Code: use AskQuestion, then call create_project with directory, backend, region, and push filled in. Do not call without those fields in Cursor (MISSING_PREFS).
• Claude Desktop and clients without a quiz: create_project with useElicitationForm: true and missing directory/backend opens the MCP form.

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

When you ask to "run the app". The assistant should use a structured quiz (not a markdown list) for:

1. Platform: iOS, Android, or web
2. 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)

Credentials and integrations

These nine used to be stuck in the terminal because MCP closes stdin (no answering prompts one by one). What made it work: the assistant collects values via structured quiz (AskQuestion) or MCP form first, then calls the tool once with everything. License keys and OAuth secrets are plain text, not multiple-choice quizzes. 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)

Fix the project (Reference)

Design system and screens

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)

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

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)

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:

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:

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

1. Install the MCP (if you have not yet)
2. Prepare your machine
3. Create your first app

Last updated on 08/23/2026