Skip to main content
Glama
sohamkamat28

Ripplecheck MCP Server

by sohamkamat28

Ripplecheck

test License Python

Ripplecheck is a counterfactual schema migration compiler powered by the DataHub MCP Server. Paste breaking warehouse DDL and it projects the metadata graph, proves a bounded release policy, routes an executable migration DAG to owners, writes a hash-sealed decision capsule back to DataHub, and generates a merge-ready PR evidence pack.

It runs with no API key, no paid billing, no network, and no Python dependencies. A synthetic DataHub snapshot makes the judge path deterministic and fully offline. Live mode swaps in the official DataHub MCP Server without changing the orchestration path.

Ripplecheck compiling a blocked rename into a counterfactual graph and PR evidence pack

Hackathon category: Agents That Do Real Work

Why: Ripplecheck does more than retrieve or summarize metadata. It makes a release decision, compiles owner-assigned migration work and code artifacts, and persists the result for the next engineer or agent.

Live judge demo: https://ripplecheck-datahub.vercel.app

Run the judge path

python3 main.py web --host 127.0.0.1 --port 8000

Open http://127.0.0.1:8000, leave the default DDL unchanged, and click Compile migration plan.

ALTER TABLE warehouse.analytics.customer_360
RENAME COLUMN customer_tier TO loyalty_tier;

Expected output:

  • release gate CLOSED with risk 10/10;

  • 5 broken lineage edges across a dbt model, Airflow flow, ML model, and 2 dashboards;

  • 4 failed policy rules, 1 ownership warning, and 80% owner coverage;

  • exact source-to-consumer lineage paths through 2 hops;

  • a 10-node zero-downtime execution DAG from freeze gate G0 to retirement approval G1;

  • an exact 5-call DataHub MCP trace and hash-sealed writeback;

  • a downloadable 6-file PR pack containing compatibility SQL, dbt contract YAML, a parity test, review evidence, owner routing, and a hash-addressed change capsule.

For recording, use the exact click-and-say demo runbook. It includes every click, screen state, narration line, timing, recovery step, architecture answer, and the requested tech-stack table in one document.

Judges can use the dedicated testing instructions, inspect the extracted generated examples, and review the project disclosures.

Real DataHub proof: the live transport was also verified end to end against DataHub OSS 1.6.0, the official showcase-ecommerce datapack, and mcp-server-datahub. It read 23 downstream assets and completed a real update_description writeback. See the reproducible live proof and machine-readable result.

Related MCP server: dbt-doctor

Why this is not a generic blast-radius bot

A blast-radius bot ends with a list. Ripplecheck compiles a controlled migration:

  1. Parse real DDL. Snowflake ALTER TABLE renames, drops, and type changes are accepted alongside natural language.

  2. Ground the change. search and list_schema_fields resolve the exact DataHub entity, field, type, tags, and description.

  3. Project the after-state. get_lineage and get_entities produce exact paths, predicted failure modes, ownership coverage, critical consumers, and hop depth without executing DDL.

  4. Prove policy. Stable rules RC-001 through RC-044 return PASS, WARN, or FAIL with evidence and a measurable gate-open condition.

  5. Compile work. The execution DAG sequences freeze, expand, compatibility, consumer migrations, convergence proof, and human-approved retirement.

  6. Create the handoff. A deterministic ZIP contains code, tests, decision evidence, owner routing, and SHA-256 provenance.

  7. Persist memory. update_description appends the capsule, evidence hash, blockers, affected URNs, and owners to the source column.

The release authority is deterministic. A model can later broaden request parsing or propose remediation, but it cannot silently override graph evidence or policy.

DataHub MCP flow

Call

Evidence loaded

Used by the compiler

search

Exact source entity and URN

Dataset resolution

list_schema_fields

Field type, documentation, and governance tags

Before-state and governed-field proof

get_lineage

Column-level downstream graph through 3 hops

Broken edges and exact failure paths

get_entities

Owners, asset types, domains, platforms, and criticality

Owner routing, ML protection, coverage, and risk

update_description

Mutation result

Hash-sealed, durable decision capsule

Offline mode implements these official names over data/catalog.json. Live mode speaks MCP JSON-RPC over stdio to the official server. Live errors never fall back silently to fixtures.

Architecture

flowchart LR
    D["Warehouse DDL"] --> P["Constrained parser"]
    P --> A["Ripplecheck compiler"]
    A --> M["DataHub MCP transport"]
    M --> F["Offline metadata graph"]
    M --> L["Official DataHub MCP Server"]
    A --> C["Counterfactual projection"]
    C --> R["Stable policy proof"]
    R --> G["Release gate and migration DAG"]
    G --> W["Hash-sealed DataHub writeback"]
    G --> Z["Six-file PR evidence pack"]

