Fetch a URL (web page, PDF, Office doc, and more) and convert it to Markdown.
Works on publicly accessible URLs. Web pages are converted from their
served HTML; JavaScript-rendered content may be incomplete. Optional
filename_hint (e.g. "report.pdf") helps format detection when the URL
has no file extension.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| filename_hint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the conversion behavior, the limitation on public URLs, and the JS-rendering caveat, plus how filename_hint influences format detection. It does not cover failure modes or output format details, but for a read-oriented conversion tool this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and each sentence adds meaningful information without redundancy. It covers scope, constraints, a behavioral caveat, and parameter guidance in a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters and no output schema, the description covers the essential selection criteria and usage constraints. It does not specify the exact return format beyond 'Markdown' or discuss error handling, but the sibling list_supported_formats likely covers format details, so the description is adequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It explains the purpose of filename_hint with a concrete example and clarifies the URL must be publicly accessible. The url parameter is less explicitly detailed, but the context makes its semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('URL') and states the conversion output ('Markdown'). It also lists supported input types (web page, PDF, Office doc) and distinguishes itself from siblings like convert_base64 by focusing on fetching URLs rather than converting base64 content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: requires publicly accessible URLs and warns that JavaScript-rendered content may be incomplete. However, it does not explicitly name alternatives or state 'use this instead of convert_base64', though the URL-focused scope makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct role: the two conversion paths (base64 vs URL) are clearly differentiated by input source and usage guidance, and the two informational tools (format support, usage quota) do not overlap.
convert_base64, convert_url, and list_supported_formats follow a consistent verb_noun pattern. usage_status is a minor resource-style exception but remains readable and does not create real confusion.
Four tools are well-scoped for this service: two conversion entry points plus two supporting tools for format discovery and usage awareness. No redundant or filler tools are present.
The surface covers the full workflow for a stateless conversion service: ingest via base64 or URL, discover supported formats and limits, and check quota before conversion. There are no obvious dead ends or missing core operations.