Skip to main content
Glama

AI search

ai_search
Read-only

AI-powered visual search for assets in a Playbook workspace. Understands what is depicted inside assets — colors, subjects, scenes, objects, and compositions. Use this when the user describes visual content: 'ocean waves in blue', 'product shots on white background', 'videos with people outdoors'. Works regardless of filename or tags. Prefer this over search_assets for any content-descriptive query. Scope it to a board with collection_token (plus nested_assets for a parent board) — unscoped it searches the whole workspace, which for a moodboard, pitch reel or client hand-off returns mostly assets from other projects. Also filters by uploader and by date range. 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
queryYesNatural language search query
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.
date_toNoInclusive upper bound, ISO 8601 date or datetime
statusesNoRestrict results to assets carrying these status or custom field VALUES, e.g. ['Approved']. Case-insensitive, and it covers the built-in Status and every custom field, exactly as in search_assets. Several values match ANY of them — unlike search_assets there is no `and` mode here.
date_fromNoInclusive lower bound, ISO 8601 date or datetime (e.g. '2026-08-13')
parent_idNoSearch token returned as pagination.parent_id. Pass it alone to refine that search, or together with after_cursor to fetch its next page.
date_fieldNoWhich date the range applies to. 'original' is when the file itself was created (EXIF date where available); 'uploaded' is when it was added to Playbook. Defaults to 'original', EXCEPT when `uploaded_by` is set, where it defaults to 'uploaded' — so 'what did Max upload last week' means what you expect.
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.
after_cursorNoOpaque cursor returned as pagination.after_cursor. Must be paired with parent_id from the same response.
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 — it is not part of what is searched.
collection_tokenNoLimit the 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"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "query",
      -  "context"
      -]New value: +[
      +  "query"
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description still adds substantial non-obvious behavior: unscoped searches span the whole workspace, nested_assets is required for parent boards or the search returns nothing, subtree matching can lag a board move whereas list_assets reads the database, and putting a person's name in `query` does not match the uploader. These are genuine gotchas not derivable from structured fields.

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 usage, then scoping, then the uploader pitfall — a sensible priority order with no filler sentences. It runs long for a description, but for a 13-parameter tool every paragraph carries operative guidance rather than restating schema 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?

Given 13 parameters, no output schema, and rich annotations, the description covers calling correctly: scope, nesting, uploader resolution, date-field defaults, and payload retrieval. It stops short of describing the result shape or pagination flow (parent_id/after_cursor are left to the schema), which is the only meaningful gap for a tool of this complexity.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: collection_token is framed as the scoping lever with a stated consequence, nested_assets is tied to parent-board tokens, and uploaded_by is tied to a list_members resolution step. The name-in-query pitfall is a semantic warning absent from the schema itself.

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 ('AI-powered visual search for assets') and immediately qualifies what makes it distinct: it understands depicted content (colors, subjects, scenes, objects, compositions) rather than filenames or tags. It explicitly names the sibling it displaces ('Prefer this over search_assets'), so an agent can route correctly 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 concrete when-to-use examples ('ocean waves in blue', 'product shots on white background'), an explicit alternative and the condition that selects it (content-descriptive queries vs search_assets), plus a scoping recommendation with the failure mode for not scoping (moodboard/pitch reel returns other projects' assets). It also spells out the correct multi-tool workflow for uploader queries via list_members.

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