Windlass defines 3 tools with explicit schemas and descriptions. All tools have non-empty descriptions (10-200 chars range) and input parameters with type definitions. However, output schemas are not documented, responses are JSON-stringified text without declared structure. Parameter descriptions are minimal (e.g., 'Task name' for 'name' param). Error handling returns isError=true with text messages but lacks recovery guidance or categorization. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tool names follow verb_noun pattern (run_task, check_task, list_tasks) but descriptions could better explain WHEN to use each tool vs alternatives.

• Document output schemas for all tools. Define the structure of returned JSON: field names, types, required fields, and what each field represents. E.g., run_task returns {id: string, name: string, status: 'pending'|'running'|'success'|'failed', attempts: number, duration: number, failedCriteria: string[]}.
• Expand parameter descriptions with format and constraint details. E.g., 'name' → 'Task name (1-255 characters, alphanumeric + hyphens only)'. 'type' → 'Task type: one of code_execution, validation, integration_test, or custom_workflow'.
• Add tool annotations: mark run_task with destructiveHint=true (executes code, may modify system state); mark check_task and list_tasks with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., 'Task not found (ID: abc123). Call list_tasks() to see available task IDs.' or 'Invalid task definition: missing required field "success_criteria". See documentation for schema.'
• Clarify when to use run_task with inline definitions vs file paths. Add a note: 'Use inline definitions for simple single-task runs; use file paths for complex pipelines or when task definitions are pre-stored.'