Base44

Check the build status of a Base44 app. Returns one of: 'ready', 'processing', or 'error'. Use this to poll after calling create_base44_app or edit_base44_app. Poll every 30 seconds until the status is 'ready' or 'error'. When 'ready' comes with waitingForUserInput set, the build is paused on a request (waitingToolCall) that the user must answer in the Base44 Editor before it continues.

get_app_status

Returns the full contract — path/query parameters, JSON request-body schema with field descriptions and examples, and the success-response schema — for up to 10 operations chosen from list_api_catalog. Pass endpoints exactly as the catalog returned them. Unknown ones come back in an 'unknown' list instead of failing the call, and any that did not fit the response budget come back in 'omitted' — re-request those in a smaller batch. Use the returned schemas to build a correct execute_api call, and responseSchema to know what you get back before calling. A null responseSchema means the shape isn't declared, not that it's empty.

describe_api

Import a design into Base44 from a publicly fetchable URL. The file is a self-contained HTML bundle with all images, fonts, and styles inlined. Base44 starts building an editable app from it and returns the Base44 Editor URL immediately so the user can watch progress.

import-claude-design-from-url

List the OAuth connectors (third-party integrations like Google Calendar or Slack) available to a Base44 app, and which are already connected. Call with no integration_types to get the full catalog — each entry has the connector's name, description, whether it's connected, and (if connected) its status and granted scopes. Pass integration_types to get full detail for specific connectors, including the connection_config_fields needed before connecting. Use this to discover what can be connected AND to verify a connection succeeded after the user authorizes.

list_connectors

List the data models (entity schemas) defined in your app, including field names, types, and constraints.

list_entity_schemas

List directory entries for orientation, optionally recursive with a depth cap. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

list_directory

List all apps owned by the authenticated user. Always returns both app names and their IDs. Optionally filter by name.

list_user_apps

Retrieve entity records using filters, sorting, pagination, and field selection. Supports all entities including the built-in 'User' entity. Use list_entity_schemas first to see available entities and fields.

query_entities

Read file contents, optionally a line range (offset/limit) for token efficiency. Per-file errors are reported individually rather than failing the whole call. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

read_file

Execute a bash command inside the app's sandbox (working dir defaults to the app root). Each call is a fresh shell — `cd` does not persist; use the `cwd` param or chain commands. Output is capped (~1 MB) and the timeout is clamped (default 120s, max 600s). Note: shell access can read any files in the sandbox, including any secrets stored there. Changes auto-commit, but a commit is not a checkpoint: only checkpoints appear in the builder's version history, and a Restore or Revert there rolls the app back to the last checkpoint and discards everything written after it. Call create_checkpoint when you finish a unit of work and before you stop. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

run_command

Save a restore point in the builder's version history, with an optional name. Pending changes are committed first so it captures the latest code. Files you write or edit are committed but not checkpointed, so this is the only thing that makes your work restorable: a Restore or Revert in the builder rolls the app back to the last checkpoint and everything after it is lost. Call it when you finish a unit of work and always before you stop; a short name saying what changed helps the user pick the right version.

create_checkpoint

Search the app's files for a pattern (ripgrep when available, grep otherwise). Returns matching lines with file/line, capped by max_results with a truncated flag. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

grep

Show the live preview of a Base44 app in the conversation, the running app the user can click through and open fullscreen. Use it after building or changing an app with the code tools (write_file, edit_file, run_command), which show nothing to the user on their own. create_base44_app and edit_base44_app already show it. Read-only: builds and changes nothing.

show_app_preview

