Base44

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

Apply one or more exact old_text→new_text edits to an existing file. Each old_text must be unique unless replace_all is set. All edits apply atomically (all-or-nothing) and a unified diff is returned. Use dry_run=true to preview the diff without writing. If the app has no running sandbox, one is created transparently from the last commit (the first call on a cold app takes longer).

edit_file

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

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

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