Rosary exposes 4 well-named, action-verb tools (rsry_run_once, rsry_bead_create, rsry_bead_update, rsry_bead_close) with detailed descriptions and structured JSON schemas. Tools follow verb_noun naming convention. Descriptions are substantive (100 - 400 chars), explaining WHAT the tool does, WHEN to use it, and key prerequisites. Input schemas are present with proper JSON types. However, there are notable gaps: (1) Output schemas are not documented in the provided code, we cannot verify what fields are returned or their structure; (2) Tool descriptions lack explicit error guidance or recovery patterns; (3) Some parameter relationships are complex (e.g., scope vs repo_path, or the intricate file overlap semantics) but underdocumented; (4) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) present in the MCP registration, limiting LLM ability to reason about side effects. The bead creation tool has exceptionally detailed parameter descriptions that reference internal functions (has_file_overlap, ADR-0010), which is good for domain experts but potentially confusing for LLMs without those implementation details. Descriptions are LLM-optimized where present, but lack actionable error guidance (e.g., 'if bead creation fails due to missing close condition, add a test_files parameter or acceptance_criteria field').

• Document output schemas for all four tools. Specify returned fields, types, and whether results are paginated. Example for rsry_run_once: {status: 'started'|'completed', bead_id?: string, timestamp: ISO8601, pipeline_status?: {...}}
• Add tool annotations to MCP tool registration: rsry_run_once and rsry_bead_create → destructiveHint=true; rsry_bead_close → idempotentHint=true (closing an already-closed bead should be safe); rsry_bead_update → no destructive annotation if only updating metadata.
• Expand parameter descriptions in rsry_bead_update to match baseline (72+ chars). Example: 'priority' → 'New priority level (0=P0/critical, 1=P1/high, 2=P2/normal, 3=P3/low). Omit to keep current value.'
• Extract domain logic (file overlap, close conditions) into a separate documentation artifact and link it from tool descriptions. Descriptions should say: 'Files determine parallel dispatch safety (see docs/file-overlap.md). Each file must map to a specific code path touched by the work.'
• Add error recovery guidance to rsry_bead_create and rsry_bead_close: 'If creation fails with "no close condition", add an acceptance_criteria parameter (e.g., "All tests pass") or include test_files.' and 'If closing fails with "incomplete work", verify tests pass (run: `task test`) and all commits are pushed.'
• Explicitly state mutually exclusive parameter groups in each tool description. Example: 'Provide either scope (canonical) OR repo_path (legacy). scope takes priority if both are given.'
• Document what dry_run=true returns for rsry_run_once. Does it return a preview of dispatches? A full pipeline simulation? This affects LLM behavior in planning scenarios.