NVIDIA Auto Ontology: An Open-Source Context Layer That Tells Agents What Your Data Means

NVIDIA has published Auto Ontology, an Apache-2.0 framework that builds a business-meaning layer over your databases and serves it to AI agents through MCP, a CLI and an API. The repository on GitHub had about 1,100 stars and 112 forks when we read it on November 3, 2026, and it showed up on Hacker News the same morning.

The pitch is blunt. In NVIDIA's words, "reliability gates agentic analytics: a revenue metric answered faster is worth nothing if the number is wrong." Auto Ontology tries to give an agent the context a new analyst would need: where data lives, what a term means, whether to trust it, and where it came from.

TL;DR

What problem is this solving?

Anyone who has pointed an LLM at a data warehouse has seen the failure. The model writes valid SQL against the wrong table, or picks the wrong definition of "active customer," or joins two systems that count revenue differently. The query runs. The number looks plausible. It is wrong.

Text-to-SQL has been a research topic for years, and benchmarks such as BIRD measure it. We covered one recent entry in Google's Gemini SQL2 text-to-SQL results on BIRD. But benchmark schemas are small and clean. Enterprise warehouses have thousands of tables, three definitions of every metric, and tribal knowledge nobody wrote down.

Auto Ontology's answer is a context layer between the agent and the database. The README breaks it into five verbs:

• Discover. Generate enterprise ontologies from metadata, connect existing ontologies and semantic models, and build AI-ready knowledge graphs.
• Ground. Give agents trusted business meaning for metrics, entities and relationships, and reconcile inconsistent definitions across systems.
• Validate. Check generated queries against certified definitions and lineage, and return provenance with every answer.
• Expose. Serve context to any agent harness through MCP, CLI and API.
• Learn. Fold certified corrections and usage back into the ontology, so the shared context improves with every question.

NVIDIA also says the tool "complements the semantic models customers already own." That matters. It is not asking you to throw away a dbt semantic layer or a Databricks metric view. It reads and reconciles them.

How is it built?

The README lists four main components.

HashiCorp Vault is optional, for storing connection credentials. The web UI covers chat, analysis, a data catalog, analytics and settings. Authentication supports SSO, with the redirect URI set to APP_URL/api/auth/sso/callback.

A table grid with a green funnel selecting a few rows, standing for how NVIDIA Auto Ontology narrows text-to-SQL queries to certified definitions

The design choice worth noticing is that the semantic catalog lives in Postgres "alongside the catalog it describes." The ontology is not a separate graph database you must also operate. Vectors, terms and metadata share one store.

Which models does it use?

Auto Ontology calls NVIDIA NIM endpoints for inference, either the hosted API catalog at integrate.api.nvidia.com or self-hosted NIMs. The defaults in .env.example are:

• LLM: nvidia/nemotron-3-nano-30b-a3b
• Embeddings: nvidia/nemotron-3-embed-1b
• Reranking: nvidia/llama-nemotron-rerank-vl-1b-v2

Each model role is a triplet of environment variables: <PREFIX>_ENDPOINT, <PREFIX>_API_KEY and <PREFIX>_MODEL. The prefixes are DEFAULT_MODELS, REASONING, NON_REASONING, EMBED and RERANK. Any field you leave unset falls back to the matching DEFAULT_MODELS_ field, so the simplest setup fills in only the defaults.

Because the endpoint is just a URL, the README says any OpenAI-compatible model endpoint works. In practice that means you can point the reasoning role at a stronger model and keep small Nemotron models for extraction and embeddings. This matches NVIDIA's recent push for small, cheap models in agent pipelines, which we followed in Nemotron 3.5 Lightning, a 30B A3B open MoE and the Nemotron 3 Ultra 550B release.

One caution: the README's disclaimer says the software "automatically retrieves, accesses or interacts with external materials," and that you are responsible for the terms of the hosted NVIDIA APIs, any other model endpoint you configure, and your source databases. An optional KumoRFM predictive-query service activates only when KUMO_RFM_API_KEY is set.

How do agents talk to it?

The MCP server is the part most readers will care about. According to the repo's MCP documentation, it is an HTTP client of the public Auto Ontology API. It holds no database credentials, no model configuration and no credentials of its own. Authentication and permission checks stay in the Next.js layer, so "a session can do exactly what the person behind it can do — a viewer gets a viewer's answers."

For background on the protocol, see our MCP explainer.

A key fitting a narrow opening in a fence, illustrating how Auto Ontology MCP sessions inherit the permissions of the signed-in user

The tool list

Every tool is read-only. Nothing changes the glossary, the catalog or the databases.

The docs say there is "deliberately no tool for browsing databases, schemas, or raw columns." The authors want agents to reach data through the semantic layer, because a raw catalog browser "invites an agent to reason about raw tables instead." That is a sound design rule, and a useful pattern for anyone building their own MCP servers: expose meaning, not plumbing.

What ask_question really does

It calls POST /api/chat/completions, the same endpoint the web UI uses. That runs the full text-to-SQL agent, which means many sequential model calls and, per the docs, "typically tens of seconds." The result comes back as separate fields for answer, SQL and rows, so an agent can reuse the SQL without parsing prose. Results are capped at 100 rows, with row_count and truncated fields reporting what was withheld. The server also emits MCP progress notifications while the agent works.

The default chat timeout in the MCP server is 900 seconds. Plan for slow calls.

