feat(dq): add DQ rule lifecycle + job observability MCP tools

[regmimridul]

🎯 What does this PR do?

Adds MCP tools to author, manage and observe data-quality rules and job runs on an existing DQ job (DEV-198734). Together they cover a rule's full lifecycle: preview/validate → create → read → edit → delete, plus run the job and observe the outcome.

Rule authoring & lifecycle (CRUD)

• create_dq_rule — create a rule (monitor) on a job via the DQ monitoring API (POST /rest/dq/internal/v1/monitoring/monitor). monitorType is FREEFORM_SQL (full SQL) or SIMPLE_SQL (single-column check); supports filterQuery, columnName, dimensions, tolerance, and template linkage. Defaults to active and not suppressed.
• get_dq_rule — read a single rule's definition (GET /rest/dq/internal/v1/jobs/{jobName}/monitors/rules/{monitorName}).
• edit_dq_rule — update an existing rule; full-replace, with newMonitorName to rename (PUT /rest/dq/internal/v1/monitors/rules).
• delete_dq_rule — delete a rule from a job (DELETE /rest/dq/internal/v1/jobs/{jobName}/monitors/rules/{monitorName}). Marked destructive.

Pre-flight & results

• validate_dq_rule — validate a rule's SQL/definition before saving or running, so a malformed rule is caught up front (POST /rest/dq/internal/v1/rules/validate).

• preview_dq_rule_sql — run the rule's SQL and return sample columns + rows (POST /rest/dq/internal/v1/rules/previewRule).

• get_dq_rule_results — per-run results after a job run: score, breaking/passing counts, pass/fail, exceptions; paginated (GET /rest/dq/internal/v1/monitoring/rules/{jobName}/{ruleName}).

  (validate_dq_rule / preview_dq_rule_sql take edgeSiteId/connectionId/schemaName — the discovery output from prepare_create_dq_job.)

Job run & observability

• run_dq_job — trigger a run of an existing job, executing its rules (POST /rest/dq/1.0/jobs/{jobName}/run). Optional runDate/runDateEnd (dateKind DATE/TIMESTAMP) and backrun backfill; defaults to current date/time. Returns the jobRunId.
• get_dq_job_status — status of a run by jobRunId via the public API (GET /rest/dq/1.0/jobRuns/{jobRunId}): run status (RUNNING/FINISHED/FAILED…), activity, score, breaking-monitor count, failure exception.
• get_dq_job_log — execution log for a run (stages, timings, exceptions). Uses the internal DQ UI surface (GET /rest/dq/internal/v1/job/logs?jobUUID={jobRunId}) — the public DQ API has no log endpoint.

All tools validate inputs before any call, surface downstream DQ errors (400/403/404/422) as structured results, and are covered by unit tests. API contracts were taken from the dq (udq-app) controllers/OAS, not guessed. README updated with all entries.

Refs: DEV-198734

✅ Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation (if needed).
• My commit messages follow the Conventional Commits standard.

🤖 Generated with Claude Code

[svc-snyk-github-jira]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[aberkowCollibra]

@regmimridul do we have tests on the DQ side to ensure these API contracts will not change and will fail if someone modifies?

[EricWarnerCollibra]

@regmimridul I would have the same comment as here -> #88 (comment)

[aberkowCollibra]

I recommend not including this endpoint since it returns live client data. I'm not sure if the results get passed into the LLM and we'd need to verify before we can go down this path.

[regmimridul]

@aberkowCollibra @EricWarnerCollibra removed the preview_dq_rule_sql endpoint and updated the PR to use less of Collibra jargon. Will be adding tests to ensure that the API contracts do not change shortly.

[nevers]

This says collibra/dq-rules covers "run → observe, edit/delete", but that skill explicitly states it does not cover editing, deleting, or triggering runs — and no edit/delete/run tools exist in this PR. One of the two files is wrong (the code matches dq-rules). Suggest:

Suggested change

	(validate → create → run → observe, edit/delete). This workbench reuses those
	(validate → create → inspect → read results). This workbench reuses those

[nevers]

CreateDQRule hand-rolls the marshal → request → read cycle that dqDo (in this same file) already encapsulates — it looks like it predates the helper and never got refactored. Rewriting it on top of dqDo removes ~35 lines while keeping the status-mapping switch intact:

func CreateDQRule(ctx context.Context, client *http.Client, request CreateDQRuleRequest) (*CreateDQRuleResponse, error) {
	respBody, status, err := dqDo(ctx, client, http.MethodPost, "/rest/dq/internal/v1/monitoring/monitor", request)
	if err != nil {
		return nil, fmt.Errorf("creating dq rule: %w", err)
	}
	if status != http.StatusOK {
		switch status {
		case http.StatusBadRequest:
			return nil, fmt.Errorf("creating dq rule: bad request (invalid rule definition): %s", string(respBody))
		// ... same cases as today
		}
	}
	var result CreateDQRuleResponse
	if err := json.Unmarshal(respBody, &result); err != nil {
		return nil, fmt.Errorf("creating dq rule: decoding response: %w", err)
	}
	return &result, nil
}

[nevers]

The comment says "At least one filter should be provided", but the handler doesn't enforce it — a call with no filters posts an empty filter list and pages through every monitor on the instance. search_catalog_columns enforces its equivalent rule with a validation_error.

Either add the same guard here, or — if list-all is intentional — drop the sentence so the doc matches the behavior.

[nevers]

The preview omits Description and TemplateID, both of which are sent on create — so what the user approves at the checkpoint isn't the complete rule. Since the whole point of confirm=false is faithful review, consider echoing every field of the composed request.

[nevers]

The dq-rules skill promises "Names allow only letters, digits, - and _" (max 256) and the schema says description is max 256 chars — but validate() checks neither, so those mistakes only surface as downstream 400s. Cheap pre-flight checks would keep errors descriptive and self-correcting for the agent:

• monitorName matches ^[A-Za-z0-9_-]{1,256}$
• description ≤ 256 chars
• monitorType == SIMPLE_SQL ⇒ columnName required — assuming the API does require it (the schema currently says "Optional… used with SIMPLE_SQL rules"; worth confirming which is true and aligning)