Skip to content

AgentQ in Action

Qualytics implements the Model Context Protocol (MCP) as a server that provides authorized access to shared data quality context and actions through tools. This page covers the endpoint, authentication, available capabilities, and example conversations so you can understand how AgentQ and external MCP clients interact with the Qualytics platform.

Info

AgentQ enforces limits on rate, tokens, timeouts, and query types to ensure fair usage and platform stability. See AgentQ Limits for full details.

Endpoint

The MCP service is available at your Qualytics instance URL:

https://your-qualytics-instance.qualytics.io/mcp

Authentication

The MCP service uses the same authentication mechanism as the Qualytics API. You'll need a Personal API Token (PAT) to authenticate requests. Include it in the Authorization header:

Authorization: Bearer YOUR_API_TOKEN

To generate a token, navigate to Settings > Tokens and click Generate Token. For detailed instructions, see Tokens.

Capabilities

This video shows one example completed from a single natural-language prompt. In the recorded scenario, AgentQ joins data from Databricks and BigQuery, aggregates monthly customer spending, and creates a quality check. AgentQ infers details such as join keys, rule types, and field mappings from the available context. Results depend on the data, permissions, prompt, provider, and model. Review the inferred details and created assets before using them.

Datastore Exploration

When you connect an AI assistant to Qualytics via MCP, it gains the ability to explore your data landscape and understand the structure of your datastores:

  • "What tables are in our sales database?"
  • "Show me the schema for the customer_orders table"
  • "What fields are available in the transactions container?"

Data Transformations

Create computed assets through conversation instead of manually configuring them in the UI:

  • Computed Tables: SQL queries stored and executed in the source database using its native dialect.
  • Computed Files: SQL transformations over file-based sources like S3, ADLS, or GCS.
  • Cross-Datastore Joins: Join data across supported systems, such as Snowflake and PostgreSQL or BigQuery and S3.
  • Computed Fields: Add derived or type-cast fields to existing containers using custom expressions.

Quality Check Management

Create and manage data quality checks through natural conversation:

  • "Make sure the email field in the customers table is never null"
  • "Add a check that order_total is always between 0 and 1,000,000"
  • "Verify that ship_date is always after order_date"

AgentQ can select a rule type and parameters from your request and the context available to it. Before relying on the check, confirm that its fields, conditions, filters, and other settings match the business expectation.

Inside a quality check or check template dialog, the embedded AgentQ assistant can turn a plain-language requirement into a proposal card. Select Apply to form to preview the suggested settings in the form, review the highlighted changes, and make any corrections. Nothing is written to the check or template until you save it yourself.

For how conversations in that panel are scoped to the item, see Conversations Inside the Check and Template Dialogs.

Proposal Cards

A proposal card appears once the assistant has finished replying, never while it is still writing. The card opens with a line reading Proposed in a check dialog, or Proposed template in a check template dialog, followed by the rule type it settled on. When the proposal includes a description, the next line shows that description condensed to a single line.

Below that, the card spells out the configuration, so you can weigh a proposal before it touches the form. Both kinds of card list the rule properties, the filter, the coverage, and the tags. A check card also lists the fields, the custom anomaly description, the owner, and the anomaly assignee. A template card also lists whether the template is Locked. Apply to form sits at the bottom right, under those details.

Only the settings the proposal names are listed, with two exceptions: coverage is shown only when the proposal sets it below 100%, and a long value such as a filter expression is shortened to fit. The card also never shows the table or file a check proposal targets, so check the container in the form after you apply.

Applying writes the values into the form and nothing else: no check, template, or setting is saved. The parts of the form the apply changed are outlined and tinted so you can see what moved. Rule properties are marked one input at a time; everything else is marked by section, so a change to the coverage outlines the whole Pass Criteria group. The form then scrolls the first changed part to the middle of the view, which matters when a change lands further down the form than you can see. The highlight pulses for about a second and a half and then stays on until you next put the cursor in the form, so it survives a scroll away and back.

You can apply the same proposal as many times as you like. The card does not change to an applied state afterwards, so nothing on it records that you already used it.

When you ask for a revision, the assistant produces a new card and the older ones step aside: every earlier card in that conversation dims, its button changes to Outdated and stops working, and hovering the button explains why with A newer proposal replaces this one. Only the newest proposal can be applied.

When Only Part of a Proposal Applies

A proposal can land in part. Anything the platform cannot honor is skipped, the rest is still written into the form, and most skipped pieces raise their own notification in the top right. Several can appear at once when a proposal trips more than one. There is no combined summary and no undo, and the notifications clear themselves after a few seconds, so read them before saving.

A few pieces are dropped quietly instead. On a check or template you are editing, a proposed rule type is ignored, and so is a proposed container on a check, because neither can change after the item is first saved.

Most of these belong to the check dialog. Because the assistant checks the container, the fields, the tags, and the people it names before it ever produces a card, the first four below appear only when something moved between the proposal and the apply, or when the proposal names a container in a datastore other than the one selected in the form. The last two are ordinary and expected.

Notification Where What it means
Proposed container skipped Check The table or file the assistant proposed is not in the datastore currently selected in the form. Only possible while authoring a new check.
Proposed fields skipped Check At least one proposed field is not on the container. None of the proposed fields are applied in that case, and the form keeps the fields it already had.
Some proposed tags skipped Check and template The proposal named tags that do not exist. Tags are not created for you. The tags that do match replace the tags already in the form rather than being added to them.
Proposed owner skipped / Proposed assignee skipped Check The person proposed as owner or default anomaly assignee is not eligible on that datastore.
Template-locked settings skipped Check The check is tied to a locked template, which enforces the rule properties, the filter, and the coverage. Everything else in the same proposal still applies, including the description, tags, and fields.
Field changes skipped Check The check is an asserted metric check, which keeps the field it was asserted on.

A template proposal has far less that can be turned away, because a template has no container, no fields, and no ownership. It carries the rule type and its properties, the filter, the coverage, the description, the tags, and whether the template is Locked.

Some proposals are refused outright, leaving the form untouched. Both report Cannot apply proposal, with the reason underneath:

  • The check or template is archived, so nothing can be applied to it. You can still open the assistant and discuss it.
  • The proposed rule type is not one the form offers. In a check dialog that means the rule type is not recognized; in a template dialog it means the rule type cannot be used for templates. This one only comes up while you are creating, since a saved check or template keeps the rule type it was created with. The rest of the proposal is not applied and no highlight appears, with one exception: while creating a check, a valid proposed container may already have been written into the form before the refusal.

Separately, an apply can fail part way through if the form cannot load what it needs to place a value. That one reports Could not apply proposal and asks you to try again. Unlike the two refusals above, it can leave part of the proposal already in the form, and it stops before anything is outlined or scrolled into view, so nothing marks what already landed. Check the form before you save or retry.

A proposal that could not be built in the first place behaves differently and never reaches this stage. If the assistant cannot find the container or field you named, or cannot resolve a person or a tag, no card appears at all: it tells you so in the conversation and, where more than one person matches a name, asks which you meant.

What the Co-Author Badge Records

Saving after you applied a proposal records the assistant as a co-author alongside you on that entry in the item's Timeline. It appears as a small badge on your avatar for that entry, and hovering it reads Co-authored by Check Assistant or Co-authored by Template Assistant, depending on which dialog you applied from. It marks that assistant values went into the form before this save, not that the assistant wrote what was saved, so the co-author stays on the record even if you reworked every value by hand afterwards. A partial apply is recorded the same way, as long as something was applied.

Two cases carry no co-author even though you selected Apply to form: an apply where every piece was skipped, and one that failed part way through with Could not apply proposal. In both, nothing was recorded as having reached the form.

Only that one save is marked. Your next save on the same check or template carries no co-author unless you apply another proposal first.

Drafting Controls from Regulatory Documents

AgentQ can help extract candidate requirements from regulatory publications such as BCBS 239 (Principles for effective risk data aggregation and risk reporting) and draft tagged quality checks for review. A qualified subject matter expert must determine whether a requirement applies, confirm that each check represents it correctly, and approve the control before use. Tags and descriptions can help preserve a reference to the source requirement, but they do not establish compliance on their own.

Anomaly Investigation

Investigate quality issues conversationally:

  • "Tell me about the anomalies found in yesterday's scan"
  • "What's wrong with anomaly 12345?"
  • "Explain the business impact of the data quality issues in the orders table"

Operations, Notifications, and Ticketing

Beyond analysis, AgentQ can take actions allowed by your Qualytics permissions. Review the tool steps and resulting platform changes, particularly for operations that affect shared assets or external systems.

  • Run operations: Trigger sync, profile, scan, export, or materialize operations and poll for completion.
  • Promote assets: Copy computed tables, computed files, computed fields, and quality checks across datastores from chat.
  • Send notifications: Post alerts to Slack, Microsoft Teams, Email, Webhook, or PagerDuty.
  • Create tickets: Open issues in Jira or ServiceNow, optionally linked to a specific anomaly.
  • Manage tags: Apply, remove, or replace tags on datastores, containers, fields, and quality checks. The global tag catalog (list, create, update, delete) is managed through separate tools (list_tags, describe_tag, create_tag, update_tag, delete_tag); catalog mutations require the Manager or Admin role.
  • Manage check templates: List, create, update, or delete workspace-wide quality check templates (mutations require Manager or Admin role).

Tool Step Labels

When AgentQ processes a request, each action appears as an expandable step in the response. The labels correspond to specific platform actions:

Step Label What It Does
Search Queries across datastores, containers, and fields
List Quality Checks Retrieves existing checks on a container
List Check Specifications Fetches available rule types and their schemas
Create Quality Check Creates a new quality check rule
Update Quality Check Modifies an existing quality check
Quality Scores Retrieves 8-dimension quality scores
Get Insights Retrieves daily metrics time series
Operation Insights Retrieves historical operation data
Describe Anomaly Gets full details for a specific anomaly
Workflow Executes a guided multi-step workflow

Available Tools

AgentQ and external MCP clients share the same tool set. The available tools are consistent across sessions, while access to their data and actions remains subject to your Qualytics permissions.

See the Tool Catalog for the full listing, grouped by capability, along with the category of data each tool shares with the model.

For exact parameter schemas (names, types, required vs optional), query the live MCP tools endpoint or refer to the AgentQ API reference.

Connecting External Clients

For step-by-step instructions on connecting ChatGPT, Claude Desktop, Cursor, and other MCP-compatible clients to the Qualytics MCP server, see Connecting External AI Clients.

For example conversations showing AgentQ in use, see Conversations, Responses & Context.