8 tools with complete schemas and descriptions. Naming follows verb_noun convention (get_, create_, update_, delete_, search_). Descriptions are present (avg ~80 chars) but lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameters have types and descriptions. No output schemas documented. Error handling not visible in tool definitions. Missing tool annotations (readOnlyHint, destructiveHint). Composition is sound, tools are single-responsibility and chainable (e.g., search_items → get_item_by_id). No secrets exposed as parameters.

• Document output schemas for all tools. Example: get_items should return {items: [{id, name, price, category, is_available, tags}], total: int, skip: int, limit: int}. This enables LLMs to chain tools correctly.
• Add tool annotations: mark delete_item with destructiveHint=true; mark get_* and search_* with readOnlyHint=true. Use fastmcp's @tool decorator with these hints.
• Enhance descriptions with WHEN-to-use guidance. Example: 'Get a single item by ID when you know the item_id. Use search_items to find items by name or category first if you don't have the ID.'
• Implement a confirm_delete pattern: add a dry_run parameter to delete_item, or create a separate confirm_delete_item tool that requires explicit confirmation before deletion.
• Add error handling documentation in tool docstrings. Example: 'Returns 404 if item not found, try search_items to verify the item exists. Returns 400 if price is negative, must be > 0.'

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

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