floot-mcp
Floot MCP Server lets any AI agent build and host full-stack apps directly.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- Search: Search your Floot projects and their code (ChatGPT-connector contract tool — other clients should prefer list_projects/search_code). Returns result ids usable with fetch.
- Fetch: Fetch a search result by id: a project overview ('<projectId>') or a file ('<projectId>:<path>') (ChatGPT-connector contract tool — other clients should prefer read_file/list_files).
- List Projects: List your Floot projects (id, name, last-updated), most recently updated first.
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Floot MCP Server lets any AI agent build and host full-stack apps directly. Claude, ChatGPT, Cursor, or any MCP client can create a project, write code, provision a database, enable auth, manage file storage, and deploy, all as native tool calls from a single conversation. No Floot AI, no Floot credits, no middleman. Your agent does the building on the subscription you already pay for. Floot handles the infrastructure. One conversation in, one working, hosted app out.
Список инструментов сервера (43)
Технические названия из tools/list. Нужны только разработчикам.
| search | Search your Floot projects and their code (ChatGPT-connector contract tool — other clients should prefer list_projects/search_code). Returns result ids usable with fetch. |
| fetch | Fetch a search result by id: a project overview ('<projectId>') or a file ('<projectId>:<path>') (ChatGPT-connector contract tool — other clients should prefer read_file/list_files). |
| list_projects | List your Floot projects (id, name, last-updated), most recently updated first. |
| list_resources | List the resources available to a project: the PROJECT OWNER's existing account-level resources (external credentials like OpenAI/Anthropic keys, external Postgres, GENERIC service keys — the only ones attachable to the project) plus everything Floot can add (Floot-managed resources via provision_resource; new external credentials via request_external_resource). Before requesting a new external credential, check here whether one of that type already exists. Read-only — secret values are never returned. |
| list_files | List a Floot project's virtual file tree with sizes, plus its dependencies and current version (pass the version to write tools as expected_version). |
| read_file | Read a file from a Floot project (cat -n style). Paths follow the item scheme: components/Name.tsx, components/Name.module.css, helpers/Name.tsx, pages/name.tsx, pages/name.pageLayout.tsx, endpoints/route_POST.ts, endpoints/route_POST.schema.ts, static/file.txt, base.css. Use offset/limit for large files. |
| read_files | Read MULTIPLE files from a Floot project in ONE call — much cheaper than repeated read_file (the whole project is loaded once, one round-trip). Prefer this whenever you need several files together (e.g. an endpoint + its .schema.ts + the hook that calls it, or orienting in a feature). Pass up to 20 paths (same item scheme as read_file). Each file is returned cat -n style under a header. Output is capped overall; if the batch is too large, whole files at the end are omitted and listed by name so you can read them individually. |
| search_code | Search a Floot project's files (string or regex) with optional glob filters (e.g. ['components/*', 'endpoints/**']). Returns file:line excerpts plus filename matches; capped at 40 results. |
| get_guides | Floot documentation for agents. Call with no arguments to list available guides. Pass `topic` for one guide (e.g. topic:'floot-overview') or `topics` (an array of ids) to fetch several at once. floot-overview explains how Floot projects work — read it before your first code change. Skill guides that ship seed code (marked in the list) AUTO-INJECT it into the project the first time they're loaded with a projectId — pass projectId whenever you're working on a project; idempotent, never overwrites existing files. |
| get_guide | Floot documentation for agents. Call with no arguments to list available guides. Pass `topic` for one guide (e.g. topic:'floot-overview') or `topics` (an array of ids) to fetch several at once. floot-overview explains how Floot projects work — read it before your first code change. Skill guides that ship seed code (marked in the list) AUTO-INJECT it into the project the first time they're loaded with a projectId — pass projectId whenever you're working on a project; idempotent, never overwrites existing files. |
| write_file | Create or fully overwrite a file in a Floot project. Content is written literally. Paths must follow the item scheme (see read_file); invalid paths are rejected with the rule they broke. Pass expected_version (from list_files/read_file) to detect concurrent edits. Writing components/Name.module.css sets the css of components/Name — other properties of the item are preserved. |
| edit_file | Replace old_string with new_string in a project file. old_string must match the current content exactly (including whitespace) and be unique unless replace_all is set. Prefer this over write_file for changes to existing files. |
| delete_file | Delete a project file. Deleting an item's main code file (e.g. components/Foo.tsx) removes the whole item including its css/tests; deleting an aux file (e.g. Foo.module.css) only clears that part. |
| remove_dependency | Remove npm packages from a Floot project's dependency record (record-only; nothing runs). |
| create_project | Create a new Floot project (pre-seeded with the shared component library) and return its id. `initial_prompt` is the USER'S ORIGINAL REQUEST verbatim — it grounds the project (becomes the standing <project-instructions>) and is preserved for the record; don't paraphrase it away. Then use write_file to add pages/components/endpoints. |
| apply_patch | Apply a V4A patch to a Floot project — create, update, and delete multiple files in ONE atomic operation. Format: "*** Begin Patch" envelope with "*** Add File: path" (+ prefixed lines), "*** Update File: path" (hunks: optional "@@ anchor" locator, space-prefixed context, -/+ lines, optional "*** End of File"), "*** Delete File: path", then "*** End Patch". Paths follow the Floot item scheme (see read_file). Move to: is not supported — Add + Delete instead. Keep each patch MODEST (a few files / few hundred lines): chat clients cap per-message output, and a patch cut off mid-way is rejected whole ("missing *** End Patch") — split big changes across several apply_patch calls. |
| get_logs | Your FIRST step when debugging any runtime problem — a 500, a failed request, a blank page, or 'it doesn't work' from the user. Call this before theorizing from an error message alone. Reads the project's runtime logs. source 'server' (default): the dev backend's request logs from the last hour — method, URL, status, duration, and per-request server log lines (pass log_reference_id from a previous listing for one request's full logs); includes background jobs (queueTask/scheduled/failure). source 'browser': console output AND client-side network requests (each fetch as `⇄ METHOD url → status`, with the error body for failed/4xx/5xx ones — the client-side view server logs miss, e.g. CORS/timeouts/third-party calls) captured from the user's open editor session. A browser network line's `ref=<id>` is a log_reference_id you can pass back with source 'server' for that request's full server logs. Empty if no editor is open. |
| get_backend_logs | The DEPLOYED backend's raw CloudWatch logs — every console line the workspace's backend Lambda printed (stage 'dev' = the preview backend, default; 'prod' = the published app), retained 90 days. Complements get_logs: that is the last-hour per-request debug store; this is the durable stream, includes prod, and is where console.error output shows as ERROR lines. Use for errors older than an hour, prod-only failures, or cold-start/REPORT diagnostics. `filter` matches a literal substring server-side (e.g. 'ERROR' or a request id). Events return oldest→newest within the window (default: last hour; set minutes_ago to widen); pass next_token from the reply to continue a large window. 'No logs yet' means the backend was never invoked — normal for new apps. |
| typecheck | Typecheck the project (incremental tsc on the project VM). Type errors don't block the app from running. |
| run_tests | Run the project's Jasmine spec files (helpers/*.spec.tsx) headlessly on the project VM (jsdom — no browser needed). Frontend AND backend code is testable: specs may render components (@testing-library/react) or import endpoint handlers/backend helpers and call them directly. Limits: fetch throws inside tests (mock with spyOn(globalThis, "fetch")), process.env secrets are absent, and specs importing @floot/* service modules are skipped (no mocks yet). Returns per-file PASS/FAIL with failing expectations. Defaults to all spec files except hook specs (file name contains "use" — those need real React scheduling and are excluded, matching the in-editor checker); pass `paths` to run specific spec files, including hook specs. |
| add_dependency | Add npm packages to the project (validated against Floot's supported set — rejected packages get a supported alternative named; some versions are pinned/substituted). Avoid node-gyp/native packages (exception: sharp is supported, auto-pinned) and WASM modules; pure JS/TS preferred. Installs on the project VM and persists resolved versions. After a slow install completes as a job, call add_dependency again with the same packages — the second call is fast and persists. |
| run_code_in_vm | Run a Node.js snippet on the project's compute VM (headless — no browser needed). The project's npm dependencies are importable; network access works, so you can call the project's /_api/* endpoints (get_preview_url → apiBaseUrl). ESM by default; bare require() snippets run as CJS. Returns stdout+stderr. A `_floot` global is available with project-scoped server-data helpers (no DB creds needed, no HTTP wiring): `await _floot.runSQLQuery({ query, resourceName?, reasonAndExplanationForNotReadOnly? })` (omit the reason for a read-only query; pass it to allow writes; resolves to `{rows, rowCount, command, truncated?}` — or `{results: [...]}` for multi-statement queries), `getHostingUsage({days?})`, `getLambdaUsage({days?})`, `getPushHistory({subscription?,from?,to?,offset?})`, `getBackendLogs({stage?,filter?,from?,to?,nextToken?})` (the deployed backend's CloudWatch logs; stage dev|prod), `storageList(prefix)` (prefix MUST start with "public/" or "private/" — e.g. storageList("public/") to list everything public), `storageGetUrl(key)`, `storageGetFileSizes(visibility, continuationToken?)`, `storageUpload({filename,sizeBytes,contentType})`, `storageDelete(key)`, and `getFileById(id)` (returns `{url, fileName, contentType}` — fetch the url for bytes). Same surface as runCodeInBrowser's `_floot`, minus the DOM/editor-only helpers. |
| run_code_in_browser | Run a TypeScript snippet inside the RUNNING APP's preview document in the user's open Floot editor (`document`/`window` ARE the live app's DOM — query `document` directly; do NOT look for a preview iframe, there is none from the snippet's point of view). This is the CANONICAL way to read the live app's DOM — measuring elements, reading computed styles, inspecting rendered output. If you ALSO have your own browser/DevTools automation, it CANNOT reach into the Floot preview (it renders in a cross-origin iframe — your clicks silently no-op and its DOM is invisible to you), so use THIS tool for anything inside the app, not those. `_floot.*` helpers are available. The snippet MUST `export default async function` and return a string — the returned value is the tool result (unlike run_code_in_vm, which is a plain script returning stdout). It can import project files by relative path from the root (e.g. `./helpers/foo`). Requires the user to have the project open in the editor — fails fast with guidance if no browser is connected; prefer run_code_in_vm for anything that doesn't need the DOM. Simple interaction checks work well: element.click() a button, await a beat, then read the resulting DOM/state to verify a flow end-to-end — do this instead of asking the user to test basic interactions. Multi-step e2e journeys and typed text input are where simulation gets unreliable (React controlled inputs ignore assigned values) — leave THOSE to the user. |
| navigate_preview | Point the user's OPEN Floot preview at a page URL or at a component's examples — use it to SHOW the user what you just built ("here's the new dashboard page", "here's the Button component's states"). targetType "page" navigates the app's router to `path` — a URL path with optional query/hash ("/", "/user/123?tab=settings#top"; pages/user.$id.tsx serves /user/<id>). targetType "component" renders the component's .example.tsx showcase for `name` ("HeroSection", exactly as list_files shows it; tell the user if it has no example — you can create one). Requires a Floot window to be open for this project; fails fast with guidance when none answers. Does not modify the project. |
| get_current_context | What the user is looking at RIGHT NOW in their open Floot editor: the active page/component, the preview element they selected (mapped to source file:line), the preview device size, whether they drew a screenshot annotation for you, whether they REVERTED recent changes (undoing edits — re-read before editing if so), and any requests they queued via editor action buttons ("Fix with Floot" etc.). Call this FIRST when the user refers to something without naming it ("this", "here", "the button"), reports a problem without saying where ("it's broken", "looks wrong"), or implies they triggered something in Floot ("go", "I clicked fix", "I undid that"). Cheap and text-only. With several windows open, one answers (the result says which) — but a selection made in ANY window is merged in, so a "no selection" from the answering window plus a deposited selection from another window means the deposited one is what the user means. If it reports a pending annotation, call view_annotation to see the image. |
| view_annotation | View a screenshot annotation the user drew on the app preview (annotationId comes from get_current_context). Returns the annotated image — the user's drawings/text point at what they mean. Annotations expire after ~1 day. |
| get_job_status | Poll a pending tool call by its jobId. Each poll either returns the final result (succeeded/failed/cancelled), or reports the call as still running — call it again until you get the result. Failed calls return their stored error message. Legacy v!/b! job ids are also accepted. |
| rename_file | Rename one or more items and automatically rewrite every file that imports them. Use item names WITHOUT extensions (e.g. {from:'components/OldName', to:'components/NewName'}). Preferred over delete+create — preserves content and fixes importers. Same type only. Pass several renames to apply them atomically in ONE pass; importer rewrites are resolved across the whole batch (including chains where one rename's target is another's source). |
| copy_file | Copy one or more items to new names (e.g. {from:'components/Card', to:'components/BigCard'}). Item names without extensions; same type only. Importers of the source are left unchanged. Pass several copies to apply them in one call. |
| query_database | Run a READ-ONLY SQL query against the project's Postgres database (SELECT, EXPLAIN, etc.). Writes are rejected — use execute_sql for those. Returns JSON: `{rows, rowCount, command, truncated?}` (or `{results: [...]}` for multi-statement queries). Pass `database` only if the project has more than one. |
| execute_sql | Run a WRITE SQL statement against the project's Postgres database — CREATE/ALTER TABLE, INSERT, UPDATE, DELETE, DROP, migrations. Destructive statements are allowed but your MCP client will show the user the SQL and ask them to approve it (they can allow once or for the session). Schema-changing statements (CREATE/ALTER/DROP of tables, types, …) automatically re-pull the typed schema helper and return the updated schema — no separate pull_database_schema call needed. Pass `database` only if the project has more than one. |
| pull_database_schema | Introspect the database and write a typed schema helper the app uses for queries (kysely). Usually NOT needed after execute_sql — schema-changing statements re-pull automatically. Use it to refresh manually, or with helper_name to generate the helper for an additional/external database. The helper is GENERATED — never hand-edit it or cast around its types: if a column's type is too loose (e.g. role as string when code expects "user" | "admin"), fix the DATABASE (CREATE TYPE … AS ENUM + ALTER COLUMN … TYPE) and re-pull, and the union type falls out. |
| update_project_metadata | Update project settings. 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). |
| generate_image | Generate image assets with AI and get hosted URLs to use in the app. Use this for PROJECT-SPECIFIC imagery (mascots, tailored illustrations, app/PWA icons, imagery in a particular style); for generic stock imagery (nature, textures, generic people) use Unsplash URLs instead; if you already HAVE an image as a local file (generated or downloaded yourself), use upload_asset. Generate BEFORE building the components that use the images. Reference the returned URLs in code or via update_project_metadata (iconUrl). |
| upload_asset | Get a presigned upload URL for a binary asset (image/font/audio/…) you already HAVE as a local file — e.g. one you generated or downloaded yourself. Returns uploadUrl (PUT the raw bytes to it with the EXACT same content_type and size_bytes, e.g. `curl -X PUT -H 'Content-Type: image/png' --data-binary @file.png '<uploadUrl>'`) and publicUrl (reference this in code once the PUT succeeds). Requires the ability to run shell/HTTP from your environment — if you can't (e.g. a chat-only client), use generate_image for AI imagery instead. |
| 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 — Google API access (Gmail/Calendar/etc.) via Floot's brokered Google OAuth (FLOOT_GOOGLE_INTEGRATIONS). Injects Connect button + endpoints. - 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. 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. |
| request_external_resource | Request the USER'S OWN external credential for this project — their OpenAI or Anthropic API key, an external Postgres connection string, or any other service's key (type GENERIC, e.g. Stripe/Resend — name the env vars via secret_env_vars). NOT for Floot-managed resources (database/auth/push/oauth/…) — use provision_resource for those; they need no user input. Returns a secure connect link: SHOW it to the user (UI-capable hosts render a Connect button automatically; on terminal hosts with shell access open it in the user's default browser yourself and paste the URL as plain text) and ask them to open it. The call completes only when the user finishes the connect flow — it never expires. Do NOT block on it: request the credential EARLY, keep building everything that doesn't need the secret (the env var names are known now — reference process.env.X in code before the secret exists), and check the request between tasks; the user may never connect it, and the build must not stall. NEVER ask the user to paste a secret into the chat. On completion you get the env var names — never the secret values. Re-calling with the same type returns the same pending request. |
| get_publish_status | Read-only publish snapshot for a project: published (true/false, with the live URL when published), paid (the workspace owner has a paid plan, which allows removing the Floot badge), and displayFlootLogo (whether the live app shows the 'Made with Floot' badge; true until a paid owner turns it off). The publish card calls this on load to render fresh state; also check it before publishing — publish_app errors when the app is already published (use republish_app then), and republish_app errors when it is not. |
| publish_app | Publish to production or set up a custom domain. Bare call (only projectId): unpublished → shows the user a publish form (never ask for the domain in chat); published → returns the live URL and status. Direct publish (form fallback only): domain_type 'floot_subdomain' + domain — errors if already published; use republish_app to rebuild a live app. Custom domain: pass domain_type 'custom_domain' and nothing else — the editor wizard collects the domain. Publishing returns a jobId — poll get_job_status. |
| republish_app | Rebuild the LIVE production app on its existing subdomain with the current project code — use after making changes the user wants live. Errors if the app is not published (use publish_app first — get_publish_status tells you which applies). Returns a jobId — poll get_job_status; production builds take a few minutes. |
| unpublish_app | Release the floot subdomain and take the app offline. Destructive — confirm with the user first. Fails while a custom domain is attached. |
| cancel_request | Withdraw a pending request you created — a credential request from request_external_resource, or a custom-domain setup request from publish_app (jobId from that tool). Only pending requests can be cancelled — completed ones are final. Use when the user says they don't want to proceed or you no longer need it. |
| get_preview_url | Show the user a live preview card. When working on an EXISTING project, call this EARLY (before making changes) so the user can watch edits live. If your client has in-app browser tools (e.g. Claude Desktop's Browser pane), open the tokenized browser URL from the result in a tab — the preview live-updates there as you edit. Do NOT call it right after create_project — that result already showed the same card; calling both duplicates it. The ONLY URL to give the user is the live preview link; the sandbox API base it also returns is INTERNAL (for your own use — headless /_api/* testing, etc.) and must NOT be shared with the user. Floot HOSTS the app — to go to production use publish_app; never suggest deploying a Floot app to an external host. |