Skip to main content
Glama

1. What is Proofline MCP?

Proofline is an open-source validation control plane for agentic data pipelines. It gives coding agents and AI-assisted engineering workflows an MCP tool that answers a question conventional job status cannot:

The pipeline job says “success”—but did the correct data actually land in the correct place?

Proofline compares observed pipeline behavior with deterministic invariants or a trusted reference and returns a structured evidence report: pass/fail, expected value, actual value, and diagnostic context. An agent can call it before accepting a generated pipeline change, approving a deployment, or reporting that a run is healthy.

The server currently exposes two tools:

MCP tool

Purpose

validate_candidate_pipeline

Reproducible reference-versus-candidate validation using the public taxi-shaped benchmark

validate_geospatial_run

Domain-neutral semantic checks from orchestrator, worker, database, and spatial evidence

Related MCP server: Patronus MCP Server

2. Why does it exist?

AI coding agents can generate ingestion and transformation code quickly, but a syntactically valid change is not necessarily a semantically correct pipeline. Unit tests and orchestration status cover only part of the failure surface.

Proofline targets the semantic correctness gap in agentic data engineering:

  • Silent-success failures: the orchestrator is green while an expected row, partition, polygon, or aggregate was never produced.

  • Schema and data-contract drift: a generated transformation changes keys, cardinality, types, partitions, or null behavior without crashing.

  • Behavioral regression: candidate output differs from a golden dataset or last-known-good implementation even though both jobs complete.

  • Distributional drift: time buckets, geospatial areas, aggregates, and other population-level signals shift because of timezone, mapping, filtering, or join defects.

  • Weak agent feedback loops: coding agents see logs and exit codes, but lack deterministic, machine-readable evidence explaining what invariant failed.

  • Fragmented observability: orchestration metadata, worker status, database state, and output quality are checked independently instead of as one cross-system assertion.

  • Unverifiable AI-generated changes: an agent proposes code without attaching a reproducible evaluation record that a human or another agent can audit.

In AI-platform terms, Proofline acts as an eval and guardrail at the data-pipeline boundary. MCP makes that eval callable by any compatible agent, while deterministic checks keep the final decision outside the language model. Proofline complements logs, traces, unit tests, and data observability; it does not replace them.

3. How does it work?

flowchart TD
    A["Agent changes pipeline"] --> B["Reference or evidence"]
    B --> C["Deterministic invariants"]
    C --> D["Structured proof report"]
    D --> E["MCP response"]
    E --> F{"Accept change?"}
  1. The agent or automation supplies candidate output or an evidence envelope.

  2. Proofline evaluates exact invariants: row counts, key sets, uniqueness, aggregates, distributions, write completion, shape presence, session parity, area drift, or Jaccard.

  3. Each check records its expectation, observed value, status, and focused evidence.

  4. The MCP tool returns an overall decision plus every individual check.

  5. The caller can block acceptance on status: "fail" and use the evidence to diagnose or repair the pipeline.

Proofline's decision path is deterministic: the LLM chooses when to call the tool, but it does not decide whether a violated invariant passes.

Live product demo

The repository includes a real MCP demo client and a reproducible VHS recording specification. First verify the interaction directly:

python scripts/demo_live.py

The product video is a one-time documentation artifact, not a CI job. To record it locally, install VHS and FFmpeg, then run this command from the repository root:

vhs demo/proofline.tape

This records the real MCP stdio interaction as assets/proofline-demo.gif. The checked-in MP4 is derived from that recording with FFmpeg. Normal GitHub Actions remain dedicated to tests and benchmarks.

4. Setup instructions

Requires Python 3.11 or newer.

git clone https://github.com/Abhishek249/proofline-mcp.git
cd proofline-mcp

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

ruff check .
pytest

Run the local MCP server over stdio:

proofline-mcp

Example Cursor-compatible MCP configuration:

{
  "mcpServers": {
    "proofline": {
      "command": "/absolute/path/proofline-mcp/.venv/bin/proofline-mcp"
    }
  }
}

Restart the MCP client after changing its configuration. It should discover validate_candidate_pipeline and validate_geospatial_run.

Run the public proof and benchmark:

