pipeverify

Overview Schema Source Related Servers Discussions Admin

check_against_source

Read-onlyIdempotent

Verify an output table against its raw source when no prior version exists, catching silent value conflicts, mismatched values, missing rows, and orphan rows.

Instructions

Check an output table against the raw source it was built from, when there is no "before" to compare.

It catches a transformation that looks clean but decided something it had no basis for: the source
sent two different amounts for one key and the output kept one without saying so, values that no
longer match the source, source rows that never arrived, or output rows with no source at all.

Use this for a new table, a first load, or a dedupe or repair step, where compare_tables has nothing
to compare with. Use compare_tables when you do have the table from before the change; you can run
both for the strongest check.

Behavior: read-only and repeatable. The table and the source are each read once (files are opened
read-only; Snowflake, dbt and SQL sources run one SELECT each, with credentials already configured
on this machine) and loaded into a temporary in-memory DuckDB. Nothing is written anywhere. Usually
takes seconds. Fails with a readable error if a file, table, key or column does not exist.

Returns verdict ("pass", "review" or "block"), headline (one sentence you can show the user), and
tables: one entry with stats and findings, each with check, severity, message, column and metrics.
A "review" here usually means the source itself is ambiguous, so a person must choose; say so.

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": {
      "table": "<table>",
      "source": "<source>",
      "key": "<key>"
    },
    "name": "check_against_source"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	Column or columns that identify one row in the output, for example ["txn_id"].
`name`	No	Name to show for the table in the report. Defaults to 'table'.
`table`	Yes	The output table to check (for example a silver or gold table). A file path (.csv, .parquet, .json, .xlsx; CSV and JSON may be .gz or .zst), 'duckdb:<file.db>:<table or SELECT>', 'snowflake:<DB.SCHEMA.TABLE or SELECT>', 'dbt:<model>', or an object such as {"dbt": "fct_orders", "project_dir": "analytics", "target": "prod", "manifest": "prod-manifest.json"}, {"snowflake": "DB.SCHEMA.T", "connection": "name", "where": "..."} or {"url": "<SQLAlchemy URL>", "table": "schema.table"}. Relative paths are relative to the server's working folder.
`where`	No	SQL filter for the source rows that should reach the output, for example "status <> 'test'". Omit when every source row should.
`checks`	No	Which checks to run, from: conflict (the source has conflicting values for a key and the output silently kept one), mismatch (an output value differs from its source value), missing (a source key is absent from the output), orphan (an output key is absent from the source). Defaults to ["conflict"].
`source`	Yes	The raw input the output was built from (for example the bronze table or landing file). Same forms as 'table'.
`columns`	No	Columns to compare, as {output column: source column}, for example {"amount": "amt"}. Needed for the conflict and mismatch checks; omit to check only keys.
`source_key`	No	The key column or columns in the source, in the same order as 'key', when they are named differently. Omit if the names match.

Output Schema

Name	Required	Description	Default
`tables`	Yes
`seconds`	Yes
`verdict`	Yes
`version`	Yes
`headline`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the description is not carrying the safety profile alone. It nonetheless adds real context beyond them: each input is read once into a temporary in-memory DuckDB, Snowflake/dbt/SQL sources run a single SELECT with machine-configured credentials, nothing is written, and it fails with a readable error on missing file/table/key/column. It stops short of describing volume limits or what a large source does to the in-memory step, so it is strong but not maximal for an open-world tool.

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?

Front-loaded with the one-line purpose, then scenario, then behavior, then returns — a good order. Some content is redundant with the schema's `checks` enum (conflict/mismatch/missing/orphan are restated in prose), which costs a little, but the rest of the wording is dense and purposeful.

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?

Covers the hard parts an agent needs: the no-baseline premise, the read-once/no-write execution model, source-dialect credential assumption, failure mode, and how to interpret a 'review' verdict ('usually means the source itself is ambiguous, so a person must choose'). With an output schema present it need not detail return shape, yet the verdict/headline/tables summary is a useful orientation rather than filler.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond by giving the conceptual purpose behind the parameters — the 'source sent two different amounts for one key' example makes concrete what `columns` and `key` are for, and the no-before framing clarifies why both `table` and `source` are required. It does not add syntax or format detail for `where`, `checks` or `source_key` beyond the schema text.

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 ('Check an output table against the raw source') and immediately scopes it to the case where there is no 'before'. It names the sibling it is not — compare_tables — and explains the condition that selects each, so an agent can distinguish them without opening schemas.

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 ('a new table, a first load, or a dedupe or repair step'), explicit when-not ('use compare_tables when you do have the table from before'), and a combined-use suggestion ('you can run both for the strongest check'). Nothing is 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