Skip to content

[Feature]: Reusable data tables are unlistable — tool descriptions point at "Data tools" that do not exist #463

Description

@borskyj-symph

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:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions