Workflowy MCP server has 13 tools with generally adequate naming and descriptions, but significant gaps in schema documentation and parameter descriptions. Tool names follow verb_noun conventions (find_node, create, delete, edit, move, search_nodes, etc.), which is good. Descriptions are present for all tools and average ~120 characters, within the 10-1024 character baseline. However, parameter schemas visible in the tool list show inconsistent documentation: most tools have parameters with descriptions, but the actual JSON Schema visibility is limited in the provided code excerpt. The server includes both read-only and destructive operations, with some error handling guidance expected but not fully visible in the snippet. Tool composition is reasonable, separate tools for different operations (find_node vs search_nodes, create vs insert, edit vs move vs delete). Output schemas are not documented in the provided code. Pagination and result limiting are not evident. The audit_mirrors and review tools perform domain-specific analysis, which is good specialization.

• Document output schemas for all tools. Specify what fields each tool returns, their types, and whether they are nullable. Include examples of the response structure so LLMs can plan downstream calls.
• Add pagination parameters (limit, offset/cursor, page_size) to search_nodes, children, and subtree. Cap default results at 20-50 items and document the limit in the tool description.
• For the delete tool, add a 'confirm' boolean parameter that defaults to false, and require a confirmation call before actual deletion. Alternatively, implement a separate 'confirm_delete' tool.
• Expand descriptions for children, edit, audit_mirrors, and review to 100-200 characters. Include context on when to call the tool and what it returns (e.g., 'Returns a list of direct child nodes with their IDs and names. Use this to explore the tree structure.').
• Clarify optional parameter semantics: 'description' in create (optional, defaults to empty), 'relative_priority' in move (optional, appends to end if omitted). Make these explicit in parameter descriptions.
• Add error guidance to write operations (create, insert, edit, move, delete). For example: 'If parent_id is invalid, the error will indicate which node IDs are valid. Retry with a valid parent_id.'
• Document what search_nodes returns beyond matching nodes, include hit count, whether results are paginated, and how to fetch the next page.
• For review's optional 'source_moc_blob' parameter, explain the expected format (e.g., 'Session log text, line-delimited') and what happens if it's omitted (e.g., 'Skips source MOC re-citation check').

Inferred effective spec: <=2025-11-25.

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