The Plane MCP server defines 3 tools with schemas and descriptions, but exhibits significant gaps in parameter-level documentation, output schema specification, and error handling guidance. Tool naming is action-oriented (workitem, workitem_type, get_pql_reference) and appropriate. Descriptions exist but are generic and lack depth about when/why to use each tool, dependencies, or return value structure. Parameters have type definitions but most lack detailed descriptions explaining constraints, formats, or allowed values. No output schemas are documented for any tool. Error handling and recovery guidance are absent. The middleware stack (PlaneLoggingMiddleware, CoerceArguments, ValidateActionArguments) suggests validation occurs, but tool-level error recovery patterns are not evident in the source. Overall structure is solid but execution falls short of production quality.

• Add output schema documentation for each tool. Example for workitem: 'Returns: {id: string, name: string, status: string, created_at: ISO8601, project_id: string}' so LLMs know what to expect and can chain calls.
• Expand tool descriptions to 80 - 150 characters explaining WHEN to call each. Example: 'workitem: Create, retrieve, update, or delete work items (tickets/tasks) in a Plane project. Use with project_id and optional pql filters. Destructive operations (delete, update) should be confirmed before executing.'
• Add enum constraints to 'action' and 'detail' parameters: action: enum ["create", "retrieve", "update", "delete", "list"], detail: enum ["brief", "full"].
• Document required vs optional parameters. Mark type_id and name as required for 'create'; optional for 'retrieve'/'list'.
• Add error recovery guidance to each tool. Example: 'If project_id is invalid, call list_projects to discover valid IDs. If pql syntax is wrong, call get_pql_reference(detail="full") for syntax help.'
• Describe side effects clearly: 'delete and update operations are irreversible. No dry-run mode available, verify inputs carefully.'
• Add parameter format hints. Example for pql: 'Plane Query Language filter syntax. See get_pql_reference for examples. Common: "status = open AND assignee = me".'
• Declare idempotency per action. Example: 'create action is NOT idempotent, calling twice creates two work items. Use update action to modify existing items.'
• Return sample response structure in descriptions. Example: 'Returns work item object: {id, name, status, project_id, assignee, created_at}. Use id for chaining to other tools.'

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry