Skip to main content
Glama
alexeiveselov92

semantic-warehouse-mcp

semantic-warehouse-mcp

A read-only MCP server that lets any AI agent work with SQL databases the way an analyst does: knowing what the data means. You give it your semantic model in an open format (Apache Ossie, formerly OSI), your own metadata, context and documents — and it lets agents find the right tables, read what they mean and query them, safely.

Status: pre-alpha — working, and used on real warehouses; its interfaces may still change. Metrics, saved query sets and more databases are on their way (the plan).

What it does now

  • ClickHouse, PostgreSQL, MySQL and DuckDB, configured in one YAML file: the tables agents may read, the large tables a query must bound (and the columns it must name values of — an event log of every kind of event), limits per query; secrets by variable name, never written in it.

  • Read-only, checked twice: one SELECT at a time, parsed for the database's own dialect by sqlglot and by the database itself; only the tables you allow, wherever they are read; large tables bounded; rows and time capped, never cut without saying so — on top of a read-only database user. Every answer carries the SQL as it ran and when.

  • A semantic layer in Apache Ossie: datasets, fields, relationships and metrics, with ai_context for agents and custom_extensions for anything of your own — categories, layers, links to code, owners — checked against a vocabulary you declare and served with what each value means — and lists filtered by it, with the menu of its values.

  • An importer from dbt: semantic-warehouse-mcp import-dbt writes your dbt project's tables, descriptions, meta and tags as an Ossie model — with what each model reads and its SQL, if you want them; the tables chosen by name or as dbt selects them (tag:daily, path:models/marts); the mapping yours, in its configuration.

  • A draft from the database itself, where no dbt project describes it: semantic-warehouse-mcp import-database writes its readable tables, columns and comments as an Ossie model for you, or an agent, to give meaning to.

  • Your own context and skills: instructions, documents and skills (the Agent Skills format: a folder with a SKILL.md and the files it refers to) served to agents as written — from disk, or straight from a git repository, kept fresh.

  • Any MCP client: stdio for one person's agent, Streamable HTTP for a server a team shares (a token on every request, /health, a container image).

Related MCP server: sql-steward

Install

Each engine's driver is an extra — postgres, mysql, duckdb, or all (ClickHouse needs none):

uvx --from 'semantic-warehouse-mcp[all]' semantic-warehouse-mcp --config config.yaml --check   # check, reach every database
uvx --from 'semantic-warehouse-mcp[all]' semantic-warehouse-mcp --config config.yaml           # serve over stdio
pip install 'semantic-warehouse-mcp[postgres]'                                                  # or install it

Connect Claude Code (any client that runs stdio servers takes the same command):

claude mcp add warehouse -- uvx --from 'semantic-warehouse-mcp[all]' semantic-warehouse-mcp --config /path/to/config.yaml

Documentation

swm.pipelab.dev — the guide, built from docs/:

  • Getting started — from nothing to an agent answering about a made-up shop's data.

  • The guide: tools, configuration, semantic models and vocabularies, the dbt importer, the guard, engines, running it.

Why

An agent with a bare SQL connection writes plausible queries over the wrong tables. What makes its answers right is semantics: what a table holds, which column is the date, how a metric is defined, what not to mix. That knowledge already exists in teams — in dbt projects, semantic layers, wikis — but every tool wants it in its own shape. This server reads it in an open, vendor-neutral format and serves it beside the data.

Development

Python 3.12, uv, the official MCP Python SDK.

uv sync
uv run pytest
uv run ruff check . && uv run ruff format --check .
uv run python examples/data/make_shop.py    # the made-up shop the examples describe
uv run semantic-warehouse-mcp --config examples/config.example.yaml   # the server over stdio

License

Apache-2.0.

Available Tools

1 tool
aboutA
Read-only

What this server is and what it will offer. Call it to check the connection.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description reinforces this implicitly as a diagnostic/connection-check call but adds no detail on what the response contains or how failures manifest, leaving modest added value.

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 short sentences with zero waste, and the identity statement is front-loaded ahead of the call-to-action. Nothing is padded.

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 no output schema, the description should ideally say what an agent gets back (server name, version, capabilities) so the tool's result can be reasoned about. It gestures at this with 'what this server is and what it will offer' but stops short of concrete return-value disclosure.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a param-less tool applies. The description correctly does not fabricate any inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns information about the server and its offerings, but 'what it will offer' is vague about the actual content. There's no concrete verb+resource framing (e.g., 'returns server name, version, capabilities') and no siblings to differentiate from, so the purpose is only loosely established.

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?

It gives an explicit trigger: 'Call it to check the connection.' With no sibling tools, there are no alternatives to exclude, so the usage context is clear enough for an agent to know when to invoke it.

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.

  1. 1 tool updatev0.0.1
    • First observedabout

TDQS

B3.3/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is nothing to confuse it with, so an agent cannot misselect. The tool's purpose (report server identity and capabilities) is unambiguous.

Naming Consistency3/5

A single name ('about') offers no pattern to evaluate, but it is a readable, conventional diagnostic name with no style clashes. Neutral score reflects the absence of any naming convention rather than a violation.

Tool Count1/5

A server whose entire surface is one trivial informational tool is an extreme mismatch for a 'semantic-warehouse' purpose. The tool only reports what the server 'will offer', indicating it is a stub with no actual capability.

Completeness1/5

There are no query, schema, catalog, or data-access tools at all, only a connection check. Any real warehouse task (list tables, run queries, inspect semantics) is impossible, making the surface severely incomplete.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to understand and query your database safely by providing a semantic layer of metadata, with tools to search, explain, validate, and generate safe SQL.
    2
    MIT
  • A
    license
    A
    quality
    F
    maintenance
    A governed SQL gateway that exposes typed tools to AI agents, compiling safe read-only queries from a semantic layer while blocking PII before execution, supporting SQL Server, Postgres, and SQLite.
    9
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to securely interact with multiple databases (MySQL, PostgreSQL) via natural language queries, with cross-database querying and enterprise-grade security.
    10 npm
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to query governed data warehouses through plain language, returning grounded answers with SQL, confidence grades, and signed receipts while enforcing access, testing, and audit controls.
    279 PyPI
    17
    Apache 2.0