Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and error guidance. Three generic HTTP request tools (cloud_request, storagebox_request, robot_request) expose raw API complexity to the LLM without abstraction. The contribute_or_report tool is well-scoped. Parameter descriptions exist but lack constraint details (e.g., no enum values shown for 'surface' in contribute_or_report, no format specs for 'method'). No output schemas documented. Error handling is minimal, no recovery guidance or categorization. Tool naming follows verb_noun pattern but 'cloud_request' is generic; more specific names like 'create_server', 'list_volumes' would better guide LLM selection.

• Decompose generic HTTP tools into domain-specific operations: create_server, list_servers, delete_server, create_volume, attach_volume, etc. Each tool should have a clear verb_noun name that guides LLM selection.
• Document output schemas for all tools. Specify which fields are returned, their types, and which are safe to pass to downstream tools. Example: 'Returns {server_id: string, status: string, public_ip: string, ...}'.
• Add enum constraints to 'method' parameter: [GET, POST, PUT, PATCH, DELETE]. Add format/pattern constraints to 'path' (e.g., '^/[a-z_]+(/[a-z0-9_-]+)?$').
• Add error handling guidance: document which errors are retryable (network timeout, rate limit), which require user input (missing token, invalid region), and which are fatal (malformed request). Example: 'If you get 401 Unauthorized, check your HETZNER_CLOUD_TOKEN environment variable.'
• Expand parameter descriptions with concrete constraints. Replace 'query parameters as key-value pairs' with 'Query parameters as key-value pairs. Common keys: per_page (1-500), page (1+), sort (id|name|created). See API docs for endpoint-specific params.'