MCP

Model Context Protocol - Connecting Coalesce Quality to AI applications

What is MCP?

The Model Context Protocol (MCP) is an open standard that enables AI applications to securely connect with external data sources and tools. MCP is supported by various AI tools including Claude Desktop, Cursor, VS Code, and other AI development environments.

For detailed information about MCP, see:

• Anthropic’s MCP Documentation
• Introduction to MCP

Getting Started

MCP works out of the box — no workspace configuration needed. Just add the server to your AI client and authenticate:

Client Setup

Use the MCP server URL for your region:

Region	MCP Server URL
EU (default)	https://mcp.synq.io/mcp
US	https://mcp.us.synq.io/mcp
AU	https://mcp.au.synq.io/mcp

Claude Code

Run the command for your region:

# US region
claude mcp add synq --transport http https://mcp.us.synq.io/mcp

# EU region
claude mcp add synq --transport http https://mcp.synq.io/mcp

# AU region
claude mcp add synq --transport http https://mcp.au.synq.io/mcp

Claude Desktop / claude.ai

Go to Settings → Connectors → Add custom connector and enter the MCP server URL for your region. This works in both the Claude Desktop app and on claude.ai.

Alternatively, add the following to your Claude Desktop MCP configuration file:

{
  "mcpServers": {
    "synq": {
      "url": "https://mcp.us.synq.io/mcp"
    }
  }
}

The snippet shows the US URL — replace it with https://mcp.synq.io/mcp for EU or https://mcp.au.synq.io/mcp for AU.

Cursor

Open Settings → MCP → Add new MCP Server and add an HTTP server with this configuration (or paste it into ~/.cursor/mcp.json):

{
  "mcpServers": {
    "synq": {
      "url": "https://mcp.us.synq.io/mcp"
    }
  }
}

The snippet shows the US URL — replace it with https://mcp.synq.io/mcp for EU or https://mcp.au.synq.io/mcp for AU.

VS Code

Add the following to .vscode/mcp.json (workspace) or your user MCP config:

{
  "servers": {
    "synq": {
      "type": "http",
      "url": "https://mcp.us.synq.io/mcp"
    }
  }
}

The snippet shows the US URL — replace it with https://mcp.synq.io/mcp for EU or https://mcp.au.synq.io/mcp for AU.

Requires VS Code 1.102 or newer (built-in MCP support).

Codex CLI

Run the command for your region:

# US region
codex mcp add synq --url https://mcp.us.synq.io/mcp

# EU region
codex mcp add synq --url https://mcp.synq.io/mcp

# AU region
codex mcp add synq --url https://mcp.au.synq.io/mcp

Codex stores the server under ~/.codex/config.toml. On the first run (codex), Codex opens your browser for the OAuth flow — approve on the consent screen and the session starts with Coalesce Quality tools available.

Gemini CLI

Run the command for your region:

# US region
gemini mcp add synq --transport http https://mcp.us.synq.io/mcp

# EU region
gemini mcp add synq --transport http https://mcp.synq.io/mcp

# AU region
gemini mcp add synq --transport http https://mcp.au.synq.io/mcp

Use -s user to save the server globally instead of in the current project. On the first tool call, Gemini opens your browser for the OAuth flow; once approved, Coalesce Quality tools are available in the session.

Other Clients

Any client that speaks the MCP Streamable HTTP transport can connect. Point it at the regional URL and let it drive the OAuth flow:

https://mcp.us.synq.io/mcp

The snippet shows the US URL — replace it with https://mcp.synq.io/mcp for EU or https://mcp.au.synq.io/mcp for AU.

Authentication

Coalesce Quality MCP uses OAuth2 with PKCE for secure authentication. This is the recommended way to connect — no API keys or tokens need to be pasted anywhere, and every action the AI takes is attributed to you, with a via MCP badge on the actor chip so it’s clear the change came from an AI assistant rather than the app.

The flow is fully automatic:

