Server defines 11 tools with Zod schemas and descriptions in Russian. All tools have input schemas with type definitions and parameter descriptions. However, descriptions are terse (avg ~80 chars, below the 194-char baseline), lack WHEN/WHY context, and do not guide LLM selection between similar tools (e.g., metadata_list vs metadata_search vs metadata_get). Output schemas are undocumented, LLMs cannot predict response structure. Error handling is minimal: OnecError exists but handlers do not return actionable recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (9 READ_ONLY, 2 WRITE). Parameter descriptions are present but sparse; e.g., 'filter' in metadata_list lacks format/example guidance. No pagination support documented for list tools. Naming is clear (verb_noun pattern) and consistent.

• Document output schema for every tool. Include field names, types, and whether fields are always present or conditional. Example: 'Returns {items: [{fullName: string, kind: string, synonym: string}], total: number}'.
• Expand tool descriptions to 100 - 200 chars. Add WHEN/WHY context: 'Use metadata_list to discover available object types (Справочники, Документы, etc.). Use metadata_search to find a specific object by name. Use metadata_get to retrieve full structure of a known object.' This disambiguates similar tools.
• Add tool annotations to schema. Mark read-only tools with readOnlyHint: true. Mark write tools with destructiveHint: true. Mark idempotent tools with idempotentHint: true. This enables agents to reason about safety without reading descriptions.
• Add pagination to list tools. Include limit (default 20, max 100) and offset/cursor parameters. Return {items: [...], total: number, hasMore: boolean} so agents can iterate safely without blowing context.
• Enhance error messages with recovery guidance. Instead of 'OnecError: HTTP 404', return 'Object not found. Try metadata_search() to find the correct fullName, or metadata_list() to browse available objects.' Categorize errors as retryable (network timeout) vs user-fixable (invalid parameter) vs fatal (permission denied).