Server has 13 tools with consistent naming (verb_noun pattern) and descriptions present for all. However, parameter descriptions are often generic or incomplete. Input schemas are visible and mostly well-typed, but output schemas are not documented, tools return JSON strings without declared structure. Error handling is minimal (generic try-catch with string messages). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound: tools are single-responsibility and chainable via IDs. Naming is clear and action-oriented, but parameter constraints (enums, ranges) are largely absent.

• Document output schemas for all tools. E.g. shiori_list_bookmarks returns {bookmarks: [{id, title, url, tags, excerpt, public}], total: int}. This enables LLMs to chain calls and extract fields.
• Add tool annotations via FastMCP. Mark shiori_delete_bookmark and shiori_delete_bookmarks with destructiveHint=true. Mark read-only tools with readOnlyHint=true. This signals to clients which tools are safe to retry.
• Add parameter constraints: limit as integer with minimum=1, maximum=100; offset as integer with minimum=0. Add enum for public (true|false). Add regex pattern for tag names if Shiori enforces one.
• Improve error messages with recovery guidance. E.g. 'Bookmark not found (id={bookmark_id}). Try shiori_search_bookmarks() to find the correct ID.' Categorize errors as retryable vs user-fixable.
• For shiori_update_bookmark, accept structured input (title, excerpt, tags, public, createArchive fields) instead of raw JSON string. Validate each field before sending to API. This prevents malformed JSON and improves LLM usability.