Server has 4 tools with explicit Zod schemas and basic descriptions. However, descriptions are minimal (10-30 chars), lack context on WHEN to use each tool, and omit error recovery guidance. Parameter descriptions exist but are generic. Output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint). Naming follows verb_noun convention (list, search, add, delete) but lacks clarity on relationships between tools. Error handling returns only 'ok'/'fail' strings with no actionable guidance. Composition is reasonable (each tool has one responsibility), but missing pagination, result limits, and chaining IDs in responses.

• Expand tool descriptions to 100-200 chars. For listKnowledge: 'List all knowledge items with multi-dimensional filtering by project type, app ID, visibility, owner, and tags. Use this to discover available knowledge before searching. Supports permission-based filtering via currentUser and currentTeam.'
• Document output schemas in tool descriptions or as a separate schema field. E.g., 'Returns array of {id, title, summary, example, projectTypes, visibility, owner, tags, createdAt, updatedAt}' so LLMs know what fields to extract.
• Add pagination to listKnowledge and searchKnowledge: introduce 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return {items: [...], total: N, hasMore: bool} to enable multi-page discovery.
• Replace 'ok'/'fail' responses with structured error objects: {success: bool, message: string, code: string, suggestion?: string}. E.g., deleteKnowledge failure: {success: false, code: 'PERMISSION_DENIED', message: 'User does not own this item', suggestion: 'Contact the owner or an admin to request deletion'}.
• Add tool annotations in server.tool() calls: pass a third parameter with {readOnlyHint: true} for listKnowledge/searchKnowledge, {destructiveHint: true} for deleteKnowledge, {idempotentHint: true} for addKnowledge (if ID-based deduplication is implemented).