Server has 17 tools with consistent naming (verb_noun pattern) and Zod schemas present. However, descriptions are generic and parameter documentation is sparse. Most tools lack actionable error guidance, recovery hints, and output schema documentation. Schemas are defined but not visible in tool registration calls, inferred from separate schema file. No tool annotations (readOnlyHint/destructiveHint) despite risk labels in metadata. Response format parameter is present on all tools but adds noise without clear value. Average description length ~60 chars (below 194-char baseline); many lack context for LLM selection.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. E.g., 'Update author metadata (name, bio). Use this to correct author details after matching. Returns updated author object with all fields.'
• Add tool annotations to registration: mark grimmory_delete_authors and grimmory_unmatch_authors with destructiveHint=true; mark all read-only tools with readOnlyHint=true. This enables LLM safety reasoning.
• Document output schemas for all tools. Create a schema reference showing: list_books returns {books: [{id, title, author_id, ...}], total, page}. This enables tool chaining without guesswork.
• Add error recovery guidance to descriptions of write/destructive tools. E.g., 'If matching fails, try grimmory_search_author_metadata first to verify the author exists and has metadata available.'
• Consider removing response_format parameter or document its purpose clearly. If it's for display formatting, handle it client-side. If both JSON and markdown are needed for different use cases, explain when each is appropriate.

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

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