ChatGPT, Claude, Cursor, and your own agents can use different interfaces while asking questions through the same governed business context.
You ask your favorite AI assistant a simple question:
Why did revenue drop in the West region?
The assistant can reason. It can write SQL. It can explain a chart.
But does it know what your company means by revenue?
Does revenue include refunds? Is it recognized when an order is placed, when an invoice is issued, or when cash arrives? Which regional hierarchy is current? Which table is authoritative? Is the person asking allowed to see every customer behind the number?
A fluent answer is not necessarily a trusted answer.
That is the gap Genie One MCP is designed to close. It gives AI clients a common path to Genie, where questions can be answered using governed business context rather than whatever definitions happen to be inside one prompt.
MCP stands for Model Context Protocol.
Think of it as a common connection between an AI application and the tools or information it needs. Without a shared protocol, a team may build one integration for ChatGPT, another for Claude, another for Cursor, and another for its own internal agent.
Every integration has to learn how to authenticate, discover tools, send a request, and understand the response.
MCP gives those clients a common way to do that work.
The important word is common. It does not make the underlying data correct. It does not create business definitions. It creates a reusable doorway through which an AI client can reach a tool that has those definitions.
Genie One MCP brings that doorway to enterprise data. An MCP client can ask Genie a natural-language question. Genie can search governed data, produce SQL, and return an answer grounded in the business context available through Genie Ontology.

The shape is simple:
The model can change. The client can change. The business meaning should not.
Imagine that two analysts ask the same question in different tools.
The first asks an internal agent. The second asks a coding assistant. Both ask why West-region revenue fell.
Without shared context, one tool may query orders.total_amount. The other may query a finance metric that subtracts refunds and excludes unrecognized revenue. Both answers can look reasonable. Only one may match the number used by finance.
Now imagine that both tools connect to the same Genie One MCP service.
Genie can work from the same governed definition of revenue, the same region mapping, the same trusted sources, and the same permissions. The result is not guaranteed to be perfect, but the starting point is consistent.
This is the first big idea: the definition should travel across tools.
If your company defines an active customer as someone who purchased within the last 90 days, that meaning should not change because an employee switches from one assistant to another.
The assistant is a choice. The definition is enterprise context.
A direct database connector can expose tables and run queries. That is useful, but it leaves an important burden on the AI client.
The client still has to decide which table to trust. It still has to infer what a metric means. It still has to understand relationships, synonyms, filters, and business rules.
Genie One is intended to sit above that raw access layer.
Genie One combines natural-language analysis with governed data and business context. Genie Ontology adds a shared context layer built from modeled meaning and context inferred from existing analytics work.
That distinction matters.
A table tells an agent what columns exist. An ontology helps it understand what those columns mean to the business, which definitions carry authority, and how concepts relate.
For the revenue question, the useful context may include:
The answer depends on all of them.
AI tools will keep changing.
A company may use ChatGPT for general work, Claude for analysis, Cursor for engineering, and internal agents for support or operations. A year from now, that list may look different.
Rebuilding business meaning inside every assistant creates drift.
One prompt says active customer means 90 days. Another says 60. A third calculates revenue from a convenient table rather than the governed metric. Each system slowly develops its own version of the company.
A shared Genie service changes the design.
Instead of teaching every client the full business language, the organization manages that language closer to its governed data. Clients use the common MCP interface to reach it.
This does not remove all client-specific work. Authentication, user experience, and task design still matter. But the most valuable layer becomes reusable.
That is a better boundary:
AI clients own the interaction. The enterprise owns the meaning.
A plain text response is often not enough for data analysis.
If revenue fell, the reader may need a chart by week, a table of product categories, the SQL behind the result, and a link back to the governed source.
MCP Apps is an open extension to MCP that lets compatible clients render interactive views inside the conversation. It is not a Databricks-only format. Genie One can use it with clients that support the extension.
That means the response can become richer than a block of text. A compatible client can show Genie's progress, results, and visualizations inline.
This is the second big idea: the common interface can carry an inspectable analytical experience, not only an answer string.
The distinction is important for trust. A chart can reveal a sudden weekly change. A source link can help a reviewer check the result. Visible SQL can help an engineer find an incorrect join.
Good enterprise AI should make verification easier, not hide the path behind a confident paragraph.
A common connection creates convenience. It also creates a governance question.
Who can invoke the service? Which tools can it expose? Which calls should be allowed? How can the organization observe usage?
Databricks addresses this through Unity Gateway and Unity Catalog.
An MCP Service can be registered as a Unity Catalog securable. It receives a three-level name such as catalog.schema.mcp_service. Permissions can then determine who is allowed to invoke it.
This turns an MCP server from an unmanaged endpoint into a governed enterprise object.
The control layer can cover:
Some service-policy capabilities remain in preview, so teams should verify the current Databricks documentation before designing production controls.
This is the third big idea: the organization governs the connection as well as the data behind it.
Unity Catalog already provides the foundation for data permissions and lineage. The Unity Catalog lesson explains that foundation from first principles. MCP services extend the same governance mindset toward the tools agents use.
The architecture becomes clearer when viewed through the four ideas in The Context Advantage: Choice, Context, Control, and Cost.

People should be able to use the assistant that fits their work.
A common MCP interface makes it easier to connect different clients to the same governed service. The enterprise does not have to put its meaning inside one model or one chat interface.
Choice is not about using every tool. It is about avoiding a design where changing the client means rebuilding the truth.
The model needs more than schema names.
It needs shared definitions, trusted metrics, relationships, authority, and current state. Genie Ontology is Databricks' attempt to organize that context for Genie.
Our broader enterprise context guide explains why collecting more documents is not enough. Context has to be relevant, current, governed, and connected to the decision.
An agent should not gain access simply because it can speak MCP.
Permissions still apply. Tool access still needs policy. Sensitive actions still need stronger checks than read-only questions. Audit history still matters.
Unity Gateway and Unity Catalog provide the control plane, but the organization still has to design roles, approvals, and safe boundaries.
Duplicated integrations cost time and money.
So does duplicated context. If five teams separately define revenue and maintain five assistant integrations, the technical cost is only part of the problem. The larger cost appears when their answers disagree.
A reusable interface and shared context layer can reduce repeated work. Teams should still measure model calls, query cost, latency, and the work required to curate definitions. Shared does not mean free.
MCP does not make poor data trustworthy.
If the revenue table is late, the answer is late. If the metric definition is wrong, the assistant can repeat the wrong definition consistently. If permissions are too broad, a governed service can still expose more than it should.
Genie Ontology also does not remove human judgment. Authority scores and inferred context can help organize meaning, but business owners still need to decide which definitions are approved.
The system needs good data engineering underneath it:
This is why agent systems are also data systems.
The data quality lesson shows how to turn assumptions into checks. The incremental processing lesson explains how to keep business state current without rebuilding everything. The AI agent memory versus business state article explains why an agent should verify important facts against authoritative systems before acting.
Databricks announced Genie One MCP as generally available on September 22, 2026. At the time of this review, some Databricks documentation pages still label the managed Genie MCP server as Beta and describe a workspace preview setting.
Genie Ontology is documented separately as a preview capability.
The safe reading is that the product announcement and some documentation are not yet fully aligned. Check the current documentation and your workspace before planning a production rollout.
Databricks' Genie One MCP documentation describes setup, authentication, supported clients, and response behavior.
[!notice] Workspace note
This capability depends on a Unity Catalog-enabled Databricks workspace and enterprise governance features that are not available for hands-on use in Databricks Free Edition. The concept is explained here for understanding.
You do not need Genie One MCP to practice the most important design habit.
Create a small table or notebook with these fields:
| Business term | Approved definition | Trusted source | Owner | Freshness |
|---|---|---|---|---|
| Revenue | Paid order amount minus refunds | gold.daily_revenue | Finance | Daily, 07:00 UTC |
| Active customer | At least one paid order in 90 days | gold.customer_activity | Growth | Daily, 07:30 UTC |
| West region | Current sales-territory mapping | silver.region_mapping | Sales Operations | Weekly |
Then take one question, such as the West-region revenue question, and write down every definition required to answer it.
Ask:
That exercise is context engineering. The platform feature comes later.
The Genie Spaces lesson gives you a Free Edition path for learning how natural-language questions depend on clean data, clear descriptions, and good example queries.
Do not begin by connecting every assistant to every source.
Start with one decision that already has a trusted answer. Revenue by region is a good example because the definitions and owners are usually visible.
Document the metric, dimensions, sources, permissions, freshness, and known exceptions.
Expose a narrow Genie experience. Compare its answer with the approved report. Test paraphrases of the same question. Confirm that different users see only what their roles allow.
Then connect one MCP client.
Measure answer consistency, source quality, latency, query cost, and how often a human has to correct the context. Expand only after the narrow path is dependable.
A useful first success is not “the agent can query everything.”
It is “different people can ask the same business question in different words and reach the same governed meaning.”
Genie One MCP matters because it separates two things that should not be confused.
The assistant is replaceable. The business meaning is not.
Models will improve. Interfaces will change. Teams will adopt new agents. MCP may evolve too.
Your definitions of revenue, customer, product, risk, and authority belong to the enterprise. They should be governed close to the data, reusable across tools, and understandable by the people responsible for them.
That is the long-term advantage.
The strongest AI architecture is not the one with the most assistants. It is the one where every approved assistant can reach the same context, under the same control, without forcing the enterprise to surrender choice or duplicate cost.
https://youtu.be/kKmV_5vyU_s