MCP - Coalesce Quality Documentation

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:

Getting Started

MCP needs no setup in the workspace. Add the server to your AI client and sign in.

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`

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

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.

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.

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).

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 the Coalesce Quality tools.

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.

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. You do not paste API keys or tokens anywhere. Every action the assistant takes is recorded as yours, with a via MCP badge, so the audit trail shows which changes came from an AI assistant. The flow:

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

OAuth consent screen showing permission options

Static tokens (legacy)

The MCP server also accepts long-lived workspace tokens (prefixed st-…) created under Settings → API. Pass the token as a Bearer token in the Authorization header of the MCP connection. Use a token only when OAuth is not possible, for example for automation that runs without a user, or when user API access is disabled for the workspace. For interactive AI clients, use OAuth. Actions are recorded as the real user instead of a shared identity, each user can revoke their own access, and the user’s role limits what they can grant.

Permissions

During authorization, you choose what access to grant. The consent screen offers only what your user role allows.

Permission	What it allows
Read-only access	Browse assets, lineage, issues, monitors and tests, see who uses a table, query and profile data, and see what Coalesce Quality recommends changing in the workspace setup and which integrations are failing. No changes are made.
Make changes on your behalf (Write)	Everything in read-only access, plus manage issues, incidents, alerts and your own saved views, add comments, and dismiss or ignore recommendations.
Manage governance (Governance)	Manage data products, domains, owners, alert routing, check categories and service accounts. It does not include Write. Grant it when the assistant should manage the catalog but not issues or incidents.
Deploy and manage data quality checks (Deploy)	Create and change monitors, SQL tests, deployment rules and monitoring exclusions, and promote reconciliation suites. It does not include Write. Grant it when the assistant should manage checks but not issues or incidents.

The tool tables below use the short names in brackets (Read, Write, Governance, Deploy) in the Required scope column. Every tier also includes read-only access.

If the application asks for specific scopes, each tier grants only the scopes it asked for in that tier. The consent screen lists them per tier. Read them before you approve, and untick a tier you do not want to grant. If the application asks for no specific scopes, each tier grants everything in it, so select only the tiers the assistant needs.

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 stop users from giving third-party applications, MCP clients included, OAuth access to the Coalesce Quality API. The setting is Disable user API access in Settings → Workspace. A user with the Admin role can turn it on or off at any time.

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.
Long-lived workspace tokens (st-…) and client credentials still work. Use them for programmatic access while the setting is on.

When you turn the setting off, OAuth works again. Users must authorize their MCP client again the next time it connects.

Coalesce Quality MCP Tools

The tables below list the tools your AI assistant gets, grouped by purpose. A session sees only the tools that the granted permissions allow.

Session and Identity

Tool	Description
`iam`	Report the authenticated caller’s identity: the workspace, the granted permission scopes and the Coalesce Quality user. Use it to confirm which workspace and access level a session has
`list_users`	List workspace members, with an optional name or email filter. Use it to find the exact email for an incident owner

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 (see `describe_resolver_ql`) and return the matched entity ids, paginated. Use it to write, test and refine a selection
`list_annotations`	List all annotations used in the workspace, with how many entities carry each. Start here when you do not know the workspace’s annotations
`batch_entity_annotations`	Read the annotations of specific entities, up to 1000 entities in one call. `get_entity_details` and `batch_entity_details` do not return annotations

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_join_patterns`	Show how other tables join a table. Each pattern is a join key found in the SQL of the workspace’s tables, views and models, or in the warehouse query history of the last 30 days. A pattern says where it was seen, which join types use it, its query and user counts, and who ran it (a tool such as Looker or Sigma, a dashboard or model, or people). It also says if the join can return more rows than the table has. Each table in the result comes with its SQL name, row count and unique keys. Filter by one column or one other table to get fewer patterns. Set the number of days of query history to read, or 0 for none
`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.)
`get_entity_knowledge`	Read the description your team wrote for a batch of entities and the knowledge pages pinned to them. Names the entities with no knowledge
`list_knowledge_pages`	List your workspace’s knowledge pages by name, including the many pinned to no entity, optionally narrowed by name or to certified pages
`get_knowledge_pages`	Read knowledge pages: their content, where they sit in the page tree, who owns them, and the entities and pages pinned to them

The three knowledge tools appear only when the workspace is linked to a Coalesce Catalog account. Browse the catalog’s folder hierarchy: the root folders, the sub-folders of a folder, the folders an entity is in, and the entities in a folder. These tools are read-only. By default a call returns one level, with direct members only. Set deep=true, or browse the sub-folders one by one, to go deeper. Use these tools to find the folder ids that the ResolverQL 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 breadcrumbs of each given entity. To list its siblings, call `list_folder_members` on the parent folder
`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

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 and the first page of comments. For an issue raised by a monitor, it also returns the monitor configuration and the 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 the checks of each segment of a segmented monitor. They are left out by default, as a monitor segmented by a column has one 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 and actual values and confidence bands. Use it to find out why anomaly detection is wrongly calibrated. 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 of a monitor, with each segment’s raw value, its display label and its check id. The prediction and label tools filter on the raw value. The app and alerts show the label
`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 its own warehouse connection, to get the results. Your data stays in your warehouse, and the MCP server holds no 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. `get_code` returns the asset’s definition, and `execute_monitor` returns the query that the monitor runs against the 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

Workspace Setup

What needs attention in how the workspace is set up: the changes Coalesce Quality recommends, such as a grant an integration’s role is missing or a setting that stopped matching what runs, and the integrations that are failing.

Tool	Required scope	Description
`list_recommendations`	Read	List the recommendations still open, each with what was found, what to change and where, and the integration it is about. Optionally include the dismissed and ignored ones, with who decided and why
`decide_recommendation`	Write	Dismiss a recommendation until something new is found about it, ignore it for good, or restore it, with the reason in your words. The decision applies to the whole workspace
`list_integration_health`	Read	List the enabled integrations that are not healthy, the worst first, with the status of the last run, when one last succeeded and its message

Deciding about a recommendation on an integration also needs permission to edit integrations.

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 in one call: rename it, change its state, change its owner, or attach and detach issues

Managing Monitors and Tests

These tools create and change monitors, table-stats monitors and SQL tests. They need Deploy access. Start with describe_check_types, which needs no granted scope, to pick the right check type for a goal. Setting up monitors and SQL tests describe the same checks in the app. To keep checks under version control, see defining monitors in code.update_sql_tests takes a patch. Send the test’s id and only the fields to change, and the other fields keep their values. update_monitors and update_table_stats_monitor replace the whole object. Get the current definition with the matching list_* tool, make your edits, and send the complete object. Fields you leave out are cleared.Some changes need the user’s confirmation: a change that resets a check’s baseline (retrains anomaly detection or runs a test again), and a change to a check that the app or a YAML config owns. The first call does not apply such a change. It reports what needs approval. The assistant calls again only after the user confirms, and never confirms on its own.

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 every session whatever scopes were granted
`create_monitors`	Deploy	Create one or more custom monitors, for example anomaly, freshness, volume, field-stats and category distribution monitors. 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 in the segment’s check, its search result and its alerts. What the monitor checks does not change. 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)
`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 as a patch: only the fields you send change. Reports per test which updates landed and why any did not. A test deployed by a SQL test deployment rule is refused; change the rule instead
`delete_sql_tests`	Deploy	Delete SQL tests by id

Deployment Rules

A deployment rule deploys monitors to every asset that a ResolverQL selection query matches. These are the same rules that Setting up deployment rules describes in the app. All of these tools need Deploy access, except describe_resolver_ql. Call describe_resolver_ql for the query grammar, then preview_deployment_rule to see the impact, and only then deploy_deployment_rule. The deploy and delete tools need the user’s confirmation, and the assistant never confirms on its own.

Tool	Required scope	Description
`describe_resolver_ql`	None	Return a reference for writing ResolverQL selection queries: the syntax, the common functions and asset type names, worked examples, and the metric, sensitivity and severity values. A static reference, available in every session whatever scopes were granted
`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 the assets it skipped. It changes nothing, so you can also use it to validate a query
`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

Monitoring Exclusions

Turn automatic monitoring off, or back on, for specific assets while the deployment rules that select them stay as they are. Each asset gets its own exclusion, which wins over every rule selecting it, so a noisy table can be silenced without editing a broad rule that may own hundreds of monitors.

All three tools need Deploy access. They take assets as entity_ids: an entity id, or a dotted database.schema.table.Excluding is safe to repeat. Adding one more table leaves the existing exclusions untouched, and assets that were already excluded come back in their own list.exclude_from_monitoring and unexclude_from_monitoring are confirmation-gated. The first call applies nothing and lists the assets whose monitoring would change; the assistant re-calls only after the user approves, and never confirms on its own. Lifting an exclusion created in the app or by a YAML config takes a second, separate overwrite confirmation.To check the result, call list_monitoring_exclusions with the same entity_ids. The monitor counts on deployment rules stay the same when an exclusion lands, so they tell you nothing here.

Tool	Required scope	Description
`list_monitoring_exclusions`	Deploy	List what is not monitored and which rule turned it off. With no arguments it returns the workspace’s exclusions as the rules define them; with `entity_ids` it gives a verdict for each asset, including assets excluded by a broader selection
`exclude_from_monitoring`	Deploy	Stop automatic monitoring of the named assets, and report which of them had a live monitor. An asset with no monitor yet still gets an exclusion, so a rule that selects it later does not start monitoring it. Gated
`unexclude_from_monitoring`	Deploy	Lift the exclusions on the named assets, so the rules that already select them monitor them again. An asset listed in a shared exclusion rule is removed from that rule and the other assets stay. An exclusion written as a selection, rather than a list of assets, is left as it is and the response names the rule to edit. Gated

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, also tables that only start matching later. SQL tests covers the tests themselves.

Listing, reading and previewing these rules needs Read-only access. Deploying and deleting a rule needs Deploy access and the user’s confirmation, the same as for monitor deployment rules. To overwrite a rule made in the app or by a YAML config, the user must confirm a second time.Two things decide which rule a call addresses and what it deploys:

The title identifies the rule. A spec with the title of an existing rule updates that rule, and a new title creates a new rule. Pass an existing id only to rename a rule, or to edit a rule in a YAML config’s namespace. Then pass the same id to preview and to deploy, or the two calls address different rules.
A test that names a column fails on a matched table that does not have that column. Select on the column (with_columns("email")) instead of deploying broadly. Views match the same as tables, as a SQL test is a plain SELECT. Add with_type("table") to match tables only.

