Server has 7 tools with complete input schemas and descriptions in German. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or what to do with results. Parameter descriptions exist but are minimal (avg ~40 chars, below 72-char baseline). No output schemas documented. Error handling is absent, tools fail silently or return raw database errors. No tool annotations (readOnlyHint/destructiveHint). Tool composition is reasonable (single responsibility), but register_service and rate_service lack confirmation/dry-run patterns for destructive operations. Naming follows verb_noun convention (register_, search_, get_, rate_, list_, top_, directory_) which is good, but descriptions don't explain dependencies or recovery paths.

• Document output schemas for all tools. Example for search_services: 'Returns array of {name: string, category: string, avg_rating: float, total_ratings: int, capabilities: [string], tags: [string], endpoint: string}. Results ordered by rating DESC, calls DESC. Limit capped at 20 to prevent context overflow.'
• Expand descriptions to 100 - 200 chars with WHEN/WHY guidance. Example: 'Search the service directory by keyword, category, or tags. Use this to discover available AI services before calling get_service for details. Results ranked by rating and popularity.'
• Add error recovery guidance. Example for register_service: 'Registers or updates a service. If name already exists, the service is updated. Returns {name, registered: bool, updated_at}. On validation error, returns {error: string, suggestion: string}.'
• Implement dry-run or confirmation for register_service and rate_service. Add optional 'dry_run: bool' parameter. When true, validate but do not persist. Return {valid: bool, errors: [string], preview: object}.
• Add tool annotations via FastMCP. Mark register_service and rate_service with destructiveHint=true. Mark read-only tools with readOnlyHint=true. This enables agents to reason about side effects without reading descriptions.