MCP Examples¶

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.

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.

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.

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.