What can you do with this server?

Scherlok is a data quality monitoring server that connects to your data warehouse, learns normal data patterns, and automatically detects anomalies — without writing any rules or configuration. * list_tables — Discover all tables visible through the configured warehouse connection, returning table names and a total count. * investigate — Profile one or more tables (or all tables) to establish a baseline snapshot of row counts, column types, NULL rates, distributions, freshness, and cardinality. The first run sets the "normal" benchmark; no anomalies are reported. * watch — Re-profile tables and compare against the stored baseline to detect anomalies such as volume drops/spikes, NULL surges, schema drift, distribution shifts, cardinality explosions, and freshness alerts — each scored as INFO, WARNING, or CRITICAL. * status — Get a quick health overview: connection target, visible table count, and anomaly counts from the last 30 days — without re-profiling. * history — Retrieve a log of anomalies recorded over the last N days (default 30) from the local profile store, without hitting the warehouse. * check — Run a full watch over all tables and return a CI-style pass/fail result, configurable to fail on critical (default) or warning-level anomalies — suitable for CI/CD pipelines.

Which integrations are available for this server?

Works with dbt to automatically profile and monitor data models after runs. Sends anomaly alerts via Discord webhooks. Connects to DuckDB databases for profiling and monitoring. Provides CI/CD integration with GitHub Actions to gate deployments on data quality. Supports remote storage of profile data in Google Cloud Storage. Connects to MySQL databases for profiling and monitoring. Connects to PostgreSQL databases for profiling and monitoring. Sends anomaly alerts via Slack webhooks. Connects to Snowflake databases for profiling and monitoring.

scherlok

by rbmuller

Overview Schema Related Servers Score Discussions

Python

Remote

Zero config. Zero YAML. Zero rules to write. Scherlok learns what "normal" looks like, then tells you when something changes.

The Problem

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.

Related MCP server: AnomalyArmor

The Solution

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.

After five valid profiles, Scherlok learns per-metric variability from the latest 30 profiles using robust historical baselines for volume, numeric mean shifts, NULL rates, and distinct counts. During cold start or when history is not usable, it keeps the conservative fixed defaults.

What It Catches

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 3+ standard deviations (Shewhart-style control limit)	INFO, WARNING above 5σ
Cardinality explosion	Status column went from 5 values to 500	CRITICAL

Every anomaly is auto-scored: INFO, WARNING, or CRITICAL. No thresholds to configure.

Works with dbt

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

The wrapper runs dbt run by default and uses the successful model nodes recorded in target/run_results.json, so partial runs profile only what dbt actually built. Use --build to run dbt build; successful models are still profiled when a test failure causes downstream models to be skipped on dbt's handled failure path (exit 1), while the wrapper preserves dbt build's exit code. Unhandled failures fail fast without reading the artifact.

Both dbt and dbt-run-and-watch accept --output json for CI parsers — a single JSON document on stdout, nothing else.

Supported adapters: postgres, bigquery, snowflake, mysql, duckdb. For others, pass --connection-string explicitly.

📖 Full docs: dbt integration guide →

dbt Package — native tests

Prefer staying inside dbt? Install Scherlok as a dbt package for native data quality tests — no Python CLI needed.

# packages.yml
packages:
  - package: rbmuller/scherlok
    version: [">=1.0.0", "<2.0.0"]

# schema.yml
models:
  - name: fct_orders
    tests:
      - scherlok.volume_anomaly:
          sensitivity: 3.0
      - scherlok.row_count_between:
          min_value: 100
    columns:
      - name: email
        tests:
          - scherlok.not_null_proportion:
              max_rate: 0.01
      - name: updated_at
        tests:
          - scherlok.recency:
              days: 2

Tier 1 — Instant (no setup): not_null_proportion, row_count_between, recency, unique_proportion

Tier 2 — Auto-learning (Shewhart control limits): volume_anomaly, null_anomaly — require the scherlok_metrics model to build baseline history.

📖 Full docs: dbt package README →

HTML dashboard

scherlok dashboard

scherlok dashboard --out report.html

One self-contained HTML file (~28 KB): KPIs, per-table incidents grouped with first-seen timestamps, +/−/~ schema-drift diff, sparklines, and full anomaly history. Auto dark/light theme via prefers-color-scheme.

📖 Full docs: dashboard guide →

Use it from an AI agent (MCP)

Let Claude Code / Claude Desktop run data-quality checks directly:

pip install scherlok   # scherlok-mcp ships built-in since v0.7.0

{
  "mcpServers": {
    "scherlok": {
      "command": "scherlok-mcp",
      "env": { "SCHERLOK_CONNECTION": "postgresql://user:pass@host/db" }
    }
  }
}

