url_to_pdfFetch a public http/https URL and render the live page to a PDF. Returns a file_id (chainable into the PDF tools) and a ~1h download URL. Private/internal hosts are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The http/https URL to snapshot. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description carries full transparency: it discloses the private/internal host blocking constraint, the ~1h download URL expiration, the file_id return contract, and that it captures a live render. These are precisely the behaviors an agent needs to anticipate (auth restrictions, output lifetime, composability).
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?
Three sentences, each carrying distinct value: core purpose, output contract, and constraint. The main action is front-loaded, the parenthetical 'chainable into the PDF tools' adds composability context without bloat, and there is zero redundancy.
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 a single simple string parameter and no output schema, the description covers the essential contract thoroughly: input constraints, output format, and URL expiration. It omits edge-case behaviors like timeout or redirect handling, but for this complexity level the description is near-complete.
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 description adds meaningful detail beyond the 100%-covered schema: it introduces the 'public' constraint not present in the schema's 'The http/https URL to snapshot' and specifies the return contract (file_id + download URL). The schema already covers http/https and the snapshot intent, so the added value is solid but not maximal.
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 specific verbs ('Fetch', 'render') and a clear resource ('public http/https URL' → 'PDF'), which distinguishes it from siblings like read_url (returns page content), url_to_screenshot (image output), and render_html_to_pdf (raw HTML input). The phrase 'live page' further differentiates it from file-based PDF tools.
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?
Implicit guidance is clear: 'public http/https URL' tells the agent this is for live web pages, not raw HTML or markdown (vs render_html_to_pdf, markdown_to_pdf) and not local files (vs merge_pdfs, split_pdf). Siblings are not explicitly named, but the constraints strongly imply when to choose this tool.
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.
Most tools have clearly distinct purposes, such as extracting PDF text versus filling forms or rendering URLs to PDF versus screenshots. The only mild overlap is read_url and scrape_page, both fetching a URL, but their outputs are explicitly differentiated as clean Markdown versus raw HTML with metadata.
Names mostly follow a verb_noun pattern like extract_pdf_text, fill_pdf_form, and rotate_pdf. A few conversion tools use 'to' constructions (images_to_pdf, markdown_to_pdf, url_to_pdf) and some pluralize objects (merge_pdfs, select_pages), creating minor inconsistency but no real confusion.
With 15 tools, the set is at the upper edge of the ideal range and every tool serves a distinct, useful function within the PDF and URL processing domain. The count feels justified rather than excessive.
The PDF tooling covers creation from images and Markdown, text extraction, form filling and reading, merging, splitting, rotating, selecting pages, and watermarking. URL handling covers reading as Markdown, scraping raw HTML/metadata, generating PDFs, and taking screenshots, providing well-rounded coverage for the stated domain.