1. When your AI client connects for the first time, your browser will open automatically
2. If you are already logged in to Coalesce Quality, the consent screen appears directly. Otherwise, you will be asked to log in first.
3. Select the permission level you want to grant (see Permissions below)
4. Click Approve to authorize

All actions performed through MCP are tracked as done on behalf of the authenticated user, and carry a via MCP marker so the audit trail distinguishes AI-driven actions from ones performed directly in the app.

Static tokens (legacy)

Long-lived workspace tokens (prefixed st-…) created under Settings → API still work with the MCP server — pass one as a Bearer token in the Authorization header of the MCP connection. Use this only when OAuth is not an option (for example, headless automation without a real user, or when user API access is disabled for the workspace).

We recommend OAuth for all interactive AI clients: actions are attributed to the real user rather than to a shared service identity, tokens can be revoked per-user, and the scopes granted match what that user’s role already allows.

Permissions

During authorization, you choose what level of access to grant. The available permission scopes on the consent screen are determined by your user role in the workspace — you will only see options that your role allows.

Permission	What it allows
Read-only access	Search and browse entities, browse the folder hierarchy, resolve ResolverQL selections to entities, view schemas and lineage, inspect issues and incidents, review execution history, query data, and profile columns, list existing monitors and SQL tests, review how checks are categorised, browse data products, domains, owners, and saved views, and report how much of the catalog those data products and owners cover. No changes are made.
Write access	Everything in read-only, plus acting on your behalf — manage issues, declare and close incidents, add comments, and manage your own saved views.
Governance access	Manage the governance surface — create, edit, and delete data products, domains and their hierarchy, owners, their notification channels, the alert routing for owned assets, and the rules that categorise checks. This is independent of Write, not a superset — grant it when the assistant should manage the catalog and alert routing without touching issues or incidents.
Deploy access	Put data quality checks into production — create, configure, and delete monitors, table-stats monitors, SQL tests, and query-based deployment rules (including listing and previewing rules), and promote reconciliation suites so they run on a schedule or via the API. This is independent of Write, not a superset — grant it when the assistant should manage checks without touching issues or incidents.

A permission grants what the application asked for within it, not every capability listed above. The consent screen shows those permissions grouped by tier — read them before approving, and untick any group you would rather withhold. An application that asks for nothing in particular is offered the whole tier instead, so grant the narrowest one that covers what you want the assistant to do.

The set of MCP tools available to your AI assistant depends on the permissions you grant during authorization. For example, if you only grant read-only access, tools that modify data (like managing issues or deploying monitors) will not be available.

Disabling User API Access

Workspace admins can prevent users from authorizing third-party applications (including MCP clients) to access the Coalesce Quality API via OAuth. The toggle lives in Settings → Workspace and can be flipped on or off at any time by a user with the admin role — individual users do not need to take any action when the setting changes.

While this is enabled:

• New OAuth consent attempts from MCP clients are rejected with an explanatory message on the consent screen.
• Existing OAuth tokens issued to users stop working.
• Workspace-provisioned long-lived tokens (st-…) and client credentials continue to work — use those if you need programmatic access in this mode.

Turning the setting back off immediately restores the OAuth path; users will need to re-authorize their MCP client the next time it connects.

Coalesce Quality MCP Tools

Once connected, your AI assistant has access to a wide range of tools for working with your data infrastructure. The tables below group them by purpose.

Session and Identity

Tool	Description
iam	Report the authenticated caller’s identity — workspace, granted permission scopes, and the associated Coalesce Quality user. Useful for confirming which workspace and access level a session has
list_users	List workspace members with an optional name/email filter — used to find the exact email for incident ownership

Discovery and Search

Tool	Description
search_entities	Search for entities by name, description, and other metadata with optional filtering by entity types
sample_entities	Get entity count sampling by type for search queries to understand distribution before detailed searches
resolve_query	Compile and evaluate a ResolverQL selection (via describe_resolver_ql) and return the matched entity ids, paginated — the general author → resolve → refine loop
list_annotations	List all available annotations with their usage counts across entities — the workspace’s vocabulary, and where to start when you do not know it yet
batch_entity_annotations	Read the annotations specific entities carry, up to 1000 entities in one call. Annotations do not come back on get_entity_details or batch_entity_details: what an entity carries is a separate read from what an entity is

Core Entity Operations

Tool	Description
get_entity_details	Retrieve detailed information about a specific data entity including properties, metadata, current state, and the folder breadcrumb(s) it lives in
batch_entity_details	Get details for multiple entities simultaneously (including folder breadcrumbs) - more efficient than multiple individual calls
get_schema	Retrieve schema definition including column names, types, and constraints for table-like entities
get_database_coordinates_from_entity	Retrieve physical DWH coordinates (dialect, connection, instance, database, schema, object) for table entities
get_entity_from_database_coordinates	Map SQL table references (fully/partially/unqualified) to Coalesce Quality entity IDs
get_code	Access the latest version of source code that defines or implements data entities (SQL definitions, dbt models, etc.)

Folder Navigation

Browse the catalog’s folder / containment hierarchy — the roots data hangs from, the sub-folders under any folder, the folder(s) an entity lives in, and the entities inside a folder. Read-only; membership is shallow by default (one level per browse, direct members only) — set deep=true or browse sub-folders in turn to recurse. Use these to discover the real folder ids that ResolverQL’s in_folder(...) operand needs.

Tool	Description
browse_folders	Browse one level of the hierarchy: the roots (no argument) or a folder’s direct sub-folders and direct members
folder_of	Return the folder breadcrumb(s) each given entity lives in — pair with list_folder_members on the immediate parent to list siblings
list_folder_members	List the entity ids contained in a folder, paginated; deep=true includes nested sub-folders, types narrows by entity type

Data Lineage Analysis

The same graph the lineage view draws, including column-level lineage where the warehouse supports it.

Comprehensive Lineage

Tool	Description
get_lineage	Advanced dependency analysis with directional control (upstream, downstream, or both) and configurable depth

Upstream Analysis

Tool	Description
get_upstream_dependencies	Find all upstream dependencies with configurable traversal distance
get_immediate_upstream_dependencies	Find only direct upstream dependencies for quick analysis
get_upstream_sources	Trace data lineage to find original data sources (dbt sources, SQLMesh external models, Coalesce sources)

Downstream Analysis

Tool	Description
get_downstream_dependencies	Find all downstream dependencies with configurable traversal distance
get_immediate_downstream_dependencies	Find only direct downstream dependencies for quick analysis

Cross-Entity Analysis

Tool	Description
get_common_upstream_dependencies	Find shared dependencies between two entities using connected components analysis

Orchestration

Tool	Description
get_orchestration	Get orchestration relationships for entities - shows what orchestrates them (upstream) and what they orchestrate (downstream)

Issue and Incident Management

The read side of the workflow Incidents describes. The tools that change an issue or an incident are under Write Actions.

Tool	Description
list_open_issues	List all open issues currently requiring attention with optional entity filtering
list_open_incidents	List all currently open incidents that need attention or resolution with optional entity filtering
get_issue	Return the core issue record for a specific issue ID (status, severity, trigger entity)
get_issue_details	Return the issue record plus the first page of comments and — for monitor-triggered issues — the monitor configuration and schema of the monitored entity. Prefer this over get_issue when you need context to reason about the issue
get_issue_comments	Get comments and discussions on issues if available
get_incident_details	Retrieve detailed information about a specific incident by ID, including attached issues, state, and comment timeline
list_history	Find historical incidents and issues to identify patterns and recurring problems

Impact Analysis

Tool	Description
get_entity_impact	Get impact analysis showing all entities and systems affected if there was an issue on the entity
get_issue_impact	Get impact analysis showing all entities and systems affected by a specific issue

Data Quality and Monitoring

