Skip to navigation

Common Mediation MCP workflows

View as Markdown

Learn how to investigate failed runs, author and test meters, recover stuck runs, and refresh prefetch data.

Use the following workflows to combine Mediation MCP operations into common tasks. Review the impact of each write operation and obtain approval before you execute it.

Investigate a problem meter

  1. Call list_meters or get_meter to identify the pipeline.
  2. Call get_run_status to determine whether the meter is running.
  3. Call list_run_history to find the runHistoryId or session, such as R-*.
  4. Call get_run_summary to review received, processed, and error counts.
  5. Call audit_trail_entries with exportType set to ERROR to retrieve failure samples and codes.
  6. Optionally call get_operator_summary to identify a slow or failing step.

Author, test, and reconcile a meter

  1. Call meter_guidance.
  2. Call validate_meter without saving the task graph.
  3. After approval, call create_meter.
  4. After approval, call run_meter with debug mode.
  5. Call get_run_status and get_run_summary to review the run.
  6. Call audit_trail_entries with ERROR to review failures.
  7. If you need a larger data set, call create_audit_export and download the export after the job is ready.

Recover a stuck run

  1. Call get_run_status.
  2. Call stop_meter_run with the runId and use a graceful stop.
  3. Poll the status until the run stops.
  4. If the run remains stuck, obtain approval before you force stop it through REST.
  5. Review ERROR audit data after the stop.

A force stop on a streaming run might drop data that is in flight.

Refresh the prefetch cache

  1. Call list_prefetch_definitions or get_prefetch_status.
  2. Call start_prefetch. You can optionally provide a processor ID.
  3. Call get_prefetch_status until the prefetch operation is complete.

Common example calls

Use the following examples as starting points. Replace the sample meter ID, version, and history ID with values from your tenant.

List meters:

{
"operation": "list_meters"
}

Check the current run status:

{
"operation": "get_run_status",
"meterId": "52",
"version": "0.0.1"
}

List run history:

{
"operation": "list_run_history",
"meterId": "52",
"pageSize": 10
}

Retrieve an operator summary:

{
"operation": "get_run_summary",
"runHistoryId": "<id from list_run_history>"
}

Use the runHistoryId returned by list_run_history.

Retrieve error samples:

{
"operation": "audit_trail_entries",
"meterId": "52",
"exportType": "ERROR",
"pageSize": 10
}

Natural-language requests and agent actions

When you make a request in natural language, the agent should use the following operation or workflow:

Your requestAgent action
“What meters do I have?”Call list_meters.
“Show meter 52.”Call get_meter.
“Is meter 52 running?”Call get_run_status.
“Why did this run fail?”Call list_run_history, then get_run_summary, and then review ERROR audit data.
“Run meter 52 in debug.”Ask for confirmation, then call run_meter with debug mode.
“Stop meter 52.”Prefer stop_meter_run with the runId from the start response.
“Export errors for reconciliation.”Call create_audit_export with ERROR, poll the export job, and download the export.
“Clone this meter for a test.”After approval, call duplicate_meter, then run the duplicate in debug mode.

The agent must not execute write operations without approval.