The agent gets list_tables, investigate, watch, status, history, and check as tools. Credentials are resolved server-side (never passed by the model), every operation is read-only on the warehouse, and there's no arbitrary-SQL tool.

📖 Full docs: MCP server guide →

AI-explained alerts (`--explain`)

Your alert says what broke. --explain adds why — and what to check next.

pip install 'scherlok[explain]'
export ANTHROPIC_API_KEY=sk-ant-...

scherlok watch --webhook https://hooks.slack.com/... --explain

When anomalies fire, Scherlok makes one Claude call for the whole batch and injects a short root-cause hypothesis into the same Slack/Discord/Teams/email/JSON alert:

Works on watch, ci, check, dbt, and dbt-run-and-watch. On dbt projects the hypothesis is lineage-aware: upstream parents from manifest.json go into the prompt, so cascading failures get traced to the source model instead of alerting on every downstream symptom.

What it costs — one call per fired run (not per anomaly), Claude Haiku 4.5 by default: well under a cent per run (~$0.003). Override the model with SCHERLOK_EXPLAIN_MODEL. Runs with zero anomalies make no API call.
What it sends — aggregates only: the anomaly type/severity/message strings already in your alert, dbt model names, detection timestamps. Never warehouse rows, cell values, or credentials — the test suite pins this as a contract.
How to turn it off — it's opt-in; don't pass --explain. If the API call fails (no key, timeout, rate limit), the original alert is delivered unchanged with a one-line note. Alerting never blocks on the LLM.

📖 Full docs: explainer guide →

How It Works

1. `investigate` — Learn the patterns

$ scherlok investigate

  Profiling 12 tables...
  ✓ users         — 45,231 rows, 8 columns
  ✓ orders        — 1,203,847 rows, 15 columns
  ✓ products      — 892 rows, 12 columns
  ...
  Done. Profiles saved.

Scherlok profiles every table: row counts, column types, NULL rates, value distributions, freshness cadence, cardinality. Stores everything locally in SQLite.

2. `watch` — Detect anomalies

$ scherlok watch

  Checking 12 tables against learned profiles...

  🔴 CRITICAL  orders    volume_drop     Row count dropped 52% (1,203,847 → 578,412)
  🟡 WARNING   users     null_increase   Column "email": NULL rate 2.1% → 18.7%
  🔵 INFO      products  distribution    Column "price": mean shifted 3.2σ

  3 anomalies detected. Exit code: 1

3. Alert — Slack, CI/CD, or both

# Slack
scherlok watch --webhook https://hooks.slack.com/services/...

# Discord
scherlok watch --webhook https://discord.com/api/webhooks/...

# Microsoft Teams
scherlok watch --webhook https://outlook.office.com/webhook/...

# Any endpoint (generic JSON payload)
scherlok watch --webhook https://my-api.com/alerts

# CI/CD gate (fails pipeline on CRITICAL)
scherlok watch --exit-code --fail-on critical

Auto-detects Slack, Discord, and Teams from the URL and formats the payload accordingly. Any other URL receives a generic JSON payload.

CI/CD Integration

Use Scherlok as a data quality gate. The ci command does it in one line:

# GitHub Actions
- name: Data quality check
  run: |
    pip install scherlok
    scherlok config --store s3://my-bucket/scherlok/profiles.db
    scherlok ci ${{ secrets.DATABASE_URL }} \
      --webhook ${{ secrets.SLACK_WEBHOOK }} \
      --fail-on critical

If Scherlok detects a critical anomaly, the pipeline fails. Bad data never reaches production.

Email alerts

export SCHERLOK_SMTP_HOST=smtp.gmail.com
export SCHERLOK_SMTP_USER=alerts@company.com
export SCHERLOK_SMTP_PASSWORD=app-specific-password

scherlok watch --email team@company.com --email cto@company.com

Connectors

# PostgreSQL
scherlok connect postgres://user:pass@host:5432/db

# BigQuery — see src/scherlok/connectors/bigquery.md for auth, billing, CI patterns
pip install scherlok[bigquery]
scherlok connect bigquery://project-id/dataset-name

# Snowflake
pip install scherlok[snowflake]
export SNOWFLAKE_USER=...
export SNOWFLAKE_PASSWORD=...
export SNOWFLAKE_WAREHOUSE=...
scherlok connect snowflake://account/database/schema

# MySQL
pip install scherlok[mysql]
scherlok connect mysql://user:pass@host:3306/dbname

# DuckDB
pip install scherlok[duckdb]
scherlok connect duckdb:///path/to/file.db

