changesets_discard
ChatGPTMark one pending changeset Discarded so it will not be applied (for example, so a corrected plan can be staged). This does not delete the changeset or its op-log, and it does not change records, files, or toolkit artifacts. The discarded plan stays readable with changesets_show, and an identical plan can be staged again. Changesets are org-wide: this can discard one staged by someone else, and whoever discards it is recorded on the changeset.
changesets_list
ChatGPTList changesets, newest first. By default this returns only your own pending changesets (a long-lived org accumulates many settled or abandoned ones); pass another status ("applying", "applied", "discarded", "superseded", "failed", or "any" for all statuses) or mine=false to widen the listing.
changesets_show
ChatGPTShow one changeset: status, op-log, and a short summary. Use after changesets_stage to check whether a human has approved, discarded, or not yet reviewed it. A files changeset applies in the background and reports "Applying" until it settles on "Applied" or "Failed", so poll it. A files changeset is also the only kind that can apply in part: when one fails, applied_operation_count gives the number of operations applied, and everything after that is still outstanding. "chain" describes this changeset's extends line. "chain.root" is the oldest ancestor as a tree node, or null when the changeset has no relatives; every node carries uuid, title, status, is_subject (true on the one you asked for), in_plan, and "extensions", the nodes extending it. Ancestors run in a single line down to the subject, and only the subject branches. in_plan means that node shares a plan with the subject: an ancestor whose ops this changeset's apply will run, or an extension whose apply would run this changeset's ops -- so approving any in_plan extension applies this changeset too, and supersedes it. "chain.preview_notice" is set when part of this plan has already been applied since it was staged, which means applying this changeset now writes less than its preview shows.
changesets_stage
ChatGPTStore one pending changeset for a human to review. This does not write records, change a Registry Table, edit a toolkit artifact, change files, or send messages. Pass an ordered list of operations of a single kind (records, registry tables, toolkit, files, or messages). The plan is validated in one pass: an invalid plan returns per-op errors and nothing is stored; a valid plan is saved as Pending and returns a review_url. Live data changes only when a human approves that link in Tabulous. File-upload operations need a staged_upload token from the tabulous CLI (see cli_connect); this tool cannot accept file bytes. Message operations only queue a send through the organization's messaging integration for approval; they do not post anything now. To append operations to a pending or discarded changeset of the same kind, pass its uuid as extends. Files changesets and messages changesets cannot extend or be extended. A plan, including the changesets it extends, may not create a record and then revise it, change the same table's schema twice, or create, delete, or rename the same toolkit artifact twice (repeat updates or deletes of an existing record, and non-renaming updates of a toolkit artifact, including one the plan creates, are fine). To replace such an operation, discard the changeset with changesets_discard and stage a corrected plan.
cli_connect
ChatGPTSet up the tabulous CLI and connect it to this workspace. Returns shell steps to run yourself: download the self-contained CLI from this Tabulous server, then log in with the embedded single-use code (the redeemed key lasts 24 hours and never appears in this conversation; it can read and stage changesets for review, like these tools). Calling again before the code is redeemed returns the same code; once it is redeemed or expired, calling again mints a fresh one -- always log in with the newest code.
docs
ChatGPTServer-hosted documentation. Call with no arguments first: the default returns the agent workflow guide for working with this workspace over MCP or the tabulous CLI, including how to compose changesets_stage plans -- read it before your first changesets_stage call. Pass a topic for detailed references: "schema" (Registry Table configuration plus every field type and its options -- read before staging registry-tables changes), "computed-fields" (computed-expression rules), "toolkit" (App/Script/Skill definition schemas), "workspace-design" (setup and redesign playbook), "python" (the Tabulous Python client, for Script code), "python-legacy" (the legacy TabulousClient SDK that existing Scripts use -- for editing those, never for new code), "app" (the JavaScript SDK, for app HTML), "api" (the REST API reference), and "help" (user-facing product docs).
files_list
ChatGPTList files and folders in one folder of the organization's connected file storage (Google Drive, SharePoint, or Box). Metadata only, non-recursive: this does not upload, move, rename, or delete anything. Scope with a record_name (the record's folder), a path, or both.
messages_list_channels
ChatGPTList the channels the organization's messaging integration (Slack today) can post to. Each has "id", "name", and "is_member". Use a name or id as the channel of a messages-send operation. To message a person, use their email from users_list instead. Fails when messaging is not connected.
records_dataset_refresh
ChatGPTSync a Dataset field from its linked spreadsheet in the organization's connected file storage (Google Drive, SharePoint, or Box). When the file has changed, or when force is true, this saves a new version of the field's tables from a fresh parse. The previous tables stay in the field's history and can be viewed and restored. It does not edit or delete the spreadsheet or the record. A field with no linked file, or a file that has not changed, changes nothing. Returns refreshed, source_file metadata, and a tables summary. After a refresh, fetch full tables via records_list masks (e.g. Field__tight).
records_list
ChatGPTList records from one Registry Table, with optional filtering, search, sorting, a field projection, and pagination. Returns 25 records per page unless page_size is set; while has_more is true, re-call with the next page number.
records_suggest_names
ChatGPTSuggest the next available record name(s) for a Registry Table, following its naming pattern.
registry_tables_list
ChatGPTList every Registry Table in the workspace with its full schema (fields, types, options). Call this first to learn the workspace shape; table and field names here are the vocabulary for records_list.
toolkit_list
ChatGPTList the workspace toolkit: Apps (embedded HTML/JS apps), Scripts (form-driven code templates), and Skills (custom assistant instructions; the web app UI still calls these "Workflows"). The default listing is metadata only: each artifact's body is omitted and flagged body_omitted. Pass include_body to read it.
toolkit_update
ChatGPTStage an update to one toolkit artifact (App, Script, or Skill) as a pending changeset for human review -- the single-artifact convenience over changesets_stage, with one extra capability: the body field (an app's html_content, a script's code_template, a skill's instructions) also accepts a list of anchored edits, so changing part of a large body does not require resending all of it. Every other field takes its full value, and only provided fields change. For creates or deletes, use changesets_stage. To update several artifacts as one reviewable plan, chain calls with "extends": each call stages a changeset extending the previous one, and approving the final changeset applies the whole chain. The live artifact is unchanged until that approval.
users_identify
ChatGPTIdentify the authenticated user. Returns "First Name", "Last Name", "Email", "Role", "Status", and "UUID". Call early in a session to know who you are acting as.
users_list
ChatGPTList the organization's users. Each has "First Name", "Last Name", "Email", "Role", "Status", and "UUID". Use to fill User fields correctly.
workspace_info
ChatGPTDescribe the workspace you are connected to: organization name, the web app URL (build deep links for humans from this, never from the MCP endpoint origin), and whether/where file storage is connected (files_list needs a connected provider).
