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 MCP Tool

Summary

The create_data_element tool is well-implemented, follows all Chip conventions, and handles edge cases gracefully. Approved.

Convention Compliance ✅

• Package name matches directory (create_data_element)
• Exports exactly: NewTool, Input, Output
• NewTool takes *http.Client, returns *chip.Tool[Input, Output]
• handler is unexported, returns chip.ToolHandlerFunc[Input, Output]
• Input/Output use json and jsonschema tags
• Optional fields (display_name, status_id) use json:"...,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"
• Registered in register.go

Independent Test Results

Check	Result
go build ./cmd/chip	✅ Pass
go test ./pkg/tools/create_data_element/...	✅ 8/8 tests pass
go test ./...	✅ All packages pass
golangci-lint run ./...	✅ Clean
factory mcp-list	✅ Tool registered
factory mcp-call (happy path)	✅ Returns error from API (expected with test UUIDs)

Adversarial Testing (8 edge cases)

Input	Result
Empty name ("")	✅ "name is required"
Empty domain_id ("")	✅ "domain_id is required"
Missing name field entirely	✅ MCP schema validation rejects
Empty {} input	✅ MCP schema rejects (missing name, domain_id, type_id)
Unicode + HTML in name (🔥 <script>)	✅ API returns 400, handled gracefully
Malformed UUIDs (not-a-uuid)	✅ API returns 400, handled gracefully
Very long name (5000 chars)	✅ API returns 400, handled gracefully
Empty optional fields	✅ API returns 400, handled gracefully

No panics, no unhelpful errors — all edge cases handled cleanly.

Observations (non-blocking)

1. type_id as required input vs. spec wording: The spec says "typeId set to the Data Element asset type" which could imply the tool should auto-set this value. However, the current implementation requires the caller to provide it, which is consistent with the existing codebase pattern — no other tool hardcodes asset type IDs. The caller can use asset_types_list to look it up. This is a reasonable design choice.

2. Generic error on some 400 responses: When the API returns a 400 without a "message" field in the response body, the error shows "unexpected status: 400" rather than including the full error body. Minor improvement opportunity for future iteration (e.g., including the raw body or errorCode field).

Test Coverage

The test file covers: success, optional fields, missing name, missing domain_id, duplicate name conflict (400), unauthorized (401), forbidden (403), and server error (500). Solid coverage.

Files Reviewed

• pkg/tools/create_data_element/tool.go — Tool implementation
• pkg/tools/create_data_element/tool_test.go — Unit tests (8 tests)
• pkg/clients/create_data_element_client.go — API client
• pkg/tools/register.go — Tool registration