Server provides 7 read-only tools with basic schemas and descriptions. All tools have input schemas and descriptions present, but descriptions are minimal (10-80 chars, well below the 194-char baseline). Parameter descriptions are sparse or absent. No output schemas documented. Error handling returns isError flags but lacks recovery guidance. Tools follow verb_noun naming convention (read_, search_, get_) but descriptions do not explain WHEN to use each tool or how they differ. No tool annotations (readOnlyHint, etc.). Composition is reasonable, each tool has one responsibility, but parameter naming could be more explicit (e.g., 'id' should be 'entry_id' for clarity).

• Expand tool descriptions to 100 - 200 chars. Include WHEN to use each tool and how it differs from similar ones. E.g., 'Search for entries by keyword across title, content, and tags. Use this for exploratory queries; use get_entry_by_id if you already know the entry ID.'
• Document output schemas for all tools. Specify the structure of returned entries (fields, types, required vs optional). E.g., 'Returns an array of entry objects, each with {id: string, title: string, content: string, category: string, tags: string[], relatedIds: string[]}'.
• Rename parameters to include type hints: 'entry_id' instead of 'id', 'category_id' instead of 'category'. This removes ambiguity and helps LLMs pass the correct values.
• Add recovery guidance to error messages. E.g., 'Entry with ID "xyz" not found. Try search_entries(query) to find entries by keyword, or call get_knowledge_stats() to see available entries.'
• Add tool annotations to the tool definitions. Set readOnlyHint=true for all tools to signal they are safe to retry and have no side effects.