Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Both tools have action-verb names (search, fetch_content) and non-empty descriptions (47 and 50 chars respectively), meeting minimum bars. However, parameter descriptions are minimal, output schemas are not formally documented, and error handling lacks recovery guidance. The server implements rate limiting and timeout handling internally, but does not expose these constraints to the LLM via parameter documentation. No tool annotations (readOnlyHint, idempotentHint) despite both being read-only operations.

• Document output schemas for both tools. For search: return array of {title, link, snippet, position} objects. For fetch_content: return {content, url, truncated} object. Include field types and descriptions.
• Expand parameter descriptions with format constraints. E.g., 'query (string, 1-500 chars): The search query. Supports boolean operators (AND, OR, NOT) and quoted phrases.' and 'url (string, valid HTTP/HTTPS URL): The webpage URL to fetch. Must be publicly accessible.'
• Add recovery guidance to error messages. E.g., 'Search timed out (30s). Try a simpler query or check your network connection.' and 'Failed to fetch URL: HTTP 403. Verify the URL is publicly accessible and not behind authentication.'
• Add readOnlyHint: true to both tool definitions to signal they are safe to retry and have no side effects.
• Document rate limiting in tool descriptions. E.g., 'search: 30 requests/minute; fetch_content: 20 requests/minute. Requests exceeding limits will be queued.' This sets LLM expectations for latency.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry