[Feature]: Reusable data tables are unreachable over MCP — cannot be listed, and their rows cannot be written even with the table id

[borskyj-symph]

Problem

Reusable data tables (kind: "data") are second-class citizens on the MCP surface in two ways: they cannot be discovered, and — the part I got wrong when I first filed this — their rows cannot be written at all, even once you know the table id.

1. They cannot be listed

content_list_collections and site_list_post_types both exclude reusable data tables, and their descriptions say so — "reusable tables through Data tools" and "System tables, pages, components, layouts, and reusable data tables are excluded". The exclusion is intentional and documented. The problem is that the Data tools those descriptions point at do not exist in the MCP surface: there is no data_list_tables, no content_list_tables, nothing that enumerates a workspace's reusable tables.

The only tool that returns the id is site_list_loop_sources, whose stated purpose is building loops rather than collection discovery. An agent that has not thought to call it has no way to learn the table exists.

2. Their rows cannot be created or edited, even with the id

When I filed this I assumed a table was "fully usable once you know its id". It is not. The write tools reject the very id the read tools accept.

Against a hosted workspace with the Content workspace open and connected, table zACma5E54ndy3l-txDjcs (slug kolen, label Trainings, kind: "data", 10 custom fields, 1 row):

content_get_collection_schema("zACma5E54ndy3l-txDjcs")
  -> { collection: { id: "zACma5E54ndy3l-txDjcs", slug: "kolen", label: "Trainings",
                     kind: "data", rowCount: 1, primaryFieldId: "name",
                     fields: [ name, perex, datelabel, duration, place,
                               language, price, tipheading, tiptext, bookingurl ] } }

content_create_document({ tableId: "zACma5E54ndy3l-txDjcs", fields: { name: "..." } })
  -> Error: Collection zACma5E54ndy3l-txDjcs not found.

Same id, same session, same workspace connection: one tool in the content_* family resolves it and returns its full schema, the next says it does not exist. site_list_loop_sources also returns the table with every field and its {currentEntry.*} tokens, and a published <instatic-loop> bound to it renders its rows correctly — so the table is readable through three separate paths and writable through none.

The practical effect: a page can be wired to a data table entirely over MCP — loop node, row template, field tokens, styling, publish — and then the rows have to be typed by hand in the Data workspace, one at a time. On the site I hit this on, that is nine training dates behind an otherwise finished section.

This also affects the two issues either side of it: #433 opens with "Rows are fully covered — content_create_document, content_set_document_field(s), …", which holds for routable post types but not for kind: "data" tables.

3. There is no bulk path

Even once row writes work, content_create_document is one call per row, each needing the document to be made active before its fields can be written. Seeding or migrating a table of any size is N round trips. There is no array/CSV import over MCP, and no bulk import in the Data workspace UI either, so there is no fast path in either direction.

Proposed solution

Three pieces, in dependency order — the first two are the ones that matter:

1. Make the content_* write tools accept kind: "data" tables, matching content_get_collection_schema, which already does. content_create_document, content_set_document_field(s), content_set_document_status and content_delete_document all resolve the collection the same way; whatever lookup content_get_collection_schema uses is the one that is right. If data tables are deliberately excluded from writes, the error should say that rather than "not found", and the tool descriptions should state it.

2. Add the missing listing tool. A data_list_tables() returning { id, slug, label, kind, routable, rowCount, primaryFieldId } for reusable tables, matching the shape content_list_collections already returns. This is the option that makes the existing tool descriptions true. Alternatively, add a kind filter to content_list_collections, defaulting to today's behaviour so nothing breaks.

3. Add a bulk row write. A content_create_documents({ tableId, rows: [...] }) — or a rows array on the existing tool — that creates and fills N rows in one call, the way write_db's batch mode works elsewhere. This is what turns "the agent built the section" into "the agent built and populated the section".

Separately, include routable data tables in site_list_post_types — or state in the description why a routable: true table is not a valid postTypes target.

Alternatives considered

• Keep using site_list_loop_sources for discovery. It works, and it is what I did. It relies on a tool's incidental behaviour rather than its documented purpose, so it is not something a client can be expected to find, and nothing guarantees it keeps returning data tables. It also does not help with writes at all.
• Convert the data table to a routable post type. Post types do accept row writes, so this is a real workaround — but it changes the thing's nature: it gains a route and a permalink per row. A list of course dates has no business being nine URLs.
• Document the current state and stop there. Better than nothing, but the descriptions already document the exclusion — the gap is the tool they refer to, not the wording. And the write asymmetry in §2 is not documented anywhere; it presents as a bug.

Area

AI

---

Related: #433 asks for table and field creation over MCP. That is orthogonal to this — this is about tables that already exist — and both would still be wanted after either landed.

Observed through the MCP connector (Site + Content workspaces) against a live hosted workspace: discovery 30–31 Aug 2026, the row-write failure and bulk gap 4 Sep 2026.