See docs/ARCHITECTURE.md for the transport boundary, capsule schema, policies, and safety properties.

Run modes

Web demo

python3 main.py web

Endpoints:

  • GET /health

  • GET /api/scenarios

  • POST /api/analyze

  • GET /api/evidence-pack/<run_id>

CLI

python3 main.py assess \
  "ALTER TABLE warehouse.analytics.customer_360 RENAME COLUMN customer_tier TO loyalty_tier;"

Use --no-writeback for a read-only run.

MCP server

Ripplecheck is itself an MCP stdio server:

  • assess_schema_change

  • list_demo_scenarios

python3 main.py mcp

Copy .mcp.json.example and replace its repository path to use it from an MCP-compatible client.

Live DataHub

Start DataHub OSS with the official Quickstart, create a personal access token, install uv, and then select the live transport:

export DATAHUB_GMS_URL="http://localhost:8080"
export DATAHUB_GMS_TOKEN="<your-local-datahub-token>"
export RIPPLECHECK_MODE=live
export DATAHUB_MCP_COMMAND="uvx mcp-server-datahub@latest"
export TOOLS_IS_MUTATION_ENABLED=true
python3 main.py web

The official DataHub Quickstart runs DataHub locally; the official MCP guide documents the uvx server and required environment variables. Mutation tools require MCP server v0.5.0+ and are opt-in. Clear TOOLS_IS_MUTATION_ENABLED and uncheck writeback for a read-only live assessment.

This exact path was verified on August 10, 2026 with DataHub OSS 1.6.0 and its official showcase-ecommerce datapack. The live proof records the input, observed metrics, five MCP calls, and successful writeback without publishing credentials.

Demo scenarios

Proposed change

Expected

Distinct proof

Rename customer_tier to loyalty_tier

BLOCK

Five consumers, production ML risk, one ownership gap, generated compatibility pack

Rename finance net_revenue

BLOCK

Critical executive finance dashboard and accountable finance owner

Drop unused sandbox legacy_bucket

SAFE

No downstream consumer edge, open gate, normal contract validation

Checked-in deterministic outputs:

Regenerate through the real compiler path:

make samples

Fixture names and email addresses are synthetic. All addresses use the reserved .example domain. Offline writebacks are saved to the gitignored data/run-state.json and reapplied for the current server.

Generated PR pack

The default ZIP is generated in memory and contains:

migration/compatibility_view.sql
models/customer_360/schema.yml
tests/assert_customer_tier_compatibility.sql
review/ripplecheck-decision.md
review/owner-routing.json
manifest/change-capsule.json

The ZIP is byte-for-byte deterministic for the same assessment. Its fixed timestamps and canonical JSON make review diffs stable.

Verify

make samples
make verify

Verification covers parsing, decisions, graph paths, policy rules, execution gates, durable writeback, MCP handshake, deterministic ZIP bytes, ZIP members, generated SQL, Python compilation, required files, sample shape, and public-copy checks. GitHub Actions runs the same path.

Deploy

Vercel production

The public judge deployment runs as a static frontend plus a dependency-free Python service:

vercel deploy --prod

Production URL: https://ripplecheck-datahub.vercel.app. The Vercel adapter preserves the local API contract and rebuilds evidence packs statelessly across serverless invocations. No secret or paid resource is required.

Docker

docker build -t ripplecheck .
docker run --rm -p 8000:8000 ripplecheck

Render Blueprint

Push the repository publicly, create a Render Blueprint from it, and use the generated onrender.com URL. render.yaml selects the free web plan, fixture mode, the native Python runtime, and /health; no secret is required.

Submission package

The deadline is August 10, 2026 at 5:00 PM EDT, or August 11 at 2:30 AM IST. The submission checklist targets an earlier upload window.

Scope and honesty

  • Fixture mode is a deterministic metadata snapshot, not a DataHub Cloud connection.

  • Live mode invokes the official DataHub MCP Server and uses its real results; the checked-in proof records a completed read-and-write run against DataHub OSS 1.6.0.

  • Ripplecheck never executes the submitted DDL.

  • Generated SQL and contracts are review artifacts, not automatically applied changes.

  • The risk score is an explainable bounded score, not a probability.

  • The default path uses no LLM, OpenAI API key, or paid service.

License

Apache License 2.0. See LICENSE.

For security reports and supported judge-testing dates, see SECURITY.md.

Available Tools

2 tools
assess_schema_changeB

