OpenViking MCP has 6 tools with basic schemas and descriptions in Chinese. All tools are READ_ONLY and properly registered via FastMCP. However, critical gaps exist: (1) descriptions are minimal (10-30 chars), well below the 50-200 char LLM-optimized baseline; (2) parameter descriptions lack detail on format, constraints, and use cases; (3) no output schemas documented, LLMs cannot predict response structure; (4) error handling returns raw strings or JSON without recovery guidance; (5) no pagination support despite tools returning lists (find, glob, grep). Tool names follow verb_noun pattern (openviking_*) but are domain-specific and lack clarity for general LLM reasoning.

• Expand all tool descriptions to 80-150 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'openviking_find: Semantic search across the knowledge base. Use this for topic discovery; use openviking_grep for exact text matching. Returns up to [limit] resources ranked by relevance score.'
• Document output schemas explicitly. Add a 'Returns' section to each tool docstring specifying field names, types, and meanings. E.g., 'Returns: [{uri: string, score: float (0-1), preview: string (first 500 chars)}]'
• Add format constraints to parameter descriptions. E.g., 'pattern: glob pattern (e.g., **/*.pdf, *.md). Supports * and ** wildcards. Max 256 chars.' and 'query: free-text search string. Max 1000 chars. Supports AND/OR operators.'
• Implement pagination: add offset/limit params to openviking_find, openviking_glob, openviking_grep. Return total_count and next_offset in responses. Cap default limit at 20-50 items.
• Replace raw error strings with structured error responses. Return {error: string, code: string, retryable: bool, suggestion: string}. E.g., '{error: "URI not found", code: "NOT_FOUND", retryable: false, suggestion: "Try openviking_glob to list available resources."}'.