floot

Publish App

publish_app

Destructive

Publish the app to production — call for the first publish, to publish again after changes the user wants live, and to set up a custom domain. Omit domain and the user gets the publish form in the editor. Pass mobile: true whenever the user mentions iOS, Android, TestFlight, App Store, Google Play, or a mobile/native app — with no store account connected that returns a Connect card; with one connected it publishes with the store builds attached. When the project takes payments and its owner has not finished Stripe setup, the publish is refused and a Set up payments card is returned (nothing published): tell the owner to click the button on the card and finish Stripe setup, then call publish_app again. publish_app always publishes live (web, and the mobile app when it is built; payments in Stripe live mode) — never ask the user test or live. Mobile test builds are started by the user on floot.com. Read get_guides('publishing') for modes, inputs, and statuses before your first call.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	No	floot_subdomain only: subdomain label (lowercase, digits, hyphens, max 40). Omit to show the user the publish form instead; on a published app a different subdomain is refused (unpublish_app first, confirming with the user). Ignored for custom_domain — the wizard collects the domain.
`mobile`	No	Set true whenever the request mentions iOS, Android, TestFlight, App Store, Google Play, Play Store, a native or mobile app, or a phone build — they all mean a mobile build. No store account connected → returns a Connect card (nothing published). Connected → publishes the web app with the store builds attached; the job completes when the web build is live. Omitted on a live app follows the project's saved setting: on plans with unlimited app builds that setting decides (mobile switched off stays web-only); on metered plans omitted always means web-only, and true spends one of a small monthly allowance (the remaining count comes back in the result) — read get_publish_status for the plan and allowance first. Passing true or false also updates the saved setting; omitting leaves it alone.
`projectId`	Yes
`add_another`	No	custom_domain only: the project ALREADY has a custom domain and the user has explicitly asked for an ADDITIONAL one. Without it, a custom_domain call on a project that already has domains returns those domains instead of opening the wizard — so a user whose domain is already connected is told so rather than sent to add it again.
`domain_type`	No	Omit for the floot subdomain (shows the publish form in the editor when domain is omitted). 'custom_domain' for domain setup — a paid-plan feature (get_publish_status reports `paid`); it fails for free accounts.
`include_made_with_floot`	No	false removes the 'Made with Floot' badge (paid plans only — fails for free accounts). Omit to keep the current setting.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

removedInput schema / properties / skipPaymentsOnboarding

Removed value: -{
-  "description": "true publishes although the owner's payments setup is unfinished; the app's payment screens stay unavailable until it is done.",
-  "type": "boolean"
-}

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / skipPaymentsOnboarding

Added value: +{
+  "description": "true publishes although the owner's payments setup is unfinished; the app's payment screens stay unavailable until it is done.",
+  "type": "boolean"
+}

Changed3 schema fields changedSep 11, 2026

changedInput schema / properties / domain / description

Previous value: -"floot_subdomain only: subdomain label (lowercase, digits, hyphens, max 40). Ignored for custom_domain — the wizard collects the domain."New value: +"floot_subdomain only: subdomain label (lowercase, digits, hyphens, max 40). Omit to show the user the publish form instead; on a published app a different subdomain is refused (unpublish_app first, confirming with the user). Ignored for custom_domain — the wizard collects the domain."

changedInput schema / properties / domain_type / description

Previous value: -"Omit to show the publish form (unpublished) or current status (published). 'custom_domain' for domain setup — a paid-plan feature (get_publish_status reports `paid`); it fails for free accounts."New value: +"Omit for the floot subdomain (shows the publish form in the editor when domain is omitted). 'custom_domain' for domain setup — a paid-plan feature (get_publish_status reports `paid`); it fails for free accounts."

changedInput schema / properties / mobile / description

Previous value: -"Set true whenever the request mentions iOS, Android, TestFlight, App Store, Google Play, Play Store, a native or mobile app, or a phone build — they all mean a mobile build. No store account connected → returns a Connect card (nothing published). Connected → publishes the web app with the store builds attached; the job completes when the web build is live. Omit only for a web publish."New value: +"Set true whenever the request mentions iOS, Android, TestFlight, App Store, Google Play, Play Store, a native or mobile app, or a phone build — they all mean a mobile build. No store account connected → returns a Connect card (nothing published). Connected → publishes the web app with the store builds attached; the job completes when the web build is live. Omitted on a live app follows the project's saved setting: on plans with unlimited app builds that setting decides (mobile switched off stays web-only); on metered plans omitted always means web-only, and true spends one of a small monthly allowance (the remaining count comes back in the result) — read get_publish_status for the plan and allowance first. Passing true or false also updates the saved setting; omitting leaves it alone."

Changed1 schema field changedSep 3, 2026

addedInput schema / properties / mobile

Added value: +{
+  "description": "Set true whenever the request mentions iOS, Android, TestFlight, App Store, Google Play, Play Store, a native or mobile app, or a phone build — they all mean a mobile build. No store account connected → returns a Connect card (nothing published). Connected → publishes the web app with the store builds attached; the job completes when the web build is live. Omit only for a web publish.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 1, 2026

addedInput schema / properties / add_another

Added value: +{
+  "description": "custom_domain only: the project ALREADY has a custom domain and the user has explicitly asked for an ADDITIONAL one. Without it, a custom_domain call on a project that already has domains returns those domains instead of opening the wizard — so a user whose domain is already connected is told so rather than sent to add it again.",
+  "type": "boolean"
+}

First observedAug 27, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Compared to annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description adds crucial behavioral context beyond structured fields: Stripe setup refusal behavior, Connect card generation for mobile, that publish always goes live, the editor publish form for web omissions, and the allowance mechanics on metered plans for mobile builds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the primary action and branches logically through mobile, payments, and domain cases. Some sentences are long and packed with conditional clauses (the mobile: true paragraph), but every clause carries operational value and nothing is redundant.

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 complexity of the publish flow (different modes, payment setup gates, mobile build semantics, paid plan limits), the description covers the key decision points an agent needs to call correctly. It defers detailed modes and statuses to get_guides('publishing') and defers plan/allowance checks to get_publish_status, which is appropriate for preserving conciseness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is high (83%), the description adds substantial meaning beyond the schema: explains that omitting domain shows the publish form, that passing mobile: true triggers store build handling and updates the saved setting, and the refusal conditions when payments aren't set up. This is far richer than what the schema alone conveys.

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?

States a specific verb+resource (publish the app to production) and enumerates the distinct use cases: first publish, republish after changes, and custom domain setup. The agent can distinguish this from siblings like unpublish_app or get_publish_status.

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 instructs when to pass mobile: true (iOS, Android, TestFlight, App Store, Google Play, native/mobile app). Explains onboarding edge cases (Stripe setup refusal, Connect card) and explicitly says never to ask the user test vs live. Points to get_guides('publishing') for first-call context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All floot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?