Your agent needs to build software on Floot: create a project, write pages and endpoints, provision a database, run the tests, and publish. You go looking for the Floot API and find a hosted MCP server instead, plus the backend endpoints of whatever app Floot ends up hosting. So the Floot MCP vs Floot API decision is not the usual tradeoff between two views of one platform. The surfaces do different jobs, authenticate different principals, and fail differently in production. Here's how to decide what your Floot agent builds against.
Two objects, and only one of them can change a Floot project.
Floot builds and hosts full-stack TypeScript and React apps, and it expects your assistant to drive it through a hosted remote MCP server that Floot runs itself. The server speaks Streamable HTTP, answers in plain JSON with no SSE stream, and holds no session state: every request carries its own bearer token. Floot registers the same tool set for every client, and Scalekit's catalog lists 45 tools. One client caveat: standard ChatGPT only exposes the search and fetch tools. Floot documents the server on its own connector page and in its "Connect any MCP client" guide.
Floot's documentation describes no public REST API for managing projects. Its API pages cover the other direction: how the apps you build call third-party APIs and receive webhooks. What does exist is each app's backend. Endpoints live in files such as endpoints/route_POST.ts, Floot's tool descriptions call them the project's /_api/* routes, and a published app serves them on its own domain. Authentication on those endpoints is whatever your app's code enforces. The closest official reference is Floot's "Connecting external services" guide.
Scalekit mirrors that shape. Floot appears as one vendor MCP connector, flootmcp, using OAuth 2.1 with dynamic client registration and routing calls to Floot's own server. Scalekit prefixes each of the 45 tools with flootmcp_. There is no separate Floot API connector, because there is no platform API to wrap. Schemas and setup steps are in the Floot MCP connector docs, and the Floot MCP connector page has starter prompts for projects, files, preview, and publishing.
The capability split follows from that asymmetry. MCP can do almost anything to a project; your app's endpoints can only do what you wrote into them.
Tool names are Floot's own; through Scalekit, each carries the flootmcp_ prefix.
Floot draws a deliberate line around money and handoff. No tool can buy anything, change a plan, or add a payment method. Exporting the code zip, finishing custom-domain DNS, the first native mobile build before a store account is connected, and adding collaborators all happen in Floot's web app. Any agent workflow that ends in one of those steps needs a human handoff you design, not a tool call you retry.
Several Floot tools only work while the user has the project open in Floot's editor. run_code_in_browser fails fast without a connected browser, navigate_preview needs an open Floot window, and get_current_context reports what the user is looking at right now. Call publish_app without a domain and the user gets a publish form in the editor instead. The catalog also carries card_upload_asset, which Floot marks as an internal bridge not meant for agents, and get_guide, an alias of get_guides. A headless agent should never see the editor-bound tools, and it should always pass the subdomain label as domain when it publishes.
Floot's tool descriptions are long because they carry Floot's conventions: patch formats, path schemes, concurrency guards, destructive-action warnings. Scalekit's catalog entry for the 45 tools runs to roughly 9,700 words of descriptions and parameter docs, on the order of 16,000 tokens at four characters per token. Loading all of it on every run is a cost problem and an accuracy problem. The fix is not better prompting. It is surface reduction.
The two surfaces authenticate different principals. MCP authenticates your end user to Floot; your app's endpoints authenticate whoever calls your app.
Floot's MCP server is its own OAuth authorization server. It runs the OAuth 2.1 Authorization Code flow with PKCE (RFC 7636), accepts only the S256 challenge method, and supports dynamic client registration (RFC 7591), so there is no client ID or secret to create. Consent happens on Floot's site, and the client then sends the access token as a standard bearer header. There is no API key or personal token alternative; Floot tells clients to leave those fields empty. The grant is account-wide: a connected client can read and edit any project in that Floot account.
Floot's provisioned auth is built for your app's human users: email-and-password sessions, plus Google and Microsoft sign-in that Floot brokers. Floot's docs describe no machine credential for an external agent calling your endpoints, so that check is code you write in the endpoint. The secret it verifies is yours to issue, rotate, and revoke. Storing it through request_external_resource as a GENERIC credential keeps the value out of the model's view; the model only ever sees the environment variable name. Static secrets are simpler for headless callers. They also never expire unless you make them.
Floot meters connector work in build actions: one per tool call, reads included, with failed and cancelled calls free. Free accounts get 100 a day, Pro ($25 a month) gets 1,000, and Power ($100 a month) gets 5,000. Six housekeeping tools are exempt, including list_projects, get_job_status, and unpublish_app. The count lands on the account whose Floot login authorized the connector, not on the project owner. Every redundant read_file where one read_files call would do spends the user's allowance, which gives tool selection accuracy a direct price on Floot.
Recommended Reading: Rate Limiting in Virtual MCP Servers: Per-User, Per-Tool, and Per-Tenant Controls
Floot runs the server, the build machine, and the hosting. Everything between your agent and a correct, attributable call is still yours.
You own the per-user OAuth tokens: storage, refresh, and reauthorization when a user revokes access. You also own how the agent handles Floot's asynchronous model. Long-running calls return a jobId to poll with get_job_status, write tools accept an expected_version guard against concurrent edits, and a production build past 15 minutes of wall clock returns a definite failure. When a user hits a build-action limit, the refusal names the limit and the reset time. Your agent has to stop and surface it, not retry.
Floot's safety model assumes an interactive MCP client. execute_sql allows destructive statements and relies on the client to show the user the SQL and ask for approval, and unpublish_app tells the model to confirm with the user first. A headless agent calling those tools through execute_tool has no approval dialog. The human-in-the-loop gate becomes code you write, or the tool never enters that agent's surface.
The contract you depend on is Floot's tool list, and it moves when Floot ships. Floot says tools it adds later are metered unless it exempts them, and its docs describe no way to pin a tool-set version. Name the tools each agent may call instead of trusting whatever the server lists today.
Here you own everything: endpoint design, the credential check, input validation, and the retry behavior of whichever agent calls in. Floot's backend is serverless on AWS Lambda, so nothing survives between requests outside the database or storage. Published apps are also protected from runaway traffic: when traffic spikes far past an app's baseline, Floot caps its backend concurrency and lifts the cap no sooner than 30 minutes later. An agent polling your endpoints in a tight loop can look exactly like the runaway poller that throttle is built to catch.
The split is cleaner than for most tools, because the two surfaces barely overlap.
Neither surface gives you somewhere to keep credentials for many users, and Floot's account model makes the shortcut unusually costly.
The tempting design for a multi-tenant Floot agent is one Floot account behind the whole product. Three things break at once. The grant is account-wide, so the agent acting for tenant A can read and edit tenant B's projects. Build actions pool, so 40 tenants share one 1,000-call daily allowance on Pro. And Floot's records can only ever name that one account, so they cannot tell your tenants apart. Shared credentials are a single-user solution. They do not survive a second user.
Per-user accounts fix isolation and turn it into bookkeeping. Every end user completes Floot's OAuth consent once, and you now hold N tokens to encrypt at rest, refresh before expiry, and discard the moment a user revokes access. Floot keeps a raw audit row per tool call, with the tool name, a capped argument summary, and the result, for three days. Anything longer, attributed to your own users, is yours to keep. The app endpoint path has the same shape: N callers, N secrets, N revocations.
Recommended Reading: How to Handle Token Refresh for AI Agents
Scalekit's Floot MCP connector handles the OAuth flow, token storage, and refresh for every user, so your credential infrastructure doesn't change with the path you pick. Each user signs in to Floot once, and credentials never touch the agent runtime or the model's context. If other agents call your Floot app's endpoints, bring your own connector puts that API under the same connected-account model. What the user can't do, the agent can't do.
The examples use Python and LangChain: a deterministic call, a scoped agent, and a multi-tool Virtual MCP server. The snippets share the actions client from the first one.
Create a Floot MCP connection in the Scalekit dashboard under AgentKit, then Connections. Floot supports dynamic client registration, so Scalekit registers itself as the OAuth client and there is no Floot app to create. Copy your environment URL, client ID, and client secret from Developers, then API Credentials. The connection_name in every call must match the connection name in the dashboard exactly; a mismatch is the most common integration error.
The first run sends the user through Floot's consent screen once. After that, execute_tool runs a named Floot tool with no model in the loop, the pattern for pipelines that must behave the same way every time.
Before the loop starts, retrieve the tools this user's connected account is authorized to call, filtered to what this agent role needs. The agent never sees the 45-tool catalog. It sees seven read-and-verify tools, none of which writes, publishes, or needs an open editor.
Floot recommends Opus-class models for long, multi-tool builds, which is why the example uses Claude Opus. Scalekit's LangChain example covers the adapter's other filters.
A release agent needs Floot and Slack, but only a few tools from each. A Virtual MCP server declares exactly that surface once per agent role and returns a static mcp_server_url. Setup runs once, not once per user. The mapping includes flootmcp_get_guides because the flootmcp_publish_app description asks the model to read the publishing guide before its first call.
Before each run, confirm the user's connections are active, mint a short-lived session token for that user, and pass the URL and token to the agent as bearer auth. Setup once per agent role. Mint a token before each run. The endpoint is static; the identity is not.
Session tokens default to about an hour, and create_session_token is also the remint call; there is no refresh endpoint. Tools left out of the mapping, such as flootmcp_unpublish_app and flootmcp_execute_sql, do not exist for this agent. Slack tool names are in the Slack connector docs, and the configuration guide covers updates and deletion.
Floot's three-day audit rows know nothing about your tenants. Scalekit sits in the call path: execute_tool returns an execution_id, provider-side failures raise ScalekitToolException with the provider's error code and message, and the dashboard keeps tool call logs alongside auth logs you can filter by user and organization. Write the execution_id next to your tenant ID and you have an audit record that outlives Floot's window.
Auth logs can also stream to a SIEM or data warehouse. Agent webhooks emit connected account events, so a scheduled Floot agent can pause when a user disconnects instead of failing mid-build. The agent audit trail guide covers which events to keep.
The decision is less MCP versus API than control plane versus data plane.
If your agent creates, edits, debugs, or publishes Floot apps, it builds against Floot MCP, because nothing else can. Scope each agent role to the tools it needs, keep editor-bound tools out of headless runs, and gate destructive SQL and unpublishing in your own code.
If your agent reads or writes the app's data after launch, or an external system pushes events into it, call the app's endpoints and own that contract. Most production Floot products end up running both: an MCP-driven builder and an endpoint-driven integration. Either way, the per-user credential problem is the same, and that is the part that needs production-grade infrastructure.
Start with the Floot MCP connector docs and the Floot MCP connector page, or browse all connectors to pair Floot with Slack, GitHub, or Linear. The DevOps assistant agent and incident response agent templates show the multi-connector pattern, and pricing covers plan limits. Building a Floot agent right now? Talk to us for hands-on help.
