mcp-datahub v1.12.0
Maintenance and correctness release. The headline is a read-side bug fix for tag display names (created tags no longer render as UUIDs) plus a usability fix that lets datahub_update accept the association URN in value — eliminating a common avoidable failed round trip for AI agents. The rest is dependency and CI hardening.
No breaking changes. No schema-compatibility changes — still validated against DataHub v1.5.0.1 (minimum supported v1.3.x).
🐛 Bug Fixes
Created tags rendered as UUIDs on read (#180)
Tags created through datahub_create (without an explicit id) showed up as UUIDs on every subsequent read instead of the name you chose.
Root cause: DataHub's createTag mutation generates a UUID entity key when the input carries no id; the display name lands in the tagProperties.name aspect. The read path's tag fragments selected only the tag's top-level name, which DataHub derives from the entity key (deprecated in the GraphQL schema in favor of properties.name). For a UUID-keyed tag, that field is the UUID. Seeded tags with human-readable keys (e.g. urn:li:tag:PII) were unaffected, so the bug only bit tags created through this toolkit's own create→attach→read round trip.
Fix (read-side): Every tag fragment now also selects properties { name description } and prefers those values, falling back to the legacy top-level fields for older servers and key-named tags. Applied across all read paths:
datahub_search(SearchQuery)datahub_get_entity(GetEntityQuery)datahub_get_schemafield-level tags (GetSchemaQuery,BatchGetSchemasQuery)- document queries
The optional write-side change (passing id to createTag for human-readable URNs) was intentionally not made — the issue flagged it as cosmetic. The read-side fix alone resolves the observed defect.
✨ Enhancements
datahub_update accepts value as the association target (#181)
Attaching a tag/term/owner/domain required the association URN in target_urn, but agents frequently passed it in the generic value field — so a natural first attempt failed with target_urn parameter is required and only succeeded on retry.
Fix: New resolveTargetURN() logic, wired into the tag, glossary_term, owner, and domain (set) handlers:
target_urnstays authoritative.- A lone
valuecarrying a URN is now accepted. - Both set and equal → succeeds.
- Both set and different → rejected with a clear message (no silent guessing).
- Neither set → still errors, naming
target_urn.
Schema descriptions were also tightened so first attempts succeed more often: value now states it is not the association URN for add/remove/set (accepted only as a fallback), and target_urn documents which what/action combinations require it.
🔧 CI & Maintenance
- ci: roll up Dependabot GitHub Actions bumps (#183, closing #175/#176/#177/#178):
github/codeql-action(init,autobuild,analyze,upload-sarif) → v4.37.0 (all sub-actions kept in lockstep)docker/setup-buildx-action→ v4.2.0
- ci: bump
docker/login-action→ v4.4.0 (#179)
📦 What's Changed
- fix: tag display names on read (#180) and value-as-target in
datahub_update(#181) by @cjimti in #182 - ci: bump
docker/login-actionfrom 4.2.0 to 4.4.0 by @dependabot in #179 - ci: roll up dependabot action bumps (#175, #176, #177, #178) by @cjimti in #183
Full Changelog: v1.11.0...v1.12.0
Installation
Claude Desktop (macOS/Windows)
Download the .mcpb bundle for your platform and double-click to install:
- macOS Apple Silicon (M1/M2/M3/M4):
mcp-datahub_1.12.0_darwin_arm64.mcpb - macOS Intel:
mcp-datahub_1.12.0_darwin_amd64.mcpb - Windows:
mcp-datahub_1.12.0_windows_amd64.mcpb
Homebrew (macOS)
brew install txn2/tap/mcp-datahubClaude Code CLI
claude mcp add datahub \
-e DATAHUB_URL=https://your-datahub.example.com/api/graphql \
-e DATAHUB_TOKEN=your-token \
-- mcp-datahubDocker
docker pull ghcr.io/txn2/mcp-datahub:v1.12.0Verification
All release artifacts are signed with Cosign. Verify with:
cosign verify-blob --bundle mcp-datahub_1.12.0_linux_amd64.tar.gz.sigstore.json \
mcp-datahub_1.12.0_linux_amd64.tar.gz