Skip to main content
Glama

AgentMD

by io.github.djrobson5
OverviewDiscussionsAdmin

Convert URL to markdown

convert_url_to_markdown

Fetch a URL (web page, PDF, DOCX, etc.) and convert it to clean, LLM-ready markdown. Extracts the main article content from web pages and preserves tables. Supports reading only part of a large document: PDF page ranges, a heading outline, a single section, or a token cap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe http(s) URL of the document or page to convert
modeNo"full" (default) returns the document body. "outline" returns just the heading tree — each line is `- [#3] Heading text (~120 tokens)`. For a long document, call with mode: 'outline' first, then fetch only what you need with section: '#3' or a heading title.
pagesNoPDFs only: 1-indexed, inclusive page ranges to convert, e.g. "1-3,5,8-" (an open-ended range runs to the last page). Ignored with a warning for non-PDF formats.
sectionNoReturn only one section: either "#<n>" using the index from a mode: 'outline' call (e.g. '#3'), or the heading text itself (case-insensitive; exact match wins, then prefix, then substring). Ignored when mode is 'outline'.
maxTokensNoCap the returned markdown at roughly this many tokens, cutting at a paragraph boundary. When the output is cut, the result starts with a `> Truncated: ~X of ~Y tokens` line — narrow with pages or section rather than raising this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / maxTokens
      Added value: +{
+  "description": "Cap the returned markdown at roughly this many tokens, cutting at a paragraph boundary. When the output is cut, the result starts with a `> Truncated: ~X of ~Y tokens` line — narrow with pages or section rather than raising this.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "\"full\" (default) returns the document body. \"outline\" returns just the heading tree — each line is `- [#3] Heading text (~120 tokens)`. For a long document, call with mode: 'outline' first, then fetch only what you need with section: '#3' or a heading title.",
+  "enum": [
+    "full",
+    "outline"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / pages
      Added value: +{
+  "description": "PDFs only: 1-indexed, inclusive page ranges to convert, e.g. \"1-3,5,8-\" (an open-ended range runs to the last page). Ignored with a warning for non-PDF formats.",
+  "type": "string"
+}
    • addedInput schema / properties / section
      Added value: +{
+  "description": "Return only one section: either \"#<n>\" using the index from a mode: 'outline' call (e.g. '#3'), or the heading text itself (case-insensitive; exact match wins, then prefix, then substring). Ignored when mode is 'outline'.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that web pages are stripped to main content, tables are preserved, page ranges are ignored for non-PDFs, section is ignored in outline mode, and truncation adds a marker line. These are specific behavioral traits beyond the schema, though error handling or invalid-URL behavior is not covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each adding distinct value: core function, extraction behavior, and partial-reading options. It is front-loaded and contains no filler words or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters and no output schema, the description explains the main behaviors and partial-reading workflow comprehensively. It does not cover error handling or edge cases like unreachable URLs, but the essential usage and behavior are clear enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% parameter descriptions, including mode enum, page range format, section matching rules, and maxTokens truncation behavior. The tool description adds a valuable workflow suggestion (outline-first pattern) that supplements the parameter semantics and guides effective usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (fetch a URL and convert to markdown) and resource (URL) with a specific output format. It distinguishes from the sibling by emphasizing URL-based fetching, and adds detail about content extraction and table preservation, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides concrete guidance on handling large documents (call with mode 'outline' first, then use section) and advises narrowing with pages or section instead of raising maxTokens. It does not explicitly mention the sibling tool as an alternative, but the URL focus strongly implies the tool's domain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AgentMD toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources