Skip to main content
Glama

Crawl a site

crawl_site

Paid plans: scan several pages of one site at once, from its sitemap's address or a list of its pages, each as a page scan of its own, compressing every image they load with the settings given; an image the pages share is compressed once. It answers straight away with the crawl queued; a crawl takes a few minutes, so call get_crawl until it is done. Each crawl counts one against the account's daily site crawls, and takes up to the plan's pages per crawl (get_usage, limits.pages_per_crawl); its pages do not count against the daily page scans, nor their images against the daily images. A list longer than the plan takes, or one mixing two sites, is refused. Another plan is refused with pro_required: scan the pages one at a time with scan_page instead. The site crawls reference: https://www.iminify.com/docs/site-crawls

Input Schema

NameRequiredDescriptionDefault
levelNoHow hard to compress. "smart" (the default) finds the lowest quality that still looks like the original; "ultra" goes further and softens fine texture a little; "lossless" changes no pixel unless a size_limit needs it to; "none" only converts, resizes, fits a size limit and strips metadata.
pagesNoThe pages to crawl, all on one site. https:// can be left out. Send this or sitemap, not both.
scaleNoResize to this percentage of the original, 1 to 100. Not together with width or height. Like width, it is refused for an animated WebP or PNG.
widthNoResize to this width in pixels. Alone, the height follows the aspect ratio; with height too, the image is resized to exactly that size. An animated WebP or PNG cannot be resized and is refused with animation_not_resizable; an animated GIF can.
formatNoConvert to this format. "auto" encodes every format that can hold the image and keeps the smallest. Leave it out to keep each image's own format (a HEIC or TIFF always comes back in another one).
heightNoResize to this height in pixels, the same way as width.
sitemapNoThe address of the site's sitemap (XML, a sitemap index, or a text file with one address a line). The crawl takes its first pages on the sitemap's own site. Send this or pages, not both.
alt_textNoWrite an AI alt text for each image the page shows with no alt attribute, for the audit's suggested_alt. On by default; false leaves it out. Each counts against the account's daily AI alt texts.
keep_metadataNoKeep the EXIF metadata (camera, date, location). Off by default, which strips it; the orientation is applied to the pixels first.
alt_text_languageNoThe language to write the alt text in, as a language tag. English ("en") by default. The suggested file name follows it for languages written in the Latin alphabet and is in English otherwise.

Output Schema

NameRequiredDescriptionDefault
idNoThe crawl's id.
urlNoThe sitemap read, or the first page listed.
hintNoWhat to do next: poll again while pages or images are at work, then where each page's images and report are.
noteNoWhy the crawl failed.
auditNoThe site's report, an image the pages share counted once. Null until the crawl is done.
pagesNoEach page, in the order the crawl took them.
sourceNo
statusNocompleted once every page and its images have finished. failed: the crawl could not start its pages; note says why.
settingsNo
created_atNo
monitor_idNoThe weekly site check this crawl is a run of, or null.
updated_atNo
pages_countNo
saved_bytesNo
images_countNo
pages_failedNo
original_sizeNoBytes, over the finished images.
saved_percentNo
optimized_sizeNoBytes, over the finished images.
pages_left_outNoPages past the plan's pages per crawl, not scanned.
images_finishedNo
pages_in_progressNo
images_in_progressNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the crawl is queued and takes minutes, consumes daily site-crawl quota, does not count pages against daily page scans, shares image compression across pages, and can be refused by plan limits. This is exactly the operational context an agent needs before invoking it.

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?

The key paid-plan and bulk-crawl context is front-loaded, and the dense paragraph earns most of its length through quota, polling, and refusal details. It could be split into shorter statements for easier scanning, but it is not padded with irrelevant material.

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?

For a complex asynchronous, quota-limited crawl tool, the description covers initiation, polling, billing, limits, refusal behavior, and the alternative sibling tool. With a rich schema and an output schema present, this is sufficiently complete for correct selection and invocation.

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%, so nearly all parameter meaning is already in the schema. The description reinforces the `pages` versus `sitemap` choice and the idea of per-page settings, but it does not add significant parameter-level detail 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 names a specific action and resource: scanning several pages of one site at once, each as its own page scan, with images compressed. It distinguishes this bulk crawl from the sibling `scan_page` and makes the paid-plan scope clear.

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?

It explicitly says when to use this tool, how to poll with `get_crawl`, how to check page limits with `get_usage`, and when to fall back to `scan_page` if the plan is refused with `pro_required`. It also states refusal cases such as lists longer than the plan or mixing two sites.

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.

Resources