Compile proposed DDL or a column change into a counterfactual DataHub graph, policy proof, release gate, migration DAG, and merge-ready evidence manifest.

ParametersJSON Schema
NameRequiredDescriptionDefault
changeYesSnowflake DDL or natural language, for example: ALTER TABLE warehouse.analytics.customer_360 RENAME COLUMN customer_tier TO loyalty_tier;
writebackNoAppend the hash-sealed decision capsule to the DataHub column.

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention the writeback parameter's default of true and its side effect of appending a hash-sealed capsule to a DataHub column, nor does it clarify whether the operation is read-only, requires permissions, or returns a specific format. The word 'counterfactual' hints at hypothetical analysis but is not explicit about side effects.

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 sentence that immediately opens with the verb 'Compile', making the primary action front-loaded. It is free of filler, though the dense list of outputs is jargon-heavy. Still, it is efficiently packed with useful information.

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?

This is a complex tool producing multiple artifacts, yet there are no annotations and no output schema. The one-line description does not explain operational context, side effects, when to use it, or any caveats. It also fails to mention the writeback behavior, which is a significant gap for a tool that appears to perform an assessment but may also mutate DataHub.

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?

The input schema already describes both parameters (change, writeback) with 100% coverage. The description adds context that 'change' accepts DDL or natural language, which aligns with the schema example, but it adds no additional meaning for 'writeback' beyond the schema. Baseline of 3 is appropriate since the schema handles the heavy lifting.

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 description uses a specific verb 'compile' with a clear resource ('proposed DDL or a column change') and enumerates concrete outputs (counterfactual DataHub graph, policy proof, release gate, migration DAG, evidence manifest). This makes the tool's function unmistakable and fully distinguishes it from the sibling 'list_demo_scenarios'.

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?

There is no guidance on when to use this tool, no mention of prerequisites, and no comparison with alternatives. The description only states what it does, not in what situations it should be selected over other tools like list_demo_scenarios.

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

list_demo_scenariosA

List the built-in offline scenarios and their expected decisions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It implies a read-only operation ('List') and notes scenarios are 'offline', but does not disclose return format, side effects, or any caveats. For a simple list tool, it is minimally adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It states the action and the object clearly and economically.

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

Completeness4/5

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

For a zero-parameter, no-output-schema list tool with a sibling, the description provides the core purpose and expected content. It is slightly vague about the format of 'expected decisions,' but overall it is reasonably complete for the tool's simplicity.

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?

There are zero parameters, so schema coverage is complete at 100%. The description does not need to elaborate on parameters; the baseline of 4 applies given the absence of parameters and no contradictions.

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?

Uses a specific verb ('List') and identifies the resource ('built-in offline scenarios'), and adds the output dimension ('expected decisions'). It is clear on its own, though it does not explicitly differentiate from the sibling tool 'assess_schema_change'.

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 on when to use this tool versus alternatives. The presence of a sibling tool ('assess_schema_change') makes the absence of explicit usage context more noticeable.

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

TDQS

B3.4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: assess_schema_change performs a complex analysis, while list_demo_scenarios provides test scenarios. No overlap or ambiguity exists.

Naming Consistency5/5

Both tools follow the same verb_noun pattern (assess_schema_change, list_demo_scenarios), making the API predictable and easy to navigate.

Tool Count3/5

With only two tools, the server feels minimally scoped. While appropriate for a niche utility, the count is on the thin side, making it harder to justify a standalone server.

Completeness3/5

The core assessment functionality is present, but the server lacks any management operations (e.g., listing past assessments, retrieving specific results), which limits its coverage of the full workflow.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Agentic data quality MCP server — runs structured validation rules against warehouses (DuckDB, BigQuery, Athena, Databricks, Postgres), diagnoses failures with LLM root cause analysis, and proposes SQL remediations. Full audit trail of every AI decision.
    6
    4
    Apache 2.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    AI-driven MCP server that audits, profiles, detects schema drift, and auto-generates documentation for dbt projects, enabling natural language interaction with your dbt project's health.
    133
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Zero-config data quality monitoring as MCP tools. Profiles a warehouse (Postgres, BigQuery, Snowflake, MySQL, DuckDB), detects anomalies, and gates CI — read-only with the connection resolved server-side, never via the model.
    6
    9
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    LLM-assisted, safety-gated Postgres migrations exposed as an MCP server, using a deterministic rule engine over Postgres's own parser AST for safety enforcement, with two-phase approval and append-only audit ledger.
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sohamkamat28/ripplecheck'

If you have feedback or need assistance with the MCP directory API, please join our Discord server