connect_databaseLABSCO SUMMARY
Ontology-checked SQL: structural errors are caught before the query reaches the database.
OBQC is deterministic — it parses the generated SQL and cross-references every table, column, join and aggregation against the ontology, so a fan-trap that would silently multiply your numbers comes back as an error instead of a wrong answer. On a large schema, graphrag_query_context is the other half: it hands the model a focused slice instead of the whole catalogue.
What it is
A Text-to-SQL server that first reads your schema into an RDF/OWL ontology, then validates every generated query against it — across 8 database connectors including PostgreSQL, MySQL, Snowflake, ClickHouse, Dremio, BigQuery, DuckDB and Databricks SQL.
What you get
- connect_database, list_schemas, discover_schema and get_table_details map the database, including relationships
- generate_ontology produces RDF/OWL with SQL annotations; load_my_ontology takes your own Turtle file instead
- execute_sql_query runs SQL through OBQC first — missing tables and columns, Cartesian joins, type mismatches, GROUP BY gaps and fan-traps are caught, and errors block execution
- suggest_semantic_names and apply_semantic_names rename cryptic identifiers into business-readable ones
- graphrag_query_context narrows a large schema to just the relevant tables and columns before SQL generation; graphrag_find_join_path resolves how two tables join, graphrag_search explores by keyword
- reachable_from, measurable_from and plan_composite_query work out fan-trap-safe decompositions for a given grain
- query_sparql, store_ontology_in_rdf and add_rdf_knowledge give a SPARQL 1.1 interface over a persistent Oxigraph store
- generate_chart renders Plotly bar, line, scatter and heatmap output; download_artifact exports the ontology or R2RML mapping as Turtle
- sample_table_data previews rows, save_semantic_model and list_semantic_models keep models per connection
Requirements
Python 3.13+ and uv. Credentials come from environment variables per database — POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DATABASE, POSTGRES_USERNAME and POSTGRES_PASSWORD for PostgreSQL, SNOWFLAKE_ACCOUNT and its siblings for Snowflake — not from tool parameters. The server listens on http://localhost:9000, configurable through MCP_SERVER_PORT. Licensed BSL 1.1.
Setup effort
Build from source — git clone https://github.com/ralforion/orionbelt-analytics
USE CASES
01
Asking a business question of a database you did not design
Connect, discover the schema, generate the ontology, then let the query run with structural validation in front of it.
02
Keeping an aggregate from silently double-counting
Fan-traps across multiple one-to-many joins are detected against the ontology and block the query rather than returning inflated numbers.
03
Working with a schema too large to hand the model whole
Narrow it to the tables and columns the question actually touches, then generate SQL against that slice.
04
Figuring out how two tables connect
Resolve the join path by graph traversal instead of reading foreign keys by hand.
05
Making cryptic column names readable
Detect the abbreviations, review the suggestions, and write the business-friendly names into the ontology.
06
Getting a chart out of the answer
Send the result set straight into a Plotly chart rendered in the client.
07
Taking the model into another tool
Export the ontology or the R2RML mapping as Turtle for Protégé, Ontop or D2RQ.
27 tools
Listed in project docs. Your client may show a different list.
list_schemasreset_cachediscover_schemaget_table_detailscleanup_workspacegenerate_ontologysuggest_semantic_namesapply_semantic_namesload_my_ontologydownload_artifactsample_table_dataexecute_sql_querygenerate_chartgraphrag_searchgraphrag_query_contextgraphrag_find_join_pathreachable_frommeasurable_fromplan_composite_querystore_ontology_in_rdfquery_sparqladd_rdf_knowledgesave_semantic_modelget_semantic_modellist_semantic_modelscleanup_old_versionsBEFORE YOU INSTALL
What to know first
Tools you get
27 tools named in the project's documentation.
Requires
- Python 3.13+ and uv
- Credentials in .env for the one database you connect — only that database's variables (PostgreSQL, MySQL, Snowflake, Dremio, Databricks, BigQuery or MotherDuck)
INSTALLATION
Connect your client
Server setup
TERMINAL
git clone https://github.com/ralforion/orionbelt-analytics
cd orionbelt-analytics
uv sync
cp .env.template .envEdit .env with the credentials for the one database you connect (for PostgreSQL: POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DATABASE, POSTGRES_USERNAME, POSTGRES_PASSWORD)
TERMINAL
uv run server.pyThe server starts on http://localhost:9000 — keep it running and connect your client below.
MCP Clients
Claude Desktop
CLAUDE DESKTOP · JSON
{
"mcpServers": {
"OrionBelt-Analytics": {
"command": "npx",
"args": [
"mcp-remote",
"http://localhost:9000/mcp",
"--transport",
"http-only"
]
}
}
}Database credentials go in the server's .env file, not in the client configuration. Set only the variables for the database you connect; the rest stay empty. docs/configuration.md lists every variable.
Claude Code
CLAUDE CODE · TERMINAL
claude mcp add --transport http orionbelt-analytics http://localhost:9000/mcpDatabase credentials go in the server's .env file, not in the client configuration. Set only the variables for the database you connect; the rest stay empty. docs/configuration.md lists every variable.
LibreChat
LIBRECHAT · YAML
mcpServers:
OrionBelt-Analytics:
url: http://host.docker.internal:9000/sse
timeout: 60000
startup: trueSet MCP_TRANSPORT=sse in the server's .env and restart it first — this entry uses the /sse endpoint.
Database credentials go in the server's .env file, not in the client configuration. Set only the variables for the database you connect; the rest stay empty. docs/configuration.md lists every variable.
