dScribe exposes an MCP (Model Context Protocol) server, letting AI assistants and agent workflows query your catalog metadata directly. It now offers nine tools — search, lineage, impact analysis, data quality and documentation gaps — so an assistant can follow a question through your catalog rather than making a single lookup.
It is reachable over Streamable HTTP at https://app.dscribe.cloud/catalog/api/mcp, or https://<tenant>.dscribe.cloud/catalog/api/mcp for tenant-scoped environments.
Connecting
Authenticate exactly as you would with our REST API: an API key, or an OAuth client. Nothing about the connection has changed.
With an API key
Generate a key in dScribe under Settings → API keys — it starts with fd__. Pass it as the x-dscribe-api-key header. In Claude Desktop, open claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"dscribe": {
"url": "https://app.dscribe.cloud/catalog/api/mcp",
"headers": {
"x-dscribe-api-key": "<your-dscribe-api-key>"
}
}
}
}Save and fully restart Claude Desktop. Other assistants work the same way — find where they let you add a custom header, and pass the key and URL there. Send the key on its own, with no Bearer prefix.
With an OAuth client
Use this for Databricks Genie and other platforms that fetch a token themselves. Create a client on the OAuth clients page, then fill in:
Field | Value |
Host |
|
Port |
|
Client ID | from the OAuth clients page |
Client Secret | from the OAuth clients page |
OAuth scope |
|
Token URL |
|
Base Path |
|
A token is fetched under the hood and your assistant is authenticated against your catalog.
The server is stateless, so there is no session to keep alive and no reconnect step — each request stands on its own. That matters for always-connected assistants, which can call from any of their workers at any time.
What it can do
Nine tools. Eight read your catalog; one proposes a change and is off unless you switch it on.
Every result carries an id, and every other tool accepts one — which is what lets an assistant follow a question rather than making a single lookup.
Tool | Answers | Takes |
| "What do we have about revenue?" | A question, plus optional filters on domain, owner, asset type, PII and any property you define |
| "Tell me everything about this one" | An asset id |
| "Which fields here hold personal data?" | A dataset id, optionally filtered by name or PII |
| "Who owns this? What mentions it?" | Any node id — asset, column, user, team or source |
| "Where does this come from? What depends on it?" | An asset id, and how many hops to follow |
| "What breaks if I change this?" | An asset id |
| "Can I trust this, and where did it break?" | An asset id |
| "What should we document next?" | A gap type — undocumented columns, unlinked glossary terms or missing descriptions |
| Proposes a description or property value | An asset id and a reason |
Two worth calling out. analyzeImpact answers in one step what would otherwise take several: it walks downstream, then reports the contracts at risk with their named consumers and the owners to notify. getDataQuality pairs an asset's own rule results with failing rules on the sources feeding it — an asset whose own checks pass can still be serving bad data, and that is usually the half people miss.
How the tools fit together
A question starts at searchGraph. Its results carry ids, and every other tool takes one — so an assistant can open a result, list its columns, walk out to its owners and lineage, and end at an impact or data-quality judgement, without you stitching the calls together.
Filtering by your own vocabulary
Filter values are given as labels, not ids. Ask for domain: ["Finance"]. The same goes for people: owner: ["Simon Temmerman"] or an email address both work. If a name cannot be resolved, or matches two options, the tool replies with the valid choices rather than quietly filtering on the wrong thing.
To find out what your catalog actually defines, the server also exposes four resources:
Resource | What it lists |
| Every property, its type, and the allowed values for the ones with a fixed set |
| Your business domains |
| Your asset types |
| The relation types, and what each one means |
An assistant can read these instead of guessing. Most clients surface them under a paperclip or "attach" control.
Two things that are easy to miss:
Pass
"NULL"as a value to find assets where a property is not set — "which data products have no domain?" is a filter, not a search.Set
includeFacets: truewhen a search is too broad. You get counts per domain, asset type and source, so the next question narrows on real values rather than a guess.
Suggesting changes
suggestAssetChange is the only tool that writes, and it does not change anything directly. It creates a suggestion in the same review queue your team already uses, carrying the assistant's reason alongside it, for a steward to accept or reject.
It is off by default. An assistant cannot see it, let alone call it, unless the API key carries the mcp_suggest scope — which is not granted by a key's general access. Add it on the key you want to allow, and only that one.
The practical use is closing the gaps findGovernanceGaps turns up: an assistant that has just read a dataset's columns and its lineage is well placed to propose a description, and a steward is well placed to judge it in a second.
We deliberately do not expose direct edits. Suggestions keep a person in the loop, and the audit trail records what was proposed and why.
Good to know
Lineage can be incomplete, and says so. The traversal caps how many relations it follows from any one node, so a heavily connected asset has neighbours it did not expand. When that happens traceLineage and analyzeImpact say so explicitly and name the nodes affected — raise maxRelationsPerNode to include them. Treat a blast radius without that warning as complete, and one with it as a floor.
Large result sets are paged, not truncated. Every list tool reports the true total alongside the page you are looking at. findGovernanceGaps on undocumented columns can run to tens of thousands catalog-wide; scope it with pii: true, a datasetId or nameContains rather than paging. The PII subset is usually the one worth documenting first.
Access follows the credential. A key reaches everything in the catalog it belongs to. Per-user discovery policies are not applied on this surface, so treat an MCP key as you would any service credential with full read access — and use a separate key per integration.
Derived lineage is labelled. A glossary term is not part of the physical is_used_in graph; it links to a dataset through a column. Where lineage crosses that bridge it is marked as derived, so you can tell it from a real data flow.
Contracts are optional context. Assets without a data contract still search, expand and trace normally — getDataQuality simply reports that there is nothing defined, rather than failing.