The read side of a workspace’s checks. Monitors overview covers the monitor types and SQL tests the tests; creating and changing them is under Managing Monitors and Tests.

Tool	Description
list_checks	Retrieve all data quality checks configured for a specific entity (direct and inherited). Set include_segments to also list a segmented monitor’s per-segment checks — left out by default because one monitor segmented by a column stands behind a check per distinct value, often hundreds
get_monitor	Retrieve detailed information about a specific monitor including configuration and status
get_monitor_predictions	Return recent model predictions for a monitor with expected vs actual values and confidence bands — useful for diagnosing miscalibrated anomaly detection. Accepts a monitor’s entity id, one of its segments’ ids, or the monitor’s own id as list_monitors reports it
list_monitor_segments	List the segments a monitor is split into — each segment’s raw value, the label it is shown under, and its check id. A monitor segmented by an id or a code is unreadable without this: the value is what the prediction and label tools filter on, and the label is what every other surface displays
get_entity_metrics	Return raw metric timeseries (row counts, freshness, etc.) for an entity; resolves logical assets (e.g., dbt models) to their underlying physical tables
list_monitors	List custom monitors, optionally filtered by asset, config, ids, or a name substring
list_sql_tests	List SQL tests, optionally filtered by asset, config, or ids
list_table_stats_monitors	List table-stats monitors, optionally filtered by asset or ids

Executions

Tool	Description
get_latest_executions	Get the most recent execution for each specified entity (monitors, dbt models, airflow tasks, etc.)
list_executions	List execution history for specific entities with filtering by time range, status, and execution type
batch_executions	Get detailed information for specific executions by their IDs
summarise_executions	Get aggregated execution statistics - counts by type and status, time ranges, and latest execution per entity

SQL Generation for Data Analysis

These tools generate the SQL that Coalesce Quality would run to analyse data, but the MCP server does not execute queries against your warehouse. The response includes the full executedSql — run it yourself (or let your AI client run it through a separate warehouse connection) to get actual results. This keeps your data inside your own warehouse and avoids giving the MCP server any standing database credentials.

Tool	Description
execute_monitor	Generate the SQL a monitor would run, including any extra segmentation, WHERE clauses, or time filters you pass in. Similar in spirit to get_code but for the check SQL — get_code returns the asset’s definition, execute_monitor returns the query the monitor executes against that asset
profile_columns	Generate SQL that computes statistics for specific columns (supports String, Numeric, and Time types)
sample_column_values	Generate SQL that returns the frequency distribution of values for specific columns, with optional time-based filtering

Change Tracking and History

Database Changes

Tool	Description
list_database_changes	Retrieve history of schema and SQL definition changes for specific entities
get_database_change_details	Return full change details for specific change IDs

Git Integration

Tool	Description
list_commits	List commits that affect a specific entity, providing git history and change information
get_commit_diff	Retrieve exact diff content of specific commit changes with optional path filtering

Write Actions

The tools in this section modify workspace data and require Write access (for issue/incident actions) during OAuth consent. If the user granted only read-only access, these tools will not appear in the client.

Tool	Required scope	Description
set_issue_status	Write	Set the status of a single issue (e.g., mark as expected behaviour, fixed upstream, no action needed). An optional note is posted as a comment to preserve the audit trail
add_comment	Write	Post a Markdown comment on an issue or incident, attributed to the authenticated user
create_incident	Write	Create a new incident grouping one or more related issues under a shared name for coordinated investigation
update_incident	Write	Edit an existing incident — rename, change state, reassign owner, or attach/detach issues in a single call

Managing Monitors and Tests

These tools create and change data quality checks — monitors, table-stats monitors, and SQL tests all require Deploy access. Start with describe_check_types (available without any granted scope) to pick the right check type for a goal. Setting up monitors and SQL tests describe the same checks as the app builds them; defining monitors in code is the third way, for checks you want under version control.

Two safeguards apply to every write here:

• Full replace, not patch. update_* tools replace the whole object — fetch the current definition with the matching list_* tool, apply your edits, and send the complete object. Omitted fields are cleared.
• Confirmation-gated changes. A change that would reset a check’s baseline (retrain anomaly detection / re-run a test) or overwrite a check owned by the app UI or a YAML config is not applied on the first call. The tool reports what needs approval; re-call only after the user explicitly confirms. The assistant never self-confirms.

Tool	Required scope	Description
describe_check_types	None	Return the catalog of check types the server can create (custom monitors, SQL tests, table-stats monitors) with guidance on which fits a given data-quality goal, down to the sub-type level. A static reference — available in any session regardless of granted scopes
create_monitors	Deploy	Create one or more custom monitors — anomaly, freshness, volume, field-stats, category distribution, and more. Ids are deterministic, so identical re-runs are idempotent
update_monitors	Deploy	Update custom monitors by id (full replace)
delete_monitors	Deploy	Delete custom monitors by id
set_monitor_segment_labels	Deploy	Give a monitor’s segments human-readable names. The label replaces the raw value wherever the segment appears — its check, its search result, and the alerts it raises — so a monitor segmented by an opaque id becomes readable without changing what it monitors. Segments are addressed by the value that list_monitor_segments reports
create_table_stats_monitor	Deploy	Create and deploy a table-stats monitor (row count, load delay) on a single warehouse table in one step, reading cheap warehouse metadata rather than querying the table each run
update_table_stats_monitor	Deploy	Update a table-stats monitor by id and redeploy (full replace of the metric set)
delete_table_stats_monitor	Deploy	Disable table-stats monitoring for the given asset paths
create_sql_tests	Deploy	Create one or more SQL tests from a template (not-null, unique, accepted/rejected values, relationships, freshness, min/max, business rules, etc.) or a raw SQL expression
update_sql_tests	Deploy	Update SQL tests by id (full replace)
delete_sql_tests	Deploy	Delete SQL tests by id

Deployment Rules

Deployment rules deploy monitors automatically to every asset matching a ResolverQL selection query, rather than to a fixed list of paths — the same rules Setting up deployment rules describes in the app. All of these tools — listing, previewing, deploying, and deleting rules — require Deploy access. Call describe_resolver_ql for the query grammar, preview_deployment_rule to see the exact impact, and only then deploy_deployment_rule — the deploy and delete tools are confirmation-gated and never self-confirmed.

Tool	Required scope	Description
describe_resolver_ql	None	Return a reference for authoring ResolverQL selection queries — syntax, the common functions and asset-type names, worked recipes, and the metric / sensitivity / severity enums. A static reference — available in any session regardless of granted scopes
list_deployment_rules	Deploy	List query-based deployment rules
get_deployment_rule	Deploy	Return one rule by id with its full settings and the canonical ResolverQL selection string
preview_deployment_rule	Deploy	Resolve a rule’s query and return the monitors that would be created, deleted, or kept if it were deployed now, plus assets skipped — side-effect-free, and doubles as query validation
deploy_deployment_rule	Deploy	Create or update a rule and materialize its monitors. Gated: preview first, then re-call with confirmation after the user approves
delete_deployment_rule	Deploy	Delete a rule and the monitors it owns. Gated the same way as deploy

SQL Test Deployment Rules

The same query-based deployment, applied to SQL tests: a rule carries a set of tests, a ResolverQL selection, a schedule and a severity, and deploys those tests onto every table or view the selection matches — including tables that only start matching later. SQL tests covers the tests themselves.

Reading the rules needs Read-only access — unlike the monitor rules above, listing and previewing these does not take Deploy. Deploying and deleting do. The write pair is gated exactly as the monitor rules are: preview, surface the impact, and re-call with confirmation once the user approves. Overwriting a rule authored in the app or by a YAML config takes a second, separate confirmation.

Two things decide which rule a call addresses and what it deploys:

• The title is the identity. A spec reusing a live rule’s title updates that rule; a new title mints a new one. Pass an existing id only to rename a rule, or to edit one under a YAML config’s namespace — and pass the same id to preview and to deploy, or the two calls address different rules.
• A test naming a column the matched table does not have fails on that table. Select on the column (with_columns("email")) rather than deploying broadly. Views match as readily as tables, since a SQL test is a plain SELECT — restrict with with_type("table") when you mean tables only.

Tool	Required scope	Description
list_sql_test_deployment_rules	Read	List SQL test deployment rules with the number of tests each currently has deployed — where the rule id the other four need comes from
get_sql_test_deployment_rule	Read	Return one rule by id with the tests it deploys, its selection, schedule and severity
preview_sql_test_deployment_rule	Read	Resolve the rule’s selection and return the tests that would be created, updated, deleted or kept, plus the tables it matched but had to skip. Side-effect-free, and doubles as validation — a malformed selection is rejected here with the parse message
deploy_sql_test_deployment_rule	Deploy	Create or update a rule and deploy its tests. Gated: the first call applies nothing and reports the impact, including the tests it would delete. By default a table that stops matching loses its tests and their run history
delete_sql_test_deployment_rule	Deploy	Delete a rule and the tests it deployed. Gated the same way, and the unconfirmed call names the tests that would go

Check Categorisation

Every check carries one category per dimension — governance (what the check is for: completeness, accuracy, timeliness) and technical (what it does mechanically: nullness, uniqueness, freshness). The category comes from a per-check override, from the producer that declared it, or from a categorisation rule, in that order of precedence. Check categories describes the feature itself; these tools drive the same rules and overrides the Health → Check categorisation screens do.

Start with describe_check_categorisation (available without any granted scope) for the resolution order, the matcher grammar, and the authoring loop. Reading categories and rules needs Read-only access; the three writes need Governance access — a rule applies to every check matching it today and every check ingested afterwards, the same blast radius as restructuring the catalog.

A rule’s matcher is the same predicate the app builds: either a structured predicate over the check’s platform, asset type, package, kind, name patterns and annotations, or a CEL expression, never both.

The writes are confirmation-gated: the first call reports the impact and applies nothing, and the assistant never self-confirms. A save that would move checks off the category they already carry, or an override that replaces one somebody else set, needs a second explicit overwrite confirmation. Global rules cannot be edited or deleted — every workspace rule is tried before every global rule whatever the priorities are, so the way to change what one does is a workspace rule that matches.

Tool	Required scope	Description
describe_check_categorisation	None	Return a reference for check categorisation — the two dimensions, the three sources a category comes from and their precedence, the order rules are tried in, the matcher grammar, and the authoring loop. A static reference — available in any session regardless of granted scopes
list_check_categories	Read	Return the workspace’s category vocabulary per dimension: which names are in use, how many checks carry each, whether a workspace or global rule produces it, and how many checks are still uncategorised. Optionally returns the platform, asset type, package and kind values the workspace’s checks actually carry — the values a matcher can be built from
list_categorised_checks	Read	List checks with the category each resolves to on both dimensions, filtered by category, by the rule that produced it, by whether the category came from an override, or by “uncategorised”. This is where the entity id for set_check_category comes from
list_check_categorisation_rules	Read	List the rules that apply to the workspace — its own plus the global defaults — in the order they are tried, with how many checks each currently categorises and the state of the recategorisation sweep
preview_check_categorisation_rule	Read	Report what a candidate rule would change without saving it, resolved against the live rule set so scope, priority, overrides and producer-declared categories are all honoured. Side-effect-free, and doubles as matcher validation — a matcher that does not compile is rejected here with the compiler’s message
save_check_categorisation_rule	Governance	Create or update a workspace rule and schedule the recategorisation sweep over the checks that already exist. Gated: preview first, then re-call with confirmation after the user approves
delete_check_categorisation_rule	Governance	Delete a workspace rule — the checks it categorised fall back to the next rule that matches, or become uncategorised. Gated, and the unconfirmed call reports how many checks depend on the rule
set_check_category	Governance	Set or clear the per-check override on specific checks, per dimension. An override outranks the producer’s value and every rule and survives later rule changes, so use it for genuine exceptions and a rule for anything that generalises. Gated

