Problem
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 result is that a table is fully usable once you know its id, and undiscoverable until then.
In a workspace containing a data table rezervace-skoleni (kind: "data", routable: true, 6 custom fields):
content_list_collections -> [ posts ] # table absent, as documented
site_list_post_types -> [ posts ] # table absent, as documented
content_get_collection_schema(id) -> full schema, 6 fields # works fine
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.
Two consequences:
- Rows in that table — form submissions, for instance — cannot be read or written over MCP by any client that has not first gone hunting through loop sources.
- Because
site_list_post_types also omits it, a postTypes template cannot target the table even though it is routable: true. If routable data tables are genuinely not valid template targets, the routable flag on them is misleading and worth a doc note either way.
Proposed solution
Either of these closes it:
- 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.
- Add a
kind filter to content_list_collections. Default to today's behaviour so nothing breaks, and let a caller ask for kind: "data" explicitly.
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.
- 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.
Area
AI
Related: #433 makes the same read/write-asymmetry point about creating tables and fields. This one is narrower and orthogonal — it is about finding tables that already exist, and would still apply after #433 landed.
Observed through the MCP connector (Site + Content workspaces) against a live hosted workspace, 30–31 Aug 2026. Workspace version not recorded; latest tag at the time of writing is v0.0.17.
Problem
content_list_collectionsandsite_list_post_typesboth 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 nodata_list_tables, nocontent_list_tables, nothing that enumerates a workspace's reusable tables.The result is that a table is fully usable once you know its id, and undiscoverable until then.
In a workspace containing a data table
rezervace-skoleni(kind: "data",routable: true, 6 custom fields):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.Two consequences:
site_list_post_typesalso omits it, apostTypestemplate cannot target the table even though it isroutable: true. If routable data tables are genuinely not valid template targets, theroutableflag on them is misleading and worth a doc note either way.Proposed solution
Either of these closes it:
data_list_tables()returning{ id, slug, label, kind, routable, rowCount, primaryFieldId }for reusable tables, matching the shapecontent_list_collectionsalready returns. This is the option that makes the existing tool descriptions true.kindfilter tocontent_list_collections. Default to today's behaviour so nothing breaks, and let a caller ask forkind: "data"explicitly.Separately, include routable data tables in
site_list_post_types— or state in the description why aroutable: truetable is not a validpostTypestarget.Alternatives considered
site_list_loop_sourcesfor 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.Area
AI
Related: #433 makes the same read/write-asymmetry point about creating tables and fields. This one is narrower and orthogonal — it is about finding tables that already exist, and would still apply after #433 landed.
Observed through the MCP connector (Site + Content workspaces) against a live hosted workspace, 30–31 Aug 2026. Workspace version not recorded; latest tag at the time of writing is v0.0.17.