Zero-config data-quality monitoring: profile a warehouse, detect anomalies, gate CI.
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"io-github-rbmuller-scherlok": {
"command": "<see-readme>",
"args": []
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
Scherlok makes sure it doesn't happen next time.
No automated test available for this server. Check the GitHub README for setup instructions.
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
No package registry to scan.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in ecommerce
Production-grade MCP server and CLI tool for Shopify Admin GraphQL API — 49+ tools, YAML-extensible, dual auth, dual transport, Docker-ready
A command line tool for setting up commercetools MCP server
35+ AI tools for TCG card grading, Monte Carlo pricing, 370K+ product search. BYOK.
This is the reference implementation for the mcp server
MCP Security Weekly
Get CVE alerts and security updates for io.github.rbmuller/scherlok and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
Zero config. Zero YAML. Zero rules to write.
Scherlok learns what "normal" looks like, then tells you when something changes.
Every data team has the same nightmare:
A source API silently changes from dollars to cents. Revenue dashboards show wrong numbers for 3 weeks before anyone notices.
A column starts returning NULLs. A table stops updating. Row counts drop 40% on a Tuesday. Nobody knows until the CEO asks why the report looks weird.
Current tools (Great Expectations, Soda, dbt tests) require you to define what "correct" looks like before you can detect what's wrong. Hundreds of rules. Dozens of YAML files. And you still miss things — because you can't write rules for problems you haven't imagined yet.
Scherlok takes the opposite approach: learn first, then detect.
scherlok connect postgres://user:pass@host/db # connect once
scherlok investigate # learn your data
scherlok watch # detect anomalies
Three commands. Five minutes. Done.
| Anomaly | What Happened | Severity |
|---|---|---|
| Volume drop | Row count dropped 40% overnight | CRITICAL |
| Volume spike | 3x more rows than normal | WARNING |
| Freshness alert | Table hasn't updated in 12h (normally every 2h) | CRITICAL |
| Schema drift | Column removed or type changed | CRITICAL |
| NULL surge | NULL rate jumped from 2% to 45% | WARNING |
| Distribution shift | Column mean shifted 5+ standard deviations | WARNING |
| Cardinality explosion | Status column went from 5 values to 500 | CRITICAL |
Every anomaly is auto-scored: INFO, WARNING, or CRITICAL. No thresholds to configure.
Already running dbt? Scherlok complements dbt test with automatic anomaly detection — no rules to write.
pip install scherlok[dbt]
# After `dbt run`, point Scherlok at your project
scherlok dbt --project-dir ./my_dbt_project
Scherlok reads target/manifest.json, discovers every materialized model (table, incremental, view), auto-resolves the connection from your profiles.yml, and profiles each model:
Investigating 4 dbt models in ./my_dbt_project (postgres)
✓ stg_customers (12,345 rows)
✓ stg_orders (98,765 rows)
✗ fct_orders CRITICAL: Row count dropped 42% (98,765 → 57,283)
✓ dim_customers_inc (12,300 rows)
Summary: 4 profiled, 1 anomalies (1 critical, 0 warning)
Use it as a CI gate after dbt run:
- run: dbt run --target prod
- run: scherlok dbt --project-dir . --target prod --fail-on critical
Or collapse both steps into one with the wrapper:
- run: scherlok dbt-run-and-watch --project-dir . --target prod --fail-on critical
Supported adapters: postgres, bigquery, snowflake, mysql, duckdb. For others, pass --connection-string explicitly.
📖 Full docs: dbt integration guide →
![scherlok dashboard](https://raw.githubusercontent.com/rbmuller/scherlok/HEAD/assets/dashboard-screens