create_initiative/update_initiative: state enum not serialized ("Object of type InitiativeState is not JSON serializable")

[andromeda-vinicius]

Summary

create_initiative (and update_initiative) fail whenever a state is provided:

Object of type InitiativeState is not JSON serializable

Passing state="ACTIVE" through the MCP tool is coerced to the InitiativeState enum (the parameter is typed InitiativeState | str | None), and the enum is then handed to the request body without being converted to its .value, so it blows up at JSON serialization.

Environment

• plane-mcp-server 0.2.10 (installed via uvx plane-mcp-server)
• Target: Plane Cloud (app.plane.so)
• Transport: MCP over stdio

Reproduction

1. Call create_initiative with name="Q3", state="ACTIVE", and any start_date/end_date.
2. The tool errors with Object of type InitiativeState is not JSON serializable.
3. Omitting state entirely, the same call succeeds.

Expected

The initiative is created with the given state — the enum should be serialized to its string value ("ACTIVE") before the request is sent.

Where (source on current main / 0.2.11)

plane_mcp/tools/initiatives.py:

• create_initiative: signature state: InitiativeState | str | None = None (~L74), then state=state (~L115)
• update_initiative: same shape (~L153 / ~L190)

The value is passed straight through with no .value conversion, so the coerced enum reaches serialization. The passthrough is unchanged between 0.2.10 and 0.2.11, so this looks like it still applies on the latest release.

Workaround

Creating/updating the initiative through the Plane REST API directly (POST /api/v1/workspaces/{slug}/initiatives/ with "state": "ACTIVE") works — which confirms it is the MCP serialization layer, not the API.

Other rough edges seen on 0.2.10 (not re-tested on 0.2.11 — listing in case they help)

• list_work_item_properties, and reading back a property just created with create_work_item_property, fail with Output validation error: None is not of type 'string' — a nullable field validated against a string schema. The property is created server-side and is readable via REST.
• update_module responses come back with id: null, so a caller cannot confirm from the response which module was updated (has to re-list).
• (Gap, not a bug) There is no tool to set a custom property value on a work item — create_work_item_property defines the property, but values have to be written via REST (.../work-items/{id}/work-item-properties/{prop}/values/).

Note: the sparse-fieldsets validation failure I also hit on 0.2.10 (fields= without name failing PaginatedWorkItemResponse validation) looks already addressed by #182, so it is not included here.