Skip to content

mcp-datahub-v1.12.0

Latest

Choose a tag to compare

@github-actions github-actions released this 12 Jul 23:18
Immutable release. Only release title and notes can be modified.
bbf99e2

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_schema field-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_urn stays authoritative.
  • A lone value carrying 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-actionv4.2.0
  • ci: bump docker/login-actionv4.4.0 (#179)

📦 What's Changed

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-datahub

Claude Code CLI

claude mcp add datahub \
  -e DATAHUB_URL=https://your-datahub.example.com/api/graphql \
  -e DATAHUB_TOKEN=your-token \
  -- mcp-datahub

Docker

docker pull ghcr.io/txn2/mcp-datahub:v1.12.0

Verification

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