dataranger

Overview Schema Source Related Servers Discussions Admin

run_demo

Generate 60 days of synthetic payment data with planted issues, then patrol it to demo DataRanger reports and test result handling without touching real data.

Instructions

Run a patrol on generated sample data, to see what DataRanger reports without touching real data.

Generates 60 days of synthetic payment transactions with planted problems (duplicates, missing days,
orphan rows, wrong amounts and some harmless decoys), then patrols them exactly as patrol_duckdb and
patrol_files do. Use this to try DataRanger, to show a user the report format, or to test your own
handling of the results. Use patrol_duckdb or patrol_files for real tables.

Behavior: needs no input data, credentials or network. The only side effect is writing the report
files (dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv) to out_dir. Takes a few seconds.

Returns the same summary as the patrol tools: counts, needs_a_person, all_incidents and outputs.
Pass outputs.folder and a partition to get_incident for the evidence behind one decision.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_demo"
  }
}

Input Schema

Name	Required	Description	Default
`seed`	No	Random seed for the generated data. The same seed on the same day gives the same table.
`out_dir`	No	Folder to write the report files into. Created if missing; report files already there are overwritten. Omit to use a new temporary folder; its path comes back in outputs.folder.

Output Schema

Name	Required	Description	Default
`note`	Yes
`table`	Yes
`outputs`	Yes
`escalate`	Yes
`incidents`	Yes
`auto_fixed`	Yes
`rows_checked`	Yes
`all_incidents`	Yes
`gate_threshold`	Yes
`needs_a_person`	Yes
`no_action_needed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.2Nov 12, 2026

addedInput schema / properties / out_dir / description

Added value: +"Folder to write the report files into. Created if missing; report files already there are overwritten. Omit to use a new temporary folder; its path comes back in outputs.folder."

addedInput schema / properties / seed / description

Added value: +"Random seed for the generated data. The same seed on the same day gives the same table."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "Incident": {
+      "properties": {
+        "decision": {
+          "title": "Decision",
+          "type": "string"
+        },
+        "partition": {
+          "title": "Partition",
+          "type": "string"
+        },
+        "problems": {
+          "items": {
+            "type": "string"
+          },
+          "title": "Problems",
+          "type": "array"
+        },
+        "proposed_fix": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "title": "Proposed Fix"
+        },
+        "residual": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "title": "Residual"
+        }
+      },
+      "required": [
+        "partition",
+        "problems",
+        "decision",
+        "proposed_fix",
+        "residual"
+      ],
+      "title": "Incident",
+      "type": "object"
+    },
+    "Outputs": {
+      "properties": {
+        "audit_log": {
+          "title": "Audit Log",
+          "type": "string"
+        },
+        "dashboard": {
+          "title": "Dashboard",
+          "type": "string"
+        },
+        "folder": {
+          "title": "Folder",
+          "type": "string"
+        },
+        "incidents_csv": {
+          "title": "Incidents Csv",
+          "type": "string"
+        },
+        "proposed_fixed_version": {
+          "title": "Proposed Fixed Version",
+          "type": "string"
+        }
+      },
+      "required": [
+        "folder",
+        "dashboard",
+        "audit_log",
+        "incidents_csv",
+        "proposed_fixed_version"
+      ],
+      "title": "Outputs",
+      "type": "object"
+    }
+  },
+  "properties": {
+    "all_incidents": {
+      "items": {
+        "$ref": "#/$defs/Incident"
+      },
+      "title": "All Incidents",
+      "type": "array"
+    },
+    "auto_fixed": {
+      "title": "Auto Fixed",
+      "type": "integer"
+    },
+    "escalate": {
+      "title": "Escalate",
+      "type": "integer"
+    },
+    "gate_threshold": {
+      "title": "Gate Threshold",
+      "type": "number"
+    },
+    "incidents": {
+      "title": "Incidents",
+      "type": "integer"
+    },
+    "needs_a_person": {
+      "items": {
+        "$ref": "#/$defs/Incident"
+      },
+      "title": "Needs A Person",
+      "type": "array"
+    },
+    "no_action_needed": {
+      "title": "No Action Needed",
+      "type": "integer"
+    },
+    "note": {
+      "title": "Note",
+      "type": "string"
+    },
+    "outputs": {
+      "$ref": "#/$defs/Outputs"
+    },
+    "rows_checked": {
+      "title": "Rows Checked",
+      "type": "integer"
+    },
+    "table": {
+      "title": "Table",
+      "type": "string"
+    }
+  },
+  "required": [
+    "table",
+    "rows_checked",
+    "incidents",
+    "auto_fixed",
+    "no_action_needed",
+    "escalate",
+    "gate_threshold",
+    "needs_a_person",
+    "all_incidents",
+    "outputs",
+    "note"
+  ],
+  "title": "PatrolSummary",
+  "type": "object"
+}

First observedv0.1.0Nov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations: no input data, credentials, or network required; the sole side effect is enumerated as specific files (dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv) in out_dir; runtime is quantified as a few seconds. It even explains the data content (planted duplicates, missing days, orphan rows, decoys), which annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose, usage, behavior, then return shape, in that order, with no filler sentences. Slightly long, and the output-chaining note in the returns paragraph edges toward detail the output schema already carries.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a demo tool with an output schema, prerequisites, side effects, runtime, and downstream chaining are all covered. The description explicitly defers return-value detail to the output schema while noting it matches the patrol tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already fully documented, and the description adds only marginal detail (out_dir overwrite behavior and temp-folder fallback restate the schema). The one genuinely additive hint is chaining 'outputs.folder and a partition to get_incident', which is workflow guidance rather than parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('run a patrol on generated sample data') and immediately scopes it as synthetic, distinguishing it from patrol_duckdb and patrol_files which it names. An agent can tell what it does and what it does not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit use cases (try DataRanger, demonstrate report format, test result handling) and an explicit exclusion with the alternative named: 'Use patrol_duckdb or patrol_files for real tables.' Nothing left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server