Skip to main content
Glama

Search library, catalog and providers

search_assets
Read-only

Search your uploads, the offline CC0 catalog, or enabled providers (Pexels, Pixabay, Freesound, Iconify, Giphy) by keyword and kind, then pass the returned provider and externalId to add_asset.

Instructions

Find assets. source "library" = your own uploads (name and tags; empty q lists all); omitted or "catalog" = the Reelsaw catalog (CC0, works offline); or a provider an admin enabled. Returns { provider, items: [{ provider, externalId, name, kind, license, durationSec }], nextCursor }. Adds nothing: a catalog / provider hit's provider + externalId go to add_asset.

Input Schema

NameRequiredDescriptionDefault
qNoWhat to look for, e.g. "whoosh", "arrow", "city at night"; empty lists everything in the source
kindNoOnly this kind of result
limitNoResults per page (1-60, default 24)
cursorNonextCursor from the previous page; omit for the first page
sourceNolibrary, catalog (default), pexels, pixabay, freesound, iconify, openverse, giphy or klipy
deletedNolibrary only: list your deleted items instead (their ids go to restore_asset)
licenseNofreesound only: cc0 (default) or by (CC0 and CC-BY, attribution is stored)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.26.3
    • addedInput schema / properties / deleted
      Added value: +{
      +  "description": "library only: list your deleted items instead (their ids go to restore_asset)",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / removed
      Removed value: -{
      -  "description": "library only: list the items removed in the last 30 days instead (their ids go to restore_asset)",
      -  "type": "boolean"
      -}
  2. Addedv0.19.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real value with the return shape (provider, items, nextCursor), the offline/catalog behavior, and the fact that this tool adds nothing itself. It stops short of disclosing auth requirements or provider-enablement nuance, but it is well beyond the annotation baseline.

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?

Dense and front-loaded: purpose first, then source semantics, then return shape, then the add_asset handoff. It is slightly telegraphic ('Adds nothing', parentheticals) and could be marginally smoother, but nearly every clause earns its place.

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 7-param, read-only search tool with no output schema, the description supplies the return envelope and pagination token, covers all source modes, and links to the downstream add_asset call. Remaining gaps (kind/limit filtering details, license attribution nuance) are covered by the rich schema, so the description is essentially complete for correct invocation.

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; the description adds semantics the schema does not, notably source default behavior, the library name-and-tag matching scope, offline catalog behavior, and the role of provider + externalId in add_asset. The deleted and license params are only lightly touched, but the core source semantics are clarified.

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+resource ('Find assets') and immediately distinguishes three source modes (own uploads, catalog, admin-enabled provider) plus the terminal action of routing hits to add_asset. An agent can tell this apart from add_asset and unrelated siblings 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 defines when each source applies: library = own uploads, omitted/'catalog' = Reelsaw catalog (CC0, works offline), otherwise an admin-enabled provider. It also states the follow-up path ('a catalog / provider hit's provider + externalId go to add_asset'), removing ambiguity about the search-then-add workflow.

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