Skip to main content
Glama

Search assets

search_assets
Read-only

Search for assets in a Playbook workspace by metadata: filename, title, or tags. Use this when the user knows the name of an asset or is searching by tag or file type. Does NOT understand visual content — use ai_search for queries about what is depicted in the asset. Supports filtering by media type (image, video, document, audio), board, uploader, and status or custom field value. This is also the ONLY tool that finds assets BY a custom field value ('everything marked High') — pass the value as statuses, which ai_search also accepts. A filter-only call automatically searches all text (query: '*'), and any statuses call without an explicit media type searches every media type. To find what a PERSON uploaded, call list_members to resolve their name to a token, then pass that token as uploaded_by. Putting a person's name in query does NOT match the person who uploaded an asset — it searches the asset's own text and will return unrelated files.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_assets"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (1-indexed)
queryNoText search query. Omit it for a filter-only search such as `statuses`
fieldsNoReturn ONLY these fields on each result. `token` is always included. Valid names: token, title, media_type, text_type, status, approved, approved_after, tags, permalink, display_url, stream_url, collection_token, size, is_skeleton, uploaded_by, source_error, ai_generated, ai_agent_payload. `display_url` and `permalink` are ~400 characters each, so narrowing a large result set is most of the saving. An unknown name is refused, not ignored: there is no `created_at`, `updated_at` or `type` among them — `media_type` is the name for an asset's kind, and its other metadata comes from get_asset or get_assets.
statusesNoRestrict results to assets carrying these status or custom field VALUES, e.g. ['High', 'Approved']. Case-insensitive, and it covers both the built-in Status and every custom field — get the exact option names from list_custom_fields. Matching is on the option name ALONE, with no way to say which field it came from, so a value name two fields share matches assets tagged under either.
media_typeNoFilter by type. Ordinarily omitting this searches images only. When `statuses` or `include_archived` is set, the tool automatically uses 'all' so no asset type is silently excluded.
statuses_opNoHow to combine several `statuses`: 'or' (default) matches any of them, 'and' requires all of them at once — which is how you intersect values from different fields, e.g. Priority High AND Season Summer. Ignored unless `statuses` is set.
uploaded_byNoRestrict results to assets uploaded by these people. Pass member tokens from list_members. A name is accepted as a fallback and resolved server-side, but only when it matches exactly one member — otherwise the call fails and lists the candidates to choose from.
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.
nested_assetsNoSearch the board's entire nested subtree rather than only the assets sitting directly in it. Requires `collection_token`. Set it whenever the token might be a PARENT board — without it a parent whose assets all live in sub-boards returns nothing at all. Caveat: subtree matching reads a search-index field that refreshes when an asset is re-indexed, so it can briefly lag a board being MOVED; list_assets with `nested_assets` reads the database and cannot.
get_ai_payloadNoInclude each result's `ai_agent_payload`. Default false, and the key is then ABSENT rather than null. This only RETURNS the payload — you cannot search or filter on its contents.
collection_tokenNoLimit search to a specific board
include_archivedNoAlso return assets that sit directly in the Archive, which are left out by default. Assets inside an archived board are returned either way. Without `media_type` this searches every media type, not only images. Results mix archived and active assets, and nothing in a result marks which is which; unarchive_assets refuses the active ones and names them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / include_archived
      Added value: +{
      +  "description": "Also return assets that sit directly in the Archive, which are left out by default. Assets inside an archived board are returned either way. Without `media_type` this searches every media type, not only images. Results mix archived and active assets, and nothing in a result marks which is which; unarchive_assets refuses the active ones and names them.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / media_type / description
      Previous value: -"Filter by type. Ordinarily omitting this searches images only. When `statuses` is set, the tool automatically uses 'all' so no asset type is silently excluded."New value: +"Filter by type. Ordinarily omitting this searches images only. When `statuses` or `include_archived` is set, the tool automatically uses 'all' so no asset type is silently excluded."
  2. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  3. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
      -  "type": "string"
      -}
    • removedInput schema / required
      Removed value: -[
      -  "context"
      -]
  4. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish a safe read operation, and the description adds non-obvious runtime behavior on top: filter-only calls auto-search all text via `query: '*'`, and any `statuses` call without a media type searches every type rather than defaulting to images. It also flags a footgun (uploader names in `query` do not match). It stops short of describing result ordering, caps, or the shape of returned items, which the missing output schema leaves undocumented.

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?

Seven sentences is long, but the capability and the ai_search boundary are front-loaded, and each later sentence carries a distinct, load-bearing caveat (status-only semantics, `statuses` as the custom-field path, the two-step uploader lookup, the query/uploader mismatch). Some schema-level detail could have been left to the schema, but nothing is filler.

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 12-parameter tool with no output schema, this covers the decisions that actually change a call: metadata vs. visual search routing, automatic media-type widening, the only path to custom-field-value search, and uploader lookup. The remaining gap is return-shape and pagination expectations, though `page` and `fields` are documented in the schema itself.

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 exceeds it by explaining that `statuses` is the ONLY cross-tool way to find assets by custom field value and that it accepts a bare value like 'everything marked High'. That routing insight plus the `uploaded_by` name-resolution workflow and the `query`-doesn't-match-uploader warning add meaning the schema alone doesn't 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?

Opening sentence names a specific verb (search) and resource (assets) and pins the search surface to metadata: filename, title, tags. It then draws a hard boundary against the sibling it most resembles — 'Does NOT understand visual content — use ai_search' — so an agent can route without opening 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?

Explicit when-to-use ('user knows the name of an asset or is searching by tag or file type'), explicit when-not (visual content → ai_search), and named prerequisites for the tricky case (list_members to resolve a person to a token before uploading_by). It also warns that putting a name in `query` will silently return unrelated files, which is the single most likely misuse.

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.

Resources