A
licenseA
qualityD
maintenanceA Model Context Protocol (MCP) server that wraps the dbt CLI tool, enabling AI coding agents to interact with dbt projects through standardized MCP tools. Developed by Mammoth Growth.
9
18
MIT
dbt-mcp
by qraza
Use this MCP server to inspect a dbt project's run state and diagnose failures. Capabilities include:
run_summary – Summarize the most recent dbt run: how many tests failed and their names.
list_failing_tests – List each failing test, what it guards, failed row counts, and whether it is generic or hand-written.
sample_failing_rows – Fetch the actual rows that caused a test to fail, capped by a limit.
explain_failure – Get an AI-generated root cause, fix suggestion, and confidence grounded in those rows.
model_lineage – Find a model's upstream dependencies, downstream dependents, and blast radius.
test_history – See whether a failure is new or long-standing and its trend.
health – Check configuration, artifact availability, warehouse connectivity, and manifest/warehouse consistency.
usage_stats – Summarize structured call logs for tool usage, latency, and errors.
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., "@dbt-mcpwhat failed in the last dbt run?"
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.
sentinel-mcp
Ask your dbt project what's wrong, in plain English. An MCP server that exposes a dbt project's run state as tools, so an AI assistant composes its own answers to questions like "is the warehouse healthy?" or "what broke and why?" — no orchestration written by hand.
Built on dbt-sentinel, which does the artifact parsing, row sampling and grounded analysis.
Tools
Tool | Answers | Uses AI? |
| What failed in the last run, at a glance | No |
| Each failure: what it guards, rows, test type | No |
| The actual offending rows, capped | No |
| Root cause, fix and confidence, grounded in those rows | Yes |
| What a model depends on, what depends on it, blast radius | No |
| New breakage or long-standing, with trend | No |
| Config, connectivity, and manifest/warehouse consistency | No |
| Call counts, latency, errors, estimated time saved | No |
Only one tool calls a model. Lineage, history and summaries are deterministic lookups — using an LLM for them would add cost, latency and risk for no benefit.
Related MCP server: @us-all/dbt-mcp
Quickstart
uv sync
export DBT_TARGET_DIR=/path/to/dbt/target
export DBT_DUCKDB_PATH=/path/to/warehouse.duckdb # or BQ_PROJECT=my-project
export ANTHROPIC_API_KEY=sk-ant-... # only needed for explain_failure
uv run sentinel-mcpRegister it with Claude Code:
claude mcp add sentinel-mcp \
-e DBT_TARGET_DIR=$DBT_TARGET_DIR \
-e DBT_DUCKDB_PATH=$DBT_DUCKDB_PATH \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
-- uv run --directory /path/to/sentinel-mcp sentinel-mcpOr inspect it interactively:
npx @modelcontextprotocol/inspector \
-e DBT_TARGET_DIR=$DBT_TARGET_DIR \
-e DBT_DUCKDB_PATH=$DBT_DUCKDB_PATH \
uv run sentinel-mcpWhat it looks like in use
Asked "Is my dbt project healthy? If not, what broke, why, and what's the blast
radius?", an agent called run_summary, list_failing_tests, sample_failing_rows,
explain_failure and model_lineage in sequence. None of those were named in the
question — that composition is the point of exposing tools rather than a fixed CLI.
It then did something better than answer: it cross-checked the diagnosis against the repository, found that the model's source already contained the correct formula, and concluded the manifest being analysed was a stale snapshot — so the confident, internally-consistent diagnosis described SQL that was no longer deployed.
That finding produced the staleness guard now in health: a manifest older than 24
hours is flagged, because its compiled SQL may no longer match the warehouse. A tool
that can be confidently wrong should say when its inputs are suspect.
Configuration
Variable | Purpose |
| dbt |
| DuckDB warehouse file |
| BigQuery alternative |
| Snowflake (key-pair auth); optional |
| Required only by |
| dbt-sentinel history database (defaults to |
The server deliberately does not read a .env file: MCP clients pass environment
explicitly in their config, so configuration has exactly one source.
Design decisions
Why MCP rather than a CLI. A CLI answers the question you anticipated. MCP tools let an agent compose answers to questions you didn't — it picks the tools and the order.
Thin tools, not one catch-all. Each does one legible thing so a model can reason about when to use it. The docstrings are the interface: they become the descriptions the model reads when choosing.
AI only where it earns its place. Seven of eight tools are deterministic. Only root-cause explanation needs a model.
Read-only by contract. The warehouse is opened read-only; this inspects, never mutates.
Errors are messages, not stack traces. Missing config returns "DBT_TARGET_DIR is not set; point it at a dbt target/ directory" — something an agent can act on and recover from.
Status
Complete: eight tools, a data-quality-brief Claude Skill, structured call logging with
usage measurement, self-contained tests, and CI on Python 3.11 and 3.12. Verified against a
real dbt project via MCP Inspector and Claude Code.
Related projects
dbt-sentinel — the library underneath this server, published on PyPI; does the artifact parsing, row sampling and grounded analysis.
taxi-analytics-pipeline — the dbt project used to verify it end to end.
Development
uv sync --group dev
uv run ruff check .
uv run pytest -vTests build their own dbt fixtures in a temp directory — no warehouse, no API key, no sibling repository required.
Observability and measurement
Every tool call is appended to a structured log (.sentinel-mcp/calls.jsonl by default,
override with DBT_MCP_LOG): tool name, duration, status, truncated arguments, and any
error. usage_stats summarises it.
Logging never writes to stdout. Under stdio transport stdout carries the MCP protocol itself, so anything else written there corrupts the JSON-RPC stream. Records go to a file; logging failures go to stderr and never break a tool call.
Observed on a real dbt project:
Metric | Value |
p50 latency | ~4 ms |
p95 latency | ~11 s |
Deterministic tools | ~4 ms |
| ~11 s |
That 2,500x gap is why only one of eight tools uses a model. Lineage, history and run summaries are graph and file lookups; routing them through an LLM would add latency and cost for no gain in accuracy.
Time saved is estimated, not measured. The figure counts completed diagnoses against
a stated baseline (MANUAL_BASELINE_MINUTES, default 15 — roughly how long it takes to
open run_results.json, cross-reference manifest.json, and query the warehouse by hand).
An earlier version counted every tool call, which overstated the benefit roughly five-fold,
since one question costs several calls.
Available Tools
4 toolshealthA
Check that the server is configured correctly and can reach its inputs.
Verifies the target directory, the required artifacts, and warehouse connectivity.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly lists the checks performed, which implies a read-only health check. It does not detail return format or permission requirements, but given the nature of a health check, this is reasonably transparent.
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 two sentence long, front-loaded with the primary action, and provides specific details without any wasted words. Every sentence contributes to the understanding of the tool's purpose.
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?
For a simple health check with zero parameters and an output schema, this description adequately covers the purpose and the specific checks. It is complete enough for an agent to select and invoke the tool correctly, and the output schema handles return-value details.
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 tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and it doesn't. Baseline score of 4 for parameter-less tools is appropriate.
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 clearly states the tool's function with a specific verb ('Check') and resource ('server configuration and inputs'). It lists concrete checks (target directory, artifacts, warehouse connectivity), which distinguishes it from sibling tools like run_summary, list_failing_tests, and sample_failing_rows that deal with test outputs rather than system health.
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 implies use for verifying system readiness but provides no explicit guidance on when to choose this tool over alternatives, nor does it mention exclusions or prerequisites. The context is clear but lacks direct 'use this when' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_failing_testsA
List every failing test in the last dbt run, with what it guards.
Returns the test name, the model and column it protects, how many rows failed,
and whether it is a generic (not_null, unique...) or hand-written test.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope and the kind of output, but it does not mention that this is a read-only operation, what happens if no run exists or no tests fail, or any permissions/dependencies. Since an output schema exists, the description's enumeration of return fields is partly redundant, but the 'generic vs hand-written' distinction adds useful semantic context.
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 and well-structured: the first sentence states the primary purpose, and the second elaborates on the output. It is front-loaded with the core action and contains no filler or redundant wording.
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?
For a simple, zero-parameter tool with an output schema, the description is complete enough. It captures the essential purpose, scope, and distinguishing return information. No key context appears missing.
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 tool has zero parameters, so the empty schema has 100% coverage. According to rubric, 0 params gives a baseline of 4. The description does not need to explain parameters, and it doesn't introduce confusion.
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 ('List') and resource ('failing tests') with clear scope ('in the last dbt run'). It also enumerates returned fields (test name, model/column, rows failed, generic vs hand-written), making it unambiguous and distinct from siblings like sample_failing_rows and run_summary.
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 gives clear context for when this tool applies ('last dbt run' and listing all failures), but it does not explicitly mention alternatives or scenarios where a sibling tool like sample_failing_rows would be preferable. Thus it has clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_summaryA
Summarise the most recent dbt run: how many tests failed, and their names.
Use this first to judge overall health before drilling into any one failure.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (summarising recent run, test failure count and names) and the 'most recent' scope. It doesn't detail side effects, but for a read-only summary, this is adequate.
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, front-loaded with the action and key output. The second sentence adds actionable usage context without unnecessary detail. Very concise and well-structured.
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?
The tool is simple and zero-parameter. The description covers purpose, scope, and usage order. An output schema exists, so return details are not needed in the description. The guidance to use first provides necessary context for a health-check step.
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 tool has zero parameters, so schema coverage is 100% vacuously. Per guidelines, 0 params earns a baseline 4. The description adds no parameter information, which is appropriate since none exist.
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 clearly states the tool summarises the most recent dbt run, specifically how many tests failed and their names. This is a specific verb+resource combination that distinguishes it from sibling tools like list_failing_tests and sample_failing_rows.
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 instructs to use this tool first to judge overall health before drilling into any one failure, providing clear when-to-use guidance and implying it precedes more detailed tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sample_failing_rowsA
Fetch the actual rows that caused a test to fail.
Args:
test_name: the test's name or unique_id, as returned by list_failing_tests.
limit: maximum rows to return (kept small on purpose).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| test_name | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that the tool fetches rows and that the limit is intentionally small. It also implies the operation is read-only via the verb 'Fetch'. However, it does not describe error behavior for invalid test_name, response format, or what happens when no rows exist. This leaves some transparency gaps, but the provided details are meaningful.
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 succinct and well-structured. It opens with a one-sentence purpose, followed by a clear Args list. Every sentence earns its place, with no fluff or repetition. The format is front-loaded and easy to parse.
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 output schema is present, the description does not need to detail return values. It covers the tool's purpose, parameter semantics, and usage sequence, which is sufficient for a simple read operation. It could mention edge cases (e.g., no failing rows) but these are likely covered by the output schema. Overall, it is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema descriptions are absent (0% coverage), the description's Args section compensates fully. It explains test_name as 'the test's name or unique_id' from list_failing_tests, and limit as 'maximum rows to return (kept small on purpose)'. This adds meaning beyond the bare schema and clarifies how to supply each parameter correctly.
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 clearly states the tool's function: 'Fetch the actual rows that caused a test to fail.' This is a specific verb+resource combination that distinguishes it from sibling tools like list_failing_tests (which lists tests) and run_summary (which provides summaries). The purpose is unambiguous and immediately recognizable.
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 usage context by stating test_name is 'as returned by list_failing_tests', indicating the workflow of calling list_failing_tests first. It also adds the caution that limit is 'kept small on purpose', setting expectations for output size. However, it does not explicitly state when not to use this tool or mention alternative tools for other scenarios, so it falls short of a perfect score.
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.
4 tool updates
v0.1.0- First observed
health - First observed
list_failing_tests - First observed
run_summary - First observed
sample_failing_rows
TDQS
A4.5/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: run_summary provides a high-level overview, list_failing_tests enumerates failures in detail, sample_failing_rows retrieves offending rows, and health checks configuration. Even though run_summary and list_failing_tests both relate to failing tests, they operate at different levels of detail, leaving no ambiguity.
Naming Consistency4/5
Most tool names follow a consistent verb_noun pattern (run_summary, list_failing_tests, sample_failing_rows). However, 'health' breaks the pattern as a single noun rather than a verb_noun construct, a minor but noticeable deviation.
Tool Count5/5
With 4 tools, the server is well-scoped for its purpose of analyzing dbt test failures. Each tool earns its place, and the count is appropriate for a focused domain without feeling thin or bloated.
Completeness5/5
The tool set covers the full workflow: verifying setup (health), getting a summary (run_summary), drilling into failures (list_failing_tests), and examining specific rows (sample_failing_rows). No obvious missing operations within the stated scope.
Maintenance
ActivityMaintained
ResponsivenessNo issues
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
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
The Buildkite MCP server exposes Buildkite product data (pipelines, builds, jobs, and test data) to AI tools, editors, and agents through the Model Context Protocol. It provides capabilities including pipeline creation and management, build monitoring with specialized tools like 'wait_for_build', efficient log querying using Apache Parquet conversion and caching, and OAuth-based authentication for both read-write and read-only access to Buildkite's REST API.
Related MCP Servers
- AlicenseBqualityAmaintenanceA read-only MCP server that exposes dbt project artifacts and data quality result tables (BigQuery/Postgres) to LLM clients, enabling deep introspection, run-history analysis, source freshness, test coverage, and lineage walks.2774MIT
- 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
- AlicenseNot gradedqualityDmaintenanceMCP server that provides tools to interact with dbt, including dbt Core, Cloud CLI, Semantic Layer, and Discovery API.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/qraza/sentinel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server