Call this first, before any other Base44 tool, once per conversation, including for simple lookups. Explains which tool fits which job, the two ways to create and change an app (Base44's AI builder, or editing the files), and the step-by-step loop for driving the builder AI: how to send a change, how to poll on every host, how to read the AI's reply and act on a paused turn, and how to preview and deploy. Do not call it again for follow-ups in the same conversation.

base44_readme

Update the field definitions, types, or constraints of an existing entity. To modify data records, use update_entities. Always check existing schemas with list_entity_schemas first. This also writes the entity's definition into the app's source code (base44/entities/<Name>.jsonc), so the change is durable. IMPORTANT: Security rules are automatically preserved when omitted from your update: - Entity-level RLS (the top-level 'rls' field) is preserved if you omit it. - Field-level security (per-field 'rls' inside properties) is preserved for each field that omits it. To intentionally modify or remove security rules, include them explicitly (use an empty object like 'rls': {} to clear). ## Row-Level Security (RLS) Entity schemas can include RLS rules under the 'rls' field to restrict record access based on user identity. RLS rules are defined per operation: create, read, update, delete. Template variables: {{user.id}}, {{user.email}}, {{user.role}}, {{user.data.<field>}}. Rule types: 1. user_condition — exact equality check on user attributes (no MongoDB operators). E.g. {"user_condition": {"role": "admin"}} 2. Entity-user field comparison — MongoDB query syntax. Custom fields MUST use "data." prefix (e.g. "data.user_id": "{{user.id}}"). Built-in fields (id, created_by_id, created_date, updated_date) are at root level. Combine with $and/$or/$in/$nin. Rules must reference user template variables, never static values. Example: {"rls": {"read": {"created_by_id": "{{user.id}}"}, "update": {"$or": [{"created_by_id": "{{user.id}}"}, {"user_condition": {"role": "admin"}}]}}}

update_entity_schema

Update entity records matching a query using MongoDB update operators. Does not require individual record IDs — use a query filter to match records and apply operators to all matches (up to 500 per call). IMPORTANT: The 'data' field MUST use update operators — bare field assignment like {"status": "active"} is not accepted; use {"$set": {"status": "active"}} instead. The built-in 'User' entity cannot be updated through this tool. If the response contains has_more=true, more records matched than the batch limit — call again with an adjusted query that excludes already-updated records (e.g. filter on the old value) to avoid an infinite loop. Supported operators: $set, $rename, $unset, $inc, $mul, $min, $max, $currentDate, $addToSet, $push, $pull. Examples: query={"status": "pending"}, data={"$set": {"status": "active"}} to update matching records; query={"category": "legacy"}, data={"$rename": {"oldField": "newField"}} to rename a field on matching records.

update_entities

Add a file to a Base44 app's media library (the Assets the user sees in the editor) and get back its public URL. Use it for assets the app shows or links to: images, logos, icons, video, audio, PDFs and other documents, 3D models. The app's code or data then points at the URL (an <img src>, a CSS url(), a record field). Not for the app's source code: the files the app is built from (components, pages, CSS, HTML, JSON config, entity schemas) go in with write_file, which commits them to the code. An asset is not part of the code and is not versioned with checkpoints; it stays in the library, and live at its URL, until deleted. Accepted types: 3g2, 3gp, avi, csv, docx, fbx, gif, glb, gltf, ico, jpeg, jpg, json, m4v, md, mkv, mov, mp3, mp4, mtl, obj, ogv, pdf, png, pptx, svg, txt, wav, webm, webp, wmv, xlsx, zip.

upload_app_asset

Change a Base44 app directly, without the builder AI, by writing a file in its code. Creates a new file, or overwrites an existing one only when overwrite=true (never silently clobbers). Prefer edit_file for changes to existing files. Writes text into the app's source code only: for an image, video, PDF or other asset the app shows or links to, use upload_app_asset and reference the returned URL in the code. Changes auto-commit; only create_checkpoint makes them restorable from the builder's version history. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

write_file

List main and active branches of a Base44 app, with names, IDs, and status. Use the returned ID as branchId/branch_id in subsequent MCP calls, or the name with CLI --branch. Main has a null ID: omit branchId/branch_id to target main. Ask the user when the intended branch is unclear.