Tool	Required scope	Description
`list_sql_test_deployment_rules`	Read	List SQL test deployment rules, with the number of tests each rule has deployed. The other four tools need a rule id from this list
`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. It changes nothing, so you can also use it to validate a selection. A selection with an error is rejected 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 has one category in each of two dimensions: governance, what the check is for (completeness, accuracy, timeliness), and technical, what the check does (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, which needs no granted scope. It explains the resolution order, the matcher grammar and how to write a rule. Reading categories and rules needs Read-only access. The three writes need Governance access, as a rule applies to every check it matches, now and in the future.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. You cannot edit or delete a global rule. Workspace rules are always tried before global rules, whatever their priorities, so to change what a global rule does, add a workspace rule that matches the same checks.

Tool	Required scope	Description
`describe_check_categorisation`	None	Return a reference for check categorisation: the two dimensions, the three sources of a category and their precedence, the order in which rules are tried, the matcher grammar, and how to write a rule. A static reference, available in every session whatever scopes were granted
`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 of the workspace’s checks, which are the values a matcher can use
`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 rules and 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. It changes nothing, so you can also use it to validate a matcher. A matcher that does not compile is rejected 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 get their category from 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.

save_data_product and delete_data_product need Governance access. They need the user’s confirmation: the first call only reports what would change, and the assistant calls again after the user approves. A product managed by an external source, such as Atlan, needs a second, 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

A domain is a named area of ownership. It groups the assets, data products and sub-domains of one part of the business, see Domains. A domain can have a parent domain, and a parent’s membership includes everything in its sub-domains. Use list_domains to walk the hierarchy. Leave out parent_id to get all domains at all levels, pass a domain id to get its direct children, or pass an empty string to get only the top-level domains. 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. A domain can reference other domains and data products, and its membership is resolved recursively. A write that makes these references form a loop is rejected, and the error names the path of the loop.

save_domain and delete_domain need Governance access. They need the user’s confirmation: the first call only reports what would change, and the assistant calls again after the user approves. A domain managed by an external source, such as Atlan, needs a second, 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 in it, including the assets of 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

An owner is a named responsible party with notification channels (contacts). An ownership assigns assets to an owner and sets the alerts sent to that owner. 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 the ownerships of one owner, or specific ownerships by id, with 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

Alerts

Alerts are named rules that send a notification to a set of targets (Slack or Microsoft Teams channels, email recipients, an owner, a webhook) when something happens. An alert is one of three kinds: issues on the selected assets, schema changes on the selected assets, or incident state changes. Assets are selected with a ResolverQL query. Setting up alerts describes the same alerts in the app.

Reading alerts needs Read-only access; the four writes need Write access. All four writes are confirmation-gated: the first call changes nothing and reports what would happen, and the assistant re-calls only after the user approves, never confirming on its own.save_alert is a patch on update: a field you set is written, a field you leave out stays as it is, and targets replaces the whole list. Without an id, the alert’s fqn is the key, so a repeated call updates the same alert rather than creating a second one. The kind of an alert cannot change.

Tool	Required scope	Description
`list_alerts`	Read	List the workspace’s alerts, optionally filtered by kind, owner or name. Also says whether the incident-owner alert, which notifies each incident’s owner, is on
`get_alert`	Read	Fetch alerts by id or fqn with their full configuration: the asset selection, targets and kind settings
`send_test_alert`	Write	Send a test message to the given targets and report for each one whether the channel accepted it, so a wrong channel name or webhook shows up before the alert is relied on. Gated
`save_alert`	Write	Create or update an alert. Gated
`set_alert_enabled`	Write	Pause or resume an alert, or turn the workspace’s incident-owner alert on or off. Gated
`delete_alert`	Write	Delete an alert by id or fqn. Gated

Coverage

Coverage tells you how much of the catalog is in a data product or has an owner. These three read tools answer it without listing every product and owner first: what claims one asset, how much of a selection is claimed, and which assets are not claimed.

Start with get_coverage_summary. It takes up to twenty named selections in one call, returns only counts, and answers most coverage questions. Use list_entity_coverage only to name specific assets. When the gap is large, narrow the selection instead of paging through it. One selection per schema, folder or asset type shows where the gap is.Choose the candidate asset types with care. Data products group what is delivered, so for data product coverage, select tables, views and models. Without a type filter, most of the result is monitors, tests and reconciliation cases, which are never in a data product. For owner coverage, include checks, as a check usually should have an owner.

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. Use it with `get_entity_details` to find which teams hear about a failing table and which products it feeds, without a scan of the whole catalog

How to read the numbers:

The counts overlap. An asset that is in a data product and has an owner is counted under “in a product”, under “has an owner” and under “both”. Only “claimed by nothing” does not overlap with the others.
Selections can overlap too, so do not add rows together to get a workspace total. A common shape is one selection for the whole workspace and one per asset type. Adding those rows counts the same asset more than once. Ask for the total as its own selection.
Membership is recalculated at intervals, and every answer says when. members_computed_at says when membership was last calculated. Show it next to every finding. If the answer must include a change made a moment ago, ask for live freshness. It is exact at the time of the call, but costs more, as it resolves the whole catalog again.
Membership follows identity. If one table appears twice in the catalog, for example as a transformation model and as the warehouse table it builds, an overlay that matches one also claims the other. Ask about the one you have.
get_entity_overlays answers for every id you give it. An id that names no entity comes back as claimed by nothing, the same as a real asset that nobody owns. If you typed the ids yourself instead of taking them from another tool’s response, check them with batch_entity_details before you report a gap.

Usage and Popularity

These tools read your data platforms’ query history: how a table is used and by whom, and what a login, job, tool, service account or person reads, writes and costs.

Tool	Required scope	Description
`get_entity_access`	Read	Say how one entity is used over a time window: what loads, runs, builds and reads it, how popular it is compared with similar entities, who reads and writes it, and when in the day and week. The first tool to reach for on “how is this table used” or “what maintains this”
`get_query_activity`	Read	Say what one data platform login, job, tool, service account or person read, built and wrote over a time window, what its queries cost per compute and when it works. With none of them named, it answers where the workspace’s queries and compute go, per group of logins, and which entities are read most. Needs a role that can see service accounts: Analyst and up
`list_access_signals`	Read	List the entities that match one access pattern over a time window, for the whole workspace or a selection. The patterns are: built but never read (with what building it cost), not touched at all, read through a shared BI or app login so the viewer is unknown, and written outside its pipeline. Use it for cleanup and cost questions, such as which tables nobody reads. It names entities and tools, never a login

Service Accounts

A data platform login often acts for a tool (a BI tool, a scheduler, a transformation job) rather than for a person. Service accounts say which logins, or which of a login’s queries, belong to a tool, and person links name the person behind the rest. Together they decide whose reads count toward an entity’s popularity.

Reading service accounts needs Read-only access; planning and applying a change needs Governance access, because one matcher attaches every login that matches it, now and later. list_platform_users also needs the Developer or Admin role, since it shows every login on the connected platforms.The loop the assistant follows:

list_platform_users with unclassified_only to see the logins nothing classifies yet.
list_service_account_suggestions for the accounts the evidence points at, or write an account yourself. list_service_accounts shows what already applies.
plan_service_account_changes to see what the change set moves: every login whose reading changes, the reads it adds or removes from popularity, and the entities whose rank moves most.
apply_service_account_changes with the plan, only after the user confirms it.

A change to an existing account or person link is a patch: only the fields you set change, and matchers are added and removed by id, so the assistant can change one matcher without sending the others back. apply_service_account_changes without confirmed writes nothing and only returns the plan again. If the service accounts changed after the plan was made, apply is refused and the change has to be planned again.

Tool	Required scope	Description
`list_platform_users`	Read	List the workspace’s logins by their share of the workspace’s activity, highest first: how each one reads, the accounts it is in, and the evidence about it. Developer and Admin only
`list_service_accounts`	Read	List the workspace’s service accounts with their matchers, then the built-in ones, in the order they apply, and the person links
`list_service_account_suggestions`	Read	Suggest service accounts for the logins the evidence says are not a person, each as a change set `plan_service_account_changes` takes as it is. A suggestion changes nothing by itself
`plan_service_account_changes`	Governance	Report what a change set would change, without writing it
`apply_service_account_changes`	Governance	Write a planned change set, all of it or nothing. Gated: without `confirmed` it only returns the plan again. Applying a change set already in place answers applied, so a retry is safe

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 need Write access. set_saved_view_pin needs only read access, as a pin is a personal preference and does not change 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

​What is MCP?

​Getting Started

​Client Setup

​Authentication

​Static tokens (legacy)

​Permissions

​Disabling User API Access

​Coalesce Quality MCP Tools

​Session and Identity

​Discovery and Search

​Core Entity Operations

​Folder Navigation

​Data Lineage Analysis

​Issue and Incident Management

​Impact Analysis

​Data Quality and Monitoring

​Executions

​SQL Generation for Data Analysis

​Change Tracking and History

​Workspace Setup

​Write Actions

​Managing Monitors and Tests

​Deployment Rules

​Monitoring Exclusions

​SQL Test Deployment Rules

​Check Categorisation

​Data Products

​Domains

​Owners and Ownership

​Alerts

​Coverage

​Usage and Popularity

​Service Accounts

​Saved Views

​Utilities

What is MCP?

Getting Started

Client Setup

Authentication

Static tokens (legacy)

Permissions

Disabling User API Access

Coalesce Quality MCP Tools

Session and Identity

Discovery and Search

Core Entity Operations

Folder Navigation

Data Lineage Analysis

Issue and Incident Management

Impact Analysis

Data Quality and Monitoring

Executions

SQL Generation for Data Analysis

Change Tracking and History

Workspace Setup

Write Actions

Managing Monitors and Tests

Deployment Rules

Monitoring Exclusions

SQL Test Deployment Rules

Check Categorisation

Data Products

Domains

Owners and Ownership

Alerts

Coverage

Usage and Popularity

Service Accounts

Saved Views

Utilities