retrieve_work_item_by_identifier fails with Pydantic validation error when work item has assignees

[gzl10g]

Description

retrieve_work_item_by_identifier fails with a Pydantic validation error when the returned work item has one or more assignees.

Error

1 validation error for WorkItemDetail
assignees.0
  Input should be a valid dictionary or instance of UserLite [type=model_type, input_value='<uuid-string>', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/model_type

Steps to reproduce

1. Assign a user to any work item in Plane
2. Call retrieve_work_item_by_identifier(project_identifier="PREFIX", issue_identifier=N)
3. Observe Pydantic validation error

Expected behavior

The tool should return the work item data, including assignees as expanded UserLite objects or raw UUID strings that the model can handle.

Actual behavior

The Plane API returns assignees as an array of UUID strings (e.g. ["uuid"]), but the WorkItemDetail Pydantic model expects an array of UserLite dicts. This causes a validation error.

Work items without assignees (empty array) work fine.

Workaround

Use list_work_items(project_id=...) and filter by sequence_id instead.

Environment

• plane-mcp-server 0.2.8
• Self-hosted Plane instance
• Python 3.10

[1h23]

Confirmed on our self-hosted Plane setup after upgrading from plane-mcp-server 0.2.7 to 0.2.8.

Environment:

• plane-mcp-server 0.2.8
• plane-sdk 0.2.8
• Self-hosted Plane

Repro:

• retrieve_work_item_by_identifier(project_identifier="###", issue_identifier=###)

Actual result:

1 validation error for WorkItemDetail
assignees.0
  Input should be a valid dictionary or instance of UserLite [type=model_type, input_value='95953e11-b28b-40bb-a599-fc0a774a5834', input_type=str]

What we verified locally:

In plane_mcp/tools/work_items.py, retrieve_work_item_by_identifier returns client.work_items.retrieve_by_identifier(...) directly.
In plane/models/work_items.py, WorkItemDetail still expects:
assignees: list[UserLite]
In this response shape, the API returns assignees as a list of UUID strings, not expanded user objects.
So this is still reproducible on 0.2.8, not only 0.2.7.

A practical fix would be one of:

Change WorkItemDetail.assignees to accept list[str] | list[UserLite]
Normalize assignees before model validation in the MCP layer
Return a model closer to WorkItemExpand semantics for this endpoint