Server has 12 tools with complete input schemas and descriptions. Naming follows verb_noun convention (publish_post, list_posts, get_post, etc.). Descriptions are present but brief (avg ~60 chars, below the 194-char baseline). Parameters are typed and mostly described, but lack actionable constraints (enums, ranges, format hints). Output schemas are not documented in the source. Error handling is minimal, no recovery guidance or categorization. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE). Missing parameter validation rules and dependency documentation.

• Document output schemas for all 12 tools. Example: publish_post returns {file: string, title: string, id: string, createdAt: string}. This enables LLMs to chain tools correctly.
• Add tool annotations: mark delete_post with destructiveHint=true, publish_post/update_post with idempotentHint=false (or true if retries are safe), and read-only tools with readOnlyHint=true.
• Enhance parameter descriptions with format constraints. E.g., 'file: Post filename (e.g., my-post.md, no path separators)' and 'query: Search term (1-100 chars, case-insensitive)'.
• Implement confirmation flow for delete_post: return {status: 'confirm_required', file: string, message: 'Delete post X? This cannot be undone.'} and require a confirm_delete_post tool or a confirmation parameter.
• Add error recovery guidance in tool descriptions. E.g., 'If file not found, call list_posts() to discover available posts' and 'If dev.to API fails, retry after 30s or use local-only mode.'

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained