Ripplecheck MCP Server
The Ripplecheck MCP server is a counterfactual schema migration compiler that analyzes proposed DDL changes against a DataHub metadata graph. It provides the following capabilities:
Assess schema changes (
assess_schema_change): Submit Snowflake DDL or natural language to:Resolve DataHub entities, fields, types, tags, and documentation
Project a counterfactual after‑state graph and identify broken lineage edges
Evaluate stable policy rules (RC‑001 – RC‑044) with PASS/WARN/FAIL evidence
Return a release gate decision (OPEN/CLOSED) and bounded risk score
Generate a zero‑downtime execution DAG sequencing freeze, expand, compatibility, migration, and retirement steps
Route migration work to owners with coverage metrics
Optionally write back a hash‑sealed decision capsule (SHA‑256 provenance) to the DataHub column description
Produce a downloadable 6‑file PR evidence pack (compatibility SQL, dbt contract YAML, parity test, review evidence, owner routing, change capsule)
List demo scenarios (
list_demo_scenarios): Retrieve built‑in offline scenarios and their expected release decisions for testing and demonstration.Support both offline and live modes: Operates with deterministic synthetic DataHub snapshots or connects to an official DataHub MCP server; write‑back can be toggled.
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., "@Ripplecheck MCP ServerRename customer_tier to loyalty_tier on customer_360 and compile the migration"
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.
Ripplecheck
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.

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 8000Open 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
CLOSEDwith risk10/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
G0to retirement approvalG1;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:
Parse real DDL. Snowflake
ALTER TABLErenames, drops, and type changes are accepted alongside natural language.Ground the change.
searchandlist_schema_fieldsresolve the exact DataHub entity, field, type, tags, and description.Project the after-state.
get_lineageandget_entitiesproduce exact paths, predicted failure modes, ownership coverage, critical consumers, and hop depth without executing DDL.Prove policy. Stable rules
RC-001throughRC-044returnPASS,WARN, orFAILwith evidence and a measurable gate-open condition.Compile work. The execution DAG sequences freeze, expand, compatibility, consumer migrations, convergence proof, and human-approved retirement.
Create the handoff. A deterministic ZIP contains code, tests, decision evidence, owner routing, and SHA-256 provenance.
Persist memory.
update_descriptionappends 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 |
| Exact source entity and URN | Dataset resolution |
| Field type, documentation, and governance tags | Before-state and governed-field proof |
| Column-level downstream graph through 3 hops | Broken edges and exact failure paths |
| Owners, asset types, domains, platforms, and criticality | Owner routing, ML protection, coverage, and risk |
| 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 webEndpoints:
GET /healthGET /api/scenariosPOST /api/analyzeGET /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_changelist_demo_scenarios
python3 main.py mcpCopy .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 webThe 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 | BLOCK | Five consumers, production ML risk, one ownership gap, generated compatibility pack |
Rename finance | BLOCK | Critical executive finance dashboard and accountable finance owner |
Drop unused sandbox | SAFE | No downstream consumer edge, open gate, normal contract validation |
Checked-in deterministic outputs:
Regenerate through the real compiler path:
make samplesFixture 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.jsonThe ZIP is byte-for-byte deterministic for the same assessment. Its fixed timestamps and canonical JSON make review diffs stable.
Verify
make samples
make verifyVerification 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 --prodProduction 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 ripplecheckRender 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 toolsassess_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.
| Name | Required | Description | Default |
|---|---|---|---|
| change | Yes | Snowflake DDL or natural language, for example: ALTER TABLE warehouse.analytics.customer_360 RENAME COLUMN customer_tier TO loyalty_tier; | |
| writeback | No | Append the hash-sealed decision capsule to the DataHub column. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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
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.
Both tools follow the same verb_noun pattern (assess_schema_change, list_demo_scenarios), making the API predictable and easy to navigate.
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.
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
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
Monitor MCP servers, API contracts and AI outputs for schema drift. Alerts on breaking changes.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Paid remote MCP for schema drift checks, approvals, receipts, and release audit logs.
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
Related MCP Servers
- AlicenseBqualityDmaintenanceAgentic 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.64Apache 2.0
- AlicenseNot gradedqualityCmaintenanceAI-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.133MIT
- AlicenseAqualityAmaintenanceZero-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.69MIT

terrabaseofficial
AlicenseNot gradedqualityDmaintenanceLLM-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
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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