offdataai
Context layer

The context layer for AI agents that query your data

Agents fail on data questions because they lack context, not intelligence. offdataai serves concepts, metrics, join paths, catalog metadata and your documents over MCP, under the access rules you set.

Connect your agents Book a demo
  • From $1/month
  • 8 SQL targets
  • 174 templates
Claude · MCP · offdataaiConnected

tools/list

list_ontologies
get_query_context
search_concepts
get_concept
join_path
run_query
query_ontology
ask_ontology
search_catalog
propose_concept
Which customer segment drove revenue last quarter?
Any MCP client connects with an API key; answers follow the ontology's access rules.
Watch the demo

See it in action

A narrated walkthrough, recorded in the real app.

How it works

Three steps, minutes not months

1

Describe or import

Answer a short interview, open a template, draw on the canvas or connect a live database.

2

Review a validated model

Keys, grain, history and PII are checked before any code is written. Refine it in plain English.

3

Ship and keep it current

Native DDL, dbt, seeds, docs and an ontology. Push to Git, diff versions, generate migrations.

Overview

Why teams choose offdataai

app.offdataai.com
The ontology agents read over MCP: concepts, relations and metrics, each reviewed

The ontology agents read over MCP: concepts, relations and metrics, each reviewed

  1. 01

    Point an AI agent at a warehouse and it sees a few thousand table names like fct_ord_ln and dim_cust_v2.

  2. 02

    It does not know which column is net revenue, that order lines must not be joined twice, or that the email column is personal data.

  3. 03

    So it guesses.

  4. 04

    The fix is not a bigger model or a longer prompt.

  5. 05

    It is a context layer: a service that hands the agent exactly the business context a question needs, at the moment it needs it.

  6. 06

    offdataai builds that context from three things you already have.

  7. 07

    The ontology holds the meaning, with concepts, relations and metrics derived from your data model and approved by your team.

  8. 08

    The data catalog holds the inventory, with every system, table and column across your connections and which concepts use them.

  9. 09

    Knowledge bases hold the documents, such as dictionaries, definitions and runbooks, that never made it into the schema.

  10. 10

    Agents reach all of it through one MCP server.

  11. 11

    A call to get_query_context returns the relevant concepts, the metric formula, the valid join path and the fields that will be masked.

  12. 12

    The agent can then call ask_ontology or query_ontology to get a governed answer, or run_query for a read-only query on a connection.

  13. 13

    When it notices something missing, it calls propose_concept and a person reviews the suggestion before anyone else sees it.

  14. 14

    Governance is part of the context, not an afterthought.

  15. 15

    API keys carry scopes, ontologies carry access rules and row filters, personal data stays masked unless a key has pii:read, and every agent request is logged on the activity dashboard.

  16. 16

    Your team decides what agents can know, and can prove afterwards what they did.

Real output

The code it writes, not a sketch

This is the shape of what offdataai generates here, straight from the validated model. Copy it, download it, or push it to Git.

  • Context for a question, in one call
  • Meaning from the ontology
  • Inventory from the catalog
mcp · get_query_contextjson
1// Claude → offdataai MCP server
2{
3  "tool": "get_query_context",
4  "arguments": {
5    "ontology": "acme-sales",
6    "question": "Which customer segment grew net revenue fastest this year?"
7  }
8}
9
10// ← context the agent gets back
11{
12  "concepts":  ["Customer", "Order", "Order line"],
13  "metrics":   [{ "name": "Net revenue", "formula": "sum(amount - discount)", "grain": "order line" }],
14  "dimensions":["Customer.segment", "Order.order_month"],
15  "join_path": "Order line → Order → placedBy → Customer",
16  "masked":    ["Customer.email", "Customer.phone"]
17}
Capabilities

What the context layer gives an agent

  • Context for a question, in one call

    get_query_context returns the concepts, metrics, dimensions, join path and masked fields that matter for a specific question, instead of the whole schema.

  • Meaning from the ontology

    Concepts, relations and metric definitions come from a reviewed ontology bound to real tables, so agents use the same definitions as your analysts.

  • Inventory from the catalog

    search_catalog finds tables and columns across Postgres, MySQL, Snowflake, BigQuery, Redshift, Databricks and HubSpot, with the concepts that use them.

  • Your documents as context

    Knowledge bases make data dictionaries, metric docs and runbooks searchable, so the context includes what was written down outside the warehouse.

  • Agents propose, people approve

    propose_concept and propose_relation put agent suggestions in a review queue. Nothing reaches other agents until a person accepts it.

  • Scoped, masked and audited

    Scoped API keys, access rules, row filters, PII masking without pii:read, and a log of every request on the agent activity dashboard.

