Skip to content

feat: technical lineage MCP tools and techlin skill (Snowflake)#98

Draft
hlazkyau wants to merge 6 commits into
feature/DEV-202506-jdbc-ingestion-mcp-toolsfrom
DEV-202513-tech-lineage-integration-mcp-tools
Draft

feat: technical lineage MCP tools and techlin skill (Snowflake)#98
hlazkyau wants to merge 6 commits into
feature/DEV-202506-jdbc-ingestion-mcp-toolsfrom
DEV-202513-tech-lineage-integration-mcp-tools

Conversation

@hlazkyau

@hlazkyau hlazkyau commented Jul 9, 2026

Copy link
Copy Markdown

🎯 What does this PR do?

Adds the technical lineage (techlin) flow on top of the jdbc-ingestion tools: the start_technical_lineage trigger, the collibra/techlin skill with an etl-integration-style per-source reference catalog (Snowflake first), and capability-tool guidance corrected against the harvester runtime (lin-harvester) and live Edge behavior verified on the dev tenant:

  • databaseNames is required in both snowflakeMode values — the manifest marks it optional, Edge accepts a capability without it, and the harvest then fails asynchronously
  • fixed mode/query mapping: external_stages is SQL-mode, access_history (required, previously undocumented) is SQL-API, dynamic_tables/semantic_views are mode-independent
  • query defaults are automatic: omit the parameter (Edge materializes required defaults at save) or pass the "use-default" sentinel — the agent never collects or invents SQL
  • techlinHost/techlinKey are encoded inside the customParameters list parameter; top-level keys are silently ignored by the harvester
  • edge_list_capability_types reframed as an inventory (existence/names/options); the per-source reference owns runtime requiredness, mode gating, and question order
  • Edge save semantics documented in the tool descriptions: required-default materialization, and 400 "Connection(s) already used in the capability of the same type" means the capability exists (update or trigger, never switch connections)

✅ Checklist

  • My code follows the style guidelines of this project.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have made corresponding changes to the documentation (if needed).
  • My commit messages follow the Conventional Commits standard.

hlazkyau added 5 commits July 9, 2026 16:00
…t, unique source id, techlin custom properties)
…t, unique source id, techlin custom properties, mode-dependent queries)
…e-truth parameter guidance

Restructure collibra/tech-lineage into collibra/techlin with an
etl-integration-style per-source catalog (references/index.md), and correct
the skill content against the harvester runtime and live Edge behavior:

- databaseNames is required in BOTH snowflakeMode values (manifest marks it
  optional; Edge accepts a capability without it and the harvest then fails
  asynchronously with "No database names provided")
- fix the mode/query mapping: external_stages is SQL-mode, access_history
  (required, previously undocumented) is SQL-API, dynamic_tables and
  semantic_views are mode-independent
- query defaults are automatic: omit the parameter (Edge materializes
  required defaults at save) or pass the "use-default" sentinel — never
  collect or invent SQL
- techlinHost/techlinKey must be encoded inside the customParameters list
  parameter ({name, value, type, secret, encrypted, fromVault}); top-level
  keys are silently ignored by the harvester
- reframe edge_list_capability_types as an inventory: manifests carry
  existence/names/options, not requiredness or mode gating (no conditional
  metadata exists in the manifest format); the per-source reference owns
  the runtime semantics
- document Edge save behavior in the skill and tool descriptions: required
  defaults are materialized, and a second capability of the same type on
  one connection is rejected with 400 "already used" (treat as exists,
  never switch connections)
…Edge UI, trigger gated on confirmation

techlinKey passed through edge_create_capability is stored plaintext and
readable back through the management API, so the key must never transit
the conversation. When the user opts into configuring the techlin server:

- collect techlinHost only and create the capability without the key
- the user then adds techlinKey in the Collibra/Edge UI (capability
  Custom Properties, marked secret so it is masked and encrypted)
- start_technical_lineage is triggered only after the user confirms the
  key is in place
- techlinHost alone can still be changed later via the upsert; the key
  always goes in through the UI

Encoded in the snowflake reference (question script + custom-properties
flow), the techlin skill (conversation rule, trigger step gate, hard
rule 5), and the edge_create_capability parameters description so the
rule also holds for skills-off clients.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants