Reweave demonstrates solid naming conventions (verb-first: list_, run_, approve_, reject_, add_, get_) and comprehensive tool annotations (readOnlyHint, destructiveHint). All 9 tools have descriptions (avg ~120 chars, within baseline 34-392 range) and explicit input schemas with required fields. However, parameter descriptions are sparse: most parameters lack inline descriptions explaining their purpose, format, or constraints. For example, 'source_id' appears in 3 tools but has no description. The 'actor' parameter in approve_heal and reject_heal lacks guidance on expected format (email? username? full name?). Output schemas are entirely undocumented, LLMs cannot infer what list_sources, get_rows, or impact_report return. Error handling is implicit; no tool documents recovery paths or categorizes failures. The 'golden' parameter in add_source (array of objects) has no schema for the object structure. Overall: good naming and annotation discipline, but parameter and output documentation gaps prevent higher scores.

• Document output schemas for all tools. Example: list_sources should return {sources: [{id: string, name: string, health: 'healthy'|'degraded'|'failed', spec_version: string}], total: number}.
• Add descriptions to all parameters. For 'source_id', add: 'The unique identifier of the monitored source (string, required).' For 'actor', add: 'Email or username of the human approving this deploy (required for audit trail).'
• Add error recovery guidance to tool descriptions. Example for run_pipeline: 'If source_id not found, call list_sources() first to see available sources.'
• Define the schema for 'golden' array items in add_source. Example: 'golden: array of objects, each with {field_name: string, value: any} or {css_selector: string, expected_value: string}.'
• Add a dry_run parameter to approve_heal to preview the deployment before committing. Return the proposed spec diff and ask for confirmation.