UML-Architect provides 7 tools with complete input schemas and descriptions in Indonesian. However, critical gaps limit production readiness: (1) No output schemas documented, LLMs cannot predict response structure for downstream chaining. (2) Descriptions lack actionable detail on WHEN to use each tool vs. alternatives (e.g., generate_uml_diagram vs. trace_endpoint_flow both produce diagrams). (3) Parameters like 'detail_level' use inconsistent enums (L1/L2/L3 vs. standard/high/deep) without explanation of differences. (4) No error handling guidance, tools return results or fail silently. (5) Tool names are descriptive but lack verb-noun clarity (trace_endpoint_flow vs. get_endpoint_flow). (6) No pagination, rate limiting, or result limits documented despite tools operating on entire codebases. Baseline: 549 production tools average 194-char descriptions; these average ~150 chars but lack recovery guidance.

• Add explicit output schemas to every tool. E.g., generate_uml_diagram returns {type: 'object', properties: {mermaid_code: {type: 'string'}, diagram_type: {type: 'string'}, theme: {type: 'string'}}}.
• Standardize detail_level enum to one set (e.g., [basic, standard, detailed]) and document what each level includes (e.g., 'basic: actors and main flows only; detailed: all branches and error paths').
• Expand tool descriptions to 150-250 chars with explicit WHEN-to-use guidance. E.g., 'Use trace_endpoint_flow to map full API execution (middleware→controller→DB); use generate_uml_diagram for quick visual summaries from natural language queries.'
• Add error handling section to each tool: document common failure modes (file not found, syntax error, unsupported language), categorize as retryable/user-fixable/fatal, and provide recovery steps.
• Document result limits and pagination. E.g., 'Returns up to 50 endpoints; use offset/limit params for pagination. Large projects may timeout, consider tracing individual endpoints instead.'