Skip to main content
Glama

Get thumbnails batch

get_thumbnails_batch
Read-only

Fetch base64-encoded thumbnails for a list of asset IDs to display search results or ad-hoc photo sets without an album. Choose thumbnail or preview size and cap returned items.

Instructions

Get base64-encoded thumbnails for arbitrary asset IDs without needing an album. Use this to visually display search results or any ad-hoc set of photos. For album-based thumbnails, use get_album_thumbnails. For a single photo, use get_asset_thumbnail. Read-only.

Args:
    asset_ids: List of asset UUIDs to fetch thumbnails for.
    size: 'thumbnail' (250px) or 'preview' (1440px). Default: 'thumbnail'.
    limit: Max thumbnails to return (1-50, default 20). Only the first N IDs are fetched.

Returns: JSON with thumbnails array (each with asset_id, base64 data, filename, date).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "asset_ids": "<asset_ids>"
    },
    "name": "get_thumbnails_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNothumbnail
limitNo
asset_idsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety needs no restating (the 'Read-only' line is mild redundancy). Beyond that, the description discloses the base64 payload format and the truncation semantics for limit ('Only the first N IDs are fetched'), which is genuine behavioral context an agent cannot infer from the schema.

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 lead sentence carries the core distinction, followed by tightly formatted Args and Returns blocks with no filler. Minor waste: the 'Read-only' tagline duplicates the annotation and the Returns block restates what the output schema already defines.

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 simple three-parameter read tool, every decision an agent must make is covered: which tool, what values are legal for size, how limit behaves, and what shape comes back. The declared output schema means the return summary need not go deeper, and nothing material is missing.

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 0% and the schema carries no enums, so the description must carry the load — and it does: it names all three parameters, supplies the two legal values for size with their pixel dimensions (250px / 1440px), states the limit range and default (1-50, default 20), and explains that limit truncates rather than errors. This meaning exists nowhere in the structured 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?

States a specific verb and resource ('Get base64-encoded thumbnails') plus the key differentiator ('for arbitrary asset IDs without needing an album'), and explicitly names the two sibling tools it is not. An agent can select this over get_album_thumbnails and get_asset_thumbnail without inspecting either 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?

Gives a positive use case ('visually display search results or any ad-hoc set of photos') and routes the agent away with two named alternatives keyed to their conditions (album-based, single photo). Both the when-to-use and when-not-to-use cases are covered explicitly.

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

Deploy Server

Other Tools