Single tool 'ask_oracle' has a complete input schema with proper types, descriptions, and constraints (temperature 0-2, max_tokens 100-8000). Tool description is adequate (127 chars, within 10-1024 range) but generic, lacks WHEN to use it or recovery guidance. All 4 parameters have descriptions and type definitions. However, no output schema is documented, and error handling returns plain text without actionable recovery steps. Missing tool annotations (readOnlyHint, idempotentHint). Naming is clear but lacks verb_noun pattern (ask_oracle vs query_oracle or consult_oracle).

• Document output schema: specify that response is a text field containing the oracle's answer, with optional metadata (tokens_used, model_version).
• Enhance error handling: categorize errors as retryable (timeout, rate limit) vs user-fixable (invalid query format) vs fatal (auth failure). Return actionable messages: 'Rate limited. Retry in 60s.' or 'Query too long (5000 chars). Reduce context and try again.'
• Expand tool description to 100-150 chars: 'Query DeepSeek V3.2 for expert coding advice, debugging, and complex problem-solving. Use when you need deep technical analysis beyond your knowledge. Returns detailed explanations and code solutions.'
• Add tool annotations: mark as readOnlyHint=true (no side effects) and idempotentHint=true (safe to retry). This signals to LLMs that repeated calls are safe.
• Use a secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault) instead of .env file scanning. At minimum, document that OPENROUTER_API_KEY must be set in the environment before server startup, not discovered at runtime.