Your business knows what good data looks like. Who keeps it in check?

Most leading data quality platforms have added a way for an AI agent to scan a table and generate rules. Fewer have solved the harder problem underneath that: making sure the rules have business value. An inferred rule that is statistically valid but disconnected from what the business actually needs is just noise with a score number. Collibra’s Data Quality (DQ) tools for MCP are built to close that gap: monitoring generated from governed context, not from a guess.

What's new: Data Quality tools for MCP

The DQ tools for MCP enable LLMs to create jobs, discover and read existing rules, create new rules and even convert rules into templates. But the real value is that these are not siloed tools, they are part of the bigger suite of MCP tools for the Collibra Platform. In simple terms, you ask an agent to look inside your Collibra environment and turn governed context into a data quality job, with no rule written by hand.

Ask your favorite LLM about a data product and it reads the data contract's column and table-level terms, translates each one into a rule, finds the physical table and columns the contract actually governs and deploys a job against them. Point it at a business rule instead and it performs the equivalent translation from plain-text to SQL against all the columns that business rule links to.

How the MCP tools help

Governance work already produces business rules and data contracts, but translating those requirements into enforced data quality controls required heavy coordination and resources. Someone still had to open the DQ UI, translate a rule into a query by hand, work out which table it actually applies to and keep the resulting job in sync every time the rule or contract changed.

Problems it solves

• Rules stay on paper: a business rule written in plain text does not become a running check on its own, someone has to translate it into SQL first.
• Contracts and monitoring drift apart: a data contract states what should be true, but the job checking it is built and maintained separately, so the two quietly fall out of sync.
• Coverage depends on who has time: whether an asset gets monitored comes down to whether someone got around to authoring a rule for it.
• Deploying monitoring means leaving the workflow: most users hate switching apps, it breaks their “flow” state.

How the MCP tools work

Say you just declared a new data contract for the Revenue Analysis and Prediction output from a sales data product.

You are not in the DQ UI, you are wherever you already work, and you ask your agent to make sure that contract is enforced.

The agent reads the contract and works through its terms one at a time.

On the column auto_year, the contract requires a positive number. On the email column, it calls for duplicate detection. On region, it restricts values to EMEA and APAC. And at the table level, it requires that totalproductcost equals unitprice multiplied by orderqty. In plain terms, the line total has to actually match price times quantity.

From there the agent identifies the physical table and columns behind it, assembles the four checks into a single data quality job and deploys it, confirming back which columns are covered and which contract term produced each check.

A business-rule asset without a contract behind it works the same way, at a smaller scale.

Where a data contract hands over several terms at once, a single business rule hands over one: the agent reads it, translates the plain-text logic into SQL, detects the physical column it actually governs and deploys the check.

None of this works if the agent is guessing.

What makes it reliable is that the business rule, contract's terms, the data product and the physical table underneath are already connected inside Collibra. The agent is reading a relationship that already exists, not inferring one from a table name.

Why you should be excited

• Data steward: the context work finally pays off. A well-connected business rule becomes real running checks across every physical dataset it governs, all at once. The better the steward curates, the further the coverage reaches.
• Data product owner: the guarantees written into a data contract, like the ones on the “Revenue Analysis and Prediction” example, turn directly into enforced monitoring, and stay enforced when the contract changes.
• Data engineer: the job gets created without logging into Collibra at all. The check is already running by the time anyone would have opened a browser tab for it.

Use cases

• Deploy monitoring from a new data contract: apply a contract to an output port, and column- and table-level checks deploy straight from its definitions. Additionally, agents will automatically re-generate the DQ rules whenever the contract is updated instead of quietly falling behind.
• Deploy monitoring from a business rule: a plain-text business rule with no SQL behind it gets translated and deployed the same way, for assets not yet covered by a contract.
• Deploy monitoring from policies and standards: the beauty of Collibra is its ability to connect physical data not only with business rules but also with policies, standards and compliance-driven requirements. With the MCP tools, LLMs can read all of them and suggest data quality rules to keep your compliance posture in check.

Key takeaways about the DQ tools for MCP

Data quality coverage changes its starting point: instead of depending on who had time to author a rule, it comes from governed context. That shifts the job from writing checks to keeping the governed layer accurate, since the checks now follow from it automatically. This is the first step of our agentic data quality future; root cause analysis and remediation — diagnosing failures and suggesting fixes — comes next.

• The reliability comes from governed context, not a new system: the agent works from assets, contracts and lineage already inside Collibra, so there is nothing extra to maintain to keep it accurate.
• Coverage no longer depends on who had time to author a rule: it depends on what has already been agreed and governed.
• It is built for any agent, not a proprietary chat window: the same MCP tools and Skills work from whatever assistant is already in use.

Where to learn more about the DQ tools for MCP

Check out our documentation.

• 

  Beth Hoffman

  Beth Hoffman

  Senior Technical Product Manager

  Collibra

• 

  Marc Campabadal

  Marc Campabadal

  Senior Product Marketing Manager

  Collibra

• 

  Geoffery Gettings

  Geoffery Gettings

  Senior Director, Software Engineering

  Collibra