Single tool 'ask_model' has a clear verb-noun name and reasonable description (127 chars, within 10-1024 range). Input schema is well-defined with Zod validation covering all parameters: prompt (required, min 1 char), system (optional string), model (optional string with min 1 char), maxTokens (optional number, 1-65536, default 1024). However, output schema is not documented, the tool returns a JSON-stringified object with model, stop_reason, usage, and text fields, but this structure is not declared in the tool definition. Parameter descriptions are present but minimal (e.g., 'Optional model identifier' lacks guidance on format or valid values). No error handling guidance for LLMs (timeouts, API failures, malformed responses). Tool is read-only and idempotent, but these properties are not annotated.

• Document the output schema explicitly: declare that the tool returns {model: string, stop_reason: string|null, usage: {input_tokens, output_tokens}|null, text: string}. This enables LLMs to extract fields and chain calls.
• Enhance parameter descriptions with constraints and examples: 'model: Optional model identifier (e.g., claude-opus-4, claude-sonnet-4-5). Defaults to CLAUDE_MCP_MODEL env var or claude-sonnet-4-5. Must be a valid Claude model name.'
• Add error recovery guidance in the tool description: 'If the upstream service is unavailable, the tool will return a timeout or connection error. Retry with exponential backoff or suggest an alternative model.'
• Annotate the tool with readOnlyHint: true and idempotentHint: true to signal safety properties to MCP clients.
• Document the timeout behavior and default (60000ms) in the description, and explain when to increase it for long-running model calls.