Skip to main content
Glama

search_stock_media

Read-onlyIdempotent

Search curated public stock-media platforms for B-roll, photos, sounds, and music.

Use this before importing stock media. It normalizes results from API-backed providers with direct import URLs (Pexels, Pixabay, Unsplash, Freesound).

If you omit platforms, ChatCut searches only providers relevant to kind: video searches video providers, image searches image providers, audio/music searches sound/music providers, and any searches the full catalog.

Friendly workflow:

  1. Search with query + kind + optional platforms/category/orientation.

  2. Read title/description/tags/license/attribution/pageUrl before choosing.

  3. Download the selected result.downloadUrl into your own sandbox using result.downloadFilename, then call import_media for that local file. For audio/video transcript work, call track_progress target=transcription for the returned asset id before reading transcript/captions.

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": {
      "query": "<query>"
    },
    "name": "search_stock_media"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoMedia kind to search: video, audio, music, image, or any.
queryYesSearch phrase, e.g. 'startup office', 'cash register beep', 'upbeat corporate'.
categoryNoOptional category/context such as business, nature, food, technology, whoosh, piano, ambient.
platformsNoComma-separated platforms. Defaults to providers relevant to kind. Supported: pexels, pixabay, unsplash, freesound.
orientationNoVisual orientation filter for image/video providers.
limitPerPlatformNoMaximum normalized results per platform. Defaults to 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds genuinely non-obvious facts: results come only from API-backed providers with direct import URLs, and the asset must be downloaded locally before import_media can be used. It doesn't disclose result ordering, rate limits, or empty-result behavior, and the "public stock-media platforms" framing sits slightly at odds with openWorldHint=false, but that is not a hard contradiction.

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 purpose, then a scoping rule, then a numbered workflow; no filler sentences. It is on the long side, and the transcript postscript is only loosely related to a search tool, but every part is actionable.

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 6-parameter, read-only search tool with no output schema, the description covers what the tool returns (title, description, tags, license, attribution, pageUrl, downloadUrl, downloadFilename) and how to consume it, plus the next-step tool calls. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: omitting platforms scopes searches by kind (video/image/audio-music/any) and names the four supported providers. The workflow hints at how platforms, category, and orientation combine, which the schema alone 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?

States a specific verb and resource ("Search curated public stock-media platforms") and names the content types covered: B-roll, photos, sounds, music. An agent can tell it apart from sibling search tools like search_fonts and from the submit_* generation tools without opening the 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?

Explicitly says to use this before importing stock media, then gives a numbered workflow: search, inspect metadata, download to sandbox, call import_media, and finally track_progress target=transcription for transcript work. Both the trigger condition and the downstream alternative tools are named.

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.