MCP app
46 tools

Floot MCP Server

Turn your ideas into products without coding, all on one platform.

Host
mcp.floot.com
Tools
46
Connection URL
https://mcp.floot.com/mcp

Tools

  • Search Projects

    Search your Floot projects and their code. Returns result ids usable with fetch. For richer options, list_projects enumerates projects and search_code does code-level search.

  • Fetch Search Result

    Fetch a search result by id: a project overview ('<projectId>') or a file ('<projectId>:<path>'). For direct access to a known file or project, read_file/list_files give more detail.

  • List Projects

    List your Floot projects (id, name, last-updated, whether an app icon is set), most recently updated first. name_filter is a case-insensitive substring match on the stored name, which is often not the name the user uses for a project — on a small account a filter that matches nothing returns the whole list instead.

  • List Available Resources

    List the env vars a project's code can use and the resources behind them: (1) resources CONNECTED to the project — usable as process.env.<NAME> in endpoint code now; (2) the owner's other account-level credentials — reusable, but not usable in code until connected; (3) everything Floot can add. Call it to learn what env vars exist before writing backend code, and BEFORE provisioning or requesting any credential (the owner may already have the one you need). Pass query (case-insensitive substring

  • List Project Files

    List a Floot project's virtual file tree with sizes, plus its dependencies, current version (pass the version to write tools as expected_version), and current project metadata — title, description, app icon (iconUrl), splash screen, mobile app id, SSR, iOS Info.plist overrides, share target (iOS + Android), native system bars. This is where to look up those settings; update_project_metadata changes them.

  • 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. Pass include_references:true to also list which project files reference this one (static import graph plus queueTask/runCode name references and, for endpoints, URL-path string usage) — check i

  • 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; /_cdn/<name> asset paths are accepted too and images come back as image blocks). Each file is returned cat -n style under a header. Each .ts/.tsx file's current t

  • 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.

  • Floot 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

  • Floot Guides

    Compatibility alias of get_guides — the identical tool under its common misspelling. Prefer get_guides; see it for full usage.

  • 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 (served back as <project-instructions> in list_files) and is preserved for the record; don't paraphrase it away. The result renders a live preview card for the user and includes the first-build playbook: a fresh project is EMPTY until pages are written, so a session normally continues straight into get_guides("design") and

  • 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). To replace a file wholesale use Add File on its own — Add OVERWRITES. Never Delete+Add t

  • 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). sourc

  • Typecheck Project

    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 expec

  • 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), WASM modules, and packages bundling large binaries (e.g. ffmpeg/ffprobe); pure JS/TS preferred. A bare `kysely` installs 0.26.3, the version the generated db/schema helpers are written against; pass an explicit `kysely@<version>` only when upgrading it del

  • 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. Calls to the project's /_api/* are rate-guarded exactly like the browser preview: more than 20 calls to one endpoint or 150 total within 5s rejects that fetch and every later /_api/* fetch in t

  • 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-

  • Navigate the User's Preview

    Point the user's OPEN Floot preview at a page URL, a component's examples, or a page'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"), and pair it with screenshot_preview to see the result yourself. 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 .exa

  • Screenshot the User's Preview

    Capture a screenshot of the user app. Call it whenever you want to SEE what the app currently looks like (layout, styling, rendered state) or want to debug the app.

  • Get Current Editor 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"), re

Use in your AI tool

One-click into Claude, Cursor, VS Code, and more — connects straight to this server’s public endpoint.

Remote MCP URL
https://mcp.floot.com/mcp