mcp-server-datahub

DataHub MCP サーバー

DataHub 向けの Model Context Protocol サーバー実装です。

DataHub とは？

DataHub は、データサプライチェーン全体を一元的に把握できる、組織向けのオープンソースコンテキストプラットフォームです。DataHub は、すべてのテーブル、列、ダッシュボード、パイプライン、ドキュメント、ML モデルを対象に、データの発見、ガバナンス、オブザーバビリティを一元化します。

データプロファイリング、データ品質のモニタリング、データリネージ、データの所有権、データ分類などの強力な機能により、DataHub は技術面と組織面のコンテキストを結び付け、チームが信頼できるデータを見つけ、作成し、使用し、維持できるようにします。

ユースケース

DataHub MCP サーバーを使うと、AI エージェントは次のことができます。

• 信頼できるデータを見つける：自然言語を使ってデータ環境全体を検索し、最も重要な課題への回答に役立つテーブル、列、ダッシュボード、指標を見つけられます。データの人気度、品質、リネージ、クエリ履歴などの信頼性シグナルを活用して、常に適切なデータを取得できます。

• データリネージを調べ、データ変更に備える：アセットレベルと列レベルの詳細なデータリネージを通じて、重要なデータ変更が下流のユーザーに影響を及ぼす_前に_、その影響を把握できます。

• ビジネスを理解する：ビジネス用語集、データドメイン、データプロダクト、_および_データアセットなど、組織にとって重要なコンテキストをたどれます。主要な指標、ビジネスプロセス、データが互いにどう関係するかを理解できます。

• SQL クエリを説明・生成する：データのドキュメント、データリネージ、組織内でよく使われるクエリなどの重要なコンテキストを活用して、最も重要な課題に答える正確な SQL クエリを生成できます。

DataHub MCP サーバーを選ぶ理由

DataHub MCP サーバーを使えば、AI エージェントにデータエコシステム全体をすぐに可視化できます。データベース、データレイク、データウェアハウス、BI 可視化ツールに保存されたデータを見つけて理解できます。データリネージを調べ、利用状況やユースケースを把握し、データの専門家を特定し、SQL を生成できます。すべて自然言語で操作できます。

コンテキストフィルタリングを備えた構造化検索

強力なクエリ構文とフィルタリング構文で、キーワード検索を超えた検索ができます。

• ワイルドカード検索：/q revenue_* で revenue_kpis、revenue_daily、revenue_forecast を検索
• フィールド検索：/q tag:PII ですべての PII タグ付きデータを検索
• ブール論理：複雑なクエリには /q (sales OR revenue) AND quarterly

SQL インテリジェンスとクエリ生成

よく使われる SQL クエリにアクセスし、正確な新しいクエリを生成できます。

• アナリストがテーブルに対してどのようなクエリを実行しているかを確認できます（SQL の生成に最適です）
• 結合パターンと一般的なフィルターを理解できます
• 本番環境のクエリパターンから学べます

テーブルレベルおよび列レベルのリネージ

テーブルレベルと列レベルの両方で、データの流れを追跡できます。

• 下流で user_id がどのように customer_key になるかを追跡できます
• 変換ロジックを理解できます
• 上流および下流を探索できます（1～3 ホップ以上）
• エンタープライズ規模のリネージグラフを扱えます

データエコシステムを理解

検索する前に、データがどのように整理されているかを理解できます。

• 関連するデータドメイン、所有者、タグ、用語集の用語を見つけられます
• データプラットフォームや環境を横断して閲覧できます
• 推測せずに、複雑なデータ環境をたどれます

使い方

DataHub MCP サーバーのドキュメントの手順を参照してください。

ローカル stdio デプロイ

ローカルの MCP クライアントでは、デフォルトのトランスポートとして引き続き stdio が使われます。

uvx mcp-server-datahub

stdio サーバーは、環境変数から DATAHUB_GMS_URL と DATAHUB_GMS_TOKEN を読み込みます。環境変数が設定されていない場合は、datahub init で作成される ~/.datahubenv を使用します。これはローカルのデプロイモードであり、HTTP 認証は不要です。

ローカル CLI は、信頼できるローカルネットワーク内での利用に限り、SSE もサポートします。SSE では、専用の HTTP エントリーポイントで使用されるリクエストごとのベアラー認証が提供されないため、共有ネットワークサービスとして公開しないでください。

