aggregate_records
ChatGPTPerform aggregation operations (sum, avg, min, max, count, count_distinct) on a field in a table. Optionally group results by another field.
Overview
Zite helps users inspect, query, analyze, and update their private workspace data through ChatGPT, including databases, tables, fields, records, and aggregations. It can also build, edit, and publish apps on that data, with workflows and integrations, saved to the user's Zite workspace.
Tools
bash
ChatGPTRun a shell command in the sandbox workspace (working dir /workspace). 120s timeout: longer commands are killed. stdout and stderr over 100KB each are truncated. Useful for npm installs, git log/diff/pull, moving files, or one-off scripts. For typechecks use check_app. The workspace is a git clone on
main, shared with the editor and other agents — git pull origin main takes their changes, and if it refuses because your edits overlap, git add -A && git stash push && git pull origin main && git stash pop leaves conflict markers to resolve. Never git commit or git push here: use the commit tool, which also builds, snapshots, and records attribution.build_app
ChatGPTBuild what is already on main, without committing anything. commit only builds the apps a new commit touched, so use this when the code reached main another way (you pushed from elsewhere and the sandbox pulled it, another session committed, or a build failed and you want to retry). Fast-forwards the sandbox to main first and refuses, without building, if the workspace has uncommitted edits or local commits main does not have — use commit for those. Builds run in the background; publish_app reports when they finish.
bulk_create_records
ChatGPTCreate multiple records at once. Much more efficient than creating records one at a time. Complex field types have specific value encodings documented in records. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs. Example: To populate a countries table: { "baseId": "abc123", "tableId": "tbl456", "records": [ { "Country Name": "United States", "Population": 331000000, "Continent": "North America" }, { "Country Name": "China", "Population": 1400000000, "Continent": "Asia" }, { "Country Name": "Brazil", "Population": 214000000, "Continent": "South America" } ] }
bulk_update_records
ChatGPTUpdate multiple records at once. Each record object must include a recordId field to identify which record to update. Complex field types have specific value encodings documented in records. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
check_app
ChatGPTTypecheck the workspace and return compiler diagnostics plus endpoint bundling errors. Run this after editing and fix what it reports before committing. Pass appId to scope endpoint checks to one app.
commit
ChatGPTCommit the sandbox changes to the workspace repo and push. Builds for the touched apps run in the background (buildStatus "building"); publish_app reports if a build is still running or failed. Returns the commit sha and per-app editor links — share those links so the user can open the change in Fillout. Checks the workspace first and refuses without committing — leaving your files untouched — if it has an unresolved merge or an operation in progress, is off main, holds commits you made by hand, or is behind main. Every refusal names the command that clears it.
count_records
ChatGPTCount the total number of records in a database table. Optionally filter to count only matching records.
create_app
ChatGPTCreate a new app in the sandbox's workspace. A workspace holds multiple apps over one shared database — make a separate app for each distinct audience or access mode (an internal team tool vs. an external or public site must be separate, since accessMode is per-app). Scaffolds an empty app (no AI build — you write the code) into the sandbox at the returned dir. Edit its files, then commit. The same sandbox keeps working — creating an app stays in the same session. Then call show_app_preview with the new appId so the user sees it take shape.
create_database
ChatGPTCreate a new database with tables and fields. Use this to build structured data stores for any kind of information. Field templates are optional or required depending on field type, as documented in fields.template. When presenting the created database to users, include its URL as a clickable link. Example: To create a countries database: { "name": "World Countries", "tables": [{ "name": "Countries", "fields": [ { "name": "Country Name", "type": "single_line_text" }, { "name": "Population", "type": "number", "template": { "decimalPlaces": 0 } }, { "name": "GDP (USD)", "type": "currency", "template": { "currencySymbol": "$", "decimalPlaces": 2 } }, { "name": "Continent", "type": "single_select", "template": { "options": [ { "value": "africa", "label": "Africa" }, { "value": "asia", "label": "Asia" }, { "value": "europe", "label": "Europe" }, { "value": "north_america", "label": "North America" }, { "value": "south_america", "label": "South America" }, { "value": "oceania", "label": "Oceania" } ]}}, { "name": "Is UN Member", "type": "checkbox" } ] }] }
create_field
ChatGPTAdd a new field (column) to an existing table. Pass the field definition (name, type, and any required template) via the "field" argument. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
create_record
ChatGPTCreate a new record (row) in a table. Provide field values as key-value pairs where keys are field IDs or field names. Complex field types have specific value encodings documented in record. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
create_sandbox
ChatGPTBoot a sandbox for a workspace — a cloud VM with the workspace monorepo checked out and a dev server running. Returns the sandboxId that every editing tool takes, the apps and file tree, and a framework guide — read the guide before writing app code. Use one sandbox per conversation; call this once at the start and reuse the id. Idle sandboxes stop automatically. When the user is working on a particular app, show it with show_app_preview (once) so they can watch your changes land.
create_table
ChatGPTCreate a new table in an existing database. Define the table name and fields; each field template is optional or required depending on field type, as documented in fields.template. When describing this action to users, refer to databases by their human-readable names, not their IDs. When presenting the created table to users, include its URL as a clickable link.
create_workspace
ChatGPTCreate a new empty workspace — a database plus everything built on it. Add tables with create_table, then call create_sandbox with this workspaceId to build apps.
delete_field
ChatGPTDelete a field (column) from a table. This will permanently remove the field and all its data from every record. When describing this action to users, refer to databases, tables, and fields by their human-readable names, not their IDs.
delete_record
ChatGPTDelete a record from a table. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
delete_table
ChatGPTDelete a table from a database. This will permanently remove the table and all its records. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
edit_file
ChatGPTReplace an exact text snippet in a file — the primary way to change code. oldText needs to match the current file content exactly and occur exactly once; include enough surrounding lines to make it unique. Prefer this over write_file for changes to existing files.
execute_sql
ChatGPTRun a read-only PostgreSQL SELECT against a database, using the human-readable table and field names visible in the UI. Reach for SQL when query_records isn't expressive enough — counts, multi-table joins, traversing linked records, arbitrary aggregations, window functions, CTEs. Call get_database_schema first to discover table names, field names, link tables, and select-field options. Identifiers: - Quote names containing spaces: SELECT "Order Number" FROM "Orders". Names match case-insensitively against the UI. - System columns are always available: id (uuid), created_at and updated_at (timestamptz), created_by and updated_by (nullable zite_user ids), deleted_at (almost always null — see soft-delete below), autonumber_id (bigint), source_metadata (jsonb describing where the record was created from). Linked records: - Many-to-many relationships are exposed as link tables named <TableA>__<TableB>. Each link table has friendly id-column aliases (e.g.
ordersId, itemsId) that get_database_schema returns under sourceTableIdColumn / targetTableIdColumn. The aliases are camelCase so they MUST be double-quoted in JOIN clauses (e.g. JOIN "Items__Orders" l ON l."ordersId" = o.id); Postgres folds unquoted l.ordersId to l.ordersid which doesn't exist. Use the friendly (quoted) aliases instead of source_record_id / target_record_id so the direction can't be wrong. Field-type semantics: - single_select fields: read returns the option label (e.g. "Electronics") AND filter/group/order accept the same label. WHERE "Category" = 'Electronics', GROUP BY "Category", ORDER BY "Category" all behave the way they read. (The rewriter wraps the column in a CASE that translates stored value → label, so read and filter operate in label-space.) - multiple_select fields: read returns an array of labels, and the JSONB operators (@>, ?, ?|) work in label-space too — e.g. "Tags" @> '["Featured"]'::jsonb, "Tags" ? 'Featured', "Tags" ?| array['Featured','Sale']. Per-label aggregation uses jsonb_array_elements_text to unnest. Filtering on the raw option value no longer matches — always use the label. - Formula and lookup fields are stored as JSONB but the server unwraps and casts them to the field's resultType (number/text/date/boolean), so AVG(formula), WHERE lookup > 5, ORDER BY formula, COALESCE(lookup, 0), etc. all work as if the column were a native scalar. For lookup fields with a single linked target the server walks the link live (so values are current even if the cached lookup column is stale). - Array-typed formulas / lookups stay as raw JSONB so jsonb_array_length, ->, jsonb_array_elements, etc. apply directly. Soft-delete is automatic: every table reference is wrapped to exclude deleted_at IS NOT NULL rows. Don't add WHERE deleted_at IS NULL yourself — it's already applied. You also can't query soft-deleted rows via this tool. Parameter binding (use params, not interpolation): - Pass user-supplied values via params and reference them as $1, $2, … in the SQL — never interpolate them into the SQL string. pg keeps the query plan separate from the values, so user input can't change the query structure. - Examples: - { sql: 'SELECT FROM "Orders" WHERE "Status" = $1', params: ['paid'] } - { sql: 'SELECT "Name" FROM "Customers" WHERE "Created at" >= $1', params: ['2024-01-01'] } - IN-list: { sql: 'SELECT FROM "Orders" WHERE "Status" = ANY($1::text[])', params: [['paid', 'shipped']] } Supported query shapes: - WITH … AS (…) CTEs (single and multiple). Tip: alias projected columns inside the CTE if you want to reference them by a friendly name in the outer query — e.g. WITH t AS (SELECT "Email" AS email FROM "Customers") SELECT email FROM t. - Subselects in WHERE / SELECT / EXISTS / IN, including same-alias as outer (each subselect gets its own scope). - Self-references via subquery, LATERAL joins. - UNION / INTERSECT / EXCEPT, DISTINCT / DISTINCT ON, GROUP BY / HAVING, ORDER BY … NULLS FIRST/LAST. - Window functions: ROW_NUMBER() OVER (...), RANK(), LAG(), etc. - SQL-standard builtins: UPPER, LOWER, LENGTH, SUBSTRI…get_database
ChatGPTGet details about a specific database including its tables. When presenting databases and tables to users, include their URLs as clickable links.
get_database_schema
ChatGPTGet a description of a database's tables, fields, and link tables, intended for composing SQL queries via execute_sql. Use this BEFORE calling execute_sql so you know which tables exist, what their fields are called, and how they relate. Returns: - tables: each with name, primaryFieldName, and (optional) fields with type/postgresType, linksTo (when the field is a linked_record), and options (when the field is single_select / multiple_select). - linkTables: many-to-many join tables exposed as <TableA>__<TableB>. Each entry includes the friendly id-column aliases sourceTableIdColumn and targetTableIdColumn (e.g. "ordersId", "itemsId") — use those in JOIN clauses, not the raw source_record_id / target_record_id columns. Direction depends on which side the linked_record field was created on, so the friendly aliases are unambiguous. Pass
tables to scope to a subset of tables (and their adjacent link tables). Pass includeFields: false for a cheap overview of just table names.get_logs
ChatGPTRead an app's endpoint execution logs. Without runId: a list of run summaries — status, duration, error message, and per-run counts of console/SDK/fetch events. With runId (from a listed run): that run in full — console output, SDK calls with request/response data, external fetches, the run's input and output, and the error stack trace. So the loop is list first, then fetch the interesting run by id. Use this to debug runtime failures that check_app (compile-time) cannot see. Each run reports the
snapshotId that executed it: live runs execute the app's published snapshot, preview runs its latest build. publishedSnapshotId is the app's live code and latestSnapshotId its newest build, so when those differ, live traffic is running older code than the current source until the app is published.get_record
ChatGPTGet a single record by its ID from a database table.
get_table_schema
ChatGPTGet the schema (fields) for a specific table in a database.
get_workspace
ChatGPTGet one workspace: its apps, forms, and (when a sandboxId is provided) the project overview.md. Excludes trashed apps. Forms are read-only here — no tool edits a form or its settings; send the user to the form's editorUrl.
grep
ChatGPTRipgrep-backed content search across the workspace. Returns matching lines with file:line prefixes and context. Respects .gitignore and skips node_modules, so results are the app's own code. Scope with path (e.g. "apps/todo") and filter with glob (e.g. "*.tsx") to keep results tight. Use this to find the right code before editing.
list_databases
ChatGPTList all databases you have access to. Returns database IDs, names, URLs, and timestamps. When presenting databases to users, include URLs as clickable links.
list_files
ChatGPTList the files in the sandbox workspace. Apps live under apps/<dir>/, shared UI under packages/components/. Pass a filter (substring or *-glob) to narrow the list.
list_workspaces
ChatGPTList the workspaces you have access to. A workspace is a database plus the apps built on it — the id works with both the build tools (workspaceId) and the data tools (baseId).
open_zite
ChatGPTOpen Zite: the apps the user opened or changed most recently. Picking one asks you to open it, so show it with show_app_preview.
prepare_attachment_upload
ChatGPTGet a short-lived upload URL and token for attaching a local file to an attachments field. Record writes only take public URLs, so a file on disk has to be uploaded first: 1. Call this tool for the table and attachments field. 2. Run the returned curlCommand in a shell, replacing <path-to-file> with the file's path. It responds with JSON containing "url". 3. Pass that URL to create_record or update_record, e.g. { "Files": [{ "url": "<url>", "filename": "report.pdf" }] }. The token works for any number of files into that one field until expiresAt. It cannot upload anything itself — if you can't run shell commands, or the file is larger than maxFileSizeBytes, ask the user for a public URL to the file instead.
publish_app
ChatGPTPublish an app's latest built version so it goes live. External apps get a public live URL; internal apps are published for organization members only. Refuses while the build from the latest commit is still running, so a publish never ships the previous build — wait a moment and call again. The result names the commit sha that went live.
query_records
ChatGPTQuery records from a database table. Returns records with their field values.
read_file
ChatGPTRead a file from the sandbox workspace. Large files can be read in slices with offset/limit (line numbers).
run_one_off_script
ChatGPTRun a one-off TypeScript script in the same isolated runtime app endpoints use, with the workspace SDK and integration credentials injected — unlike bash, which runs in the build sandbox where no integration credentials exist. Use it for one-time data work (seed, backfill, import), integration checks ("list my Slack channels"), and verifying runtime behavior before wiring it into an endpoint. The script runs against the live database. Import what endpoints import (
zitejs/db, or an integration's npm package) and end with a bare return — the returned value comes back as output (over 20KB is truncated). List every integration the script uses in serviceTypes: that declaration is what injects each service's credentials (e.g. ZITE_STRIPE_ACCESS_TOKEN); valid values are the workspace's connectableServiceTypes from create_sandbox, plus "databases" for the project database. Integrations declared in an app's own zite.config.json resolve only when appId names that app.search_solutions
ChatGPTSearch the Zite marketplace for ready-made solutions — a database plus the apps on it (an LMS, a CRM, an applicant tracker…) that the user can start from instead of building from scratch. Check it whenever the user asks to build something. Matching is plain text over names and descriptions, so pass a few phrasings: the user's words, the spelled-out term and close synonyms (e.g. ["LMS", "learning management", "courses"]). If one fits, show it with show_solution rather than describing it.
send_feedback
ChatGPTReport a Zite platform problem — broken tooling, a misleading error, a missing capability, behaviour the docs don't explain — or pass along feedback the user asks you to send (docs gaps, missing capabilities, praise: use severity 'other'). The Zite team reads these and ships fixes. Reach for it when the platform didn't behave the way its tools, errors, or docs said it would, or when you worked around something instead of using it as intended. Report it even when you can't tell whether the fault was yours: you have context the team doesn't. Name the tool, and paraphrase what you passed and what came back rather than pasting raw output, secrets, or the user's data.
setup_integration
ChatGPTThe integration picture for a workspace: which third-party services (Stripe, Slack, Google Sheets, Airtable, Notion, email, ...) can be connected, which accounts the org already has (orgServices — attach those yourself by writing the config entry with the given connectionId; no user needed), and what is already attached. When the account does not exist yet, share connectUrl with the user — OAuth happens in their browser — then call this again after they confirm. The guide from create_sandbox has the config-entry format and usage.
show_app_preview
ChatGPTShow the user a live preview of a Zite app in the chat, with a button to open it in the editor. Call it once, the first time an app comes up — the user names it, asks about it, or asks you to change it — before you start working on it, and right after create_app. It reloads itself whenever a new build lands, so there's no need to call it again for the same app.
show_database_schema
ChatGPTShow the user a formatted view of a workspace database's tables and fields, with a link to open it in the editor. Use it when the user wants to see how their data is structured; to read the schema for your own use, call get_table_schema instead.
show_solution
ChatGPTShow the user a marketplace solution as a compact listing: what it does, the apps and database it comes with, what it replaces and works with, a link to its marketplace page, and a Use this solution button that starts their own copy (the same as use_solution). Use it after search_solutions finds one that fits what they want to build.
ui_get_app_preview
ChatGPTAn app's latest build state for the Zite preview view, plus a fresh preview link when
withLink is set.update_field
ChatGPTUpdate a field's name, type, or template. Changing the field type may affect existing data. When describing this action to users, refer to databases, tables, and fields by their human-readable names, not their IDs.
update_record
ChatGPTUpdate an existing record. Only the fields you specify will be updated; other fields remain unchanged. Complex field types have specific value encodings documented in record. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
update_table
ChatGPTUpdate a table's name. When describing this action to users, refer to databases and tables by their human-readable names, not their IDs.
use_solution
ChatGPTStart the user's own copy of a marketplace solution: a new workspace with its database and apps. Takes 30 seconds or more. Returns the workspace id (it works with every other tool) and the link to open it in Zite, where a getting-started checklist walks the user through making it theirs — share that link. Only call it when the user has chosen the solution; every call makes a new workspace. If it fails, check list_workspaces before trying again, since the workspace may already exist.
write_file
ChatGPTCreate a new file or fully rewrite an existing one. For changes to existing files, edit_file is usually the better tool.
aggregate_records
Claudebulk_create_records
Claudebulk_update_records
Claudecount_records
Claudecreate_database
Claudecreate_field
Claudecreate_record
Claudecreate_table
Claudedelete_field
Claudedelete_record
Claudedelete_table
Claudeget_database
Claudeget_record
Claudeget_table_schema
Claudelist_databases
Claudequery_records
Claudeupdate_field
Claudeupdate_record
Claudeupdate_table
ClaudeCapabilities
WritesInteractive
