Convert a URL or raw HTML to Markdown. One of url or html. Not for JS SPAs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL (alt. to html). | |
| html | No | Raw HTML (alt. to url). | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| maxChars | No | Default 12000, max 50000. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / html / descriptionPrevious value: -"Alt. to url."New value: +"Raw HTML (alt. to url)."Input schema / properties / maxChars / descriptionAdded value: +"Default 12000, max 50000."Input schema / properties / url / descriptionAdded value: +"Page URL (alt. to html)."Input schema / properties / headersAdded value: +{
+ "type": "object"
+}Input schema / properties / html / descriptionPrevious value: -"Raw HTML string to convert directly (alternative to url)."New value: +"Alt. to url."Input schema / properties / maxChars / descriptionRemoved value: -"Max characters of Markdown to return (default 12000, max 50000)."Input schema / properties / url / descriptionRemoved value: -"URL to fetch and convert (http:// or https://)."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, so the description needs only to add context beyond that. It adds the key limitation that JS SPAs are not supported, which is not present in the structured data. This contributes meaningful behavioral transparency without contradicting annotations.
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 three short sentences with no filler. The main purpose is front-loaded, and every sentence adds value: the conversion intent, the input constraint, and a key limitation. This is exemplary conciseness.
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 the tool's simple nature, complete parameter schema, and read-only annotation, the description covers the core purpose, input alternatives, and a critical limitation. It lacks explicit return-value details or edge-case behavior, but these are less critical when the schema and annotation are present. Overall, it is sufficiently complete for a tool of this complexity.
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 schema descriptions cover 100% of parameters, so the baseline is 3. The description reinforces the exclusivity of url/html ('One of url or html') but does not add new semantic meaning beyond what the schema already states in the 'alt. to' phrasing. No additional parameter-level detail is provided.
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 ('Convert') and resource ('URL or raw HTML') with a clear target output ('to Markdown'), distinguishing it from sibling tools like fetch_html or fetch_extract. It also clarifies the input constraint ('One of url or html'), making the tool's purpose unambiguous.
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?
The description provides an explicit when-not ('Not for JS SPAs') and instructs users on parameter exclusivity ('One of url or html'). It does not name specific alternative tools for JS SPAs or other use cases, so it stops short of full guidance, but the exclusion is valuable.
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.
Several tools overlap in fetching and processing web content (fetch_extract, fetch_html, fetch_metadata, html_to_markdown), which could confuse an agent. However, descriptions clarify output types, so most tools are distinguishable.
Names follow mixed conventions: verb_noun (fetch_html, remove_background), noun_verb (csv_query, rss_parse), and noun_noun (tool_catalog, screenshot_url). Each name is descriptive, but the lack of a consistent pattern makes it harder to guess tool names.
With 17 tools, the count is slightly above the ideal 3-15 range but still manageable. The inclusion of 5 meta-tools (pricing, tool_catalog, task_recipes, memory_snippet, use_tool) inflates the count but serves a discovery purpose.
The toolkit covers a broad range of web and data tasks (fetch, parse, query, convert, image, SEO). Minor gaps exist (e.g., no OCR, no image editing), but use_tool can dynamically access additional tools, mitigating incompleteness.