Server provides three read-only Wiki.JS tools with verb-based naming (search_, list_, get_) and non-empty descriptions. All tools have properly typed input schemas using Zod with parameter descriptions. However, several gaps reduce quality: (1) descriptions are brief and lack WHEN/WHY guidance for tool selection; (2) output schemas are not explicitly documented, responses are formatted as text within content arrays but the field structure and pagination metadata are not declared upfront; (3) error handling is absent, no guidance on what happens on network failure, invalid pageId, or missing pages; (4) parameters accept numeric ranges but constraints are not enforced or validated client-side; (5) no mention of rate limits, timeout behavior, or service prerequisites (Wiki.JS URL, API key injection pattern). Tools follow composition rules well (one clear action each) and chain logically (search/list return pages, get requires pageId), but lack the production-grade robustness expected for a 70+ score.

• Document output schemas explicitly. Define the structure returned by each tool: e.g., for search_wiki_pages, document that it returns {total: number, page: number, pages: Array<{title, path, updatedAt, author, description, tags}>}. This lets LLMs know what fields are available for downstream planning.
• Expand tool descriptions to include WHEN/WHY. Example: 'Search Wiki.JS pages for specific topics or keywords. Use this when you have a partial match or topic name. If you know the exact page path or ID, use get_wiki_page() instead. Returns up to 50 results per page with metadata (author, tags, update date) to help the LLM pick the most relevant page.'
• Add error handling with recovery guidance. Catch exceptions from WikiService (network errors, invalid IDs, malformed responses) and return structured errors: {type: 'not_found', message: 'Page with path "deepgram" not found. Did you mean: deepgram-setup, deepgram-api-reference? Try search_wiki_pages("deepgram") to find available pages.'}
• Validate and constrain parameters before calling WikiService. Enforce limit ∈ [1, 50], page ≥ 1. For pageId in get_wiki_page, validate that it matches numeric ID pattern (\d+) or safe string pattern [a-z0-9-]+. Return: 'Invalid pageId: "../../../etc/passwd". Expected numeric ID or kebab-case path (a-z, 0-9, hyphens only).'
• Add timeout and rate limit hints in server initialization. Document expected response times (e.g., search typically <1s, get may be slower for large pages) and recommend rate limits for agents (e.g., max 10 calls/sec). This helps clients configure circuit breakers and backoff.