Skip to main content
Glama

Extract images

extract_assets
Read-onlyIdempotent

Use when the user wants the images from a page - photos, illustrations, backgrounds, favicon, social image - as resolved URLs tagged by source (img, srcset, picture, CSS background, favicon, og). A URL that is itself an image file comes back as the single result (source file). Not for: icons and vector logos (use extract_svgs) or fonts (use extract_fonts). Returns up to 100 by default; pass limit (up to 200) for more.

Input Schema

NameRequiredDescriptionDefault
urlYesThe website URL
freshNoSkip the 24-hour cache and re-extract the live page - use when the site just changed and a cached result would be stale. Charged normally; the fresh result replaces the cached copy.
limitNoMax images to return (default 100, up to 200).
renderNoForce a real browser so the page's JavaScript runs before it is read. Slower, and adds 5 credits. Usually not needed: when the plain read comes back as a JavaScript app shell or the site refuses it (401/403/406) or timed out, the server already re-runs the page in a browser by itself at no extra cost, and usage.autoRender says so. Pass it for images, videos or Lottie that only load on scroll, with screenshot=true, or when a result is still thin after that automatic pass. If a 403 says the browser was refused too, the site cannot be extracted - do not retry. extract_code always runs in a real browser at no extra cost, so render=true is not needed there (only together with screenshot=true). On extract_design_tokens, render=true only permits the browser: the plain read still runs first, and the 5 credits are charged only if the browser was actually needed.
screenshotNoRequires render=true. Adds a screenshot field to the result: a public URL of a capture of the page (live 7 days), taken by the same browser that rendered it. Pass true for the 1440x900 viewport or 'full' for the entire page height. No extra credits beyond the render surcharge. Useful for showing the user what the extracted site looks like.
full_outputNoSkip long-string trimming. Responses still cap at ~100KB total.
response_formatNoHow much to return. 'concise' keeps lists to 10 entries and strings short - right for a summary or a chat answer. 'detailed' returns everything the tool has (same as limit=200 + full_output=true). Omit for the default, which fits a typical chat context. The generated code is never trimmed in any mode.

Output Schema

NameRequiredDescriptionDefault
urlYes
countNoTotal images found (before any trimming)
usageNoCredit usage for the authed key (spent, remaining, monthly limit).
imagesNo
truncation_noteNoPresent when the result was trimmed to fit chat context - says what was dropped and how to get more (limit / full_output arguments, or the REST API).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is the extraction behavior: a URL that is itself an image returns a single 'source file' result, and results are capped at 100 by default with a 200 ceiling. It does not restate the widely documented caching and render/screenshot trade-offs that live in the schema, which is fine but leaves it short of fully rich behavioral context.

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?

Four sentences, each earning its place: trigger, scope of results, special case, exclusions, and the one parameter nuance worth surfacing. The trigger and the sibling routing are front-loaded where an agent will read them first.

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 an output schema present, the description need not explain return shape, and it correctly focuses on routing and scope. For a read-only extraction tool with a complete schema and annotations, nothing an agent needs to select or invoke it is missing.

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 the schema already documents every parameter in depth (fresh/cache, render, screenshot, full_output, response_format). The description only echoes the limit defaults ('up to 100 by default; pass limit (up to 200)'), which is a restatement rather than added meaning. Baseline 3 is appropriate.

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?

States a specific verb and resource ('the images from a page'), enumerates the asset kinds covered (photos, illustrations, backgrounds, favicon, social image) and the tagging scheme, and explicitly names the siblings it is not for. An agent can distinguish it from extract_svgs and extract_fonts without opening a schema.

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?

Opens with the triggering condition ('Use when the user wants the images from a page') and gives explicit exclusions with named alternatives ('Not for: icons and vector logos (use extract_svgs) or fonts (use extract_fonts)'). It also resolves the ambiguous case where the input URL is itself an image.

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.