NVIDIA's Auto-Ontology Gives AI Agents a Data Dictionary Instead of Your Database

A new open-source library puts a business glossary between your agent and your warehouse. Here is how it works, how to try it, and what to fix before you trust it.

Ask an AI agent how many orders shipped last week and it will write you a SQL query in about two seconds. It will look confident. It might even be right.

The problem is the word "orders." In most companies it means at least three things, depending on who you ask: orders placed, orders paid, orders that left the warehouse. Somebody in finance decided years ago which one counts, and that decision lives in a spreadsheet, a dashboard filter, or one person's head. The agent has none of those. It has table names.

That gap, between what a column is called and what the business means by it, is where a lot of "chat with your data" projects fall apart. NVIDIA just open-sourced a tool aimed straight at it. NVIDIA/auto-ontology was posted to Hacker News early on November 3 and sat at #6 on the Trendshift momentum board when I read it that morning.

The idea worth stealing, even if you never install it: don't hand an agent your database. Hand it a dictionary of what your data means, let it ask questions through that dictionary, and make it show its work.

What auto-ontology is, in plain words

An ontology sounds academic. Here it just means a structured glossary: a list of business terms ("active customer," "shipped order," "net revenue"), what each one means, and which columns and calculations it maps to in your actual databases.

The README describes auto-ontology as "an open library" that builds that context layer for AI agents from enterprise metadata, the descriptive information your databases already hold about their own tables and columns. It lists five jobs:

Discover: generate a glossary from your metadata, or connect one you already have.
Ground: attach business meaning to metrics and entities, and settle conflicting definitions between systems.
Validate: check generated queries against certified definitions and lineage (where each number came from), and return provenance with answers.
Expose: serve all of this to agents over MCP, a command-line tool or an API.
Learn: feed certified corrections back into the glossary.

MCP, the Model Context Protocol, is the standard plug that tools like Claude Code, Cursor and Codex use to call outside services. That is the part most agent builders will touch.

Supported sources today, per the README: Databricks, Postgres, Snowflake and DuckDB. The project is Apache-2.0 licensed and had roughly 1.6k to 1.7k GitHub stars on November 3. It has no GitHub Releases yet, though NVIDIA lists a versioned 1.1.0 container on its NGC catalog.

The design choice that matters: no raw tables

The most interesting decisions are in the MCP documentation, and they are about what the agent cannot do.

The MCP server exposes nine tools. Every one of them is read-only, according to the doc. Nothing an agent calls can change the glossary, the catalog or the databases underneath.

More telling is what is missing. There is no tool for browsing databases, schemas or raw columns. The agent reaches data only through the semantic layer, which is the glossary plus its mappings. It can look up a term with search_terms or get_term, see which physical columns a term maps to with get_term_columns, read a table's description with describe_table, and ask a question in plain English with ask_question.

Think of it as the difference between giving a new hire the server password and giving them the company handbook plus a librarian. The librarian knows where things are, answers in the company's own vocabulary, and writes down which shelf every answer came from.

Three more choices from the same doc make this safer than the usual "connect the agent to Postgres" setup:

It checks who is asking. MCP sessions act as the signed-in auto-ontology user, and the app checks permissions on every call, so a viewer gets viewer-level answers and a revoked role stops working at once. One distinction matters: the doc does not say queries hit your warehouse under each person's own database login. They go through the connection you configured, so row- and column-level rules in the warehouse still apply to that connection, not to the individual.
It shows the SQL. ask_question returns the SQL it ran alongside the answer and the rows, so a person can check what the agent actually asked the database.
It caps the output. ask_question results stop at 100 rows, with fields that say how many rows exist and whether the list was cut short.

There is also a cheap pre-flight tool, check_answerable, that asks whether the glossary covers a question at all before the agent tries to answer it. That one tool is a habit worth copying into any data agent: ask "can I answer this?" before "what is the answer?"

Where the promise and the code don't line up yet

The README promises a validation step: check generated queries against certified definitions and lineage. The MCP doc, which is the part agents actually use, does not describe a separate validation step for the SQL that ask_question generates. What it does describe is provenance: you get the SQL back and can inspect it.

That might be a documentation gap rather than a missing feature. Either way, today you should treat the returned SQL as something a person reviews, not as something the system has already proven correct.

Put this into practice

The quickest way to try it is the local Docker stack described in the README. You need Docker with Compose v2 and an NVIDIA API key (one that starts with nvapi-) from build.nvidia.com.

git clone https://github.com/NVIDIA/auto-ontology.git auto_ontology
cd auto_ontology
cp .env.example .env      # then fill in the values below
docker compose up -d --build

Before that last command, set two required values in .env: AUTH_SECRET and APP_URL. The README warns that without them every page fails with a "default secret" error. Model access goes in DEFAULT_MODELS_API_KEY and the related endpoint and model fields.

When it is up, the web app is at http://localhost:3000 and the backend API on port 3001. The compose file starts Postgres, runs the schema migration and starts the backend, ingestion service and frontend.

By default, the stack calls NVIDIA-hosted models: nvidia/nemotron-3-nano-30b-a3b for language, nvidia/nemotron-3-embed-1b for embeddings (the number lists used for search) and nvidia/llama-nemotron-rerank-vl-1b-v2 for reranking (re-sorting search hits by relevance). The README says each role can point at any OpenAI-compatible endpoint instead, meaning any model server that accepts OpenAI-style requests, which is how you would keep everything on your own hardware.

To connect an agent, you run a separate MCP server process that talks to the stack. The MCP doc installs it with uvx (a runner from the Python tool uv) and points it at the app:

uvx --from "git+https://github.com/NVIDIA/auto-ontology.git#subdirectory=mcp" auto-ontology-mcp
# with AUTO_ONTOLOGY_API_URL=http://localhost:3000 set for the local stack

Then your agent's MCP config points at wherever that server listens. The doc's example uses a placeholder host:

{
  "mcpServers": {
    "auto-ontology": {
      "url": "https://auto-ontology-mcp.example/mcp"
    }
  }
}

Two details from that doc save time. The endpoint is /mcp, not the server root. And there is no token in the config: the client notices it needs a sign-in and sends you through auto-ontology's login page, then manages the token itself. For the local stack, the doc says to confirm that the login-discovery URL, /.well-known/oauth-authorization-server, returns 200 first.

A sensible first week looks like this:

Point it at a copy, not production. A DuckDB file or a read replica (a read-only copy of the database) with a few real tables is enough to see whether the generated glossary makes sense.
Read the glossary it generates before you let an agent near it. If it maps "revenue" to the wrong column, every answer after that inherits the mistake.
Make check_answerable the agent's first move. Put it in your system prompt or skill instructions: check coverage, then ask.
Log the returned SQL next to every answer. That is your audit trail, and the fastest way to catch a bad mapping.

Honest limitations

Plaintext credentials by default. The README says database connections added in the UI are stored in plaintext in Postgres, passwords included, unless HashiCorp Vault is set up. A partial Vault configuration is ignored with a warning and falls back to plaintext. Set all four Vault variables or keep this off shared machines.
One port must stay private. The FastAPI backend is an internal boundary and does not independently check the user-identity header the gateway forwards. Exposing it publicly would let a caller claim to be someone else.
Your data goes to whatever model you configure. With the defaults, questions and metadata go to NVIDIA-hosted APIs under their terms.
No outside contributions. The project says it will not review or merge external issues or pull requests. You can fork; you cannot steer.
No GitHub release yet. The repo's only tag is a backup tag, so source installs track main. Pin a commit, or use the versioned NGC container, if you depend on it.
Change the sample secrets. The repo's .env.example ships a working default admin password and AUTH_SECRET rather than empty placeholders. Replace both before anyone else can reach the machine.
The docs still have rough edges. The MCP doc describes the project as NVIDIA-internal and says the uvx install needs GitHub credentials with repo access. On a public repository that line reads as out of date, so expect some friction.
Validation is promised more clearly than it is documented. See the section above.

The part to keep, whatever you install

The usual way to wire an agent into company data starts from the database and works outward: give the agent a connection string, a schema dump, and hope. Auto-ontology starts from the other end. Meaning first, then a narrow, read-only door, then receipts.

You can adopt that pattern this week with tools you already have. Write down the ten business terms people argue about most. Map each one to the exact column and filter. Give your agent those definitions instead of the raw schema, make it say when a question is out of scope, and log every query it runs. If auto-ontology saves you the mapping work, use it. If not, the design is still the lesson.

Sources: NVIDIA/auto-ontology README and docs/mcp.md and .env.example on main, read November 3, 2026 (no GitHub release; Apache-2.0); NGC catalog entry; star count from shields.io and GitHub the same morning; Hacker News submission, November 3, 2026.