Docker HTTP デプロイ

コンテナはポート 8000 でステートレス HTTP トランスポートを実行します。サーバー全体で使用する DATAHUB_GMS_TOKEN は意図的に使用しません。DataHub の権限と監査用の識別情報をユーザーごとに維持するため、各 MCP クライアントが独自の DataHub トークンを指定します。

既存の HTTP デプロイにおける破壊的変更： HTTP 用に、独立した mcp-server-datahub-http エントリーポイントが追加されました。 DATAHUB_GMS_TOKEN が設定されていると起動を拒否し、すべてのクライアントは独自の DataHub ベアラートークンを送信する必要があります。ローカルの stdio と SSE の動作に変更はありません。

docker run --rm -p 8000:8000 \
  -e DATAHUB_GMS_URL=https://your-datahub.example \
  acryldata/mcp-server-datahub:latest

同じ独立した HTTP エントリーポイントは、Docker の外部でも利用できます。

DATAHUB_GMS_URL=https://your-datahub.example mcp-server-datahub-http

http://localhost:8000/mcp に接続し、リクエストごとにトークンを含めてください。

Authorization: Bearer <datahub-personal-access-token>

トークンは Authorization ヘッダーでのみ受け付けます。?access_token=... のようなクエリ文字列内のトークンは拒否されます。

呼び出し元の識別情報を確立するには、DataHub で METADATA_SERVICE_AUTH_ENABLED=true にする必要があります。上流の認証が無効な場合、GMS は任意のベアラー値に対して、存在しない合成アクターを返すことがあります。MCP サーバーでは、この上流の設定を修正できません。

ローカルビルドの場合は、DATAHUB_GMS_URL を含む .env ファイルを作成し、次を実行します。

docker compose up --build

イメージとサーバーは、コンテナ、ロードバランサー、Kubernetes のプローブ用に、認証不要の GET /health エンドポイントを公開します。このエンドポイントはプロセスのヘルス状態のみを報告し、DataHub には接続しません。

livenessProbe:
  httpGet:
    path: /health
    port: 8000
readinessProbe:
  httpGet:
    path: /health
    port: 8000

ベアラートークンは、転送中に保護する必要があります。HTTP デプロイを信頼できるネットワークの外部に公開する前に、イングレスまたはリバースプロキシで TLS を終端し、レート制限を適用してください。新しい無効なトークンごとに GMS への検証リクエストが発生する可能性があるため、レート制限は特に重要です。

正常に検証されたトークンとその DataHub クライアントは、5 分間キャッシュされます。キャッシュ済みのリクエストに対して DataHub が 401 または 403 を返した場合、そのクライアントはキャッシュから削除され、次のリクエストでトークンが再検証されます。検証に失敗した場合はキャッシュされません。また、DataHub を保護するため、上流への同時検証数は制限されています。

デモ

Block のチームと共同で制作したデモ動画をご覧ください。

ツール

DataHub MCP サーバーでは、次のツールを利用できます。

search

ブール論理、フィルター、ページネーション、使用状況メトリクスによる任意の並べ替えを使って、構造化キーワード検索（/q 構文）で DataHub を検索します。

get_lineage

フィルター、リネージ内検索、ページネーション、ホップ数の制御を使って、任意のエンティティ（データセット、列、ダッシュボードなど）の上流または下流のリネージを取得します。

get_dataset_queries

データセットまたは列を参照する実際の SQL クエリ（手動またはシステム生成）を取得し、使用パターン、結合、フィルター、集計の動作を確認します。

get_entities

URN を指定して 1 つ以上のエンティティの詳細なメタデータを取得します。検索結果を効率よく調べるための一括取得に対応しています。

get_aspect_history

1 つ以上のエンティティとアスペクトの組み合わせについて、現在の値と、保持されている履歴バージョンのうち新しい順に並べたページを上限付きで取得します。バージョンごとの取り込み情報と監査上の来歴も含まれます。

list_schema_fields

データセットのスキーマフィールドをキーワードで絞り込み、ページネーションを使って一覧表示します。検索結果でフィールドが省略される場合や、大規模なスキーマを調べる場合に便利です。

get_lineage_paths_between

2 つのアセットまたは列の間にある正確なリネージパスを、中間変換や SQL クエリ情報も含めて取得します。

変更ツール

これらのツールを使うと、DataHub のメタデータを変更できます。環境変数 TOOLS_IS_MUTATION_ENABLED=true で有効になります。

add_tags / remove_tags

エンティティまたはスキーマフィールド（列）にタグを追加または削除します。複数のエンティティに対する一括操作をサポートしています。

add_terms / remove_terms

エンティティまたはスキーマフィールドに用語集の用語を追加または削除します。ビジネス上の定義やデータ分類の適用に役立ちます。

add_owners / remove_owners

エンティティの所有権の割り当てを追加または削除します（技術オーナー、データオーナーなど、異なる所有権タイプをサポートします）。

set_domains / remove_domains

エンティティへのドメインの割り当てまたは割り当て解除を行います。各エンティティが属せるドメインは 1 つです。

update_description

エンティティまたはスキーマフィールドの説明を更新、追記、削除します。Markdown 形式に対応しています。

add_structured_properties / remove_structured_properties

エンティティの構造化プロパティ（型付きメタデータフィールド）を管理します。文字列、数値、URN、日付、リッチテキストの値型に対応しています。

ユーザーツール

これらのツールは、認証済みユーザーに関する情報を提供します。TOOLS_IS_USER_ENABLED=true で有効になります。

get_me

現在認証されているユーザーの情報を取得します。プロフィールの詳細やグループへの所属情報が含まれます。

ドキュメントツール

これらのツールは、DataHub に保存されているドキュメント（ナレッジ記事、ランブック、FAQ）を対象に操作します。カタログにドキュメントがない場合、ドキュメントツールは自動的に非表示になります。

search_documents

プラットフォーム、ドメイン、タグ、用語集の用語、オーナーで絞り込みながら、キーワード検索でドキュメントを検索します。

grep_documents

正規表現パターンを使ってドキュメントの内容を検索します。複数のドキュメントから特定の情報を見つけるのに役立ちます。

save_document

インサイト、決定事項、FAQ、メモなどの単独のドキュメントを DataHub のナレッジベースに保存します。ドキュメントは、設定可能な親フォルダーの下に整理されます。

設定

環境変数

変数	デフォルト値	説明
DATAHUB_GMS_URL	none	DataHub サーバーの URL です。HTTP モードでは必須です。stdio では ~/.datahubenv から読み込むこともできます。
DATAHUB_GMS_TOKEN	none	従来の stdio/SSE 認証情報です。この共有認証情報が設定されている場合、HTTP モードは起動を拒否します。
FASTMCP_HOST	FastMCP のデフォルト（127.0.0.1）、イメージのデフォルト（0.0.0.0）	HTTP/SSE のバインドアドレスです。
FASTMCP_PORT	8000	HTTP/SSE のリッスンポートです。イメージのヘルスチェックでも使用されます。
TOOLS_IS_MUTATION_ENABLED	false	変更ツール（タグ、オーナーなどの追加・削除）を有効にします。
TOOLS_IS_USER_ENABLED	false	ユーザーツール（get_me）を有効にします。
DATAHUB_MCP_DOCUMENT_TOOLS_DISABLED	false	ドキュメントツールを完全に無効にします。
SAVE_DOCUMENT_TOOL_ENABLED	true	save_document を有効または無効にします。このツールは TOOLS_IS_MUTATION_ENABLED=true の場合にのみ登録されます。
SAVE_DOCUMENT_PARENT_TITLE	Shared	保存したドキュメントの親フォルダーのタイトルです。
SAVE_DOCUMENT_ORGANIZE_BY_USER	false	保存したドキュメントをユーザーごとに整理します。
SAVE_DOCUMENT_RESTRICT_UPDATES	true	共有フォルダー内のドキュメントのみ更新を許可します。
TOOL_RESPONSE_TOKEN_LIMIT	80000	ツールの応答に含めるトークンの最大数です。
QUERY_LENGTH_LIMIT	5000	ツールの応答に含める SQL クエリ文とビュー定義の最大文字数です。
ENTITY_SCHEMA_TOKEN_BUDGET	16000	エンティティごとのスキーマフィールド用トークン予算です。
DESCRIPTION_LENGTH_LIMIT	5000	エンティティレベルの説明の最大文字数です。
FIELD_DESCRIPTION_LENGTH_LIMIT	120	スキーマフィールドの説明、編集済みの説明、非推奨に関する注記の最大文字数です。
DISABLE_NEWER_GMS_FIELD_DETECTION	false	適応型 GMS フィールド検出を無効にします。
DATAHUB_MCP_DISABLE_DEFAULT_VIEW	false	デフォルトビューの自動適用を無効にします。
SEMANTIC_SEARCH_ENABLED	false	セマンティック検索（AI を活用した検索）を有効にします。

例：データの発見と理解のフロー（DataHub ツールを使用するエージェント向け）

この例では、AI エージェントが DataHub MCP ツールを連携させて、ユーザーのデータに関する質問に回答する方法を説明します。意思決定のフロー、呼び出すツール、応答の利用方法を示します。

1. ユーザーが質問する

例：

「先月、ペットが何匹譲渡されたかを調べるにはどうすればよいですか？」

エージェントは、これが データの発見 → クエリの構築 というワークフローだと認識します。適切な SQL クエリを構築するには、（a）関連するデータセットを見つけ、（b）メタデータを調べ、（c）正しい SQL クエリを構築する必要があります。

2. 関連するデータセットを検索する

エージェントは search ツールから開始します（設定に応じて、セマンティック検索またはキーワード検索を使用します）。

ツール： search
入力： 自然言語のクエリ

呼び出し例：

{
  "query": "pet adoptions"
}

目的： adoptions、pet_profiles、pet_details などのデータセットを特定します。

3. 候補となるデータセットを調べる

検索で返されたデータセットごとに、エージェントはメタデータを取得できます。

3.1 スキーマフィールドの一覧を取得する

ツール： list_schema_fields
入力： データセットの URN
目的： スキーマ、データ型、クエリの候補となるフィールドを把握します。

例：

{
  "urn": "urn:li:dataset:(urn:li:dataPlatform:snowflake,mydb.public.adoptions,PROD)"
}

list_schema_fields はページ分割されています。最初の応答が成功しても、スキーマ全体が取得できたとは限りません。remainingCount がゼロより大きい間は、取得を続けてください。応答のトークン予算によりページが短くなる可能性があるため、指定した上限ではなく、実際に返されたフィールドの数だけオフセットを進めてください。

offset = 0
all_fields = []

do:
    page = list_schema_fields(urn=dataset_urn, limit=100, offset=offset)
    all_fields.extend(page.fields)
    offset = page.offset + page.returned
while page.remainingCount > 0

この方法では、オフセットが最後のフィールドをすでに超えている場合も安全に処理が終了します。ツールは remainingCount: 0 の空のページを返します。

3.2 リネージを取得する（任意）

ツール： get_lineage
目的： データセットが派生データか、信頼できる情報源かを判断します。

3.3 クエリの例を取得する

ツール： get_dataset_queries
目的： データセットの一般的な使用パターンとクエリのテンプレートを把握します。

4. エンティティ間の関係を理解する

質問に結合やエンティティのナビゲーション（例：ペットと譲渡データの関連付け）が必要な場合：

get_entities

上流または下流のテーブルなど、指定した URN に関連するエンティティを取得します。

get_lineage_paths_between

必要に応じて、データセット間（例：pet_profiles と adoptions の間）の正確なリネージパスを計算します。

5. クエリを構築する

エージェントは次の情報を取得しています。

• 適切なデータセット
• そのスキーマ
• 主要なフィールド
• クエリの例
• 関係とリネージのコンテキスト

エージェントは正確な SQL クエリを構築します。

例：

SELECT COUNT(*)
FROM mydb.public.adoptions
WHERE adoption_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1' MONTH)
  AND adoption_date < DATE_TRUNC('month', CURRENT_DATE);

6. 最終的な回答を返す

エージェントは次のいずれかを行います。

• SQL を直接返す
• クエリの実行が許可されている環境であれば、クエリを実行する
• クエリ結果に基づいて自然言語で回答する

使用したツールの概要

ツール名	目的
search	質問に関連するデータセットを検索します。
list_schema_fields	データセットの構造を把握します。
get_lineage	データの信頼性と来歴を評価します。
get_dataset_queries	データセットに対する一般的なクエリ方法を把握します。
get_entities	コンテキストとして関連エンティティを取得します。
get_lineage_paths_between	データセット間のより詳細な関係を把握します。

開発

DEVELOPING.md を参照してください。