Skip to main content
Glama

floot

by com.floot
OverviewDiscussionsAdmin

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 instead (nothing is published until they press Publish on it; to publish a live app again without the form, pass domain_type 'floot_subdomain' and its current subdomain). 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. Same for shipping: when the project uses Floot Shipping and its owner has not connected Shippo (or the Shippo sign-in has expired), the publish is refused and a Login Shippo card is returned (nothing published): tell the owner to click it and sign in to Shippo, 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

NameRequiredDescriptionDefault
domainNofloot_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.
mobileNoSet 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.
projectIdYes
add_anotherNocustom_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_typeNoOmit 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_flootNofalse 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.

  1. Changed1 schema field changed
    • 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"
-}
  2. Changed1 schema field changed
    • 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"
+}
  3. Changed3 schema fields changed
    • 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."
  4. Changed1 schema field changed
    • 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"
+}
  5. Changed1 schema field changed
    • 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"
+}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint/openWorldHint, and the description goes well beyond them: it discloses that omitting domain returns a publish form where nothing is published, that Stripe/Shippo blockers cause a refusal with a card and nothing goes live, and that the tool always publishes live so the agent should never ask test-vs-live. That is high-value behavioral context an agent cannot get from the schema or annotations.

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 core action before the branch conditions, and every clause is actionable. It is nonetheless long, and the Stripe and Shippo refusal passages repeat the same 'publish is refused / nothing published / click the card / call again' template, which could be collapsed into one sentence.

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?

No output schema exists, and the description compensates by describing the non-obvious return shapes — publish form, Connect card, Set up payments card, Login Shippo card, existing-domain list — and what 'nothing published' means in each. For a destructive, open-world mutation tool with 6 params, an agent has everything needed to call it and interpret the result.

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 already 83%, yet the description still adds real semantic value — when to set mobile:true, what domain_type 'floot_subdomain' plus a current subdomain means for republishing an existing live app, and the add_another caveat. Some of this duplicates the schema prose (which independently describes each param in depth), so it is additive without being essential everywhere.

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?

Opens with a specific verb+resource ('Publish the app to production') and enumerates the concrete triggers: first publish, republish after changes, custom domain setup. The verb alone cleanly separates it from siblings like unpublish_app and get_publish_status, and the mobile/payments branches make the scope concrete rather than abstract.

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?

Explicit when-to-use rules throughout: call on first publish, on republish, to set up a custom domain, and pass mobile:true whenever the user mentions iOS/Android/TestFlight/App Store/etc. It also routes the agent to alternatives and prerequisites — 'Read get_guides("publishing") before your first call' and 'read get_publish_status for the plan and allowance first' — and states the omit-domain behavior as the alternative path.

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

All floot toolsInspect
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