Why check_readiness exists

This is a candid piece of the docs. A deployment needs two independent things: a compiled semantic layer and a live database connection. Having one without the other is "the most misleading state, because everything looks healthy" while every question fails "expensively and vaguely, after minutes of model calls." The tool reports every blocker at once. Any team that has debugged an agent that silently returns empty answers will recognize the problem.

How do you try it?

Two routes: Docker Compose for a local stack, or a Helm chart for Kubernetes (see DEPLOYMENT.md in the repo).

1. Clone the repository.
2. Copy .env.example to .env. Set the Postgres credentials, DEFAULT_MODELS_API_KEY, and CONNECTION_STRINGS for your source database.
3. Set AUTH_SECRET and APP_URL. Without them, every page fails with a Better Auth "default secret" error.
4. Run docker compose up -d --build.
5. Open http://localhost:3000. The API is on :3001.

You need Docker with Compose v2 and an NVIDIA API key from build.nvidia.com. If the UI loads without its left navigation panel after a restart, clear the site cookie for localhost:3000; NVIDIA says a stale session cookie causes it when AUTH_SECRET changes or the database resets.

For scripts and notebooks, mint an API token from the user menu and send it as x-api-key or as a Bearer token. Tokens are stored only as a SHA-256 hash and act as their owner, with no extra permissions. Deleting the token or banning the user revokes access on the next request.

To wire the MCP server into a client, run it with the URL of your deployment:

AUTO_ONTOLOGY_API_URL=https://auto_ontology.example.com auto-ontology-mcp

Then point the client at the /mcp endpoint. The docs note that the client signs in through Auto Ontology's own login page and registers itself automatically, so there is nothing to register with an identity provider.

A note on the install instructions

The MCP doc says something worth flagging: "Auto Ontology is NVIDIA-internal today, so this install needs GitHub credentials with access to the repository." The uvx command installs straight from GitHub, and the plain uvx auto-ontology-mcp form will work "once the package is published to PyPI." The repository is public, so the note may simply be left over from before release. Treat the package route as unfinished and install from the repo.

What do the agent skills add?

The repo has an AGENTS.md for coding agents and a skills/ folder with three skills: nvidia-ontology-setup, nvidia-ontology-management and nvidia-ontology-query. A separate CLAUDE.md is for the maintainers themselves. So you can hand a coding agent the repo and ask it to set up the stack, manage the ontology, or query it. If you are new to the format, our guide to agent skills explains how they work.

How does it compare with other ontology tools?

Several projects chase the same gap, which tells you it is a real one:

• Helix Foundry turns company data into an agent-drafted graph. It leans toward drafting the graph with agents.
• Sakana Aquarium uses an ontology as the governance base for managed enterprise agents.
• Graphify builds a knowledge graph of a codebase, not business data.

Auto Ontology sits closest to the first two but is narrower and more SQL-centered. Its stated job is to make generated queries match certified definitions and to return provenance with every answer. Its largest difference is the vendor. NVIDIA has hardware and model reasons to promote agent workloads that call many small-model steps, and the defaults show it.

What are the limits?

Based on what the README and docs say:

• Heavy to run. Four services plus Postgres is a lot for a pilot. Expect to read DEPLOYMENT.md.
• Credential storage. Connections added through the UI keep the full connection object, password included, unencrypted in the catalog row unless Vault is fully configured. A partial Vault configuration is ignored with a warning and falls back to plaintext. Use the CONNECTION_STRINGS route or set up Vault first.
• No accuracy figures. The README points to a separate "ontology SQL evaluation repository" for BIRD-style runs. It gives no scores. Until someone runs it, treat reliability claims as untested.
• No outside contributions. "Issues, pull requests, and patches submitted from outside the Auto Ontology maintainer team will not be reviewed or merged." You can fork under Apache-2.0, but you cannot count on upstream fixes.
• Slow answers. Tens of seconds per question is fine for analytics, bad for chat.
• Read-only MCP. Safe by default, but corrections must go through the web UI or API.

What developers are saying

The Hacker News thread had 10 points and a single comment when we checked, so there is no real community verdict yet. We will add an update if hands-on reports appear. The early signal is the GitHub count, which is already past 1,000 stars for a repo that carries NVIDIA's name.

What this means for what you build

If you build internal analytics agents, the lesson is portable even if you never run this repo. An agent needs a layer that carries definitions, lineage and permissions. Start with a glossary of the 20 metrics your business argues about. Map each to the columns and SQL that define it. Give the agent tools that search that glossary before any tool that touches raw tables. Return the SQL and the rows with every answer so a human can check.

If you handle sensitive data, watch the permission model. The design where an MCP session inherits the signed-in user's role is the right one, and it is the opposite of one shared service token. For deeper guardrails on what agents can do with tools, AgentBeam is the agent security platform from the explainx.ai team.

If you want to benchmark it, run the evaluation repo on your own schema, not on BIRD alone. Public benchmarks reward clean schemas. Your warehouse is not one.

Related reading

• Google's Gemini SQL2 and BIRD
• Helix Foundry: open-source company data ontology
• Sakana Aquarium ontology platform
• Graphify codebase knowledge graph
• What is MCP?
• What are agent skills?
• Nemotron 3.5 Lightning

Details are accurate as of November 3, 2026. The repository changes often, so check the README before you deploy.