The server provides 2 tools with basic but incomplete definitions. Both tools have action-verb naming and descriptions, but parameter documentation is sparse and output schemas are not documented. Input schemas are visible and properly typed, but descriptions lack the depth needed to guide LLM decision-making effectively. No error handling guidance is documented. The tool descriptions are brief (39-79 chars) but meet minimum viability. Parameter descriptions are absent, only the parameter name and type are provided.

• Add detailed parameter descriptions for 'url': 'The URL of the resource to fetch. Must be a valid HTTP(S) URL. Maximum 2000 characters. Request times out after 30 seconds. Supports status codes 200-299; 3xx/4xx/5xx will return an error.'
• Expand tool descriptions to 80-150 chars, explaining when each tool is appropriate: 'Fetch an HTML webpage and extract all visible text, headings, links, and tables, converting to Markdown format. Handles JavaScript-rendered content. Returns plain Markdown text. Use this when you need readable content from a live URL. For PDFs, use pdf_to_markdown instead.'
• Document the output schema in docstrings or parameter annotations. E.g., 'Returns: A string containing the Markdown-formatted content extracted from the resource. If extraction fails partially, returns available content with a note about what was skipped.'
• Add error handling documentation in each tool's docstring listing common failure modes and recovery steps: 'Raises: HTTPError if the URL is unreachable (404, 500, etc). TimeoutError if fetch exceeds 30s. ValueError if the URL is invalid or not HTTP(S).'
• Add parameter constraints: url format (regex or length), supported schemes (http/https only), and size limits (e.g. max 100MB for PDF). Enforce at runtime and return validation errors like 'Invalid URL: must start with http:// or https://. Got: ftp://example.com'.