Skip to main content
Glama

Import images and PDF pages

import_media

Bring a PDF or an image into the project as media: comic pages, hand-drawn storyboards, style or reference pictures. A PDF becomes one image per page (at most 50 pages per call; pass pages for the others). An image file is page 1.

findPanels: true finds the panels of each page (comic panels, storyboard frames) and cuts each one as its own image, labelled "Page N, panel K" with a one-line caption of what it shows. Use it for comic pages and storyboard boards: it is more precise than boxes you place yourself, and you need not see the pages first. It costs about 1 credit per page; when more than 20 pages need it, the call returns confirmation_required with the estimate: ask the user, then call again with confirm: true. Pages already searched cost nothing again. With mediaId, it finds the panels of that stored image.

crops cuts boxes out of pages: each box becomes its own image, stored next to the page and linked to it. Boxes are fractions of the page (x, y from the top-left corner, width, height, all from 0 to 1), so a box over the top half of a page is { x: 0, y: 0, width: 1, height: 0.5 }. You decide the boxes (comic panels, storyboard frames, webtoon strips); the tool only cuts the pixels. At most 300 crops per call. To cut boxes from a page imported earlier, pass its mediaId and crops. When you cannot see the pages (a PDF is often not shown to you as images), import without crops first, look at the pages with view_media and their media ids, then cut them with mediaId and crops.

Pass one source: uploadId (from create_upload: the way to send a file you hold), url (a public https URL), base64 with mimeType (files up to 1024 KB only) or mediaId (crops of stored media). Up to 25 MB per file.

Returns the media id, size and page of every page and crop (with panelsFound per page, and panelsFailed for a page the model could not read: cut that one with crops), and the panel spend. Importing the same file again returns the same media ids and stores nothing twice. Without findPanels the import is free.

Over MCP, a long import (a large PDF, many pages with findPanels) may answer with status "running" and a jobId before it is done: it goes on after the answer. Call get_import_job with the jobId for the result; do not import the file again meanwhile.

Input Schema

NameRequiredDescriptionDefault
urlNoPublic https URL of the file.
cropsNoBoxes to cut out, each stored as its own image.
pagesNoPDF pages to import (1-based). Default: all pages, up to 50. Pages that crops name are imported too.
base64NoThe file as base64, for files up to 1024 KB. Use create_upload for larger files.
confirmNoTrue once the user agreed to the findPanels estimate (needed above 20 pages).
mediaIdNoMedia id of a stored image (a page imported earlier) to cut crops from.
fileNameNoName of the file, shown with its media (base64 or url).
mimeTypeNoType of the base64 file.
uploadIdNouploadId from create_upload, once the file was PUT to its uploadUrl.
projectIdYesScreenWeaver project id (from list_projects).
findPanelsNoTrue to find the panels of each page and cut each one (costs credits).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Far beyond the annotations: it discloses the credit cost (~1 credit/page), the 20-page confirmation gate producing confirmation_required and the required confirm:true retry, that already-searched pages are free, that imports without findPanels are free, caps (50 pages, 300 crops, 25 MB, 1024 KB base64), dedup on re-import, panelsFailed handling, and the async status "running" + jobId path with get_import_job. This is the kind of cost/authorization/side-effect disclosure that lets an agent call safely and avoid duplicate spend.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then organized by feature (findPanels, crops, sources, returns, async) with no filler sentences. It is long and a few details restate the schema (fraction ranges, max 300 crops), which costs it the top mark, but the density is justified for an 11-parameter tool with cost and async behavior.

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?

With no output schema, the description supplies the return contract (media id, size, page of every page and crop, panelsFound per page, panelsFailed, panel spend) and the async completion path via get_import_job. Combined with cost limits and the view_media fallback, an agent has everything needed to call this correctly on the first attempt.

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?

Schema coverage is already 100%, yet the description still adds real meaning: it explains why boxes are fractional with a worked example (top half = {x:0,y:0,width:1,height:0.5}), states that crops boxes are caller-decided and the tool only cuts pixels, clarifies mediaId means "crops of stored media" as a source, and explains that confirm exists to carry a user's approval of the estimate. That is meaning the schema does not convey.

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 opening sentence gives a specific verb and resource ("Bring a PDF or an image into the project as media") and enumerates the intended content types (comic pages, storyboards, reference pictures). It is clearly distinguishable from siblings like create_upload (sends a file, doesn't import it), add_reference_images and import_script.

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?

Explicit routing rules: use findPanels for comic/storyboard pages because it beats hand-placed boxes, use crops when you already know the boxes, and a stated fallback workflow (import without crops, view with view_media, then cut with mediaId + crops) for when pages aren't visible. It also states the mutually exclusive source options (uploadId / url / base64+mimeType / mediaId), which removes the most likely invocation error.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.