Tables

Tables are structured tabular databases scoped to your project. Use them to store, query, and manage structured data that your playbooks and AI agents can read and write programmatically.

Creating a table

Open the Creation Picker (Cmd+N) and select Table, or use the create_data_store MCP tool from an agent session.

Each table has typed columns. Data is persisted in a per-project SQLite database.

Column types

Columns also support format sub-types for richer display: email, currency, percent, rating, singleSelect, multiSelect, and rank. Select formats carry options with id, label, and color.

Natural keys

An optional natural key column marks the value that uniquely identifies a row (a date, an email, an external ID). It's what makes repeated writes idempotent instead of duplicating rows.

What a key collision does depends on which path is writing:

• Playbook writeToStore steps upsert. A row whose key already exists is updated in place. This is what makes a periodic playbook safe to re-run.
• The insert_data_store_rows MCP tool refuses by default. A row whose key already exists fails and the existing row is left untouched, because an agent inserting blind shouldn't be able to overwrite data it never read. Pass mode: "upsert" to insert-or-refresh, or mode: "update" to refresh only.

Views

Tables support alternate view modes:

• Table — the default spreadsheet-style view.
• Kanban — cards grouped by a singleSelect column.
• Gantt — timeline view using start and end date columns.
• List — rows as filterable cards behind a persistent filter rail (see List view below).

Switch or add a view from the view switcher at the top of the table. Each alternate type shows a + ‹type› button until it's been created. List is always available; Kanban needs a singleSelect column and Gantt needs a date column before its button enables. View tabs are named by type — there's no per-view rename. You can also create and manage views with the create_data_store_view / update_data_store_view MCP tools.

List view

The List view renders each row as a card behind a persistent left filter rail — a fast way to browse and narrow a table without scanning a grid. It's built to stay responsive on very large tables (it virtualizes the cards, so it handles stores with hundreds of thousands of rows).

Adding a List view

Click + List in the view switcher. Because a list needs no particular column type, the button is always enabled. A setup sheet opens where you configure the view; you can reopen it later from the Configure List menu (the sliders icon in the header). The setup sheet has four controls:

You can also flip Grid ↔ Feed and change the sort directly from the toolbar above the cards.

The filter rail

The rail on the left always shows one widget per filterable column, picked by the column's type:

Filters combine with AND. The checklist counts are computed against the other active filters — each option's number tells you how many rows you'd get if you also picked it. A dot marks any column that's currently filtering, and Clear all (N) at the top of the rail resets everything.

Working with cards

Each card shows its title, its field columns, and select values as pills. Click a card (or press Enter when it's focused) to open the row editor. Clicking a select pill on a card toggles that value as a filter, the same gesture as the Kanban board.

When nothing is showing, the view tells you why:

• No rows yet — use New to add one. — the table is empty.
• No cards match the current filters. — rows exist but none match; Clear filters and Clear search buttons appear as relevant.

Creating a List view from an agent

The create_data_store_view / update_data_store_view MCP tools accept view_type: "list". The optional list config mirrors the setup sheet: layout ("grid" | "feed"), cardTitleColumnID, cardFieldColumnIDs, sortColumnID, and sortDescending. All are optional — a bare list view renders every row as a card with sensible defaults.

Querying data

Use the query_data_store MCP tool to filter, aggregate, group, sort and page a table — addressing columns and select options by their display names, not internal ids. It returns JSON, and it's the way to get an exact count without pulling rows:

{ "store": "Internal Tickets",
  "select": [{ "column": "Status" }, { "agg": "count", "as": "n" }],
  "group_by": ["Status"] }

run_data_query remains available for hand-written UUID-keyed query specs and cross-table joins.

Queries can also be embedded directly into notes as live chart/table blocks — the note auto-refreshes when the underlying data changes.

MCP tools

Playbook integration

Two dedicated playbook step types work with tables:

• writeToStore — upserts rows with natural-key-aware writes. Validates column IDs against the live schema.
• readFromStore — queries with column filters and limits. Returns rows as step output for downstream steps to consume.