All 17 tools share an identical, severely underdeveloped schema. Each tool accepts only a generic 'payload' parameter (type: object, description: 'JSON body for the toolbox endpoint') with no nested field definitions, type constraints, or validation guidance. Tool descriptions are present but minimal (10 - 50 chars), offering no actionable context for LLM selection. No output schemas are documented. The design treats the MCP server as a thin HTTP proxy rather than a well-defined tool interface, violating core patterns around parameter clarity, schema completeness, and LLM-optimized descriptions.

• Expand each tool's description to 100 - 200 chars. Include: what the tool does, when to use it (vs. similar tools), required input fields, and output structure. E.g., 'Summarize a single text into a concise summary. Use batch_summarize for multiple texts. Input: {text: string, max_length?: number}. Output: {summary: string, word_count: number}'.
• Define nested schema for 'payload' parameter. For each tool, document required and optional fields with types and constraints. E.g., summarize payload: {text: string (required, 1 - 100k chars), max_length: integer (optional, 50 - 1000, default 200)}.
• Document output schemas for all tools. Specify field names, types, and meanings. E.g., summarize returns {summary: string, word_count: number, source_word_count: number}. This enables LLMs to chain tools and extract data reliably.
• Add error handling guidance. When toolbox is unreachable or returns an error, include a recovery hint: 'Toolbox at http://localhost:8888 is unreachable. Ensure the FastAPI backend is running. Retry in 5 seconds.' For validation errors, echo the invalid field and expected format.
• Rename ambiguous tools: 'batch' → 'batch_operations' or 'run_batch_operations'; 'chat' → 'send_chat_message' or 'chat_with_model'. Add descriptions clarifying the distinction from single-operation tools.