The view registry model
- Every queryable surface is a view registered in the platform’s view catalog: a slug, a display label, a source table (or dataset), and a registered column list (
column_name+ displaydata_type). - Views can be physical-table backed (rows in a real table) or dataset backed (rows in a generic JSONB store, projected to the registered columns). Query semantics are identical for both.
- Table-level visibility follows department mapping and is default-closed: a view with no department mapping is visible to nobody except tenant admins; otherwise it must be mapped (enabled) to one of your departments. Admins see all views.
- Queryability requires the source table to be tenant-scoped (both
tenant_idandworkspace_idcolumns). Admin meta/audit views are listed for admins withqueryable:falseand cannot be queried over MCP. - Row-level visibility: on a view whose source table has a
scopecolumn, you only receive the rows scoped to you — tenant-wide rows, rows of your departments, your own user-scoped rows, and your provider’s rows. Admins see every row, so a member’s counts can legitimately be lower than an admin’s. Views without ascopecolumn are unfiltered at row level. - Registry fixed filters: a view may carry admin-defined fixed filters (e.g. a “strategy knowledge” view that only shows one category). These are enforced on every read and cannot be bypassed.
- Soft archive: views whose source has an
archived_atcolumn hide archived rows by default; passinclude_archived:trueto see them. - Per-agent ceilings: when an agent (rather than a user key) queries a view, its admin-set view preferences act as a ceiling — pinned columns are the only requestable columns, default filters are always ANDed in, and a row cap limits every call. These preferences are configured via
agent_create.data_sources/agent_update.view_prefs(see Agents).
Column catalog: the concrete set of views and their columns is per tenant and lives in the registry, not in code. Discover it at runtime with
data_view_list — that response is always the authoritative column table for your tenant. The Appendix: view & column catalog at the end of this page is a snapshot of the global template views (the defaults every tenant inherits); a tenant may add its own views or hide columns on top of these.Data types
Thedata_type shown per column is a display type: text | number | currency | datetime | date | boolean | status | link | email | image | json | markdown. Free-text search matches columns of type text, email, link and markdown (identifier-like columns such as id, *_id, *_by are excluded automatically).
data_view_list
List the data tables (views) this user may query — slugs, labels, columns and a queryable flag. Call before data_query.
Parameters: none.
Returns:
reason.
Permissions: read tool; per-view department visibility applies (default-closed for members, all views for admins).
Example:
data_query
Query one data view by slug: exact-match filters, free-text search, count-only totals, sort, limit and column projection. This is the typed path for every exact/aggregate/numeric question — counts, prices, inventory, filtered records. For conceptual recall use knowledge_search / memory_search instead.
Parameters:
Returns:
{rows, count, truncated} — truncated:true means the result hit the limit and more rows may exist. count_only returns {count}. If a requested search could not be applied (no searchable columns), search_applied:false is included. Unknown filter/sort/projection columns return a clear error listing the valid columns.
Row visibility: scoped rows are filtered to your identity as described above; your totals can differ from an admin’s.
Example:
Row writes
Row writes target registered, tenant-scoped catalog tables (entries ofview_type:"table" in data_view_list). Each writable table is gated by its own grant — see Row Write Tools for the full list of insert_/update_ tools. Common rules:
tenant_idandworkspace_idare set automatically from your credential — never pass them.- Only the table’s registered creatable columns are accepted; identity/ownership columns (
id,tenant_id,workspace_id, …) are stripped or protected. - If the table has an owner column (
submitted_by_user_id/owner_user_id/user_id), it is stamped with the calling user, so user-scoped rows really belong to you. - Each table needs a per-table write grant on the key/agent:
insert_<table>orupdate_<table>(toggled in Settings → MCP Access → Write access per table; granted automatically on OAuth first connect). Without the grant the call is rejected. - All three tools support
dry_run:true.
data_row_save
Upsert one row keyed on external_id — the write counterpart of data_query. A second save with the same external_id updates the existing row instead of creating a duplicate. Use for ingestion watchers (videos, leads, orders).
Returns: the saved row / upsert receipt (dry-run: the would-be upsert).
Permissions: write; requires
insert_<table> or update_<table> grant.
data_row_create
Insert a new row (no external_id required — the database assigns the row id and any auto-generated columns such as sequence numbers).
Returns: the created row (including its new
id).
Permissions: write; requires insert_<table> grant.
data_row_update
Update one row by id. Filters on both tenant and workspace — a row id from a different workspace returns “not found”. external_id can never be set or changed here (use data_row_save for upserts).
Returns: the updated row.
Permissions: write; requires
update_<table> grant.
View management
data_view_create
Create a new data view in the registry with columns and department visibility. The source table must already exist and be tenant-accessible.
Returns: the created view (id + slug).
Permissions: write; Company-Admin only.
data_view_update
Update an existing view: rename, replace columns, or set department visibility.
Returns: the updated view.
Permissions: write; Company-Admin only.
Appendix: view & column catalog
Snapshot of the global template views (cockpit.views where tenant_id IS NULL) and their columns, generated from the live registry on 2026-08-13. These are the defaults every tenant inherits. Your tenant’s live set may differ — data_view_list is always authoritative.
Legend: Vis = shown by default · Filt = filterable · Search = full-text searchable · Edit = updatable via data_row_update/data_row_save · Create = settable on data_row_create. A DB-view source (v_*) is read-only regardless of flags.
agents — public.agents
Capabilities: read · Columns: 9
agent_runs — public.agent_runs
Capabilities: read (read-only) · Columns: 17
agent_inbox — public.inbox_agents
Capabilities: read (read-only) · Columns: 9
decision_log — public.decision_log
Capabilities: read (read-only) · Columns: 13
decisions — public.decisions
Capabilities: read + catalog + ingest · Columns: 61
knowledge — cockpit.knowledge_base
Capabilities: read + history · Columns: 21
knowledge_strategy — cockpit.knowledge_base
Capabilities: filtered (category=strategy) + history · Columns: 21
Same column set and flags as knowledge above — the view adds a fixed filter category=strategy that is enforced on every read.
knowledge_sop — cockpit.knowledge_base
Capabilities: filtered (category=sop) + history · Columns: 21
Same column set and flags as knowledge above — the view adds a fixed filter category=sop that is enforced on every read.
