Server has 9 tools with consistent naming (verb_noun pattern) and descriptions present for all. Input schemas are visible and typed with Zod. However, output schemas are completely absent, no tool documents what it returns, forcing LLMs to guess downstream field names and types. Parameter descriptions are present but often generic (e.g., 'ID of the document to archive'). Error handling is minimal, no recovery guidance, no categorization of retryable vs. fatal errors. Missing tool annotations (readOnlyHint, destructiveHint) despite having tools marked READ_ONLY and DESTRUCTIVE. No pagination support visible on list-like tools (ask_documents). Composition is reasonable, tools are single-purpose, but chaining is hindered by absent output schemas.

• Add outputSchema to every tool definition in toolRegistry.ts. Document all returned fields with types and descriptions. E.g., create_document should return {id: string, title: string, url: string, collectionId: string, createdAt: string}.
• Register tool annotations via server.registerTool() options. Add destructiveHint: true to delete_comment and delete_document; readOnlyHint: true to ask_documents and get_collection.
• Wrap tool callbacks with error handling that categorizes errors. Return {error: string, code: 'NOT_FOUND'|'INVALID_INPUT'|'PERMISSION_DENIED'|'RETRYABLE', suggestion?: string} instead of raw exceptions.
• Add pagination to ask_documents: accept limit (1-100, default 20) and cursor parameters; return {results: [...], nextCursor?: string, total: number}.
• Enhance parameter descriptions with format/constraint details. E.g., 'Hex color code (6 digits, e.g. #FF5733)' instead of 'Hex color code for the collection'.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry