dbt MCP vs DBHub vs MotherDuck: Best Data Skill 2026

Three MCP servers keep showing up when people wire Claude Code into a data stack, and they are not substitutes for each other. dbt MCP talks to your transformation layer. DBHub talks to your database. MotherDuck talks to DuckDB. Pick the wrong one for your problem and you'll spend an afternoon wondering why the agent can't see your models.

Here's where each one actually fits, with install commands and the security posture you should know before granting any of them database access.

Quick comparison

All three are free and all three are actively maintained. The meaningful split is the middle two rows.

Install commands

claude mcp add dbt-mcp -- npx -y dbt-labs/dbt-mcp

claude mcp add dbhub -- npx -y bytebase/dbhub

claude mcp add mcp-server-motherduck -- npx -y motherduckdb/mcp-server-motherduck

Repos, if you want to read the source before running any of them, which you should since all three take credentials: dbt-labs/dbt-mcp, bytebase/dbhub, motherduckdb/mcp-server-motherduck.

dbt MCP: for people who already run dbt

This one is narrow on purpose. It exposes your dbt project to the agent: models, lineage, tests, the compiled SQL. Maintained by dbt Labs themselves, which is the strongest argument for it.

The workflow it unlocks is the one dbt users complain about most: asking "what breaks if I change this model" and getting an answer that accounts for the actual DAG rather than a grep. Lineage questions are where an agent with dbt context pulls clearly ahead of an agent with database context.

It is useless if you don't run dbt. There's no fallback mode, no generic SQL path. That sounds obvious until you watch someone install it hoping for general data-warehouse help.

Worth flagging: at 596 stars with an unreviewed security status, this is a young project carrying a big-name maintainer. The dbt Labs badge is real, but it hasn't been through independent security review. Scope the credentials accordingly.

DBHub: the general-purpose pick

DBHub is the one I'd install first if I only installed one. It speaks Postgres, MySQL, SQL Server and several others through a single server, and it's the only entry here at verified trust tier with a community-reviewed security status.

The description calls it zero-dependency and token-efficient, and the second half of that matters more than it sounds. A database MCP server that dumps entire schemas into context burns your window on table definitions you didn't ask about. DBHub is deliberately economical about what it returns, which shows up as more room for actual reasoning on long sessions.

At 3,365 stars it also has the widest usage of the three, and Bytebase maintains it as part of a database-tooling business rather than as a side project. Maintenance incentives are worth checking before you wire something into production credentials.

If your question is "I have a database and I want Claude to help me query it," this is the answer.

MotherDuck: local analytics without a warehouse

MotherDuck's server connects to DuckDB, either a local file or MotherDuck's hosted service. That makes it the odd one out, because DuckDB isn't a database you run for an application. It's an analytics engine you point at files.

The use case is ad-hoc analysis on data that doesn't live in a warehouse. Parquet files on disk, a CSV export somebody dropped in a folder, a few million rows you don't want to load into Postgres just to answer one question. DuckDB handles those well and the MCP server gives the agent a way to run the queries.

It's the least mature of the three at 506 stars, and it went longest without an update: 2026-07-27, roughly three weeks behind the other two at the time of writing. Not alarming for a project this size, but worth noting if you like your dependencies busy.

Which one to install

Run dbt in production? dbt MCP, plus DBHub. They cover different layers and don't conflict, so the agent can read your model definitions from one and query the warehouse through the other.

Have a Postgres or MySQL database and no dbt? DBHub alone. Adding the others gains you nothing.

Doing analysis on files rather than a database? MotherDuck. This is the case the other two handle badly.

Working across Snowflake or ClickHouse specifically? Neither of those is covered well here — look at mcp-snowflake-server or ClickHouse Analytics instead. ClickHouse Analytics is verified tier and community-reviewed, which puts it in better standing than the Snowflake option.

For a related angle on querying data without standing up a database at all, Musoq runs SQL against arbitrary sources and is a genuinely odd tool worth ten minutes of your time.

What none of them do

None of these three orchestrate anything. They give an agent read and query access to a system you already run. If your pipeline is broken at 3am, an MCP server does not fix it, and no amount of agent access substitutes for Airflow, Dagster, or whatever schedules your jobs.

They also don't give the agent judgment about data quality. An agent querying through DBHub will happily report a number from a table that stopped refreshing four days ago, because nothing in the protocol tells it about freshness. If staleness matters for your use case, put freshness metadata somewhere the agent will actually look rather than hoping it asks.

And none of them solve the permissions problem for you. Handing an agent a credential means every query it decides to run happens under that credential. Scope it deliberately.

A note on cost that isn't money

Each MCP server you register advertises its tool definitions to the agent at session start. Three servers means three sets of definitions occupying context before you have typed anything.

This is the strongest practical argument for installing only what you use. It's tempting to add all three because they're free, and free is true of the license but not of the context window. On a codebase where you're already pushing against your window, dropping an unused server is a cheaper win than most prompt tuning.

Run claude mcp list occasionally and remove the ones you installed for a project you finished.

The security part nobody reads

Every server on this list receives database credentials. That is the whole point of them and it is also the reason to be careful.

Two of the three carry an unreviewed security status. That's not an accusation. Most MCP servers are unreviewed, and unreviewed means nobody has audited it, not that something was found. But it does mean the review burden sits with you.

A few habits that cost nothing:

• Point these at a read-only role first. Most of what you want from an agent is querying, not writing.
• Use a separate credential per server so you can revoke one without breaking the others.
• Read the install command before running it. npx -y fetches and executes whatever is at that package path.
• Check the repo's recent commits, not just the star count. Stars measure past enthusiasm, not current maintenance.

If you want the longer version of this argument, we wrote up how to vet a skill before running it and what actually goes wrong with untrusted skills.

Analysts working further up the stack should also see our full list for data analysts, which covers the BI and visualization layer these servers feed into.

FAQ

Can I install all three at once? Yes, and for a dbt shop that's a reasonable setup. They register as separate MCP servers and don't interfere. The cost is context — each server advertises its tools to the agent, so installing servers you never use wastes window on tool definitions.

Is DBHub better than dbt MCP? They do different jobs. DBHub queries databases; dbt MCP reads your transformation project. The only sense in which DBHub is "better" is trust posture, where it's verified and community-reviewed against dbt MCP's unreviewed status.

Do any of these cost money? All three servers are free and open source. MotherDuck's hosted service has its own pricing if you use the cloud side rather than local DuckDB, but the MCP server itself doesn't charge.

What if my warehouse is Snowflake or BigQuery? None of these three is the right pick. mcp-snowflake-server exists but sits at community tier with an unreviewed status and hasn't been updated since October 2025, so read it carefully before trusting it with warehouse credentials.

Why does token efficiency matter for a database server? Because schema information is verbose. A server that returns every column of every table on each call will fill a large share of your context before you've asked a question. On a long debugging session that's the difference between the agent holding the thread and losing it.