Two tools with clear verb-noun naming (read_url, search) and reasonable descriptions (145 - 180 chars, within baseline 34 - 392). Input schemas present with typed properties. However, critical gaps: no output schema documentation, missing parameter descriptions for _apiKey (generic boilerplate), no error handling guidance, no pagination support for search results, and no input validation rules stated in descriptions. The _apiKey parameter violates secret-injection pattern by exposing credentials as a tool parameter rather than server-side injection. Truncation logic (100k/50k chars) is undocumented and could surprise agents.

• Move API key to server-side environment variable (JINA_API_KEY). Remove _apiKey parameter. Document in tool description that the server is configured with optional auth.
• Document output schema explicitly: read_url returns {url, markdown, truncated}; search returns {query, results_markdown, truncated}. Include field types and when truncated=true occurs.
• Add pagination to search: accept optional limit (1 - 100, default 20) and offset parameters. Return total_results count so agents know if more results exist.
• Document truncation limits in tool descriptions: 'Results are capped at 100,000 characters for read_url and 50,000 for search to prevent context overflow. If truncated=true, refine your query or use pagination.'
• Enhance error responses with actionable guidance: instead of {error: 404, message: '...'}, return {error: 'url_not_found', message: 'The URL returned HTTP 404. Verify the domain and path are correct.', suggestion: 'Try a different URL or use the search tool to find the page.'}