proofline-mcp
Proofline MCP is an evidence-based validation server that lets AI agents deterministically check whether pipeline outputs are semantically correct and get structured pass/fail evidence.
Compare a candidate taxi pipeline against a trusted reference using
validate_candidate_pipeline.Control benchmark scenarios via
seed,row_count, and injectedfaultssuch as duplicate rows, missing partitions, timezone shifts, and wrong zone mappings.Run domain-neutral geospatial semantic checks with
validate_geospatial_run.Verify invariants such as row counts, key sets, uniqueness, aggregates, distributions, write completion, shape presence, session parity, area drift, and Jaccard similarity.
Receive per-check evidence including expected value, actual value, status, and diagnostic context, plus an overall decision.
Use the deterministic results as a guardrail before accepting AI-generated pipeline changes or reporting a run as healthy.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@proofline-mcpValidate my candidate pipeline with timezone_shift and give me the evidence report."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 |
| Reproducible reference-versus-candidate validation using the public taxi-shaped benchmark |
| 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?"}The agent or automation supplies candidate output or an evidence envelope.
Proofline evaluates exact invariants: row counts, key sets, uniqueness, aggregates, distributions, write completion, shape presence, session parity, area drift, or Jaccard.
Each check records its expectation, observed value, status, and focused evidence.
The MCP tool returns an overall decision plus every individual check.
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.pyThe 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.tapeThis 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 .
pytestRun the local MCP server over stdio:
proofline-mcpExample 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.jsonDocker users can build the stdio server with:
docker build -t proofline-mcp .
docker run --rm -i proofline-mcp5. 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 toolvalidate_candidate_pipelineC
Compare a candidate taxi pipeline with a trusted reference and return evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| faults | No | ||
| row_count | No |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
validate_candidate_pipeline
TDQS
Scored across 1 tool
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.
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.
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.
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
Related MCP Connectors
MCP-native AI evaluation: rubric audits, eval suites, and proof reports for AI/LLM output.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables AI agents to programmatically inspect, test, and validate other MCP servers by exposing MCP Workbench capabilities as structured tools. It supports automated test spec generation, execution, and detailed failure analysis to ensure server reliability.411Apache 2.0

Patronus MCP Serverofficial
AlicenseNot gradedqualityDmaintenanceEnables running LLM evaluations, experiments, and custom evaluators through a standardized MCP interface.16Apache 2.0- FlicenseNot gradedqualityCmaintenanceEnables users to validate MCP servers, skills, extensions, and packages for schema, security, functional, and semantic quality directly from their MCP client.-
- FlicenseNot gradedqualityBmaintenanceEnables MCP-compatible AI clients to validate healthcare claims data quality by running completeness, integrity, and temporal checks on CSV files via five callable tools, including profiling and full scans.-