srdcheck provides three tools with complete input schemas and reasonable descriptions, but exhibits significant inconsistencies in schema quality, parameter documentation, and output schema visibility. Tool names follow action-verb patterns (use, move, options) but descriptions vary in completeness. Two of three tools have parameter descriptions (weight_lb, distance_ft, board, player, cell) but the 'kind' parameter in mage-hand.use lacks meaningful guidance on valid values. Output schemas are not documented in the visible code, preventing verification of response structure and downstream tool chaining. The tic-tac-toe tools (ttt.move, ttt.options) are well-scoped READ_ONLY operations with deterministic behavior, but mage-hand.use's description ('Adjudicate a proposed use...') is 96 characters, below the 194-char baseline for A-tier tools and lacks specifics on what constitutes a valid 'use'. No evidence of error handling guidance, recovery paths, or validation messaging. Parameter constraints (distance_ft, weight_lb as integers, player as X|O) are partially documented but lack explicit bounds or enum declarations in visible schema.

• Document the complete output schema for all three tools. Include response field names, types, and descriptions so LLMs can plan downstream calls. E.g., for ttt.move: {"valid": boolean, "board_after": string, "game_over": boolean, "winner": string|null, "reason": string}
• Add formal enum constraints to the 'kind' parameter in mage-hand.use. Update the schema to include: "enum": ["attack", "manipulate_object", "stow_retrieve_open", "pour_vial"] with descriptions for each option.
• Expand mage-hand.use description to 150 - 250 characters. State: 'Adjudicate whether a D&D 5e Mage Hand spell can perform the proposed action. Checks range (120 ft), object weight (max 5 lb), and allowed actions (attack invalid; manipulate, open, stow, retrieve, pour valid). Returns verdict with rule citations.'
• Add explicit bounds and constraints to numeric parameters: distance_ft (0 - 120 ft for Mage Hand), weight_lb (0 - 5 lb), cell (1 - 9). Update parameter descriptions to enforce these as validation rules, not prose.
• Implement error-handling guidance. Document that invalid board states, out-of-turn moves, or occupied cells return structured error with reason and recovery suggestion: 'Cell 5 occupied. Legal moves: [1, 3, 7, 9]'
• For ttt.move, document in description that the response includes the updated board state, whether the game is over, and who wins (if applicable). Make it clear to agents what they can infer from a single call.
• Consider adding an idempotent or read_only annotation to signal these tools do not modify persistent state (assuming they validate without saving board/game state). This guides agent retry logic.