Feature Request: Expose directed join graph (joinsTo) in /meta response

[hank-sq]

Problem

The /meta endpoint currently returns a connectedComponent for each cube, which groups cubes that are transitively joinable. However, this treats the join graph as undirected, which doesn't actually tell clients which cubes can join to which.

Joins in Cube are directional — Cube A joining to Cube B does not mean Cube B joins to Cube A. The connected component ID alone is insufficient for clients to determine whether a given combination of cubes forms a valid query. A client seeing that Cubes A, B, and C share the same connectedComponent cannot determine the actual join paths without access to the underlying schema files.

Use Case

We're building a semantic layer where multiple API clients (LLM agents, report builders, data tools) need to programmatically determine valid query combinations from the /meta response alone. Today, these clients have no way to know which cubes can actually be joined together or in what direction — they can only see that cubes belong to the same connected component, which leads to invalid queries being constructed.

Current Workaround

We've introduced a meta.joins_to tag on each cube that explicitly lists the cubes it joins to, preserving the order of the joins array:

cubes:
  - name: ItemTransactions
    meta:
      joins_to:
        - Orders
        - CustomerSnapshots
        - Channel
        - Location
        - CatalogItem
        - CatalogItemVariation
        - ModifiersTransacted
    joins:
      - name: Orders
        relationship: many_to_one
        sql: "..."
      - name: CustomerSnapshots
        relationship: many_to_one
        sql: "..."
      # ... etc

We also have a linter rule that enforces joins_to stays in sync with the actual joins array. This works, but it's a manual workaround that duplicates information already present in the schema — the join targets are right there in the joins definitions.

Proposed Solution

Add a first-class joinsTo field (or similar) to each cube in the /meta response. This would be an array of cube names that the cube joins to, derived directly from the joins definitions. For example:

{
  "cubes": [
    {
      "name": "ItemTransactions",
      "connectedComponent": 1,
      "joinsTo": ["Orders", "CustomerSnapshots", "Channel", "Location"],
      "measures": [...],
      "dimensions": [...]
    }
  ]
}

This gives clients the directed join graph they need to:

1. Determine which cube combinations form valid queries
2. Find join paths between cubes
3. Understand the directionality of relationships
4. Build query validation without access to schema source files

Optionally, including the relationship type (many_to_one, one_to_many, etc.) alongside each entry would be even more useful for clients that need to reason about cardinality.

Willingness to Contribute

If the Cube team is open to this feature, I'm happy to take a pass at the implementation.

[VoxBorealis]

It's legitimately shocking that this is not the case already. I had assumed that of course the relationships are defined in the /meta response since that would be one of the key aspects to provide consistent and accurate context for LLMs.

Honestly, am I missing something here? Now that I'm thinking about this, I'm not sure what the real value of the current /meta API is for LLM consumers; it's needlessly verbose and missing the critical relationship info. I mean, as it stands, even just providing the LLM with the YAML model files "as is", would provide a better understanding of the data with less context rot, no?

Sorry for the ranting tone, I do appreciate the work!