Skip to main content
Glama

import_stock_image

Download a stock photo by its search ID, store it in the media library with alt text and attribution, and return the asset for use in image fields.

Instructions

Import a stock photo (by the id from search_stock_images) into the media library. Downloads the image, stores it as a regular asset with alt text + attribution, and returns the asset — set its documentId on an image field with set_field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
altNoAlt text override (defaults to the provider's description)
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
providerIdYesPhoto id from search_stock_images

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare the mutation/external-network profile (readOnlyHint=false, openWorldHint=true), and the description adds genuinely useful behavior beyond that: it downloads the image, stores it as a regular asset, and attaches alt text + attribution. It does not spell out that repeat calls create duplicate assets (non-idempotent), so it stops short of a 5.

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?

Two dense sentences that front-load the operation, then the mechanics, then the downstream instruction. No filler and nothing repeated from structured fields.

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?

For a 3-param mutation with no output schema, the description covers purpose, side effects, and the follow-up step well enough to invoke correctly. The one gap, that importing the same providerId twice yields duplicate assets, is partially mitigated by the idempotentHint=false annotation.

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 all three parameters (alt override, site, providerId). The description's phrase 'by the id from search_stock_images' adds provenance for providerId, but the rest adds no meaning beyond the schema, so baseline 3 holds.

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 (import), resource (stock photo), and destination (the media library), and ties the input source directly to the sibling search_stock_images. It is clearly distinguishable from upload_asset and search_stock_images without opening any schema.

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

Usage Guidelines4/5

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

It establishes the workflow context (get the id from search_stock_images, then set the returned documentId with set_field), which tells the agent where this sits in the chain. It stops short of any when-not guidance or explicit exclusions versus alternatives like upload_asset.

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