All 15 tools share identical, severely underdeveloped schemas and descriptions. Every tool accepts a single generic 'input' parameter (type: string, description: 'Input data (JSON)') with no structure, validation, or guidance. Descriptions are 2 - 5 words, far below the 10 - 1024 character baseline and insufficient for LLM tool selection. No output schemas documented. No error handling guidance. Tools are thin proxies to a remote Bankr API; actual logic is opaque. This server fails to meet production quality standards across naming, parameter design, and schema completeness.

• Expand every tool description to 50 - 200 characters. Include: (1) what the tool does, (2) when to use it vs. similar tools, (3) what it returns. Example: 'Analyze a manufacturing process for failure modes using FMEA methodology. Returns risk priority numbers (RPN) and mitigation recommendations. Use this before design review.'
• Replace the generic 'input' parameter with domain-specific, typed parameters. For fmea_analyzer, define: process_name (string), failure_modes (array of {mode, cause, effect}), severity_scale (enum: 1-10), occurrence_scale (enum: 1-10). Document each field's purpose and constraints.
• Document output schemas for every tool. Example for fmea_analyzer: {type: 'object', properties: {rpn_scores: [{failure_mode: string, severity: number, occurrence: number, detection: number, rpn: number}], top_risks: array, recommendations: array}}.
• Add error handling with recovery guidance. Catch network timeouts, invalid JSON input, and API errors. Return: {status: 'error', code: 'invalid_input|timeout|api_error', message: 'User-friendly explanation', suggestion: 'Try calling search_processes() first to find a valid process_name'}.
• Rename tools to start with action verbs: 'fmea_analyzer' → 'analyze_fmea', 'quality_audit' → 'run_quality_audit', 'compliance_check' → 'check_compliance'. This helps LLMs parse intent from the name alone.