Server has 12 well-named tools with consistent verb_noun patterns (wellcome_search, met_get_object, etc.). All tools have descriptions (avg ~100 chars, within baseline 34-392). Input schemas are present with types and descriptions for all parameters. However, output schemas are NOT documented, LLMs cannot predict response structure. Parameter descriptions lack constraint details (e.g., pageSize ranges, enum values for 'kind'). Error handling is minimal; no recovery guidance. The download_image tool accepts arbitrary URLs without validation, creating security risk. Missing idempotency hints and permission declarations.

• Document output schemas for all tools. Example: wellcome_search returns {source: string, totalResults: number, showing: number, results: [{id, title, workType, date, description}]}. This enables LLMs to chain tools and extract correct fields.
• Add enum constraints to parameters: 'kind' in wellcome_search → enum ['works', 'images']; 'category' in loc_search → enum ['photos', 'maps', 'newspapers', 'manuscripts', 'film-and-videos']. Add min/max to pageSize (1 - 100) and numeric IDs.
• Implement path traversal protection in download_image: validate outputDir is within a safe base directory, reject '..' sequences, and whitelist file extensions (.jpg, .png, .gif, .pdf, .tiff). Sanitize filename to prevent injection.
• Add error recovery guidance. Replace 'HTTP 404 for https://...' with 'Item not found. Verify the ID is correct, or try search_wellcome() to find the work by title.' Categorize errors as retryable (network timeout) vs user-fixable (invalid ID).
• Add tool annotations via MCP SDK: mark all search/get tools with readOnlyHint=true and idempotentHint=true; mark download_image with destructiveHint=true (writes to filesystem). This helps LLMs reason about side effects and retry safety.