0

Validated templates

0

SQL targets

0

Modeling paradigms

0+

Industries covered

Native output for the warehouses you already run

SnowflakeBigQueryDatabricksRedshiftPostgreSQLSynapseFabricDuckDBdbtSnowflakeBigQueryDatabricksRedshiftPostgreSQLSynapseFabricDuckDBdbt
FAQ

Frequently asked questions

What is a context layer?
A context layer is everything an AI agent needs to know about your data before it can answer a question correctly: what the business concepts mean, which tables store them, how they join, how metrics are calculated, what the agent is allowed to see and any supporting documents. It sits between your data and the agent, and serves that context on demand instead of stuffing a whole schema into a prompt.
How is a context layer different from a semantic layer?
A semantic layer defines meaning: concepts, relations and metrics, compiled into SQL. A context layer is how that meaning, plus catalog metadata, access rules and documents, is delivered to AI agents at the moment they need it. In offdataai the semantic layer is the ontology, and the context layer is the MCP server and API that expose it, the data catalog and your knowledge bases to agents.
How is it different from a data catalog?
A data catalog lists what exists: systems, tables, columns and who uses them. A context layer answers what an agent should do with it for a given question: which concepts are relevant, the valid join path, the metric formula and which fields are masked. offdataai's catalog is one of the sources the context layer draws from, through the search_catalog tool.
Which MCP tools does offdataai provide?
list_ontologies, get_ontology, get_query_context, search_concepts, get_concept, join_path, search_catalog, query_ontology, ask_ontology, get_record, get_related_records, list_connections, run_query, list_proposals, propose_concept and propose_relation. Together they let an agent discover the model, fetch context for a question, run governed queries and suggest improvements.
Which AI agents can connect?
Any client that speaks the Model Context Protocol, including Claude Desktop, Claude Code and other MCP-compatible agents. Agents authenticate with an offdataai API key; the same keys work with the public REST API, for example POST /api/v1/ontologies/{id}/ask for plain-English questions.
Can an agent change my ontology?
No, not directly. An agent can propose a new concept or relation with propose_concept or propose_relation, and the proposal lands in the ontology's review queue. A person accepts, edits or rejects it, so the context other agents receive only ever contains approved definitions.
How is access controlled?
API keys carry scopes, for example ontology:query to ask questions and pii:read to see personal data unmasked. Each ontology's access rules and row filters apply to every agent question, and personal data stays masked without pii:read. Agents read rows only when they run a query; catalog and context calls return metadata.
What role do knowledge bases play?
Knowledge bases hold your own documents, such as data dictionaries, metric definitions or runbooks, and make them searchable as extra context. Starter includes one knowledge base with 10 documents, Pro five with 100 documents and Team unlimited knowledge bases with 1,000 documents.
Can I see what agents asked?
Yes. Every agent request is recorded on the agent activity dashboard: which key called which tool, the question, and for queries the SQL that ran. That audit trail is what lets a team trust an agent with production data.
Which plan includes the MCP context layer?
The public API and MCP server start on Pro ($99/month, 250 AI credits), together with live connections and governance. Ontologies and the data catalog start on Starter ($29/month). Each plain-English ask_ontology question uses one AI credit.
Keep exploring

Explore offdataai

Part of the offdataai platform

From business requirements to production-ready data architecture and AI-ready enterprise context.

See all six stages →
  1. 01DesignLogical, physical and dimensional models.
  2. 02GenerateSQL, dbt, documentation and migrations.
  3. 03DefineBusiness metrics, semantic models and ontology.
  4. 04ConnectReal warehouse schemas and metadata.
  5. 05GovernDrift, lineage, impact analysis and approvals.
  6. 06ActivateMake trusted context available to AI agents.

This page covers Define and Activate. Every stage works on the same model, so what you design here carries through to the rest.

Start for $1

From requirements to AI-ready context, in one platform.

Describe your business in a conversation, start from a template or connect your own database. Your first model is ready in minutes.

Get startedBook a demo

Plans from $1/month · cancel any time