Server defines 15 tools with complete input schemas and descriptions in Chinese. Naming follows verb_noun pattern (knowledge_search, knowledge_learn, etc.). Descriptions are present (avg ~120 chars) but lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameters have types and descriptions, but many lack constraints (enums, ranges, format specs). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable: tools are single-purpose and chainable via IDs. Security: no secrets in params (good), but no permission gates or audit trail declarations visible.

• Add output schema documentation to every tool. Example for knowledge_search: 'Returns {entries: [{id, title, content, tags, project, relevance_score}], total_count, next_cursor}'. This enables LLMs to plan downstream calls.
• Add tool annotations to src/index.ts tool registration. Mark knowledge_learn, knowledge_confirm, knowledge_maintenance, knowledge_import, knowledge_practice, knowledge_role_config, knowledge_request_refresh, knowledge_report_gap with destructiveHint=true or idempotentHint=true as appropriate.
• Add min/max constraints to numeric parameters. Example: knowledge_search.limit: {type: 'number', minimum: 1, maximum: 100, description: '...'}. This prevents LLM from passing unreasonable values.
• Expand descriptions with WHEN-to-use guidance. Example for knowledge_search: 'Use for keyword/semantic search across all knowledge. For role-specific context, use knowledge_relevant instead.' This disambiguates overlapping tools.
• Document error recovery paths. Example: 'If knowledge_search returns empty results, call knowledge_report_gap to flag a knowledge gap and optionally trigger auto-digestion via source_url.' This guides agent planning.