Anchor

Add a new column to an existing Anchor table. This is the column-level counterpart to create_table — same column schema, but for a single column added after the table already exists. Example input (project_id holds a record_id from a Projects table, linked but not enforced): { "table_id": "a195e7a1-b0a0-7f00-a1b2-c3d4e5f60001", "column": { "identifier": "project_id", "display_name": "Project", "type": "INTEGER", "isUnique": false, "isRequired": false, "linkedTableId": "a195e7a1-b0a0-7f00-a1b2-c3d4e5f60002" } } Example with required ENUM column and defaultValue: { "table_id": "a195e7a1-b0a0-7f00-a1b2-c3d4e5f60001", "column": { "identifier": "priority", "display_name": "Priority", "type": "ENUM", "isUnique": false, "isRequired": true, "possibleValues": ["P0", "P1", "P2"], "defaultValue": "P2" } } Under the hood this runs an ALTER TABLE … ADD COLUMN on the underlying PostgreSQL table: ALTER TABLE anchor_tables."<table_uuid>" ADD COLUMN <identifier> <PG_TYPE> [NOT NULL] [UNIQUE] [DEFAULT <value>::<PG_TYPE>] [CHECK (...)]; Type mapping: STRING → TEXT, NUMBER → DOUBLE PRECISION, INTEGER → BIGINT, BOOLEAN → BOOLEAN, ENUM → TEXT (with CHECK constraint), DATE → DATE, DATETIME → TIMESTAMPTZ, EMAIL / CREATED_BY_EMAIL → TEXT. RULES: - The column uses exactly one of two forms: standard, or ENUM (requires possibleValues). - Cannot add a column whose identifier already exists in the table. - If the column is required (isRequired: true), defaultValue MUST be set — existing rows are backfilled with it via DEFAULT. The column will be rejected without it. - If the column is not required, defaultValue is optional — existing rows get NULL when omitted. - Unique columns: when isUnique is true, isRequired must be false and defaultValue must not be set — existing rows are filled with NULL (which satisfies uniqueness). - CREATED_BY_EMAIL columns: defaultValue must NOT be set (the enforcement trigger overrides it on every INSERT/UPDATE with the caller's email). New rows inserted after the column is added are always populated by the trigger. Existing rows cannot be backfilled — the trigger only fires on INSERT/UPDATE — so isRequired may only be true if the table currently has zero rows. On a non-empty table, isRequired must be false; existing rows will be NULL while new rows are auto-filled by the trigger.

add_table_column

Builds an Anchor app from the contents of a temporary folder. Two modes: NEW APP — pass temporary_folder_id + name + destination_folder_id. Creates a new APP file in destination_folder_id, which must be in the temporary folder's org, and builds+publishes v1. NEW VERSION — pass temporary_folder_id + app_id. Builds a new version of app_id from scratch using every file currently in the temporary folder — nothing carries over from the previous version except what you put there yourself (e.g. via unpack_file first). Auto-publishes iff the app isn't shared with anyone else; otherwise the owner must publish it from the app's management page. Required temporary-folder files: index.tsx, favicon.json. Optional: index.css, functions.json, plus any number of helper modules index.tsx imports. Reserved build-output names (bundle.html, fetch.ts) are rejected if present — those are emitted by the build pipeline, not authored by you. See write_file's description for exactly how to author index.tsx, functions.json, and favicon.json (including the JSON-escaping rules for functions.json's SQL strings). index.tsx is bundled, NOT typechecked. The ./fetch helpers take positional arguments in inputSchema order — addTask(title) not addTask({ title }), listTasks() not listTasks({}). An object argument compiles, publishes, and then fails on every call with INVALID_REQUEST, so re-read every ./fetch call in index.tsx before you build. Full contract: write_file's description. index.tsx is the bundle's entry module and is responsible for mounting. The served page contains an empty <div id="root"></div> and runs your compiled bundle as a module script; the platform adds no bootstrapping code. End index.tsx with createRoot(document.getElementById('root')!).render(<App />), importing createRoot from 'react-dom/client'. A file that only exports a component produces a blank page, and the build rejects it with NO_ROOT_MOUNT. functions.json declares this version's complete data-access footprint via dependencies (TABLE and OTHER entries) plus the SQL functions that actually touch them. The build verifies the declaration is exactly right, in both directions, before it will succeed: - Every table or OTHER file a SQL function touches must be declared in dependencies, at the level actually used (READ vs WRITE) — an undeclared or under-declared touch fails with UNDECLARED_TABLE_ACCESS. - Every declared TABLE entry must actually be used at that level by some function — an unused or over-declared entry fails with UNUSED_TABLE_DEPENDENCY. An app can never ask for more access than it uses. - Every declared entry requires YOUR OWN direct access at that level before the build can succeed (TABLE READ needs your direct CONSUMER access, TABLE WRITE needs your direct CONTRIBUTOR access, OTHER needs your direct CONSUMER access) — building never grants access on your behalf. - Every OTHER entry must exist, be an OTHER file (never APP or TABLE), and not sit inside any temporary folder. - An image the app displays is such an OTHER entry: declare the file (no functions entry needed — the unused-dependency check is TABLE-only) and render it with anchorOtherFileFetch(fileId) from ./fetch as the <img src>. Never base64-encode an image into index.tsx. Building never grants anyone access to anything — it only records the requirement. If the app declares dependencies, it is unusable by everyone right after the build, including you, until each person separately consents to what it does with their access (and, for anyone lacking the access itself, requests it from the owner first); direct the user to the app's management page (app_management_link) for that flow. An app that declares no dependencies has nothing to consent to, and is reachable as soon as someone has access to it. On a successful build, the temporary folder (and everything in it) is deleted — do not try to write_file/cp/mv into temporary_folder_id afterward, it no longer exists. A failed build leaves the temporary folder in place so you can fix the problem and retry without re-writing every file. There is no other cleanup path for a temporary folder: one that's never successfully built against sits there permanently.

build_app

Turn a temporary folder of files into an Anchor document, or into a new version of one that already exists. An Anchor document is one file made of several: one HTML file per page, a config.json listing them, and whatever CSS and images they use. There is no build step — the files are served as written. To make one: mkdir(temporary: true), write the files into that folder with write_file, copy in any images with cp, then call this — naming a normal folder in the staging folder's org as the destination, never the staging one. To change an existing one: unpack_file first, edit the files it writes out, then call this with that folder and the base_version unpack_file returned. To restore an older version, unpack_file it by number and call this with the folder unchanged, the same way: it becomes a new version with the old content. Everything validates before anything is stored, so a rejected commit creates no version and leaves the folder untouched for you to fix and retry. A successful one deletes the folder. Write ordinary HTML. One complete HTML document per page, no framework. Anchor supplies everything around the page: page navigation, comments, version history, printing. Do not build navigation, in-page tabs, or anything that hides content behind a click — <details> included. What you write is also what gets printed and thumbnailed. Let height follow content, and never hide anything behind scrolling. Put the content in the markup — search engines, text extraction and version diffs see only the DOM. JavaScript is for interaction, never for producing text. Every element inside <body> needs an id, unique across every file in the document. This is checked and it is literal — a layout wrapper needs one exactly as much as a paragraph does. Inside an <svg>, only the <svg> itself and the tags that carry words (<text>, <tspan>, <textPath>, <title>, <desc>); shapes and plumbing do not. Keep ids the same across edits wherever the content has not changed: comments anchor to them, and a changed id is a lost comment. Renaming an id while its element stays is the easy mistake — it feels like tidying, and to a comment it is a deletion. If you restructure, keep the id on any element whose words survive, even where it has moved or been re-tagged. Committing names every id that is no longer present, so check each one and put back any that should have survived. Wrap each sentence in a <span>, so a comment has a natural unit to attach to. No browser storage — no localStorage, no cookies. The page has no internet. Everything it loads is a file inside the document, by relative path — Google Fonts is the only exception, and data: URIs are refused. fetch, XHR and WebSockets fail too. Links are the one way out: they may point anywhere, and Anchor handles the click, so target and window.open do nothing. Tags, attributes and ARIA roles are allowlisted, and narrower than you would guess: no form controls, iframes, canvas or on* handlers, and <label>, <progress> and interactive roles are out too — except the few below that a reader's state lives on, which are the only controls a document has, whether or not it keeps what the reader does. A rejection lists everything that would have been accepted. Ordinary CSS is fine, inline in a <style> block or in a .css file beside the page. Charts and diagrams are SVG, which stays readable to search engines, diffs and printers. config.json says what the pages are, in the order they appear: { "kind": "document", "tabs": [ { "id": "k3f9x2", "title": "Introduction", "file": "page-1.html" }, { "id": "m7p2qd", "title": "How it works", "file": "page-2.html" } ] } Each entry: `id` is a stable handle, `title` is what Anchor's chrome shows, `file` is a .html file at the root of the folder. **An `id` is opaque and permanent.** Invent about six characters with no relation to the title — a letter, then letters or digits, like `k3f9x2` — and never change it again. It is what a link to this page points at and what a reader's saved state is filed under, so changing one silently breaks both: a link that used to open here lands on the first page instead. Retitling and reordering are free, and neither touches the `id`. Do not make it resemble the title, or it will look wrong the moment the title changes and invite exactly that edit. Pick a new `id` only for a page that did not exist before. A document can show live rows from a table. Declare them in two more halves of config.json, beside `tabs` — the same `dependencies` and `functions` an app's functions.json uses, minus its `version` — and leave both out when there is no data to read: { "dependencies": [ { "id": "targets", "type": "TABLE", "file_id": "<the table's file id>", "access": "READ", "description": "Reads quarterly targets for the table on page 1." } ], "functions": [ { "type": "SQL", "name": "quarterlyTargets", "description": "Every target, by quarter", "sql": "SELECT quarter, target, actual FROM \"<the table's file id>\" ORDER BY quarter", "inputSchema": [], "outputSchema": { "quarter": { "type": "string", "description": "Quarter, as 2026-Q1" }, "target": { "type": "number", "description": "Target, in USD" }, "actual": { "type": "number", "description": "Booked so far, in USD" } } } ] } A dependency's `id` is a short lowercase name of your choosing, unique in the file. Its `description` is what the table's owner reads when they decide whether to allow this, so write it for them. Every function is `"type": "SQL"`, and `inputSchema` must be empty: nobody is there to supply an argument, and a query with parameters would return nothing. Every query runs as written, for each reader, with only that reader's own access — a reader who cannot see the table sees no rows, and the document cannot lend them any. The rows are handed to the page. There is nothing to call and no endpoint to reach: each query's rows arrive as an `anchor:data` event, and the latest rows for each name stay readable at `window.anchorData(name)`, so a script that starts listening late has missed nothing. Do both, or the page is blank whenever delivery wins the race: <script id="targets-draw"> function draw(rows) { /* replace the contents of one container */ } window.addEventListener('anchor:data', function (event) { if (event.detail.name === 'quarterlyTargets') draw(event.detail.rows); }); var rows = window.anchorData && window.anchorData('quarterlyTargets'); if (rows) draw(rows); </script> The event fires again whenever the table changes, so draw by replacing what you drew, never by appending. Rows drawn this way are not in the markup, which means they are not in a print, a thumbnail or a search result — so the document's own words still belong in the DOM, and the container they land in needs markup that reads sensibly while empty. Ids are checked on what you commit, so rows built by script need none. A reader can interact with a document, and you decide whether what they do is kept. Both kinds are written the same way — there are no form controls, so anything interactive is an element with an ARIA role and a listener — which is exactly why the choice has to be made on purpose. **Kept, and shared with everyone.** `anchor.set(id, attribute, value)` sets the attribute and stores it as a new version of the document: every reader sees it, it survives a reload, and it can be undone. This is what a shared checklist is — somebody ticks `Tests written` and their colleagues open the document and find it ticked. <span id="tests-done" role="checkbox" aria-checked="false" tabindex="0">Tests written</span> <script id="tests-done-script"> var box = document.getElementById('tests-done'); box.addEventListener('click', function () { var next = box.getAttribute('aria-checked') === 'true' ? 'false' : 'true'; anchor.set('tests-done', 'aria-checked', next); // stored, and everyone sees it }); </script> **Not kept, and nobody else's business.** Change the page yourself and the change lives in that one reader's browser until they reload. That is the right answer for anything only the person reading it should see: a mock-up of a feature inside a spec, a worked example somebody steps through. Nobody wants a colleague's click on a mock saved into the document as a new version. <div id="demo-card" class="card">Your first project</div> <span id="demo-dark" role="switch" aria-checked="false" tabindex="0">Preview in dark mode</span> <script id="demo-dark-script"> var demo = document.getElementById('demo-dark'); demo.addEventListener('click', function () { var on = demo.getAttribute('aria-checked') !== 'true'; demo.setAttribute('aria-checked', String(on)); // this reader only, gone on reload document.getElementById('demo-card').classList.toggle('dark', on); }); </script> **They look the same until somebody reloads, so ask one question:** should a second reader see this change? If yes it goes through `anchor.set`; if no it does not. A shared checklist built without it works perfectly for the person who ticked it and is empty for everyone else, and neither of them will find out until one of them reopens the document. Stored state is read back out of the markup, where it is — not out of a variable you kept alongside it. What can be stored is a state, on an element whose role owns it: `aria-checked` on a checkbox, option, radio or switch; `aria-expanded` on a checkbox, columnheader, listbox, row or rowheader; `aria-selected` on a columnheader, option, row or rowheader; `aria-valuenow` on a slider, within the `aria-valuemin` and `aria-valuemax` you gave it. Anything else is refused and the reason is logged in the page's console. Write the starting value into the markup at commit. It is the state, so a document that has never been opened already reads correctly — and it is what the print, the thumbnail and a search engine see. Saving needs edit access. A reader with view access sees the control and the change is put back, which is a good reason not to build one that looks disabled when it is not. A document reflows to whatever width it is read at. Use a wide viewport well — especially for tables — and keep running text at a readable measure rather than letting it stretch edge to edge. The page itself must never scroll sideways, down to a phone's width. Anything that cannot narrow — a wide table, a long code line, a diagram — scrolls inside its own container instead, and that is the one place a scrolling region belongs.

commit_document

Turn a temporary folder of files into an Anchor presentation, or into a new version of one that already exists. An Anchor presentation is one file made of several: one HTML file per slide, a config.json listing them, and whatever CSS and images they use. There is no build step — the files are served as written. To make one: mkdir(temporary: true), write the files into that folder with write_file, copy in any images with cp, then call this — naming a normal folder in the staging folder's org as the destination, never the staging one. To change an existing one: unpack_file first, edit the files it writes out, then call this with that folder and the base_version unpack_file returned. To restore an older version, unpack_file it by number and call this with the folder unchanged, the same way: it becomes a new version with the old content. Everything validates before anything is stored, so a rejected commit creates no version and leaves the folder untouched for you to fix and retry. A successful one deletes the folder. Write ordinary HTML. One complete HTML document per slide, no framework. Anchor supplies everything around the page: slide navigation, comments, version history, printing. Do not build navigation, in-page tabs, or anything that hides content behind a click — <details> included. What you write is also what gets printed and thumbnailed. Let height follow content, and never hide anything behind scrolling. Put the content in the markup — search engines, text extraction and version diffs see only the DOM. JavaScript is for interaction, never for producing text. Every element inside <body> needs an id, unique across every file in the presentation. This is checked and it is literal — a layout wrapper needs one exactly as much as a paragraph does. Inside an <svg>, only the <svg> itself and the tags that carry words (<text>, <tspan>, <textPath>, <title>, <desc>); shapes and plumbing do not. Keep ids the same across edits wherever the content has not changed: comments anchor to them, and a changed id is a lost comment. Renaming an id while its element stays is the easy mistake — it feels like tidying, and to a comment it is a deletion. If you restructure, keep the id on any element whose words survive, even where it has moved or been re-tagged. Committing names every id that is no longer present, so check each one and put back any that should have survived. Wrap each sentence in a <span>, so a comment has a natural unit to attach to. No browser storage — no localStorage, no cookies. The page has no internet. Everything it loads is a file inside the presentation, by relative path — Google Fonts is the only exception, and data: URIs are refused. fetch, XHR and WebSockets fail too. Links are the one way out: they may point anywhere, and Anchor handles the click, so target and window.open do nothing. Tags, attributes and ARIA roles are allowlisted, and narrower than you would guess: no form controls, iframes, canvas or on* handlers, and <label>, <progress> and interactive roles are out too — except the few below that a reader's state lives on, which are the only controls a presentation has, whether or not it keeps what the reader does. A rejection lists everything that would have been accepted. Ordinary CSS is fine, inline in a <style> block or in a .css file beside the page. Charts and diagrams are SVG, which stays readable to search engines, diffs and printers. config.json says what the slides are, in the order they appear: { "kind": "presentation", "canvas": { "width": 1280, "height": 720 }, "tabs": [ { "id": "k3f9x2", "title": "Introduction", "file": "slide-1.html" }, { "id": "m7p2qd", "title": "How it works", "file": "slide-2.html" } ] } Each entry: `id` is a stable handle, `title` is what Anchor's chrome shows, `file` is a .html file at the root of the folder. **An `id` is opaque and permanent.** Invent about six characters with no relation to the title — a letter, then letters or digits, like `k3f9x2` — and never change it again. It is what a link to this slide points at and what a reader's saved state is filed under, so changing one silently breaks both: a link that used to open here lands on the first slide instead. Retitling and reordering are free, and neither touches the `id`. Do not make it resemble the title, or it will look wrong the moment the title changes and invite exactly that edit. Pick a new `id` only for a slide that did not exist before. A presentation can show live rows from a table. Declare them in two more halves of config.json, beside `tabs` — the same `dependencies` and `functions` an app's functions.json uses, minus its `version` — and leave both out when there is no data to read: { "dependencies": [ { "id": "targets", "type": "TABLE", "file_id": "<the table's file id>", "access": "READ", "description": "Reads quarterly targets for the table on slide 1." } ], "functions": [ { "type": "SQL", "name": "quarterlyTargets", "description": "Every target, by quarter", "sql": "SELECT quarter, target, actual FROM \"<the table's file id>\" ORDER BY quarter", "inputSchema": [], "outputSchema": { "quarter": { "type": "string", "description": "Quarter, as 2026-Q1" }, "target": { "type": "number", "description": "Target, in USD" }, "actual": { "type": "number", "description": "Booked so far, in USD" } } } ] } A dependency's `id` is a short lowercase name of your choosing, unique in the file. Its `description` is what the table's owner reads when they decide whether to allow this, so write it for them. Every function is `"type": "SQL"`, and `inputSchema` must be empty: nobody is there to supply an argument, and a query with parameters would return nothing. Every query runs as written, for each reader, with only that reader's own access — a reader who cannot see the table sees no rows, and the presentation cannot lend them any. The rows are handed to the page. There is nothing to call and no endpoint to reach: each query's rows arrive as an `anchor:data` event, and the latest rows for each name stay readable at `window.anchorData(name)`, so a script that starts listening late has missed nothing. Do both, or the page is blank whenever delivery wins the race: <script id="targets-draw"> function draw(rows) { /* replace the contents of one container */ } window.addEventListener('anchor:data', function (event) { if (event.detail.name === 'quarterlyTargets') draw(event.detail.rows); }); var rows = window.anchorData && window.anchorData('quarterlyTargets'); if (rows) draw(rows); </script> The event fires again whenever the table changes, so draw by replacing what you drew, never by appending. Rows drawn this way are not in the markup, which means they are not in a print, a thumbnail or a search result — so the presentation's own words still belong in the DOM, and the container they land in needs markup that reads sensibly while empty. Ids are checked on what you commit, so rows built by script need none. A reader can interact with a presentation, and you decide whether what they do is kept. Both kinds are written the same way — there are no form controls, so anything interactive is an element with an ARIA role and a listener — which is exactly why the choice has to be made on purpose. **Kept, and shared with everyone.** `anchor.set(id, attribute, value)` sets the attribute and stores it as a new version of the presentation: every reader sees it, it survives a reload, and it can be undone. This is what a shared checklist is — somebody ticks `Tests written` and their colleagues open the presentation and find it ticked. <span id="tests-done" role="checkbox" aria-checked="false" tabindex="0">Tests written</span> <script id="tests-done-script"> var box = document.getElementById('tests-done'); box.addEventListener('click', function () { var next = box.getAttribute('aria-checked') === 'true' ? 'false' : 'true'; anchor.set('tests-done', 'aria-checked', next); // stored, and everyone sees it }); </script> **Not kept, and nobody else's business.** Change the page yourself and the change lives in that one reader's browser until they reload. That is the right answer for anything only the person reading it should see: a mock-up of a feature inside a spec, a worked example somebody steps through. Nobody wants a colleague's click on a mock saved into the document as a new version. <div id="demo-card" class="card">Your first project</div> <span id="demo-dark" role="switch" aria-checked="false" tabindex="0">Preview in dark mode</span> <script id="demo-dark-script"> var demo = document.getElementById('demo-dark'); demo.addEventListener('click', function () { var on = demo.getAttribute('aria-checked') !== 'true'; demo.setAttribute('aria-checked', String(on)); // this reader only, gone on reload document.getElementById('demo-card').classList.toggle('dark', on); }); </script> **They look the same until somebody reloads, so ask one question:** should a second reader see this change? If yes it goes through `anchor.set`; if no it does not. A shared checklist built without it works perfectly for the person who ticked it and is empty for everyone else, and neither of them will find out until one of them reopens the presentation. Stored state is read back out of the markup, where it is — not out of a variable you kept alongside it. What can be stored is a state, on an element whose role owns it: `aria-checked` on a checkbox, option, radio or switch; `aria-expanded` on a checkbox, columnheader, listbox, row or rowheader; `aria-selected` on a columnheader, option, row or rowheader; `aria-valuenow` on a slider, within the `aria-valuemin` and `aria-valuemax` you gave it. Anything else is refused and the reason is logged in the page's console. Write the starting value into the markup at commit. It is the state, so a presentation that has never been opened already reads correctly — and it is what the print, the thumbnail and a search engine see. Saving needs edit access. A reader with view access sees the control and the change is put back, which is a good reason not to build one that looks disabled when it is not. A presentation is fixed-layout. Lay every slide out against the pixel canvas in config.json (1280x720 unless it says otherwise) and position things absolutely against it — the viewer scales the whole slide to fit, so responsive CSS is not needed and will not help.

commit_presentation

Copy a file. Only files can be copied (not folders). The copy gets a new ID, the caller becomes the owner, and no existing access roles are carried over. For tables, the full PostgreSQL table (schema + data) is duplicated. For documents and presentations, only the latest version is copied and becomes version 1 of the copy, with the tables it reads declared again. For apps, the full version history (every version's source, dependencies, and built bundle) is duplicated and the copy gets a fresh slug; copying an app requires contributor access to the source, since the copy's owner can unpack its source code. Requires read access to the source file and write access to the destination folder. Only in-org copies are allowed. An OTHER file may be copied into, out of, or between temporary folders (the scratch folders `mkdir` creates with `temporary: true`); nothing else — a table, an app, a document or a presentation — can enter one.

cp

Create a new folder. Pass folder_id to create a subfolder inside an existing folder, or org_id to create a folder at the org root. Requires permission at the parent location. Set temporary: true to create a temporary folder instead — private scratch space, visible only to you, always at the org root (org_id required, folder_id forbidden). It is where files are staged before build_app, commit_document or commit_presentation. A temporary folder persists until one of those succeeds against it and deletes it; there is currently no other way to remove one, so an abandoned temporary folder sits there permanently — only create one when you are about to populate and commit it. If what you stage will call tools on an MCP server, call list_mcp_servers for the org first: a build or commit that declares a server the org has not approved is refused, and the folder stays.

mkdir

Create a new table in Anchor (File type: TABLE). Tables are structured data stores with typed columns. Under the hood, this creates a PostgreSQL table whose name is the returned UUID. The table is displayed to users without exposing database concepts, but all column configurations (types, constraints) map directly to PostgreSQL features — the Postgres type is noted next to each config option. Tables are designed to work together through normalization: - Master data entities (Customers, Products, Employees, Vendors, Locations, Categories, etc.) are the core reusable "nouns" of an organization. - Transactional tables (Orders, Invoices, Appointments, Transactions) point at master tables rather than embedding fields like "customer_name" or "product_name" directly. Store a relationship as an INTEGER column (e.g. "customer_id") holding the other table's record_id, and set linkedTableId to the other table's UUID so readers know which table to join. The database does not enforce the link. - Existing tables in the organization can be inspected with ls and describe_table to find the tables to point at and avoid duplicating master data. SCHEMA RULES: - Every table must include a "record_id" column (INTEGER, isUnique: true, isRequired: true). This column is auto-generated (GENERATED ALWAYS AS IDENTITY) — do NOT include record_id values in subsequent INSERT queries. - isRequired: true needs a defaultValue of the column's type (except record_id and CREATED_BY_EMAIL): "" for STRING, 0 for NUMBER/INTEGER, false for BOOLEAN, a date like "2024-01-01" for DATE. No sensible default? Use isRequired: false. - Columns with linkedTableId: use isRequired: false. 0 matches no record_id. - Each column has an identifier (snake_case, immutable, used in SQL) and a display_name (human-friendly, shown in UI). - Each column uses exactly one of two forms: standard, or ENUM (requires possibleValues). - columns is an array of column definitions (preferred). A legacy map keyed by identifier is also accepted. - The full column schema is set at creation time. After creating, use describe_table to inspect the schema. Example input: { "folder_id": "0195e7a1-b0a0-7f00-a1b2-c3d4e5f60001", "name": "Tasks", "description": "Tracks work items and their status", "columns": [ { "identifier": "record_id", "display_name": "Record ID", "type": "INTEGER", "isUnique": true, "isRequired": true }, { "identifier": "name", "display_name": "Name", "type": "STRING", "isUnique": false, "isRequired": true, "defaultValue": "" }, { "identifier": "due_date", "display_name": "Due Date", "type": "DATE", "isUnique": false, "isRequired": false }, { "identifier": "priority", "display_name": "Priority", "type": "ENUM", "isUnique": false, "isRequired": true, "possibleValues": ["P0", "P1", "P2"], "defaultValue": "P2" } ] }

create_table

Permanently delete any Anchor file — a table, an app, a document, a presentation, or an other-file (HTML, Markdown, CSV, etc.). The deletion is immediate and irreversible — there is no trash or undo. For a TABLE, the underlying data is dropped along with the file; for everything else, the stored content goes with it, including every version of a document, presentation or app. Only an owner of the file (or of a parent folder) can delete a file. This is a destructive action — confirm with the user before deleting files you did not create.

rm_file

Permanently delete a column from an existing Anchor table. The deletion is immediate and irreversible — all data in the column across every row is destroyed and cannot be recovered. This is a destructive action — confirm with the user before deleting a column. Under the hood this runs an ALTER TABLE … DROP COLUMN on the underlying PostgreSQL table: ALTER TABLE anchor_tables."<table_uuid>" DROP COLUMN <column_identifier>; The "record_id" column cannot be deleted — it is the primary key.

delete_table_column

Get a table's full schema, metadata, and row count. Use this to understand a table's structure before querying or modifying it with query_table, add_table_column, or delete_table_column. Does not return row data — use query_table for that. For tables with many rows, use query_table to peek at a sample or write aggregated SQL queries rather than fetching all rows. Example input: { "table_id": "a195e7a1-b0a0-7f00-a1b2-c3d4e5f60001" } Returns: - Row count: total number of rows in the table. For large tables, use query_table with LIMIT to peek at sample data, or write aggregated SQL queries (COUNT, SUM, AVG, GROUP BY, etc.) instead of selecting all rows. - Column definitions: each column has an identifier (snake_case, immutable — use this in SQL queries) and a display_name (human-friendly — use this when communicating with the user). Also includes types, constraints, allowed values, and the table each column links to (linked_table_id, not enforced). - Timestamps: creation and last update times.

describe_table