Sample Prompts

Copy-paste prompts for working with Telmai through an MCP client

Once the Telmai MCP Server is connected, you can ask about your data quality in plain language. Every block below is a prompt you can copy, paste, and edit — replace anything in <angle brackets> with your own asset, column, project, or channel name.

You don't need to know Telmai's tool names. Just describe what you want. If the assistant does the wrong thing, tell it plainly: "list the monitors on that asset instead."

The assistant can create and change real monitors. Before a session where you plan to change anything, paste this:

"Before you create, change, or disable anything in Telmai, show me exactly what you intend to apply and wait for my confirmation. Read-only questions you can answer freely."

Start here

Run these once after connecting, to see what you're working with.

What Telmai tools do you have access to? List them with a one-line description, and tell me which ones make changes versus which are read-only.

Which Telmai projects and connections can I see? For each connection, tell me the type and how many assets sit under it.

Give me a one-screen summary of our Telmai tenant: how many assets, how many have a scan schedule enabled, how many open incidents, and the average and lowest DQ score.

---

Triage today's incidents

Incidents come back with an asset ID rather than a name, so ask for names or you'll get identifiers.

Show me all open incidents, sorted by severity and then by age. Resolve each asset ID to its name, and tell me which monitor fired and how long it's been open.

Which open incidents are more than 7 days old? Resolve the asset names and group them by project — that's our backlog risk.

Summarise today's incidents into three buckets: needs action now, worth watching, and probably noise. Explain your reasoning for each.

What's our mean time to resolve for the last 30 days versus the 30 days before? Use explicit date ranges for both so the comparison actually comes back.

The incident list returns the 100 most recent. On a busy tenant, filter by project, connection, or date range.

---

Investigate one incident

This is where the assistant is strongest. Incident detail includes the expected range, the actual value, and the incident's full history — so ask for all of it.

Explain incident <ID> as if I've never used Telmai: which asset and column, which monitor fired, the expected range, the actual value, and what it means for the data.

For incident <ID>, show me every metric point with its expected range next to the actual value, and tell me exactly when it first went anomalous.

Is incident <ID> a one-off or recurring? Check how many times this monitor has raised an incident in the last 30 days.

---

Check nothing is silently broken

An asset that stopped alerting isn't necessarily healthy — it might not be running at all.

<asset> hasn't alerted in two weeks. Check whether its scan schedule and monitors are actually enabled — I want to rule out a silent gap rather than assume good news.

Which assets have monitors configured but no scan schedule enabled? Those monitors will never run.

Which assets have no ID attribute set? Uniqueness monitoring can't work on those.

If scans are failing rather than your data being wrong, that's a platform issue — contact Telmai support. Scan job status isn't available through MCP.

---

Tune a noisy monitor

The pattern that works: look at the data first, get a recommendation second, change it third.

The <monitor> on <asset> is too noisy — it raised nine incidents in two weeks and every one was fine. Show me the current threshold, pull the metric history with its learned ranges, and recommend a better threshold. Don't change anything yet.

Change the threshold on <monitor> to an absolute range of <low> to <high>, leaving everything else exactly as it is. Show me the current and modified versions side by side before applying.

Rank every monitor on <asset> by how many incidents it raised in the last 30 days, and tell me which look like real signal versus threshold problems.

Disable <monitor> on <asset> while we fix the upstream pipeline. Confirm it's disabled and tell me what we need to do to re-enable it.

Changing a monitor replaces its whole definition, so an unrelated setting can get dropped. Always ask to see the before and after.

---

Trace what's upstream and downstream

Telmai exposes your full asset lineage, so cause-and-blast-radius questions work well.

<asset> has an incident. Show me everything downstream of it — I need to know what else is affected before deciding how urgent this is.

For incident <ID>, trace the affected asset upstream. Is there an incident on any of its parents that would explain this one?

Which of our assets have the most downstream dependents? A quality problem there spreads furthest, so I want to check their monitor coverage first.

---

Audit your setup

For <asset>, show me the ID attributes, timestamp attribute, delta-only setting, scan mode, and whether a schedule is enabled. Explain whether each is right for a table that's appended to hourly and never updated in place.

Give me a coverage table by project: total assets, assets with a schedule enabled, assets with an ID attribute set, and assets with no user-defined monitors.

Which monitors have notifications turned off or no channel set? Those alerts are going nowhere. Check both the out-of-the-box and user-defined monitors.

Which assets have a DQ score below <threshold>? Show their project and connection type so I can see whether the problem clusters anywhere.

---

See what monitors exist

List every monitor on <asset> with its type, metric, threshold, impact level, and whether notifications and ticketing are set up.

For <asset>, which out-of-the-box monitors are enabled and which are disabled? Explain what each disabled one would catch if we turned it on.

Compare the monitors on <asset1> against <asset2>. They're the same kind of table, so tell me what's missing on the weaker one.

---

Create a monitor

Ask for the configuration before it's created — that one extra turn prevents most mistakes.

Create a freshness monitor on <asset>: alert if the table hasn't updated in more than 6 hours. Set impact to High and notify our <#channel> Slack channel. Show me the configuration before creating it.

Add a record count monitor on <asset> using a learned threshold so it adapts to our normal weekly pattern including the weekend dip. Show me the configuration first.

Add a completeness monitor on <asset>.<column>. This column should never be null, so use an absolute threshold at 100% and set impact to High.

Add a uniqueness monitor on <asset>.<id_column>. Duplicate IDs cause double-counting in our reporting, so set impact to High.

Before I add a completeness monitor on <asset>.<column>, show me that column's history so I can pick a threshold that reflects reality rather than a guess.

Validation rules

Record validation rules check individual records. Ask for the rule in plain English before saving — that's how you catch one that's subtly wrong.

Create a record validation rule on <asset> that checks <column> is one of <value1>, <value2>, or <value3>. Alert if correctness drops below 99%. Explain the rule before saving it.

Create a validation rule on <asset> that <amount_column> must be a positive number below <limit>. Explain what happens to rows where the value is null.

I need a rule that flags rows where <status_column> = 'active' but <date_column> is null. Write it, explain the logic in plain English, then create it once I confirm.

---

Whole workflows

These chain several steps into one prompt, which is where an assistant beats a dashboard.

Weekly review

Run our weekly Telmai review: (1) open incidents by severity with asset names resolved, (2) anything open more than 7 days, (3) assets with monitors but no schedule enabled, (4) average DQ score by project, and (5) the three highest-impact actions you'd recommend. Format it as a short report I can paste into our team wiki.

Blast-radius check

For incident <ID>: identify the affected asset, trace its full downstream lineage, check whether any downstream asset has its own open incident, and tell me whether this is contained or spreading.

Noise cleanup

Go through <asset1>, <asset2>, and <asset3> one at a time. For each, find monitors that raised more than three incidents in the last 30 days, pull the metric history, and propose a threshold change where the data shows the threshold is at fault. Give me one table of proposed changes — don't apply anything.

---

What it can't do yet

The assistant is good at investigating incidents, auditing your configuration, and creating or tuning monitors. These things it can't do at all — use the UI instead.

You want to…	Status
Add or onboard an asset	Not available. Onboard in the UI or through the REST API
Trigger a scan	Not available
Set or change a scan schedule	Read-only — you can see whether one is enabled, but not set it
Set an ID or timestamp attribute	Not available
See tables you haven't onboarded	Not available — the assistant can't list what's available to onboard
Delete a monitor	Not available, so a monitor created with the wrong type has to be removed in the UI
Replay a monitor	Not available. Replay is in the UI
Get AI monitor recommendations	Not available. Recommendations are in the UI
Check whether a scan succeeded	Not available
Read freshness values	Comes back empty, so don't rely on it for reporting
See PII masking status	Not available. PII exposure incidents are visible; masking configuration isn't
Track DQ score or pass rates over time	Current values only — no history

Good to know

• Monitors are fetched one asset at a time. There's no tenant-wide list, so keep asset lists short and explicit rather than asking about everything.

• Impact is often unset, so "show me High-impact monitors" can look empty even where monitors exist.

• Incidents have no owner field.

• The assistant may use API names, not UI names — PREDEFINED_METRIC for a built-in metric, METRIC for a user-defined one, SQL_RULE for a SQL rule, and STATIC for an absolute threshold.

---

Tips

1. Name the asset exactly. Unsure? Ask first: "Find the asset whose name contains orders and tell me its exact name and project."

2. Ask for names, not IDs. Incidents return identifiers, so say "resolve the asset IDs to names."

3. Ask to see the plan before any change — and on an edit, ask for before and after, since the whole definition gets replaced.

4. Ask to see the numbers. "Show me the values with their learned ranges" lets you check the conclusion yourself.

5. Give the business reason. "Duplicate order IDs cause double-counting in our reporting" gets a better monitor than "add a uniqueness monitor."

6. Start a fresh chat when you switch topics. Long sessions carry stale asset names forward.

7. Treat its read as a hypothesis. It's strong at triage and correlation — confirm anything that leads to a config change.

---

Related pages

• Telmai MCP Server

• Monitoring Data

• Creating a Monitor

• Record Validation Rules

• Managing Assets

• Telmai APIs