Skip to main content
Glama

floot

by com.floot

Update Project Metadata

update_project_metadata

Update project settings (current values appear at the top of list_files). Keys: title (2-100 chars), description, iconUrl, splashUrl, mobileAppId, enableSSR (boolean), flootAiDisallowed (boolean — true opts the project out of @floot/ai), and iOS Info.plist purpose strings (NS…UsageDescription — set to a string, or null to remove) plus boolean Info.plist keys (UIViewControllerBasedStatusBarAppearance — set to a boolean, or null to restore the template default). Invalid keys/values are reported and skipped. NOTE: these take effect on the published app only after the next publish (publish_app, or the user's Publish button). The iosInfoPlist keys only affect builds made before the first iOS publish; after the iOS app is published, edit the project file static/__dev/native/ios-info.plist directly with write_file/edit_file (see get_guides('ios-info-plist')). Likewise, after the first Android publish, edit static/__dev/native/android-manifest.xml directly for manifest changes (see get_guides('android-manifest')). shareTarget makes the native app appear in the iOS and Android share sheets (other apps can share photos/videos/files/text into it): pass { enabled: true, mimeTypes?, allowMultiple? } to register, { enabled: false } to remove; receiving the shared items still needs the handler in app code — read get_guides('share-target') first and ship both together. nativeSystemBars controls how the native app treats the status bar / Android navigation bar: mode 'inset' (default) keeps the app below the bars and paints the exposed strips color (default black — set it to the app's header color for a seamless look); mode 'edge-to-edge' runs the app under the bars, which REQUIRES the app to pad by var(--safe-area-inset-top/bottom) itself — read get_guides('native-system-bars') first and ship both changes together. Not superseded by the __dev/native files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatesNoFlat metadata fields (see the tool description).
projectIdYes
shareTargetNoShare-sheet target config (iOS Share Extension + Android share sheet). Omit to leave unchanged; { enabled: false } removes it.
nativeSystemBarsNoNative system-bars config. Omit to leave unchanged; { mode: 'inset' } with no color restores the default.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / shareTarget
      Added value: +{
+  "additionalProperties": false,
+  "description": "Share-sheet target config (iOS Share Extension + Android share sheet). Omit to leave unchanged; { enabled: false } removes it.",
+  "properties": {
+    "allowMultiple": {
+      "description": "Also accept multi-select shares. Default true.",
+      "type": "boolean"
+    },
+    "enabled": {
+      "type": "boolean"
+    },
+    "mimeTypes": {
+      "description": "MIME patterns to accept, e.g. [\"image/*\",\"video/*\"] (default). Allowed: image/*, video/*, audio/*, text/plain, application/pdf.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "enabled"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • removedInput schema / properties / shareTarget
      Removed value: -{
-  "additionalProperties": false,
-  "description": "Share-sheet target config (iOS Share Extension + Android share sheet). Omit to leave unchanged; { enabled: false } removes it.",
-  "properties": {
-    "allowMultiple": {
-      "description": "Also accept multi-select shares. Default true.",
-      "type": "boolean"
-    },
-    "enabled": {
-      "type": "boolean"
-    },
-    "mimeTypes": {
-      "description": "MIME patterns to accept, e.g. [\"image/*\",\"video/*\"] (default). Allowed: image/*, video/*, audio/*, text/plain, application/pdf.",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    }
-  },
-  "required": [
-    "enabled"
-  ],
-  "type": "object"
-}
  3. Changed1 schema field changed
    • addedInput schema / properties / shareTarget
      Added value: +{
+  "additionalProperties": false,
+  "description": "Share-sheet target config (iOS Share Extension + Android share sheet). Omit to leave unchanged; { enabled: false } removes it.",
+  "properties": {
+    "allowMultiple": {
+      "description": "Also accept multi-select shares. Default true.",
+      "type": "boolean"
+    },
+    "enabled": {
+      "type": "boolean"
+    },
+    "mimeTypes": {
+      "description": "MIME patterns to accept, e.g. [\"image/*\",\"video/*\"] (default). Allowed: image/*, video/*, audio/*, text/plain, application/pdf.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "enabled"
+  ],
+  "type": "object"
+}
  4. Changed3 schema fields changed
    • addedInput schema / properties / nativeSystemBars
      Added value: +{
+  "additionalProperties": false,
+  "description": "Native system-bars config. Omit to leave unchanged; { mode: 'inset' } with no color restores the default.",
+  "properties": {
+    "color": {
+      "description": "Inset mode only: #rrggbb paint of the strips under the bars. Default #000000.",
+      "type": "string"
+    },
+    "iconStyle": {
+      "description": "Color of the bar ICONS. Inset: defaults to contrast with `color`. Edge-to-edge: defaults to 'dark'.",
+      "enum": [
+        "light",
+        "dark"
+      ],
+      "type": "string"
+    },
+    "mode": {
+      "enum": [
+        "inset",
+        "edge-to-edge"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "mode"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / updates / description
      Added value: +"Flat metadata fields (see the tool description)."
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "updates"
-]New value: +[
+  "projectId"
+]
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only indicate the operation is not read-only and not destructive, so the description carries the behavioral burden. It reveals that invalid keys/values are reported and skipped, that metadata changes are deferred until publish, that iOS/Android keys have platform-specific lifecycle limitations, and that shareTarget/nativeSystemBars require app-side handling. No contradiction with 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?

The description is long but information-dense and organized by key groups and caveats. It earns most of its length, though there is some redundancy with schema descriptions for shareTarget/nativeSystemBars and the closing 'Not superseded' sentence feels abrupt. Still, every major section conveys operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers accepted keys, validation behavior, publish timing, platform-specific override paths, and required companion reads, which is highly complete for a complex tool. The main gap is that no output schema exists and the description does not explicitly state the success/failure response shape beyond saying invalid values are reported.

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?

Schema coverage is 75%, but the description is essential because the updates property defers to it ('see the tool description'). It adds operational meaning to shareTarget and nativeSystemBars, including defaults, removal semantics, and required companion code, going well beyond the schema's brief property descriptions.

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?

The description uses a specific verb and resource ('Update project settings') and then enumerates the supported metadata keys so an agent knows exactly what this tool operates on. It also distinguishes itself from the publish flow and from direct file editing tools, making it easy to tell apart from siblings like publish_app, write_file, and edit_file.

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?

The description gives explicit routing guidance: after iOS or Android publish, edit the native project files directly with write_file/edit_file instead of using this tool, and read the relevant get_guides before using shareTarget or nativeSystemBars. It also clarifies that changes only take effect after the next publish, which directly informs when to call this tool versus alternatives.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Tools are mostly distinct, but there is some overlap among file-modifying tools (edit_file, write_file, apply_patch) and between run_code_in_vm and run_code_in_browser. Detailed descriptions and clearly scoped use cases help agents select correctly.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (create_project, list_files, execute_sql), but a few deviate (apply_patch, card_upload_asset, run_code_in_vm). Overall readable and predictable, with only minor inconsistencies.

Tool Count2/5

With 46 tools, the server exceeds the typical well-scoped range and approaches the extreme threshold. While the broad scope of a full development platform justifies many tools, this count may overwhelm agents and increase misselection risk.

Completeness4/5

The tool surface covers the full development lifecycle: project creation, file operations, database management, resource provisioning, deployment, testing, and debugging. Minor gaps exist (e.g., no delete_project or checkpoint management), but core workflows are well-supported.

Resources