Data Products

Data products are named, owned groupings of assets defined by a membership query (authored as ResolverQL, via describe_resolver_ql) or pinned asset ids. Data products overview describes what they are for.

The save_data_product and delete_data_product tools require Governance access during OAuth consent. They are confirmation-gated: the first call reports what would change and never self-confirms — re-call only after the user approves. A product managed by an external source (e.g. Atlan) additionally requires an explicit overwrite confirmation.

Tool	Required scope	Description
list_data_products	Read	List data products in the workspace, paginated, with per-priority and per-source breakdowns. Definitions omitted by default
get_data_product	Read	Fetch one or more data products by id with full detail, including the membership definition rendered as ResolverQL
list_data_product_members	Read	Resolve a data product’s membership and return the entity ids of the assets that currently belong to it
save_data_product	Governance	Create or update a data product and, in the same call, replace its membership definition. Gated
delete_data_product	Governance	Delete a data product (soft-delete by default; optional purge). Gated

Domains

Domains are named areas of ownership that group the assets, data products and sub-domains belonging to one part of the business — see Domains. They nest: a domain can sit under a parent, and a parent’s membership includes everything its sub-domains contain. Walk the hierarchy with list_domains — omit parent_id for every domain at any level, pass a domain id for that domain’s direct children, or pass an empty string for top-level domains only.

Membership is a list of parts combined with OR: a pinned asset, a whole data product, a whole other domain, or a ResolverQL selection query. Unlike a data product, a domain is not a leaf — it can reference other domains and data products, and membership is resolved recursively. A write that would make those references form a loop is rejected and names the offending path.

The save_domain and delete_domain tools require Governance access during OAuth consent. They are confirmation-gated: the first call reports what would change and never self-confirms — re-call only after the user approves. A domain managed by an external source (e.g. Atlan) additionally requires an explicit overwrite confirmation.

delete_domain reports how many direct sub-domains the domain has before anything is deleted, because the two delete modes differ: a soft delete leaves those sub-domains in place, parented to a deleted domain, while a purge is refused while any of them still exist.

Tool	Required scope	Description
list_domains	Read	List domains in the workspace, paginated, with a per-source breakdown and top-level / sub-domain counts. Filter by parent_id to walk the hierarchy. Membership definitions are not included
get_domain	Read	Fetch one or more domains by id with full detail, including the membership definition with query parts rendered as ResolverQL
list_domain_members	Read	Resolve a domain’s membership and return the entity ids of the assets that currently belong to it — including everything contributed by the data products, domains and sub-domains it references
save_domain	Governance	Create or update a domain, set or clear its parent, and replace its membership definition in the same call. Gated
delete_domain	Governance	Delete a domain (soft-delete by default; optional purge). Gated

Owners and Ownership

Owners are named responsible parties with notification channels (contacts); ownerships assign assets to an owner and configure the alerts routed there. This is the “alert routing as code” surface — Ownership overview and Routing alerts describe the same model in the app.

The save_owner and delete_owner tools require Governance access. save_owner is a single use-case call that upserts the owner and its ownerships together. Both are confirmation-gated and never self-confirmed; overwriting an external-source (e.g. Atlan) owner requires an explicit overwrite confirmation.

Tool	Required scope	Description
list_owners	Read	List owners with contact counts (and, optionally, ownership counts)
get_owner	Read	Fetch one or more owners by id with their contacts and ownerships (assigned assets + alert config)
list_ownerships	Read	List ownerships — all of one owner, or a specific set by id — showing each asset selection and alert configuration
save_owner	Governance	Create or update an owner and upsert its ownerships (owner + ownerships in one call). Gated
delete_owner	Governance	Delete an owner and all its ownerships, or just one ownership when an ownership id is given. Gated

Coverage

Data products and owners both answer “who is this for” and “who is responsible”, and coverage is the question of how much of the catalog they actually reach. These three read tools answer it without enumerating every product and every owner first: what claims one asset, how much of a selection is claimed, and which assets are not.

Start with get_coverage_summary. It takes up to twenty named selections in one call, lists nothing, and answers most coverage questions outright. Reach for list_entity_coverage only to name specific assets — and when the gap is large, narrow the selection rather than paging it. A selection per schema, folder or asset type tells you where the gap sits; a thousand rows of asset ids does not.

Choose the candidate types deliberately — they decide whether the answer means anything. Data products group what is delivered, so a product-coverage question asks about tables, views and models; left unrestricted the answer is mostly monitors, tests and recon cases, which belong to no product by design. Owner coverage is the opposite: a check usually should have somebody responsible, so include those types when asking about owners.

Tool	Required scope	Description
get_coverage_summary	Read	Count coverage over up to 20 named ResolverQL selections in one call — how many candidates are in a data product, how many have an owner, how many have both, and how many have neither. Lists no assets, so it stays cheap on a whole workspace
list_entity_coverage	Read	Name the assets behind a coverage number: of the assets a selection matches, which are in no data product and which have nobody responsible. Filter by coverage state, paginated, with the owners and data products claiming each row resolved to their names
get_entity_overlays	Read	Map entity ids you already hold to the owners and data products claiming each. The companion to get_entity_details — it turns “this table is failing” into “these teams hear about it, it feeds these products” without a catalog-wide scan

A few things worth knowing when reading the numbers back:

• The counts overlap rather than partition. An asset in a product and with an owner is counted under in-a-product, under has-an-owner, and under both. Only “claimed by nothing” is disjoint from the rest.
• Selections overlap too, so never add rows together for a workspace total. A workspace-wide selection beside the per-type breakdowns inside it is the recommended shape, and summing those rows counts the same asset several times. Ask for the total as its own selection.
• Membership is recomputed periodically, and every answer says when. members_computed_at is the start of the most recent successful recomputation pass, so it stops advancing as soon as that recomputation stops succeeding — quote it beside any finding. Ask for live freshness when the answer has to reflect a change made moments ago; it is exact as of the call and costs more, because it re-resolves the whole catalog rather than the selection.
• Membership follows identity. Where one table appears twice in the catalog — a transformation model and the warehouse table it builds — an overlay matching one claims the other, so ask about whichever representation you have.
• get_entity_overlays reports back on whatever ids you give it. An id that names no entity comes back claimed by nothing, exactly like a real asset nobody owns. If the ids were assembled by hand rather than taken from another tool’s response, confirm them with batch_entity_details before reporting a gap.

Saved Views

Saved views are named, reusable selections over entities (or the checks / issues screens) with display configuration, sharing, and per-user pinning. Selections are authored as ResolverQL (via describe_resolver_ql).

save_saved_view and delete_saved_view require Write access (saved views are largely a per-user surface). set_saved_view_pin is available on read access — pinning is a per-user preference and changes nothing about the view. save_saved_view is confirmation-gated; editing a view you do not own, or changing its visibility / grants, requires an explicit overwrite confirmation.

Tool	Required scope	Description
list_saved_views	Read	List the saved views you can see, with a per-relationship (mine / shared / granted) breakdown
get_saved_view	Read	Fetch one or more saved views by id with the selection (rendered as ResolverQL), sharing, grants, your permissions, and pin state
set_saved_view_pin	Read	Pin or unpin a saved view to your own main screen (per-user preference)
save_saved_view	Write	Create or update a saved view. Gated
delete_saved_view	Write	Delete a saved view. Gated

Utilities

Tool	Description
batch_urls	Generate Coalesce Quality application URLs for multiple entities and issues for easy navigation
submit_feature_request	Submit a feature request or product feedback to the Coalesce Quality team from your AI assistant