python scripts/prove_it.py
python scripts/benchmark_mcp.py --output benchmark-report.json

Docker users can build the stdio server with:

docker build -t proofline-mcp .
docker run --rm -i proofline-mcp

5. Results on NYC taxi-shaped trip data

The public benchmark generates deterministic taxi-shaped trips, executes a trusted reference and a candidate pipeline, and injects four known defect classes across four seeds and two dataset sizes. Every trial crosses a real MCP stdio client/server boundary.

View the successful GitHub Actions run · Read the permanent benchmark record

Verified signal

Result

Tests

12 passed

Code coverage

91%

MCP benchmark trials

40

Defect trials

32

Clean trials

8

Defects detected

32/32

Detection recall

100%

False-positive rate

0%

Required-diagnostic accuracy

100%

MCP call latency

3.213 ms p50 / 5.263 ms p95

Injected defect

Required evidence

Outcome

Duplicate records

Duplicate keys and row-count drift

Detected

Missing partition

Missing keys and aggregate drift

Detected

Timezone shift

Pickup-hour distribution drift

Detected

Wrong zone mapping

Per-zone fare aggregate drift

Detected

These results establish reproducibility for Proofline's published controlled fault model on a GitHub-hosted Ubuntu 24.04 runner with Python 3.12.14. They are not claims about arbitrary production pipelines. Validation against external, real-world geospatial infrastructure is a separate milestone.

Roadmap

  • Deterministic reference/candidate framework

  • Evidence-rich MCP tools

  • Controlled fault injection

  • Independent GitHub Actions proof and benchmark

  • Reusable geospatial evidence contract

  • Real public NYC TLC Parquet adapter

  • Pluggable PostgreSQL and orchestration adapters

  • Signed evidence bundles and OpenTelemetry traces

  • Policy-gated pull-request integration

  • Empirical evaluation and research paper

Proofline is an early research prototype and is not yet a production quality gate. Contributions, fault cases, and benchmark improvements are welcome.

Available Tools

1 tool
validate_candidate_pipelineC

Compare a candidate taxi pipeline with a trusted reference and return evidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo
faultsNo
row_countNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description alone must disclose side effects and operational behavior. It only says 'compare' and 'return evidence,' but does not clarify whether the pipeline is executed, whether the operation is read-only, or what the evidence consists of.

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?

The description is a single, front-loaded sentence with no filler. It is concise, but the brevity contributes to important missing details about behavior and parameters.

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

Completeness2/5

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

Given three parameters, no annotations, no output schema, and no sibling tools, the description is too thin. It does not define what the returned 'evidence' looks like, what 'trusted reference' means, or what the parameters control.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain seed, faults, or row_count, nor how they affect the comparison. The enum values for faults hint at their meaning, but the description adds no parameter-level semantics.

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

Purpose4/5

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

States a specific action: compare a candidate taxi pipeline with a trusted reference, then return evidence. The verb and object are clear, though 'trusted reference' and 'pipeline' remain somewhat domain-specific and undefined.

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

Usage Guidelines2/5

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

No guidance about when to use this tool versus alternatives, no prerequisites, and no mention of when it should not be used. The only implicit cue is that it is for validating a candidate pipeline.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedvalidate_candidate_pipeline

TDQS

C2.3/5.0

Scored across 1 tool

Disambiguation1/5

With only one tool, there is no possibility of ambiguity between tools. However, the tool set is so minimal that the single tool must serve all purposes, which can lead to confusion about what it actually does despite its description.

Naming Consistency3/5

The single tool name 'validate_candidate_pipeline' follows a verb_noun pattern and is descriptive. However, with only one tool, it's hard to assess consistency across a set; it scores a neutral 3.

Tool Count1/5

One tool is extremely thin for a server named 'proofline-mcp'. The purpose seems to be validating pipelines, but a single tool likely cannot handle the full scope of validation, comparison, and evidence retrieval without additional supporting operations.

Completeness1/5

The server provides only one operation, which likely requires multiple steps (e.g., retrieving reference, comparing, generating evidence). Without additional tools for setup, retrieval, or even getting evidence details, the surface is severely incomplete for a meaningful workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers