Skip to main content
Glama

api2pdf

by io.usefulapi

Markdown to PDF (Chrome)

api2pdf_markdown_to_pdf
Destructive

Render a Markdown string to a PDF using headless Chrome. Returns a { FileUrl } (valid ~24h). BILLED. Api2Pdf API: POST /chrome/pdf/markdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inlineNoIf true (Api2Pdf default), the generated file is served inline; if false, as an attachment.
optionsNoEngine-specific render options (page size, margins, orientation, headers/footers, etc.). Passed through verbatim to Api2Pdf.
storageNoCustom storage target, used when useCustomStorage is true.
fileNameNoA name for the generated file, e.g. 'invoice.pdf'.
markdownYesThe Markdown source to render into a PDF.
output_binaryNoIf true, return the raw file bytes as base64 instead of a FileUrl. Default false (recommended for agents — returns a short-lived link).
extraHTTPHeadersNoExtra HTTP headers Api2Pdf forwards when it fetches a source URL (e.g. auth for a protected page/file).
useCustomStorageNoIf true, Api2Pdf uploads the result to your own storage (see `storage`) instead of hosting it.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The description goes beyond the annotations by disclosing that the call is BILLED, returns a FileUrl, and that the URL is valid for approximately 24 hours. It also reveals the underlying API endpoint (POST /chrome/pdf/markdown), which adds useful operational context. The destructiveHint annotation is not contradicted, since the description transparently flags the cost-sensitive nature of the operation.

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 short sentences with no filler: purpose, return value and lifetime, and billing/API context. Each sentence earns its place, and the most important information is front-loaded.

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?

With no output schema, the description usefully explains the return value and its 24-hour validity, which is essential for an agent deciding whether to download immediately. Combined with the 100% parameter coverage and explicit billing warning, the tool is adequately specified for correct selection and invocation, though a note about authentication requirements would make it fully complete.

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

Parameters3/5

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

The description itself does not document any parameters, but schema description coverage is 100%, so every parameter already has a meaningful explanation in the input schema. The baseline of 3 applies because the schema carries the full burden and the description adds no additional parameter-level nuance.

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 states a specific verb and resource: 'Render a Markdown string to a PDF using headless Chrome.' This clearly distinguishes it from sibling tools like api2pdf_html_to_pdf, api2pdf_url_to_pdf, and api2pdf_office_to_pdf by source format and engine.

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?

The description clearly defines the input type ('Markdown string') and rendering engine, providing enough context for an agent to select this tool when the source is Markdown. It does not explicitly name alternatives or exclusion conditions, but the resource constraint is unmistakable and sufficient for routing.

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

All api2pdf toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct operation: conversions, PDF manipulations, file deletion, and account/service info are clearly separated. Even the three HTML-to-PDF tools are distinguished by source type or rendering engine.

Naming Consistency5/5

All tools follow a consistent api2pdf_ prefix with snake_case verb-based names such as add_password, merge_pdfs, and url_to_pdf. The pattern is predictable and makes it easy to infer what each tool does.

Tool Count4/5

Sixteen tools is slightly above the typical 3-15 range, but the count is justified by the breadth of Api2Pdf's functionality spanning creation, manipulation, conversion, deletion, and account management.

Completeness5/5

The surface covers the full PDF lifecycle: generate from multiple sources, manipulate via merge/extract/compress/password, convert to markdown, delete files, plus billing and status checks. No obvious missing operations for the documented purpose.

Resources