All 5 tools have explicit descriptions and shared input schemas with type definitions and descriptions. However, schemas are overly generic (all tools accept identical parameters), violating single-responsibility principle. Descriptions are adequate (60-90 chars) but lack actionable context about when to use each tool vs. alternatives. No output schemas documented. Error handling and recovery guidance absent. Tool names follow verb_noun pattern but lack specificity, 'endpoint_info' and 'list_models_check' are vague about what 'checking' entails.

• Split shared input schema: endpoint_info should accept only {baseUrl, apiKey, timeoutMs, offline}; chat_completion_smoke_test should accept {baseUrl, apiKey, model, timeoutMs, offline}; embeddings_smoke_test should accept {baseUrl, apiKey, embeddingModel, timeoutMs, offline}. This makes each tool's contract explicit.
• Document output schemas for all tools. E.g., endpoint_info returns {endpoint: string, supportsChat: boolean, supportsEmbeddings: boolean, details: string}. This enables LLMs to chain tools correctly.
• Enhance descriptions with decision logic: 'Call endpoint_info first to validate the base URL format and discover available capabilities. Then call chat_completion_smoke_test to verify chat endpoint works, or embeddings_smoke_test for embeddings. Use compatibility_report to run all checks in one call.'
• Add error handling with recovery hints. E.g., if baseUrl is invalid, return {error: 'Invalid URL format', suggestion: 'baseUrl must be https://example.com/v1 (include /v1 suffix)'}. If connection fails, return {error: 'Connection refused', retry: true, suggestion: 'Check baseUrl is reachable and API key is valid'}.
• Rename tools for clarity: endpoint_info → validate_endpoint_format; list_models_check → check_models_endpoint; compatibility_report → run_full_compatibility_check. Names should start with action verbs (validate, check, run) and clarify the object.