feat: add create_data_element MCP tool

[connor-savage]

Summary

Add create_data_element MCP tool to Chip.

Generated by chip-factory pipeline.

[svc-snyk-github-jira]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[EricWarnerCollibra]

Review: create_data_element Tool

Convention Compliance ✅

All conventions are followed correctly:

• Package name matches directory (snake_case) ✓
• Exports exactly NewTool, Input, Output ✓
• NewTool(client *http.Client) *chip.Tool[Input, Output] signature ✓
• handler is unexported ✓
• Input/Output use json and jsonschema tags ✓
• Optional fields use omitempty ✓
• Tool name is snake_case ✓
• Errors returned as Output{}, err (no panics) ✓
• No direct mcp-go imports ✓
• Client calls go through pkg/clients/ ✓
• Permissions includes "dgc.ai-copilot" ✓

Build / Test / Lint ✅

• go build ./cmd/chip — passes
• go test ./pkg/tools/create_data_element/... — 9/9 tests pass
• go test ./... — all packages pass
• golangci-lint run ./... — clean

MCP Validation ✅

• Tool registered as create_data_element in factory mcp-list
• Happy-path creation returns {"id":"...","resource_type":"Asset"} correctly
• Optional display_name field works correctly

Adversarial Testing ✅ (all handled gracefully)

Test Case	Result
Empty name ("")	"name is required" ✓
Empty domain_id ("")	"domain_id is required" ✓
Missing name field entirely	MCP schema validation rejects: missing properties: ["name"] ✓
Malformed UUID for domain_id	"API error: HTTP 400" ✓
Non-existent domain UUID	"unexpected status: 404" ✓
Invalid status_id	"API error: HTTP 400" ✓
Unicode characters in name	Creates successfully ✓
Very long name (500 chars)	Creates successfully ✓
Duplicate name in same domain	Returns error ✓ (see issue below)

Issue Found: Error Message Parsing Bug 🐛

File: pkg/clients/create_data_element_client.go, line 76

The error body struct looks for JSON field "message":

var errBody struct {
    Message string `json:"message"`
}

But the Collibra REST API returns error details in the "userMessage" field. Actual API response for a duplicate name:

{
  "statusCode": 400,
  "titleMessage": "Value not allowed",
  "userMessage": "An asset with signifier 'X' already exists for domain 'Y' (id=...).",
  "errorCode": "termAlreadyExists"
}

Impact: The Message field is always empty when parsing real API errors, so the code falls through to the generic fallback:

"API error: HTTP 400"

instead of the helpful:

"API error (HTTP 400): An asset with signifier 'X' already exists for domain 'Y'"

Fix: Change json:"message" to json:"userMessage" (or add both fields to capture either).

Note: The unit test TestCreateDataElement_DuplicateNameConflict (line 139-163) passes because the mock server returns {"message": "..."}, which doesn't match the actual Collibra API response format. The mock should use {"userMessage": "..."} to accurately test the real behavior.

Verdict

Requesting changes for the error message parsing bug. The fix is small — update the JSON tag from "message" to "userMessage" and update the mock in the duplicate-name test to match the real API response. Everything else looks great.

[EricWarnerCollibra]

Independent Review: create_data_element tool ✅

Convention Compliance — All Passed

• ✅ Package name matches directory (create_data_element)
• ✅ Exports exactly NewTool, Input, Output
• ✅ NewTool(collibraClient *http.Client) *chip.Tool[Input, Output] signature correct
• ✅ handler is unexported, returns chip.ToolHandlerFunc[Input, Output]
• ✅ Input/Output use proper json and jsonschema tags
• ✅ Optional fields (display_name, status_id) use omitempty
• ✅ Tool name is snake_case: create_data_element
• ✅ Errors returned as Output{}, err — no panics
• ✅ No direct mcp-go imports — uses pkg/chip abstractions
• ✅ Client calls go through pkg/clients/CreateDataElement
• ✅ Permissions includes "dgc.ai-copilot"
• ✅ Client correctly sets TypeID = DataElementAssetTypeID server-side (not exposed to user)

Build / Test / Lint — All Passed

• Build: go build ./cmd/chip ✅
• Unit tests: 9/9 pass (go test ./pkg/tools/create_data_element/...) ✅
• Full suite: All packages pass (go test ./...) ✅
• Lint: golangci-lint run ./... clean ✅

MCP Validation — Passed

• Tool registered in factory mcp-list ✅
• Happy path: Created element in "Robo Land" domain → returned {id, resource_type} ✅
• Schema validation: Missing required fields caught at MCP schema level ✅

Adversarial Testing (10 edge cases) — All Handled Gracefully

Test	Result
Empty name ""	"name is required" (tool validation) ✅
Missing name field	MCP schema: missing properties: ["name"] ✅
Missing domain_id field	MCP schema: missing properties: ["domain_id"] ✅
Duplicate name	"An asset with signifier '...' already exists for domain '...'" ✅
Malformed UUID	"API error (HTTP 400): There was an error while processing JSON content" ✅
Non-existent domain UUID	"unexpected status: 404" ✅
Unicode/emoji in name	Created successfully ✅
Very long name (500 chars)	Created successfully ✅
HTML/script injection	Collibra strips tags server-side, handles gracefully ✅
Empty JSON {}	MCP schema validation catches both required fields ✅

Minor Observation (non-blocking)

For HTTP 404 responses, the client returns "unexpected status: 404" without attempting to parse userMessage from the body (error body parsing is only done for 400/409). A future enhancement could extend this to other 4xx codes for richer error messages, but this is not a bug.

Test Coverage Assessment

Unit tests cover: success, optional fields, missing name, missing domain_id, duplicate conflict, server error, unauthorized, type ID enforcement, and tool metadata. Excellent coverage.

Verdict: APPROVE — Clean, well-structured tool following all conventions with thorough tests and robust error handling.