Support
For most of the last decade the data catalog has been a destination. You log in, you search, you read, you leave. Adoption gets measured in monthly active users and the number is usually disappointing - not because the catalog is bad, but because a second system is friction, and friction loses.
What changes with the Model Context Protocol is that the catalog stops being somewhere you go and starts being something your tools can consult. MCP is an open standard for connecting AI applications to external systems in a controlled way. Think of it as an interface designed for models rather than for developers: a server advertises a set of tools, a client discovers them at runtime and calls them when a question requires it.
Dataedo publishes an MCP server for this purpose. It is a small standalone service that sits between the AI client and your catalog, calls the Dataedo API on the model's behalf and returns live metadata. The integration is read-only: the agent can search and retrieve, but it cannot modify anything in your repository.
A worked example
An analyst in a pricing team is asked to produce a view of net revenue by product line. She knows roughly where the data sits but not which of three similarly named tables is the one finance actually uses. In the current world she posts a question in a channel and waits.
With a catalog-connected assistant, the exchange looks different. She asks where net revenue is held. The assistant searches the catalog, finds three candidates, and returns them with their descriptions, their documented owners and a note that one is marked as the certified source for finance reporting. She asks what feeds it. The assistant traces documented lineage and tells her where that lineage stops. She asks whether the definition of net revenue excludes intercompany sales. The catalog has a glossary term linked to the column, so the assistant returns the approved definition and the steward who owns it.
None of that is magic. Every one of those answers already existed in the catalog. What changed is that she never had to go and get them.
The line that keeps this governable:
Metadata, not data
The agent can tell you which table holds revenue, what the definition is, who owns it and what feeds it. It cannot tell you what last quarter's revenue was. Say this on day one and keep saying it, or every demo ends with a disappointed "but can it give me the number?" That boundary is worth defending for reasons beyond expectation management. A metadata service is dramatically easier to secure, to reason about and to get approved than one that can reach into transactional systems. It is also where the unique value is: the numbers are already available in a dozen tools. The meaning is not.
Why this is different from loading documents into a chatbot
You will be asked this in the first meeting, so it is worth having the comparison ready. There are three ways to give AI access to your metadata. The middle row is where organizations usually end up by accident.
| Approach | Freshness | Permissions | What it covers | Ongoing cost |
|---|---|---|---|---|
| Paste documentation into a chat | Stale the moment you paste | None — everyone sees everything | Whatever you remembered to include | Manual, forever |
| Export the catalog into a vector index | As fresh as the last export run | Usually flattened to one level | A copy of the truth, slowly diverging | A pipeline to own, monitor and debug |
| Query the live catalog through MCP | Live on every question | Inherited from the user's catalog account | The repository itself | The service, and nothing else |
The middle row is where organisations end up by accident. It works, right up until someone asks why the assistant is confidently describing a table that was decommissioned two quarters ago, or why a contractor just received a clean explanation of the compensation schema.
Three properties that make this approvable:
- It is read-only The integration retrieves; it does not write. There is no path by which an over-confident agent rewrites a glossary term or reassigns an owner. This single property removes most of what a risk committee will worry about first.
- It is permission-aware In a hosted deployment, users sign in through your own Dataedo login, including SSO where you have it, and see only what their account is permitted to see. The agent inherits your access model rather than bypassing it.
- It is live Every question triggers a real call. There is no extraction step and no snapshot quietly drifting away from reality. A steward corrects a definition at nine; the agent uses the corrected version at one minute past.
What the catalog needs to be useful
You do not need a complete catalog. You need a credible one in at least one domain. In practice the agent is only as good as the following:
- Descriptions that discriminate. "Customer table" is useless when there are nine of them. A description that says which population it covers, at what grain, and what it excludes is what lets the agent choose between candidates.
- Named owners. An answer that ends with a person is actionable. An answer that ends with "no owner documented" is a governance finding, which is also useful, but only if someone acts on it.
- Business terms linked to technical objects. This is what lets a user ask in their own language and get a technical answer back.
- Lineage where change hurts. You do not need complete lineage. You need it on the pipelines where a schema change causes a Monday-morning incident.
- Deliberate permissions. Metadata reveals structure. Decide who can see which domains before the agent makes that question concrete.
Failure has to be informative
This is the part most teams underestimate. There are four distinct situations the agent will encounter, and collapsing them into one smooth sentence is the fastest way to lose trust:
| Situation | What the user must hear | Why it matters |
|---|---|---|
| No object matches | "I cannot find anything matching that in the catalog." | Prevents the single most damaging failure: a confident, invented table name |
| Object exists, property is blank | "That table exists but has no documented owner." | Turns a gap into a stewardship task rather than a dead end |
| User lacks permission | "You do not have access to that area of the catalog." | Makes the access model visible instead of looking like missing data |
| The lookup failed | "I could not reach the catalog just now." | Stops the model falling back on its own assumptions when a tool times out |
Getting that distinction right is most of the work. It is also what separates an assistant people keep using from one that is quietly abandoned after a fortnight, because an assistant that occasionally invents an answer is worse than no assistant at all. The user now has to verify everything, which is slower than looking it up.
The design rule
Do not move governance into the assistant. Bring the assistant to the governed metadata, and make the assistant honest about the edges of what it found.
What this asks of the catalog team
There is a shift of posture here that is easy to miss. For years the catalog team's job has been to persuade people to come and look. Under this model the traffic arrives whether they are ready or not, carried by a tool that will faithfully report every gap it encounters.
That is uncomfortable for about a fortnight and then it becomes the most useful thing that has happened to the programme. The arguments change character. Instead of defending a coverage target in a steering meeting, a steward can point at forty real questions from named people that the catalog could not answer last month. Instead of guessing which domain to document next, the queue sorts itself.
The rest of this guide is the practical path to that position: what it is worth, how to secure it, how the assistant should behave, what you deploy, and three ways to put it in front of people.
Next up → Part 2: The Business Value of an AI-Ready Data Catalog
The question your sponsor will ask thirty seconds into the pitch is "what does this actually change, and for whom?" Part 2 answers it role by role, with a value model you can run on your own numbers and a set of metrics worth agreeing before you start rather than after.
