The Maicraft MCP server exhibits severe definition quality issues across all dimensions. Tool descriptions are minimal and generic (all marked as 'auto-discovered action-based tool' with no actionable detail). No input schemas are visible in the provided source code, tools appear to be registered dynamically via ActionExecutor.getDiscoveredMcpTools(), but the actual schema objects are not shown. Parameter documentation is absent. Error handling guidance is missing. The tools lack proper verb-noun naming (query_game_state vs queryPlayerStatus use inconsistent conventions). Output structures are undocumented. This server reads like a scaffolding project rather than production-ready tooling.

• Replace all tool descriptions with LLM-optimized text (50-200 characters) explaining WHAT the tool does, WHEN to use it, and WHAT it returns. Example: 'queryPlayerStatus: Retrieve the player's current health, hunger, position, and status effects. Use this to assess player survival status before combat or environmental hazards.'
• Standardize on snake_case verb_noun naming for all tools: query_game_state → get_game_state, queryPlayerStatus → get_player_status, queryRecentEvents → list_recent_events, querySurroundings → get_surrounding_environment.
• Document input schemas explicitly in the source code. Show each tool's parameters with types (e.g., radius: {type: 'number', min: 1, max: 100}, format descriptions, and constraints. Use Zod schemas or JSON Schema for clarity.
• Document output schemas for each tool. Example for get_player_status: 'Returns {health: number (0-20), hunger: number (0-20), position: {x, y, z}, effects: array of {name, level, duration_ticks}}'.
• Add error handling guidance to tool descriptions. Example: 'If the server is not connected, returns service_unavailable, wait 5 seconds and retry. If the action times out, the player state may have changed; call get_game_state to verify.'
• Separate query tools by resource type with distinct purposes. Instead of generic 'queryGameState', offer: get_player_health, get_player_position, get_game_time, get_surrounding_blocks. This lets agents call only what they need.
• For each parameter, provide a description explaining type, range, and valid values. Example: 'radius: Search radius in blocks (1-50, default 5). Only blocks within this distance are included.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry