pipeverify

Overview Schema Source Related Servers Discussions Admin

run_config

Read-onlyIdempotent

Check every table listed in a project's pipeverify config and return one overall pass, review or block verdict, so you see the same result your CI will report before pushing.

Instructions

Check every table listed in a project's pipeverify.yml and return one overall verdict.

Use this when the project already has a pipeverify config, which is the same check its CI runs, so
you see what the pull request check will say before you push. Use compare_tables for a one-off
comparison of two snapshots without a config file.

Behavior: read-only and repeatable. Reads the config, then reads each table's snapshots (files,
DuckDB, Snowflake, dbt models or SQL databases, using credentials already configured on this
machine) into a temporary in-memory DuckDB. Nothing is written anywhere. Time grows with the number
and size of the tables. A table that cannot be read is reported as "block" with the reason in its
error field, and the remaining tables are still checked. Fails with a readable error if the config
file is missing, is not valid, or no table matches.

Returns verdict (the worst across tables: "pass", "review" or "block"), headline, and tables: one
entry per table with its own verdict, stats, error and findings. Tell the user every review and
block finding.

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_config"
  }
}

Input Schema

Name	Required	Description	Default
`config`	No	Path to a pipeverify config file, usually pipeverify.yml in the project root. It lists each table with its before, after, key and options.	pipeverify.yml
`tables`	No	Only check the tables with these names (the 'name' entries in the config). Omit to check every table.

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.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent and non-destructive, and the description corroborates rather than repeats by explaining the mechanism: config is read, each table's snapshots are loaded into a temporary in-memory DuckDB, and nothing is written anywhere. It goes further with cost expectations (time grows with table count and size), partial-failure semantics (an unreadable table becomes 'block' with an error while the rest still run), and explicit error cases for missing/invalid config or no matching table.

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 purpose, then usage, then a clearly labelled 'Behavior:' block and a returns section, which is easy to scan. It runs a few sentences longer than needed — the source list in parentheses and the return-field recap overlap with the output schema — but nothing is genuinely wasted.

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 config-driven, multi-backend check with an output schema, the description still covers the things structured fields cannot: cost scaling, per-table failure isolation, credential assumptions ('credentials already configured on this machine'), and the instruction to surface every review and block finding. An agent has enough to call it correctly and to report results.

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 both the config path and the tables filter are already documented with defaults and meaning. The description mentions the no-matching-table error, which lightly touches the filter, but adds no syntax, format, or precedence detail beyond the schema — the baseline 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?

Opens with a specific verb and resource: 'Check every table listed in a project's pipeverify.yml and return one overall verdict.' It also distinguishes itself from the sibling compare_tables by naming what that tool does instead, so an agent can choose without opening a 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?

Explicitly states the selecting condition ('when the project already has a pipeverify config') and adds a strong reason to prefer it (it is the same check CI runs, so results preview the PR check). It also names the alternative and its condition: compare_tables for a one-off comparison without a config file.

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

Deploy Server