Skip to main content
Glama
redup-ai

redup.mcp-web-parser

Official
by redup-ai

fetch_binary

Read-onlyIdempotent

Download a binary file from a URL and return its metadata and base64 content. Use when the target is a non-HTML file such as PDF, image, or archive.

Instructions

Download a binary file and return metadata + base64 bytes as JSON.

WHEN TO USE: the URL itself is a file download — pdf, docx/xlsx/pptx, odt/epub, zip/tar/gz/7z/rar, png/jpeg/gif/webp, or similar. Also use when parse_page returned is_binary=true / hint to call fetch_binary. WHEN NOT TO USE: normal HTML pages (example.com, wiki, /abs, blogs) — use parse_page. Never switch to this tool only because parse_page failed on an HTML URL (anti-bot, timeout, empty markdown).

Download only: no text extraction, no OCR, no unzip. Bytes live only in JSON content_base64 (last; may be large) — this server does not write a shared filesystem path. Downstream tools that need the bytes must use their own input contract. Prefer metadata fields kind, size, filename.

Returns JSON: success, url, status_code, media_type, kind, size, filename, truncated, error_message, used_proxy, content_base64.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYeshttp(s) URL of a binary file to download (pdf, docx, zip, png, … — not an HTML page).
timeoutNoRequest timeout in seconds (server may clamp).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A5/5.0
Behavior5/5

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

The description discloses key behavioral aspects: it performs a download only (no text extraction, OCR, or unzip), places bytes in JSON 'content_base64' rather than writing to a filesystem, and notes potential large size. It complements the annotations (readOnly, idempotent, non-destructive) with concrete details, exceeding the minimum required transparency.

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 well-organized with distinct sections (description, when to use, when not to use, download only, returns) and every sentence adds value. It avoids redundancy while covering necessary details, maintaining a concise yet complete structure.

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?

Beyond the annotations and schema, the description includes the list of return fields, explains the tool's role relative to parse_page, and specifies that it does not interact with a filesystem. This fully contextualizes the tool within its environment, making it self-sufficient for correct usage.

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

Parameters5/5

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

The schema provides clear descriptions for both parameters: 'url' is specified as an http(s) URL for a binary file (non-HTML), and 'timeout' is described with units and the clamping behavior. The tool description reinforces the URL semantics, ensuring full coverage of parameter meaning.

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 tool's purpose: downloading a binary file and returning metadata and base64 bytes as JSON. It uses specific verbs ('Download', 'return') and specifies the resource type and output format, effectively distinguishing it from the sibling tool parse_page.

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?

The 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide explicit conditions, including types of content (pdfs, zips, images) and when to prefer parse_page. It also advises against using this tool as a fallback for parse_page failures, covering both use and non-use scenarios.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/redup-ai/redup.mcp-web-parser'

If you have feedback or need assistance with the MCP directory API, please join our Discord server