DataHub MCP Server

The DataHub MCP Server is Acryl Data's official Model Context Protocol server for DataHub. DataHub is a metadata and data-catalog system: it gathers technical and organizational context about data assets, including tables, columns, dashboards, pipelines, documents, and ML models. The MCP Server gives a compatible AI client access to the metadata present in DataHub. It is not a general database-access layer and not an execution environment for arbitrary SQL against Snowflake, Postgres, or a warehouse. Its role is discovery, interpretation, and governance context; an agent can draft SQL from that context, but execution requires a separately authorized database connection or another tool.

What the server finds and explains, according to the provider

The official README describes natural-language search across the DataHub landscape. It can help find relevant tables, columns, dashboards, and metrics when those entities and their metadata have been cataloged in the organization's DataHub instance. Results can be narrowed with structured expressions, filters, and sorting; the source lists wildcards, tag field searches, and Boolean logic. For a discovered entity, an agent can retrieve details, schema fields, ownership, documentation, tags, glossary terms, usage, and quality information. That is a catalog query, not a read of a table's raw rows.

For result assessment, DataHub names trust signals such as popularity, quality, lineage, and query history. These signals can help an agent rank or interpret a result, but they do not replace business approval or establish correctness on their own. Their value depends on the metadata, quality information, and usage history the organization has actually maintained in DataHub. The server can also surface real SQL queries referenced for a dataset or column in DataHub, helping an agent understand join patterns, filters, and aggregations. Query history can expose business logic or sensitive identifiers, so it must be included in the access model.

Lineage, dashboards, and columns in context

According to the repository, get_lineage and get_lineage_paths_between retrieve upstream and downstream lineage for entities such as datasets, columns, and dashboards, with hop control, filters, and paths between assets. This can help assess which downstream objects may be affected before a planned change. Official documentation describes lineage at table and column level; it does not guarantee that every connected source supplies complete or accurate lineage. Validate high-impact conclusions with the catalog and the responsible teams.

search, get_entities, and list_schema_fields support discovery and inspection. The server can also search saved documents when the catalog includes them; the README says document tools are hidden when no documents exist. This lets an agent consider tables, columns, dashboards, metrics, and their business terms in shared context. It fits data analysis and research because it makes existing data assets discoverable and understandable, rather than bypassing source-system access controls.

Deployment and authentication

For DataHub Cloud, there is a managed MCP endpoint; the documentation recommends OAuth with Dynamic Client Registration for interactive clients. Tokens are tied to the signed-in DataHub user. For service accounts, unattended workflows, DataHub Core, or clients without remote OAuth support, the documentation names personal access tokens. The open-source server can run locally over stdio with uvx mcp-server-datahub or be self-hosted. Local stdio reads DATAHUB_GMS_URL and DATAHUB_GMS_TOKEN from the environment or from ~/.datahubenv.

For a shared HTTP deployment, the current source requires each request to carry its own bearer token. A server-wide DATAHUB_GMS_TOKEN is deliberately refused so that permissions and audit identity remain per user. Tokens belong only in the Authorization header, never in URLs. The DataHub instance must enable metadata-service authentication so it can identify the caller. The /health endpoint reports process health only and does not contact DataHub.

Permissions, metadata exposure, and the model path

The MCP Server can return only information that the selected DataHub token and DataHub policies make visible. Even read-only catalog access can be sensitive: table and column names, classifications such as PII, owners, query history, dashboards, documents, and lineage can reveal architecture, business processes, or data flows. Use a minimally privileged account for each agent. For service accounts, the documentation says a Default View can scope search to specific domains, platforms, or a team's assets.

Read-only tools do not change catalog state. Mutation tools for tags, glossary terms, owners, domains, descriptions, and structured properties are disabled by default and require TOOLS_IS_MUTATION_ENABLED=true; compatible clients can use MCP hints to request confirmation. Enable them only for narrowly defined workflows and review change-proposal processes. The server handles tool calls, but returned results may enter the connected AI client's context. Depending on client, model provider, prompt, logging, and retention, returned metadata can travel to an external model path. Review data classification, contractual terms, and client controls; never place secrets in prompts, screenshots, or repositories.

License, limits, and positioning

The acryldata/mcp-server-datahub repository is licensed under Apache-2.0. On 2026-09-08, the GitHub API reported exactly 80 stars; this is a point-in-time repository-popularity signal, not evidence of quality or security. The server is open source, while availability of DataHub Cloud, DataHub Core, self-hosted infrastructure, and the selected AI client depends on the chosen deployment. The provider publishes current terms. Data Analysis and Research fit because the server makes metadata discoverable, comparable, and usable for data questions without replacing database access itself.

FAQ

Does the DataHub MCP Server read table rows? No. According to the documentation, it returns DataHub metadata such as assets, schemas, lineage, query context, and governance information. It can draft SQL using that context; execution requires a distinct, explicitly authorized database path.

Can an agent change metadata? Only when mutation tools have been deliberately enabled through the named environment variable and the DataHub account is authorized. For research and analysis, read-only tools should remain the default.

How can I limit visibility? Use a dedicated minimally privileged user or service account. Add a Default View for service accounts and review DataHub policies before connecting the agent to an externally hosted model.

DataHub Cloud or DataHub Core, a personal access token or OAuth login, an MCP-capable client, and uv/uvx for local operation.

For DataHub Cloud, use the official OAuth endpoint https://mcp.datahub.com/mcp in the MCP client. For self-hosted stdio, securely set DATAHUB_GMS_URL and DATAHUB_GMS_TOKEN and run uvx mcp-server-datahub. Run shared HTTP only with individual bearer tokens and TLS.

uvx mcp-server-datahub

DataHub Cloud supports OAuth with a personal login. Self-hosted stdio uses DATAHUB_GMS_URL and DATAHUB_GMS_TOKEN; shared HTTP requires a bearer token per request in the Authorization header.

Visible catalog context follows the DataHub user or service account and its policies. Default Views can limit a service account search to specific data assets.

The server returns DataHub metadata and query context to the MCP client. Those results can be processed, logged, or sent to the connected model provider by that client.

Catalog metadata, query history, and lineage can disclose sensitive architecture or business details. Broad tokens and enabled mutation tools increase exposure or unintended metadata-change risk; shared HTTP needs TLS, rate limiting, and individual tokens.