Skip to main content
Glama

pdf_export_catalog

Compile all pages or the active page into a print-ready multi-page PDF at selectable resolution, then trigger a client-side download.

Instructions

Compiles all pages (or active page) into a print-ready, high-resolution multi-page PDF document and triggers client-side download.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scaleNoRendering scale multiplier (1 = Standard 72 DPI, 2 = Retina 150 DPI, 3 = Print 300 DPI, 4 = Maximum)
allPagesNoWhether to compile all pages into 1 multi-page PDF (true) or active page only (false)
filenameNoPDF file name without .pdf extension (e.g. "furniture-catalog-2026")tuval-catalog

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses a side effect beyond the schema by stating it 'triggers client-side download' and describes output quality ('print-ready, high-resolution'). However it omits where the file lands, whether an overwrite/conflict can occur, and any permission or rate considerations.

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?

A single tightly constructed sentence that front-loads the core action and outcome with no wasted words. Everything stated earns its place.

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 and no annotations, the description still covers the core action, variable scope, quality, and the download side effect, and all three parameters are self-documented. It is slightly thin on the destination/overwrite behavior of the triggered download, but otherwise complete for a low-complexity export tool.

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?

Schema description coverage is 100%, with scale, allPages, and filename each fully documented (including DPI meanings for the scale enum). The description adds no parameter detail beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Compiles') and resource ('all pages') with a clear outcome: a print-ready, high-resolution multi-page PDF plus a download trigger. It is not, however, differentiated from sibling export tools like studio_export_file or project_export_download, so an agent cannot tell from the text alone which exporter to pick.

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

Usage Guidelines3/5

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

The parenthetical '(or active page)' implies a usage mode tied to the allPages flag, and 'print-ready' implies a use case. But there is no explicit when-to-use, when-not-to-use, or naming of the alternative export siblings, so the guidance is only implied.

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