Catalog Relationships

Every connection the catalog knows about — a server exposing a tool, a server exposing a resource, a dataset containing a table, a table containing a column — is recorded as one row: a source type and ID, a destination type and ID, and a relationship kind. In practice only two kinds get written today: one specifically for a server exposing a tool, and one general-purpose kind reused for every other containment link — server to resource, server to dataset, dataset to table, table to column. Writing a connection is idempotent: the exact (source, destination, kind) triple is checked for existence first, so a discovery pass that runs every few minutes doesn't pile up duplicate connections on every cycle.

These connections are what let the catalog answer questions no single entity table can answer alone — which tables live under which MCP server, which columns belong to which table. The lookups behind "all tables for this server" and "all columns for this server" work by walking server-to-dataset-to-table-to-column through these connections rather than by a stored, denormalized reference on the table or column row itself.

Deleting an MCP server cascades through this structure rather than leaving it dangling: every connection referencing the server or anything reachable from it — its datasets, tables, columns — is removed alongside the rows themselves, followed by a cleanup pass that drops any connection left pointing at a dataset, table, or column that no longer exists.

This capability is the record of the connections, not their visualization — AI Graph, under AI Control, is what renders the same structure as an explorable diagram and layers policy protection state on top of it.