Skip to main content
Glama

patrol_files

Checks CSV, TSV, or Parquet fact tables for duplicate keys, missing partitions, bad references, null spikes, and control-total mismatches; verifies proposed fixes and flags auto-fix or escalate.

Instructions

Check a fact table in CSV, TSV or Parquet files for data-quality incidents and say which are safe to fix. A patrol checks every daily partition of the fact table for duplicate keys, duplicate rows, missing partitions, rows that point to no reference record, null spikes, and row counts or amounts that do not match the source's control totals. For each problem it proposes a fix, tests that fix on a copy against the control totals, and decides: "auto-fixed" (proven and low risk), "no action needed" (checked, the data is right) or "escalate" (a person must decide).

Use this before trusting, querying or building on a date-partitioned table exported as CSV, TSV or
Parquet files, or after a load or pipeline change to confirm the data is still right. Use
patrol_duckdb instead when the table lives in a DuckDB database. Use run_demo to see the output on
sample data.

Behavior: The three input files are only read. Your data is never modified and nothing is written back. The only side effect is
writing four report files to out_dir: dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv
(the proposed corrected table, for review). Runs locally with no network calls;
usually a few seconds, longer for tables with millions of rows. Fails with a readable error if a
file, table or mapped column does not exist; the error lists the columns that are available.

Returns the counts (incidents, auto_fixed, no_action_needed, escalate), needs_a_person (the escalated
incidents), all_incidents (partition, problems, decision, proposed_fix, residual for each) and
outputs (paths to the report files). Pass outputs.folder and a partition to get_incident for the
full evidence behind one decision. Tell the user about every escalated incident.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "facts_file": "<facts_file>",
      "ref_file": "<ref_file>",
      "manifest_file": "<manifest_file>"
    },
    "name": "patrol_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoColumn in the fact table that uniquely identifies a row (the primary key).txn_id
dateNoDate column the fact table is partitioned by, one partition per calendar day. The control totals must have a column with the same name.txn_date
amountNoNumeric amount column in the fact table. It is compared with the 'amount' control total.amount
out_dirNoFolder 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.
ref_keyNoColumn in the reference table that the fact table's reference column must match.customer_id
segmentNoColumn that splits each day into segments, for example channel or region. The control totals must have a column with the same name, where '*' means the whole day.channel
categoryNoOptional categorical column in the fact table. Omit if the table has none.
ref_fileYesPath to the reference table that fact rows point to (for example customers), as .csv, .tsv, .parquet or .pq.
referenceNoColumn in the fact table that points to the reference table (the foreign key).customer_id
thresholdNoGate threshold: the largest relative gap to the control totals that a verified fix may leave and still be marked auto-fixed (0.01 = 1%). Lower is stricter. Omit for the benchmark-calibrated default, 0.0135.
facts_fileYesPath to the fact table as .csv, .tsv, .parquet or .pq. One row per event, partitioned by a date column.
manifest_fileYesPath to the source system's control totals as .csv, .tsv, .parquet or .pq: one row per date and segment, with the date column, the segment column ('*' = whole day), n (row count) and amount (sum).

Output Schema

NameRequiredDescriptionDefault
noteYes
tableYes
outputsYes
escalateYes
incidentsYes
auto_fixedYes
rows_checkedYes
all_incidentsYes
gate_thresholdYes
needs_a_personYes
no_action_neededYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv0.4.2
    • addedInput schema / properties / amount / description
      Added value: +"Numeric amount column in the fact table. It is compared with the 'amount' control total."
    • addedInput schema / properties / category / description
      Added value: +"Optional categorical column in the fact table. Omit if the table has none."
    • addedInput schema / properties / date / description
      Added value: +"Date column the fact table is partitioned by, one partition per calendar day. The control totals must have a column with the same name."
    • addedInput schema / properties / facts_file / description
      Added value: +"Path to the fact table as .csv, .tsv, .parquet or .pq. One row per event, partitioned by a date column."
    • addedInput schema / properties / key / description
      Added value: +"Column in the fact table that uniquely identifies a row (the primary key)."
    • addedInput schema / properties / manifest_file / description
      Added value: +"Path to the source system's control totals as .csv, .tsv, .parquet or .pq: one row per date and segment, with the date column, the segment column ('*' = whole day), n (row count) and amount (sum)."
    • 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 / ref_file / description
      Added value: +"Path to the reference table that fact rows point to (for example customers), as .csv, .tsv, .parquet or .pq."
    • addedInput schema / properties / ref_key / description
      Added value: +"Column in the reference table that the fact table's reference column must match."
    • addedInput schema / properties / reference / description
      Added value: +"Column in the fact table that points to the reference table (the foreign key)."
    • addedInput schema / properties / segment / description
      Added value: +"Column that splits each day into segments, for example channel or region. The control totals must have a column with the same name, where '*' means the whole day."
    • addedInput schema / properties / threshold / description
      Added value: +"Gate threshold: the largest relative gap to the control totals that a verified fix may leave and still be marked auto-fixed (0.01 = 1%). Lower is stricter. Omit for the benchmark-calibrated default, 0.0135."
    • 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"
      +}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give hints (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description supplies the substance: inputs are read-only, the sole side effect is four named report files in out_dir, no network calls, runtime of seconds to longer for millions of rows, and readable errors that list available columns on a bad file/table/column. This is exactly the beyond-annotation detail an agent needs, and nothing here conflicts with the declared hints.

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?

Content is front-loaded — purpose, then when to use, then behavior, then returns — and every paragraph carries distinct information. The final 'Returns ...' sentence partly restates what the output schema already declares, which is the only real redundancy; the rest of the prose is dense rather than padded.

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 12-parameter, write-side-effecting tool, the definition covers what it does, when to use it, side effects and their locations, failure modes, expected latency, and the shape of the result (counts, needs_a_person, all_incidents, outputs). The sensible follow-up path to get_incident is spelled out, so nothing an agent needs before calling is missing.

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 description coverage is 100%, so the schema already explains key, date, amount, ref_key, segment, category, reference, threshold and out_dir. The description adds conceptual context (the fix is tested on a copy against control totals, driving the threshold gate) but no parameter-level detail beyond what the schema states, so the baseline of 3 applies.

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?

The opening sentence names a specific verb and resource ('Check a fact table in CSV, TSV or Parquet files for data-quality incidents') and immediately enumerates the seven checks performed, plus the three-outcome decision model. It also names the sibling it is not ('use patrol_duckdb instead when the table lives in a DuckDB database'), so an agent can separate it from patrol_duckdb without opening either schema.

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?

Explicit when-to-use is given ('before trusting, querying or building on a date-partitioned table', 'after a load or pipeline change'), along with named alternatives and their selection conditions: patrol_duckdb for DuckDB tables, run_demo for sample output, and get_incident for full per-decision evidence via outputs.folder. There is also an operator-level instruction ('Tell the user about every escalated incident').

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

Deploy Server

Other Tools