The server defines 9 tools with complete JSON Schema input definitions and risk labels, which is good. However, tool descriptions are generic and many parameter descriptions lack specificity. The descriptions fail to explain WHEN to use each tool (e.g., when should an agent call search_pages vs get_page?), what the tool returns in detail, or any prerequisites. Parameter descriptions are present but minimal, most are single phrases like 'The content of the block' without format guidance, constraints, or examples. No output schemas are documented anywhere. Error handling exists in the code but is not reflected in tool definitions. No tool has the actionable error guidance pattern. The code shows defensive practices (permission gating for delete, logging), but these are not exposed in the tool definitions where LLMs need them. Average tool description length is ~40 chars, well below the 194-char production baseline. Parameter descriptions average ~30 chars, below the 72-char baseline. No parameter uses enums despite multiple tools (e.g., create_block, update_block) accepting enum-like values (block properties, page names). The tools follow verb_noun naming correctly and have logical composition, but lack the LLM-optimized descriptions and constraints needed for reliable agent planning.

• Add comprehensive output schemas to every tool definition. Document the exact fields returned (e.g., create_block returns {success: bool, block: {id: string, content: string, page: string, properties: object}}). This enables LLMs to chain tools correctly and extract IDs for subsequent calls.
• Expand tool descriptions to 80 - 150 characters. Include: (1) What the tool does, (2) When to use it instead of similar tools, (3) Key side effects (e.g., 'creates a new page, fails if page already exists'). Example: 'Create a new page in Logseq. Use this when you need a new namespace; use get_page to retrieve an existing page. Returns the page ID.'
• Add format and constraint documentation to every parameter. Example: 'content (string, 1 - 10000 chars, markdown or plaintext): The text to insert. Special characters and newlines are allowed.' For properties, add examples or link to Logseq property documentation.
• Document pagination limits in get_all_pages and search_pages. Add parameters for limit (default 20, max 100) and offset/cursor to handle large result sets. State in the description: 'Returns up to 20 pages; use offset to paginate larger result sets.'
• Add error guidance to descriptions. Example for delete_block: 'Deletes a block permanently (irreversible). Returns an error if the block does not exist or delete permissions are disabled (set LOGSEQ_DELETE_ENABLED=true).' This helps LLMs know whether to retry, ask the user, or try an alternative.
• Disambiguate read-only tools with clear, comparative descriptions. Add a table or bullet list to tool definitions or README explaining: 'get_page retrieves a single page by exact name (fast, requires exact match); search_pages searches all pages by keyword (flexible, returns ranked results); get_all_pages lists all pages (no search, useful for discovery).'

Inferred effective spec: <=2025-11-25.

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