Ashlar provides 9 tools with consistent naming (mc_* prefix) and documented descriptions. All tools have input schemas with type declarations. However, parameter descriptions are minimal (typically 1-2 words), output schemas are not documented, and error handling lacks recovery guidance. Tool names follow verb_noun pattern well (mc_status, mc_build, mc_inspect), but descriptions average ~80 chars, below the 194-char baseline for A+ tools. No parameter constraints (enums, ranges) are visible. Schemas show types but lack depth (e.g., 'from' and 'to' arrays lack item type specs or coordinate format documentation).

• Expand parameter descriptions to 50-100 chars each. For 'from' and 'to', specify: '[x, z] for 2D regions' or '[x, y, z] for 3D regions', and document coordinate system (absolute, relative to player, etc.).
• Document output schemas for all tools. E.g., mc_status returns {version: string, playerCount: int, queueLength: int, uptime: int}. mc_survey returns {heightmap: array<int>, width: int, depth: int}.
• Add enum constraints for 'view' parameter in mc_render: explicitly list ['top', 'facade', 'slice', 'heightmap'] as an enum, not just a description.
• For mc_build, document the 'ops' array structure: 'Array of fill operations, each {x: int, y: int, z: int, blockType: string, metadata?: object}'. Specify valid blockType values or reference a discovery tool.
• Add error recovery guidance to mc_build and mc_command: 'If build fails, call mc_snapshot to create a restore point, then retry. Use mc_restore(id) to undo.' Include actionable error messages (e.g., 'Invalid block type: got "stone_slab", did you mean "stone" or "smooth_stone"?').