The 1inch MCP server has 6 tools with consistent naming patterns (verb_noun), reasonable descriptions, and visible input schemas. However, there are critical gaps: (1) Output schemas are not documented in any tool description or return type hints; (2) Parameter descriptions lack format constraints and range specifications; (3) Error handling is absent, no guidance on recovery or retryable errors; (4) Tool composition could be improved, some tools are narrowly scoped and may require chained calls. The server shows foundational competence but lacks production-grade polish expected of A-tier tools.

• Document output schemas for all 6 tools. For each tool, add a 'Returns' section describing the response structure, field types, and semantics. Example: 'Returns a list of objects with fields: {order_hash: string, maker_address: string, taker_asset: string, status: 1|2|3}.'
• Formalize parameter constraints using JSON Schema enums and patterns. For statuses in get_limit_orders_count_by_filters, add 'enum: [1, 2, 3]' to the schema. For address/hash fields, add a pattern constraint matching valid EVM addresses or hash formats.
• Enhance parameter descriptions with validation rules and units. Example for maker_amount: 'The amount of maker tokens to sell, in wei (18-decimal fixed-point integer). Range: 1 to 2^256-1.'
• Add error handling guidance to each tool. Example: 'If the wallet address is invalid, returns 400 with message: "Invalid address format. Must be a 0x-prefixed hex string, 42 characters." Retry with a corrected address.' Include guidance for not found, timeout, and API errors.
• Add explicit pagination documentation. For tools that accept page/limit, state: 'Returns {items: [...], total: int, next_cursor: string | null}. If next_cursor is null, no more results are available.' Implement limit enforcement (1-100) in the schema and description.
• Cross-reference related tools in descriptions to guide composition. Example in get_limit_orders_by_chain_and_address: 'Returns order hashes. Use get_limit_order_by_hash(order_hash) to retrieve full order details.'
• Clarify numeric semantics and supported chain IDs. Document which chains are valid (e.g., 1=Ethereum, 137=Polygon, 42161=Arbitrum) with exact chain ID to network mapping. For monetary amounts, always state units (wei, raw tokens, or scaled) and supported ranges.