Tabulous

List the organization's users. Each has "First Name", "Last Name", "Email", "Role", "Status", and "UUID". Use to fill User fields correctly.

users_list

Sync 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_dataset_refresh

Show 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_show

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

changesets_stage

Suggest the next available record name(s) for a Registry Table, following its naming pattern.

records_suggest_names

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

toolkit_update

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

workspace_info