MCP serializes array parameters as JSON-encoded strings, causing Pydantic validation failures

[Ryzhtus]

Summary

When calling tools that accept array-typed parameters (e.g. assignees, labels, members) through the MCP wrapper, the array is forwarded to the REST API as a JSON-encoded string rather than as a native JSON array. The REST API's Pydantic schema rejects the string at the schema layer before any business logic runs.

Steps to reproduce

1. Call the MCP tool to create a work item, passing assignees=["", ""].
2. Observe the request reaching the REST API.

Expected request body

json{ "assignees": ["", ""] }

Actual request body

json{ "assignees": "["", ""]" }

Result

The REST API responds with a Pydantic validation error (expected list, got str). Calling the underlying REST API directly with the correct payload shape succeeds, which confirms the bug is in the MCP wrapper's serialization layer, not in the API itself.

[Baijack-star]

I am an AI agent/operator doing MCP tool-schema compatibility diagnostics. I checked current main locally because this looks like it could be either a wrapper serialization bug or a client argument-shape bug.

What I found:

• create_work_item currently exposes assignees and labels as JSON Schema arrays through FastMCP:
  • anyOf: [{"type":"array","items":{"type":"string"}}, {"type":"null"}]
• If tools/call.arguments contains a native JSON array, FastMCP passes a Python list into CreateWorkItem, and plane-sdk==0.2.10 keeps it as a list in model_dump() / model_dump_json().
• If tools/call.arguments already contains a JSON-encoded string like "[\"uuid-1\",\"uuid-2\"]", FastMCP rejects it at tool validation as Input should be a valid list before the Plane REST client is reached.

So the next useful split is to inspect the MCP request payload before the tool function:

create_work_item.arguments.assignees = ["uuid-1", "uuid-2"]     # server path should work
create_work_item.arguments.assignees = "[\"uuid-1\", \"uuid-2\"]" # caller/path is stringifying arrays

If the second shape is what a real client sends, the pragmatic server-side compatibility fix is to accept list[str] | str | None for list-like fields and normalize JSON strings at the tool boundary before constructing CreateWorkItem / UpdateWorkItem / module/member models. That would make the MCP server tolerant of clients that stringify array arguments while still preserving the native-array schema for compliant clients.

A narrow regression test can monkeypatch get_plane_client_context(), call create_work_item via mcp.call_tool, and assert the captured CreateWorkItem.assignees is a list for both native arrays and JSON-encoded array strings.