Skip to main content
Glama
djrobson5

agentmd-mcp

by djrobson5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Convert URL to markdown

convert_url_to_markdown
Read-only

Fetches a document from any http(s) URL and converts it to clean, LLM-ready markdown, preserving tables and stripping boilerplate. Returns a single markdown block with title, warnings, and absolute links.

Instructions

Fetches a document at an http(s) URL — web page, PDF, DOCX, HTML, Markdown, or plain text — and converts it to clean, LLM-ready markdown. Use this instead of convert_file_to_markdown when the document lives on the network rather than on the filesystem of the machine running this server, and instead of convert_document_to_markdown when you hold a link rather than the raw bytes; it is the only one of the three that fetches the source itself. Returns one markdown text block: the detected title as a leading # <title> line when one is found, a > Warnings: ... blockquote line when the converter reports warnings, tables preserved as GFM, and for web pages navigation and boilerplate stripped with relative links rewritten to absolute URLs. Limits: 25 MB per document, and PDFs are text-extraction only, so scanned or image-only PDFs yield little or no text (OCR is not available yet). Requires AGENTMD_API_KEY; on a 401, a network or fetch failure, or an unsupported format it returns an isError result whose text explains what went wrong. Each successful call consumes one conversion from the account quota. To read only part of a large document, use the optional pages (PDF page ranges), mode: 'outline' then section, and maxTokens parameters instead of pulling the whole thing into context.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page or document to fetch and convert, e.g. https://example.com/report.pdf. Must be publicly reachable from the AgentMD service; URLs behind a login, a paywall, or a private network will fail.
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 changedv0.1.4
    • 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 observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly and openWorld, but the description adds substantial behavior beyond that: 25 MB limit, PDF text-only extraction with OCR unavailable, API key requirement, error handling (isError on 401/failure), quota consumption, return format details (title, warnings, GFM tables, navigation stripping, relative links rewritten). This is rich, non-redundant context.

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?

Though long, every sentence carries unique information. It is front-loaded with purpose and sibling differentiation, then covers return format, limits, auth/errors, quota, and usage tips in a logical order. No filler or repetition.

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

Completeness5/5

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

For a 5-parameter tool with no output schema, the description covers everything an agent needs: what it returns (title, warnings, tables, link rewriting), failure modes, limits, and how to use the parameters to avoid pulling entire large documents. The only minor omission is a concrete example of a warning, but that's not essential.

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?

Schema coverage is 100% and each parameter already has a detailed description. The description goes further by explaining the intended workflow (outline first, then section) and the semantics of maxTokens ('narrow with pages or section rather than raising this'). That adds value beyond the schema, so a 4 is appropriate.

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?

States a specific verb (fetch and convert), a resource (URL) and the output (clean markdown). It names both sibling tools and the exact condition that selects this one ('when the document lives on the network', 'when you hold a link'), making differentiation immediate without inspecting schemas.

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

Usage Guidelines5/5

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

Explicitly gives when-to-use vs both alternatives and adds concrete usage guidance: start with mode:'outline', then fetch specific sections via pages/section/maxTokens. Also notes when not to use (local files or raw bytes). Nothing is left to inference.

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

Deploy Server

Other Tools