Server has 9 tools with complete Zod schemas and descriptions in Russian. All tools are properly registered with input schemas visible in src/tools/*.ts. However, descriptions are minimal (10-50 chars), lack actionable context for LLM selection, and do not explain when to use each tool vs. alternatives. Parameters have types and descriptions but lack constraints (enums, ranges, patterns). Output schemas are not documented, responses are JSON stringified but structure is opaque to the LLM. Error handling is absent; no recovery guidance. Naming is clear (verb_noun pattern) but generic descriptions undermine discoverability. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction.

• Expand tool descriptions to 100 - 200 chars. Include WHAT the tool does, WHEN to use it (vs. similar tools), and WHAT it returns. E.g., 'Retrieve a paginated list of items in an ELMA365 app by namespace and code. Use this to browse app records; for tasks, use get_tasks instead. Returns {items: [...], total: number}.'
• Document output schemas in tool descriptions or as a separate schema field. Specify the structure of returned objects (e.g., 'Returns {items: [{id, name, status}], total: number, hasMore: boolean}') so LLMs know what fields to extract.
• Add error handling with recovery guidance. Wrap elmaRequest() calls in try-catch; return structured errors like {error: 'User not found', suggestion: 'Try search_users() with a partial name'} instead of raw exceptions.
• Add tool annotations: mark create_item, start_process, add_comment with destructiveHint: true; mark all get_* tools with readOnlyHint: true. This signals to LLMs which tools have side effects.
• Add parameter constraints: 'from' and 'size' should have min/max (e.g., size: 1 - 100, from: 0 - 999999); 'data' in create_item should document required fields and field types (e.g., 'Object with app-specific fields; consult ELMA365 app schema').