Critical gaps across all dimensions. Tool definitions are inferred from Dockerfile comments and a validation script rather than explicit MCP schema registration. No input schemas visible for any tool except nika_check (single string param). Descriptions are present but generic (10-80 chars, well below 50-200 char baseline for LLM optimization). No parameter descriptions for most tools. No output schemas documented. The check-mcp-tools.py script validates tool NAME consistency but does not reveal parameter types, constraints, or response structures. Tools appear to be read-only discovery/validation utilities with no composition chain or error recovery guidance.

• Add explicit input schemas for all 9 tools. For nika_explain, nika_inspect, nika_catalog, nika_tools: document required/optional parameters (e.g., workflow_name, workflow_path, query_string). Use JSON Schema with type, description, and enum/pattern constraints.
• Expand descriptions to 50-200 characters. Example: 'nika_schema' → 'Retrieve the complete Nika workflow schema specification (JSON). Use this to understand valid workflow structure, field types, and constraints before validating or creating workflows.' Include WHEN to call and WHAT to expect.
• Document output schemas for all tools. E.g., nika_schema returns {schema: object, version: string}; nika_examples returns {examples: [{name: string, code: string, description: string}]}. This enables LLMs to chain tools and extract required fields.
• Add parameter descriptions. For nika_check's 'file' param: 'Path to the .nika workflow file to validate (relative or absolute; must exist and be readable).' For tools accepting optional query/filter params, document format and constraints.
• Add error recovery guidance to descriptions. E.g., nika_check: 'Returns validation errors with line numbers and remediation hints. If validation fails, call nika_explain to understand the constraint, then nika_template to see a correct example.'