SDForge exhibits pervasive quality gaps across all 12 tools. All descriptions are in Chinese (non-English), limiting LLM comprehension in English-first environments. Tool names lack action verbs (e.g., 'hello', 'greet' instead of 'send_greeting'). Most critically, parameter descriptions are minimal (5-20 chars) and lack actionable constraints. No output schemas are documented. The 'process_data' tool accepts generic 'object' types with no field specification, violating schema clarity. Error handling is absent from all tool definitions. Only 'process_data' declares a WRITE risk; others lack risk annotations. No tool demonstrates idempotency guarantees or recovery guidance.

• Translate all tool and parameter descriptions to English. Use clear, concise language (50-200 chars per tool, 30-100 chars per param) that explains WHAT the tool does, WHEN to use it, and any prerequisites.
• Add explicit enum constraints to parameters with fixed valid values. E.g., 'calculate' operation should have enum: ['add', 'subtract', 'multiply', 'divide']. Replace free-form strings with enums to prevent hallucinated values.
• Document output schemas for all tools. Specify return type (object, array, string, number), required fields, and field types. E.g., 'get_data returns {id: integer, name: string, value: number}'.
• Replace generic 'object' types in 'process_data' with explicit schemas. Define what fields 'data' and 'options' accept, their types, and which are required vs optional.
• Strengthen tool names with action verbs. Rename 'hello' → 'send_greeting', 'greet' → 'greet_user', 'get_time' → 'fetch_current_time'. Ensure each name conveys the action before the LLM reads the description.

Inferred effective spec: <=2025-11-25.

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