Skip to main content
Glama

convert_pdf_to_card_html

Convert a local PDF into a portable, source-linked HTML reader with preserved text, page previews, and cropped tables/figures as images.

Instructions

Convert a local PDF into a portable, source-linked HTML reader.

The generated reader is static HTML with embedded assets. It keeps source text intact, includes source-page previews for verification, and crops detected tables, figures, and display formulas as images. Optional MCP sampling is limited to validated style-token choices or boundary-only card polish; raw CSS and source-text rewrites are rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ocrNoTry optional OCR fallback for image-only PDFs.
themeNoReader theme name. The default soft theme is calm and minimal.soft
titleNoOptional reader title override.
offlineNoUse only already-cached optional ML models.
pdf_pathYesAbsolute or relative path to the input PDF.
max_pagesNoOptional limit for very large PDFs.
standaloneNoKeep true to embed images, CSS, and JavaScript in one HTML file.
output_pathNoOptional path for the generated HTML file.
text_engineNo"char_geometry" or "pdfplumber_words". Defaults to geometry-based spacing.char_geometry
style_engineNo"fixed", "pdf", or "sampling". Fixed preserves the original soft reader palette. PDF derives a bounded style from local PDF visuals. Sampling asks the host LLM to choose validated style tokens from local PDF style hints.pdf
table_engineNo"auto", "pdfplumber", or "gmft". Auto uses gmft when installed.auto
model_cache_dirNoOptional cache directory for local ML table model weights.
postprocess_engineNo"none" or "sampling". Sampling asks the host LLM for boundary-only card polish operations, validates exact text preservation, and rewrites the reader.none

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations, the description discloses key behaviors: preserves source text, includes previews, crops tables/figures, and rejects raw CSS/rewrites. This is thorough but could mention output format details.

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?

Two concise paragraphs front-load the main purpose, then detail constraints. Every sentence adds value with no redundancy.

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?

Given the tool's complexity (13 params) and presence of an output schema, the description sufficiently covers behavior and output. Minor addition: could explicitly mention PDF path requirement.

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?

All 13 parameters have schema descriptions (100% coverage), so baseline is 3. The description does not add further parameter context beyond the schema.

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: 'Convert a local PDF into a portable, source-linked HTML reader.' This is specific and distinguishes it from sibling tools (publish/validate).

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 implies usage context (converting PDF to HTML) but lacks explicit when-to-use or alternative guidance. Siblings are different operations, so the gap is minor.

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

Install Server

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/velyan/pdf-card-mcp'

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