XFuel MCP server has 5 tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun convention (chat_completions, submit_task, get_quote, verify_receipt, get_task_status), which is good. However, descriptions are minimal (50-100 chars), parameter descriptions lack detail on constraints and formats, and no output schemas are documented. The server exposes financial operations (USDC payments, on-chain settlement) without documented error recovery paths or confirmation patterns. No evidence of input validation guidance, rate limiting, or idempotency markers. Schemas present but sparse, most parameters lack constraint documentation (e.g., temperature range 0-2 stated in description but not in schema; amount_usdc has no min/max bounds).

• Add JSON Schema constraints to all numeric parameters: temperature (minimum: 0, maximum: 2), max_tokens (minimum: 1, maximum: 4096), amount_usdc (minimum: 0.01, exclusiveMinimum: true). Replace informal descriptions with formal schema.
• Document output schemas for all tools. E.g., chat_completions returns {id, model, choices: [{message: {role, content}}], usage: {prompt_tokens, completion_tokens}}. verify_receipt returns {valid: boolean, payment_hash, output_hash, timestamp}.
• Add confirmation/dry-run pattern to submit_task and chat_completions (settle=true). Introduce a 'dry_run' boolean parameter or a separate 'preview_task' tool that returns cost estimate without executing.
• Expand error descriptions with recovery guidance. E.g., 'Task not found (task_id=xyz). Check task_id spelling or call get_task_status with a recent task_id from submit_task response.' Include actionable next steps for each error class.
• Declare idempotency and retry safety. Add to descriptions: 'This operation is idempotent, retrying with the same input will not create duplicate charges.' Or: 'This operation is NOT idempotent, retrying may create duplicate tasks; use task_id to check status before retrying.'