Single tool 'analyze_pdf' has a detailed description (340+ chars) explaining functionality, caching strategy, and usage tips. However, the input schema lacks proper type definitions and parameter descriptions in the code. The schema shows 'pdf_source' as 'string|array' without enum constraints or format validation, and 'queries' array items lack item-level type info. No output schema is documented. Error handling is mentioned in instructions but not reflected in tool definition. The tool performs a read-only operation (good), but lacks the structured, LLM-optimized parameter guidance needed for production use.

• Add explicit type and description to each parameter in the schema. Example: 'pdf_source': { type: 'string|array', description: 'Absolute file path (/path/to/file.pdf), HTTPS URL (https://...), or Gemini file URI(s) from previous response. Arrays only valid for Google provider.' }
• Document the output schema with all returned fields: { cached_uris: string[], responses: { query: string, answer: string }[], error?: string }. Include field types and when each appears.
• Add enum constraint for provider selection if exposed, or document in description that provider is auto-detected from environment. Prevent LLM from passing invalid provider names.
• Implement structured error responses with classification: { error: string, type: 'retryable'|'user_fixable'|'fatal', suggestion: string }. Example: 'PDF not found. Verify absolute path exists. Type: user_fixable.'
• Add idempotentHint annotation to tool definition since re-analyzing the same PDF with same queries should return consistent results. This signals to LLMs that retries are safe.