# MCP Examples

Source: https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/examples/

Real scenarios showing what you ask an AI client connected to the Qualytics MCP server, what the client does with the request, and the shape of the answer that comes back. Each scenario uses one of the **prompts** the Qualytics MCP server ships with. A prompt is a ready-made workflow: you fill in a few inputs, and the server hands the client step-by-step instructions for which Qualytics tools to call and how to present the result.

Your client lists the Qualytics prompts by name, such as **Investigate Anomaly**, in its prompt or command menu. In Claude Code, type `/` and pick the Qualytics prompt. In VS Code chat, type `/` followed by the server ID you chose, such as `/qualytics.`, and pick the prompt. The client then asks for the prompt's inputs.

The replies below are illustrative: the client answers from your own workspace, so the numbers and asset names in your conversation will be your own, and each client words its replies and asks for tool approvals in its own way. Pick a tab to see scenarios grouped by what you are trying to get done.

**Tab: Investigate**

### Explaining an anomaly in business terms

**Context.** A scan raised anomaly 10293 on the `customers` table, and you need to tell the account team what it means before anyone opens the scan results.

**What you ask.** Run the **Investigate Anomaly** prompt with the anomaly ID.

> **You**: *Investigate Anomaly*, anomaly `10293`
>
> **Claude**: **Summary**: 1,247 customer records in `customers` have no email address.
>
> **Technical Details**: A Not Null check on `email` failed in the last scan of `postgres_warehouse`. The check expects every record to have a value, and 1,247 records do not.
>
> **Business Impact**: The table carries the `Customer-Data` and `High-Priority` tags. Customers without an email miss order confirmations and password resets, and campaigns that target this table will skip them.
>
> **Recommended Actions**: Review the failed records in Qualytics to see whether they share a source or a load date, then fix the loader or the source system. Given the tags, treat this as urgent.

**What the client did.** It loaded the anomaly with its failed checks, rule types, affected fields, record count, and tags. It then classified the failure, completeness in this case, and wrote the four sections the prompt asks for.

**Why it works.** The prompt turns a technical failure into something a business owner can act on. It also points you to the anomalous records Qualytics already stored, so nobody has to query the source database to see them.

**Tab: Build**

### Creating checks from a plain-English expectation

**Context.** The data team agreed that every customer must have a valid email address, and you want that rule enforced on `customers` without picking rule types by hand.

**What you ask.** Run the **Generate Quality Check** prompt with the datastore, the container, and the expectation in your own words.

> **You**: *Generate Quality Check*, datastore `postgres_warehouse`, container `customers`, expectation "email must never be empty and must look like an email address"
>
> **Claude Code**: Your expectation covers two rules, so I suggest two checks on `customers.email`: a **Not Null** check, and a **Contains Email** check for the format. Want me to create them?
>
> **You**: Yes.
>
> **Claude Code**: Created both checks on `customers.email`. They run on the next scan of `postgres_warehouse`.

**What the client did.** It read the fields of `customers`, listed the rule types Qualytics supports with the properties each one needs, split the expectation into one check per rule, and created the checks after you agreed.

**Why it works.** You describe the rule the way the business states it, and the prompt does the translation into rule types and properties. Splitting one sentence into separate checks means each failure tells you exactly which rule broke.

---

### Building a summary dataset

**Context.** Finance wants monthly revenue by region, and you want that summary to exist as a dataset in Qualytics so it can carry its own checks.

**What you ask.** Run the **Transform Dataset** prompt with a name for the new dataset, the source, and the transformation.

> **You**: *Transform Dataset*, name `monthly_revenue_summary`, source "orders table in postgres_warehouse", criteria "last 12 months, total revenue by region and month"
>
> **Claude Code**: `orders` lives in a database, so this becomes a computed table in `postgres_warehouse`. The query groups `orders` by `region` and month for the last 12 months and sums `order_total`. The query passed validation. Want me to create `monthly_revenue_summary`?

**What the client did.** It worked out which kind of transformation fits the source, a computed table for a database, a computed file for files, or a computed join across two sources. It then wrote the query, checked that it is valid, and offered to create the dataset.

**Why it works.** You state the result you need, not the transformation type. Once the dataset exists, it can be profiled and checked like any other table.

**Tab: Assess**

### Deciding whether a table is fit for a purpose

**Context.** You are about to feed `daily_orders` into this month's revenue report and want an evidence-based opinion first.

**What you ask.** Run the **Assess Data Trust** prompt with the table and what you plan to use it for.

> **You**: *Assess Data Trust*, asset `daily_orders`, intended use "monthly revenue report"
>
> **Claude**: **Verdict**: Moderate. Usable for the report if the last three days are treated as incomplete.
>
> **Score**: 74. Timeliness (58) and Volumetrics (69) pull it down, while the other dimensions are above 90.
>
> **Drivers**: The table was last written three days ago, and a Volumetric check on the daily row count failed on the last scan.
>
> **Caveats**: The upstream `orders_staging` table has an open anomaly on `order_total`, which feeds the revenue field.
>
> **Unassessed**: No freshness reading exists for the upstream table.

**What the client did.** It collected the trust evidence for the table: the Quality Score with its dimensions and weights, active anomalies by impact, freshness, and the tables one step upstream. It then judged that evidence against the use you named.

**Why it works.** The judgment is tied to your purpose, so the same table can be fine for one use and not for another. Every claim names its evidence, and the **Unassessed** section says what could not be checked.

---

### Following quality over time

**Context.** A weekly review needs to know whether `orders` is getting better or worse.

**What you ask.** Run the **Analyze Trends** prompt with the datastore, and optionally a container, a field, and a time window.

> **You**: *Analyze Trends*, datastore `postgres_warehouse`, container `orders`, timeframe `month`
>
> **Claude**: Over the last month, the quality score of `orders` fell from 88 to 81. Most of the drop came in the second week, when Expected Values failures on `order_status` started and kept repeating. Scan volume stayed steady, so the change comes from the data, not from fewer scans.

**What the client did.** It pulled the quality metrics and operation history for the time window and described the direction, the turning point, and the likely cause.

**Why it works.** A trend tells you whether a number is a blip or a pattern. Narrowing to one container, or to one field, keeps the answer focused on the asset you care about.

**Tab: Govern**

### Asking a read-only client to change something

**Context.** You signed Codex in to Qualytics with read-only access for reporting, by running `codex mcp login qualytics --scopes read`, and then asked it to clean up old anomalies.

**What you ask.**

> **You**: Archive every acknowledged anomaly on the staging datastore that is older than 90 days.
>
> **Codex**: I found 37 acknowledged anomalies on `staging` older than 90 days, but I can't archive them. This connection only has read access, and archiving needs write access. To do this through Codex, run `codex mcp login qualytics` again without `--scopes read`. Otherwise, you can archive them in Qualytics.

**What the client did.** It found the anomalies with a read tool, then got a refusal when it tried the write tool and explained why.

**Why it works.** The access you approve when you connect a client is a hard limit. A read-only connection can answer questions without any risk of a model changing your workspace. See [MCP Permissions](https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/permissions/).

## See Also

- **Best Practices**

  Keep client connections secure and get reliable results from them.

  [Best Practices](https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/best-practices/)
- **Permissions**

  The user roles, tokens, and team permissions behind what a client can do.

  [Permissions](https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/permissions/)
- **Introduction**

  What MCP is, what the Qualytics MCP server offers, and why it matters for data quality.

  [Introduction](https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/introduction/)
- **How It Works**

  How a client, the Qualytics MCP server, and the model work together on a request, and what the model sees.

  [How It Works](https://userguide.qualytics.io/using-the-platform/mcp/deep-dive/how-it-works/)
- **Connecting External AI Clients**

  What you need before connecting a client, and the setup for each company's clients.

  [Connecting External AI Clients](https://userguide.qualytics.io/using-the-platform/mcp/connecting-external-ai-clients/requirements/)

*Last updated: November 7, 2026.*