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.

Input Schema

TableJSON 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` 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      -]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly, non-destructive, closed-world); the description adds non-obvious behavior beyond them: a filter-only call silently runs `query: '*'`, an omitted media_type defaults to images but flips to 'all' when `statuses` is set, and custom-field values are matched on the option name alone with no field attribution. These disclose hidden side effects an agent could not infer from the annotations.

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 and the ai_search split, and the later sentences carry genuinely high-value warnings (uploader-name pitfall, statuses/media_type coupling). It is dense and long, with a couple of clauses that restate schema facts, but waste is low relative to payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, zero-required discovery tool with no output schema, the description covers routing, filter interactions and the main failure modes well. It omits return-shape and pagination behavior (page size, total counts) that an agent must guess from the solo `page` parameter.

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% and already very descriptive, so the baseline would be 3; the description still adds cross-cutting semantics the schema cannot, notably that `statuses` is the only path to filtering by custom field value and that ai_search accepts the same value. It does not re-derive the per-parameter detail already in the schema, which is correct.

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 (search assets by metadata) and immediately scopes what it does not do ('Does NOT understand visual content'). It differentiates itself from the sibling ai_search by name mid-sentence, 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?

Gives explicit when-to-use ('user knows the name of an asset or is searching by tag or file type') and when-not ('use ai_search for queries about what is depicted'), plus the concrete anti-pattern that a person's name in `query` will not match the uploader and the required list_members→token workaround.

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