Database	Status
PostgreSQL	Available
BigQuery	Available
Snowflake	Available
MySQL	Available
DuckDB	Available

Remote Storage

Share profiles across CI runs and team members:

# AWS S3
scherlok config --store s3://my-bucket/scherlok/profiles.db

# Google Cloud Storage
scherlok config --store gs://my-bucket/scherlok/profiles.db

# Azure Blob Storage
scherlok config --store az://my-container/scherlok/profiles.db

Why Not [Other Tool]?

	Great Expectations	Soda	Monte Carlo	Scherlok
Setup time	Hours	30 min	Weeks	5 minutes
Config required	Hundreds of rules	YAML checks	Dashboard setup	None
Anomaly detection	Manual thresholds	Paid feature	Yes	Yes, free
Self-hosted	Yes	Limited	No (SaaS)	Yes
CI/CD gate	Yes	Yes	No	Yes
Price	Free	Freemium	$50-200K/yr	Free, forever

CLI Reference

scherlok connect <url>          Connect to a database
scherlok investigate            Profile all tables (learn patterns)
scherlok watch [-w <url>] [-e <email>]  Detect anomalies and alert
scherlok ci <url> [opts]        All-in-one CI/CD command (connect + watch + exit code)
scherlok dbt [--project-dir .] [--output json]  Profile dbt models from manifest
scherlok dbt-run-and-watch [--build] [--output json]  Run dbt + profile in one step
scherlok status [--output json] Quick health dashboard
scherlok history [--days N] [--output json]  Timeline of past anomalies
scherlok report                 Detailed profile summary
scherlok dashboard [--out .html] Generate self-contained HTML report
scherlok config --store <url>   Set remote storage
scherlok version                Show version

Install

pip install scherlok

# With BigQuery support
pip install scherlok[bigquery]

Requires Python 3.10+.

Run via Docker

A pre-built image with every warehouse extra (dbt, bigquery, snowflake) is published to GitHub Container Registry on every release tag:

docker run --rm ghcr.io/rbmuller/scherlok:latest version

Mount your project directory and inject connection details the same way your CI does it; the entrypoint is the scherlok CLI:

docker run --rm \
  -v "$PWD:/work" -w /work \
  -e SCHERLOK_CONNECTION=postgres://... \
  ghcr.io/rbmuller/scherlok:latest watch

The image is built from python:3.12-slim and runs unprivileged (USER scherlok).

Contributing

Contributions welcome! See CONTRIBUTING.md.

We're especially looking for:

New database connectors (e.g. Databricks — see #37)
Anomaly detection improvements
Documentation and examples

License

MIT — Developed by Robson Bayer Müller

Available Tools

6 tools

checkA

Run a watch over all tables and return a CI-style pass/fail gate.

fail_on is "critical" (default — fail only on CRITICAL) or "warning" (stricter — fail on WARNING or worse). Mirrors scherlok ci. Returns passed plus the severity counts the decision was based on.

ParametersJSON Schema

Name	Required	Description	Default
`fail_on`	No		critical

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions returning 'passed' and severity counts, and the fail_on effect. However, it does not explicitly state if the tool is read-only or if it has any side effects. The name 'check' implies non-destructive, but not confirmed.

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?

The description is very concise, using one short paragraph with two key pieces of information (purpose and parameter). Every sentence is functional, front-loaded with the main action.

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?

Given the tool has only one parameter and a simple output (with an output schema), the description is fairly complete. It covers the return value and parameter options. However, it doesn't elaborate on what 'watch' entails (e.g., one-time vs ongoing) or any prerequisites.

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?

The input schema has 0% description coverage, so the description must compensate. It explains the two values of 'fail_on' ('critical' and 'warning') and their meaning, adding value beyond the schema's bare type and default.

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?

The description clearly states the tool runs a watch over all tables and returns a pass/fail gate. The verb 'run' and resource 'all tables' are specific. It differentiates from siblings like 'watch' indirectly via the CI-style gate concept, but does not explicitly compare.

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

Usage Guidelines3/5

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

The description explains the fail_on parameter and that it mirrors `scherlok ci`, but it does not specify when to use this tool versus siblings like 'watch' or 'status'. There is no explicit when-not-to-use or alternative context.

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

historyA

Return anomalies recorded in the last days days (capped).

Reads from the local profile store — does not re-profile the warehouse.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

Discloses it reads from local profile store and does not re-profile the warehouse, indicating a non-destructive read operation, but lacks details on capping behavior, authorization, or data freshness.

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?

Two concise sentences: first states purpose, second adds behavioral context. Every word is necessary with no redundancy.

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

Completeness3/5

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

With only one simple parameter and an output schema present, the description covers the core idea but omits specifics about the cap, anomaly types, or result structure, leaving gaps for a complete understanding.

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?

Adds meaning by explaining the 'days' parameter specifies the time window, but does not elaborate on allowed values, range, or cap limit beyond what the schema indicates (default 30).

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?

Description clearly specifies the tool returns anomalies within a time range, using a specific verb ('Return') and resource ('anomalies recorded'), and distinguishes from siblings like 'check' and 'investigate' by focusing on historical data with a time constraint.

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

Usage Guidelines3/5

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

Implies usage for quick reads from local profile store without warehouse re-profiling, but no explicit when-to-use or contrast with siblings like 'investigate' which may also deal with anomalies.

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

investigateA

Profile tables and store them as the baseline for future anomaly checks.

Pass tables to limit to specific tables, or omit to profile everything visible. The first profile of a table establishes its baseline; no anomalies are reported here. Run watch later to detect drift.

ParametersJSON Schema

Name	Required	Description	Default
`tables`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions storing baselines (write operation) and that no anomalies are reported, but does not disclose permission requirements, side effects, or whether it overrides existing baselines.

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?

Two paragraphs that front-load the core purpose and smoothly explain the parameter and workflow. Every sentence provides value without redundancy.

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?

Given no annotations, a single optional parameter, and an output schema, the description covers the core workflow: profiling, baselines, and subsequent drift detection. Could be more complete about permissions or if the operation is reversible, but adequate for typical use.

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?

With 0% schema description coverage, the description adds crucial meaning: 'tables' limits profiling to specific tables, and omitting profiles everything visible. This goes beyond the bare schema.

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?

Clearly states the tool profiles tables and stores baselines for anomaly checks. Distinguishes from sibling 'watch' by noting that investigate establishes baseline and does not report anomalies.

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

Usage Guidelines5/5

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

Explicitly describes when to pass 'tables' vs omit, and directs to use 'watch' later for drift detection. Provides clear context and alternatives.

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

list_tablesA

List the tables visible to the configured warehouse connection.

Returns the table names (capped) and a total count. Use this to discover what can be profiled before calling investigate or watch.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, but description adequately explains behavior: lists tables, returns names and count. For a read-only listing, this is sufficient. Could mention if any authentication requirements exist, but not critical.

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?

Two sentences, each essential. First states action, second describes output and use case. No wasted words.

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

Completeness5/5

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

With no parameters and an output schema present, the description fully covers what the tool does, what it returns, and how it relates to siblings. Complete for a simple tool.

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?

No parameters, so baseline is 4. Description adds value by explaining return format and usage context, which complements the empty input schema.

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?

Clearly states the tool lists tables visible to the warehouse connection, specifies return values (capped names and count), and distinguishes from siblings by recommending use before investigate or watch.

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

Usage Guidelines4/5

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

Explicitly says to use this before investigate or watch, providing clear context. However, no mention of when not to use or alternatives for other siblings like check or history.

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

statusA

Report the current monitoring state.

Returns the connection target (password redacted), how many tables the connection can see, and how many anomalies were recorded in the last 30 days. A quick health glance without profiling anything.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry full behavioral context. It describes the output (connection target redacted, table count, anomalies) but does not explicitly state side effects (likely read-only) or any hidden behavior.

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?

Two sentences: the first states the purpose, the second lists key outputs. Every sentence adds value, and no redundant information is present. Front-loaded and efficient.

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

Completeness5/5

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

Given no parameters and presence of an output schema, the description explains the returned values (connection target, tables, anomalies) and the tool's purpose as a health glance. It is fully complete for a simple status tool.

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?

No parameters exist, so schema coverage is 100%. The description adds value by explaining what the tool returns, providing meaning beyond the empty schema and helping the agent understand the tool's output.

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?

The description clearly states it reports the current monitoring state and lists specific returned values (connection target, table count, anomaly count). It implies a quick health glance, distinguishing from siblings like 'investigate' or 'watch', but does not explicitly differentiate.

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

Usage Guidelines3/5

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

The description says it's a quick health glance without profiling, suggesting use for lightweight checks. No explicit when-not or alternatives are given, relying on implicit contrast with sibling tools.

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

watchA

Profile tables and detect anomalies against the stored baseline.

Returns the anomalies found (type, severity, message per table), capped. Pass tables to limit scope, or omit to watch everything. Tables with no prior baseline are profiled silently (their baseline is set for next time).

ParametersJSON Schema

Name	Required	Description	Default
`tables`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that tables without a prior baseline are profiled silently and their baseline is set for next time, indicating a write operation. However, it does not clarify whether the tool is read-only or destructive, nor does it specify the cap limit or potential side effects beyond setting baselines.

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?

The description is concise at four sentences. It front-loads the main purpose in the first sentence and provides necessary details without extraneous information. Every sentence adds value.

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?

Given the tool's simplicity (one optional parameter, output schema exists), the description covers the core functionality, parameter usage, and edge case (no baseline). It lacks details like the cap limit and what 'profile' entails, but these are minor given the output schema. A 4 is suitable.

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?

The input schema has 0% description coverage, but the tool description explains the parameter's purpose: 'Pass `tables` to limit scope, or omit to watch everything.' This compensates well, adding meaning beyond the schema's type definition. A 4 reflects strong compensation.

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?

The description clearly states the tool profiles tables and detects anomalies against a stored baseline. It specifies the return value (type, severity, message per table) and that results are capped. While the purpose is specific and distinct from siblings like 'check' or 'history', it does not explicitly differentiate itself, so a 4 is appropriate.

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

Usage Guidelines4/5

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

The description provides explicit guidance on the parameter: 'Pass `tables` to limit scope, or omit to watch everything.' It also explains behavior for tables without a baseline. However, it does not mention when to use this tool over siblings like 'check' or 'investigate', missing some usage context.

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. Dates show when Glama detected each change.

6 tool updatesJun 3, 2026
- First observedcheck
- First observedhistory
- First observedinvestigate
- First observedlist_tables
- First observedstatus
- First observedwatch

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: check is CI pass/fail, history retrieves past anomalies, investigate profiles and sets baseline, list_tables discovers tables, status gives health, watch detects anomalies against baseline. No overlap in functionality.

Naming Consistency4/5

All tool names are short, imperative verbs except for 'history' which is a noun. However, the naming is consistent in style and easy to understand, with no mixing of conventions like camelCase or snake_case.

Tool Count5/5

6 tools is appropriate for a data quality monitoring server. Each tool covers a necessary step in the workflow (discovery, profiling, detection, CI, history, status) without unnecessary bloat.

Completeness4/5

The tool set covers the core monitoring lifecycle: table discovery, profiling, baseline setting, anomaly detection, CI check, history, and status. Minor gaps exist, such as no tool for resetting baselines or managing anomalies, but these are manageable.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

GoldenCheck A
io.github.benseverndev-oss
Auto-discover validation rules from data — scan, profile, health-score. No rules to write.
Data Platforms Research & Data Databases
22
AnomalyArmorOAuth
ai.anomalyarmor
Data observability tools for engineering teams: alerts, freshness, schema drift, lineage, quality.
Monitoring Observability Data Platforms
21
mcpOAuth
ai.matih
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
Data Platforms Databases
2
Contextflo
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1

Related MCP Servers

bonnardofficial
Databases Data Platforms RAG Systems
bonnard-data
A
license
Not graded
quality
F
maintenance
Open-source agentic schema layer. Define metrics once in YAML, query governed data from any warehouse (Snowflake, BigQuery, Databricks, PostgreSQL, DuckDB) via MCP.
Updated 2 months ago (2026-07-03 10:52 UTC)
28
Apache 2.0
AnomalyArmor
Monitoring Observability Data Platforms
anomalyarmor
A
license
Not graded
quality
C
maintenance
Data observability for AI agents. Query alerts, monitor freshness, investigate schema drift, and trace lineage across your data warehouse via 53 MCP tools.
Updated 3 months ago (2026-05-30 04:17 UTC)
1
MIT
aegis-dqofficial
Databases AI & Machine Learning CI/CD & DevOps
aegis-dq
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.
Updated 3 months ago (2026-05-27 20:34 UTC)
6
4
Apache 2.0
dbt-doctor
Developer Tools Databases
Astoriel
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.
Updated 4 months ago (2026-05-02 14:18 UTC)
133
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/rbmuller/scherlok'

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

The Problem

The Solution

What It Catches

Works with dbt

dbt Package — native tests

HTML dashboard

Use it from an AI agent (MCP)

AI-explained alerts (--explain)

How It Works

1. investigate — Learn the patterns

2. watch — Detect anomalies

3. Alert — Slack, CI/CD, or both

CI/CD Integration

Email alerts

Connectors

Remote Storage

Why Not [Other Tool]?

CLI Reference

Install

Run via Docker

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

bonnardofficial

aegis-dqofficial

Latest Blog Posts

MCP directory API

AI-explained alerts (`--explain`)

1. `investigate` — Learn the patterns

2. `watch` — Detect anomalies