Skip to main content
Glama

floot

by com.floot
OverviewDiscussionsAdmin

Provision Resource

provision_resource

Provision a Floot-managed backend resource for the project — fully server-side (Floot mints all secrets; no keys to paste). Also seeds the working code for it. Available:

  • database — A Floot-managed Postgres database (Neon). FLOOT_DATABASE_URL is set for the app.

  • auth — Email/password + session auth (JWT_SECRET, auto-provisions a database if none). Injects auth pages, endpoints, and helpers.

  • oauth-login — Sign in with Google via Floot's brokered OAuth (FLOOT_OAUTH). Injects OAuth provider classes, login buttons, helpers.

  • microsoft-login — Sign in with Microsoft via Floot's brokered login (FLOOT_MICROSOFT_LOGIN). Injects button + auth endpoints.

  • google-integration — FLOOT_GOOGLE_INTEGRATIONS is built-in Google integration. Use it to let end users connect their Google account so the app can read/write their Gmail, Google Calendar, or Google Drive — unless the user specifies they want to use their own Google client. See get_guides("floot-provided-google-integrations").

  • microsoft-integration — Microsoft Graph access (Outlook/Teams/etc.) via Floot's brokered Microsoft OAuth (FLOOT_MICROSOFT_INTEGRATIONS). Injects Connect button + endpoints.

  • push-notifications — Web + native push (FLOOT_PUSH). Mints VAPID keys, injects helpers/pushClient (subscribe/unsubscribe) + a service worker. Enum values not listed above are beta-gated and unavailable on most accounts. SENDING email from the app is NOT a resource — the builtin @floot/email handles it with zero setup (get_guides("email")). For a user's OWN external key (their OpenAI key, an external database), this is NOT the tool — use request_external_resource instead. Idempotent: re-running returns the existing resource and skips seed files that already exist.

  • app-connection — let this project's backend call functions ANOTHER Floot app exports (no API keys): pass app_target and app_functions. Only apps the user can edit, only functions in the other app's helpers/flootAppExports.tsx (saved is enough: write both apps first, connect, then publish both); the user confirms in a dialog. Read get_guides("app-calls") first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_noteNoOnly for resource "app-connection": one sentence for the user on why this project needs these functions. Shown in the confirmation dialog.
resourceYes
projectIdYes
app_targetNoOnly for resource "app-connection": the OTHER Floot app — its project id, name.floot.app address or custom domain.
app_functionsNoOnly for resource "app-connection": the exact function names this project needs from the other app's helpers/flootAppExports.tsx.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / app_functions
      Added value: +{
+  "description": "Only for resource \"app-connection\": the exact function names this project needs from the other app's helpers/flootAppExports.tsx.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / app_note
      Added value: +{
+  "description": "Only for resource \"app-connection\": one sentence for the user on why this project needs these functions. Shown in the confirmation dialog.",
+  "type": "string"
+}
    • addedInput schema / properties / app_target
      Added value: +{
+  "description": "Only for resource \"app-connection\": the OTHER Floot app — its project id, name.floot.app address or custom domain.",
+  "type": "string"
+}
    • changedInput schema / properties / resource / enum
      Previous value: -[
-  "database",
-  "auth",
-  "oauth-login",
-  "microsoft-login",
-  "google-integration",
-  "microsoft-integration",
-  "push-notifications",
-  "self-edit",
-  "payments",
-  "shipping"
-]New value: +[
+  "database",
+  "auth",
+  "oauth-login",
+  "microsoft-login",
+  "google-integration",
+  "microsoft-integration",
+  "push-notifications",
+  "self-edit",
+  "payments",
+  "shipping",
+  "app-connection"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / resource / enum
      Previous value: -[
-  "database",
-  "auth",
-  "oauth-login",
-  "microsoft-login",
-  "google-integration",
-  "microsoft-integration",
-  "push-notifications",
-  "self-edit",
-  "payments"
-]New value: +[
+  "database",
+  "auth",
+  "oauth-login",
+  "microsoft-login",
+  "google-integration",
+  "microsoft-integration",
+  "push-notifications",
+  "self-edit",
+  "payments",
+  "shipping"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / resource / enum
      Previous value: -[
-  "database",
-  "auth",
-  "oauth-login",
-  "microsoft-login",
-  "google-integration",
-  "microsoft-integration",
-  "push-notifications",
-  "self-edit"
-]New value: +[
+  "database",
+  "auth",
+  "oauth-login",
+  "microsoft-login",
+  "google-integration",
+  "microsoft-integration",
+  "push-notifications",
+  "self-edit",
+  "payments"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / resource / enum
      Previous value: -[
-  "database",
-  "auth",
-  "oauth-login",
-  "microsoft-login",
-  "google-integration",
-  "microsoft-integration",
-  "push-notifications"
-]New value: +[
+  "database",
+  "auth",
+  "oauth-login",
+  "microsoft-login",
+  "google-integration",
+  "microsoft-integration",
+  "push-notifications",
+  "self-edit"
+]
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing that Floot mints all secrets server-side, that the tool seeds working code, that it is idempotent (re-running returns the existing resource and skips existing seed files), and that app-connection requires an in-dialog user confirmation.

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-loads purpose and scope before the bullet list. The length is driven by 11 enum values that each need disambiguation, so most sentences earn their place, though the dense prose on google-integration and app-connection could be trimmed slightly.

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?

For a mutating, no-output-schema tool this covers side effects (minted secrets, injected files, service worker), idempotency, cross-app prerequisites, and the confirmation dialog. An agent has everything needed to call it correctly.

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 60%, and the description compensates by explaining what each resource value produces (env vars like FLOOT_DATABASE_URL, JWT_SECRET, injected pages/helpers) and by flagging that unlisted enum values are beta-gated. It also clarifies app_target/app_functions constraints, though projectId remains undocumented.

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 and resource ('Provision a Floot-managed backend resource for the project') and immediately scopes it as fully server-side. The bulleted enumeration of each resource type makes it unmistakable against siblings like add_dependency or request_external_resource.

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 routes away from the tool when appropriate: 'For a user's OWN external key ... this is NOT the tool — use request_external_resource instead,' and 'SENDING email from the app is NOT a resource.' It also names the precondition for app-connection (write both apps first, connect, then publish) and points to get_guides for deeper flows.

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