Skip to main content

Ask your own LLM to suggest rules via MCP

Status: available (self-host); hosted endpoint rolling out. This uses the MCP server, which you can run yourself today; a hosted public endpoint is being finalized. The old in-app "Suggest rules with AI" flow is being retired in favour of this — your MCP client's model does the reasoning, using the context this tool gathers, and no server-side LLM spend is involved.

Goal​

You'll have your own MCP-connected LLM (Claude Desktop, the claude CLI, Cursor, …) propose rules for a data asset — grounded in the asset's real profile, the rules already on it, and the catalogue of valid rule types — then persist the ones you approve. The model reasons; Measured Cloud just hands it the evidence and validates what it writes.

Prereqs​

  • A connected MCP client pointed at the MCP server, authenticated with a dqk_… personal API key (mint one). The key must have editor role (or higher) in the target workspace to persist rules; a viewer-role key can gather context but gets a 403 on the create/update step.
  • A data asset to author rules for.
  • The asset should have a completed profile run — the model needs column stats to make grounded proposals. If it doesn't, the tool tells the model to profile it first (see Profile runs); the model can do that in the same conversation.

How it works​

The MCP server exposes a read-only tool, mc_rule_suggestion_context, that composes four existing reads into one bundle so the model has everything a human rule author would gather:

Part of the bundleWhat it gives the model
assetThe asset's name, type, and tags — what the thing is.
profileThe latest completed profile run: row_count, sampled_row_count, and per-column stats (dtype, null rate, cardinality, min/max/mean, top values, likely-unique-key). If no profile has completed, this carries a hint telling the model to run a profile first.
existing_rulesThe rules already on the asset — so the model won't propose duplicates.
rule_type_galleryThe menu of valid rule types with their kwargs_schema, example_kwargs, and applies_to, so the model authors against real types.

The tool makes no LLM call of its own and reaches nothing outside Measured Cloud's own API. The intelligence is entirely your client's model — consistent with the primitives philosophy.

Steps​

  1. Ask the model, in plain language, to suggest rules for the asset:

    "Suggest data-quality rules for the orders asset. Use its profile and don't duplicate rules it already has."

    The model calls mc_rule_suggestion_context (resolving the asset by name via mc_asset_list if needed), reads the bundle, and proposes rules as {rule_type, kwargs} using the gallery's ids — e.g. expect_column_values_to_not_be_null on a column the profile shows has a 0% null rate, or expect_column_values_to_be_unique on a column flagged is_unique_key.

  2. If the asset has never been profiled, the bundle's profile.hint says so. Ask the model to profile it first:

    "Profile it, wait for it to finish, then suggest rules."

    The model runs mc_profile_run, polls mc_profile_get until it completes, then re-gathers the context.

  3. Review the model's proposals. They're grounded in the actual data — a null-rate near zero justifies a not-null rule, a bounded numeric range justifies a between-rule, and so on. Approve, edit, or drop each one.

  4. Have the model persist the approved rules. It calls mc_rule_create once per rule, on the asset (and mc_rule_update to change a rule that's already there). Each new rule joins the asset's default validation; name validations (validation_ids) to add it to those too. The server runs the same validation the UI does, so an invalid kwargs payload comes back as an actionable error rather than a silently-stored bad rule.

    "Save the not-null and uniqueness rules on orders, and add them to the Nightly orders validation."

Verify​

  • The model's proposals reference columns that exist in the profile and rule-type ids that appear in the gallery — not invented ones.
  • Rules it says are "already covered" match what's in existing_rules; it doesn't re-propose them.
  • After the persist step, the rules show up on the asset's Rules card (or via mc_rule_list with the asset's data_asset_id) exactly as you approved them.
  • Run the asset's rules (▶ Run on the asset page, or mc_rule_run for one rule) to confirm the new rules validate, then pick them into a validation if they aren't in one yet — see Create and run a validation.

Caveats​

  • Editor role to persist. Gathering context is a read (viewer-tier); creating or updating a rule needs editor+ (adding it to a validation also needs the permission to manage validations). A viewer-scoped key surfaces a 403 at the save step.
  • Only completed profiles count. A pending or failed profile run is skipped — the tool returns the run-first hint instead of partial stats, so the model isn't tempted to guess from an incomplete profile.
  • The model can still be wrong. The context is grounded, but the proposals are the model's. Review before saving; the server validates the shape of each rule, not its business appropriateness.

See also​