Metadata MCP Connector

Search Creative Library (Images, Videos, GIFs, Documents)

search_library_creatives_by_name

Read-only

Search or list creative assets in the library by name, across ALL content types — images, videos, GIFs and documents. Returns detailed information about matching assets with pagination support.

               KEYWORDS (for tool discovery): search creative library, list video creatives,
               find videos, list uploaded videos, browse video library, search videos by name,
               list all creatives, find creative by id, look up creative id, list documents,
               list GIFs, library assets, video assets, creative assets, list creatives by type.
               This is the general-purpose library search/list tool for every content
               type — there is no separate "list videos" or "get library items" tool.

               WHEN TO USE:
               - Find specific creatives by name in the library
               - List all creatives in the library (when creativeName is omitted)
               - Search for creative assets with partial name matching
               - Filter by content type (IMAGE, VIDEO, GIF, DOCUMENT)
               - Locate creatives for use in ad creation
               - Verify creative asset availability before campaign setup
               - Get creative metadata and IDs for asset management
               - Browse through paginated results

               SEARCH BEHAVIOR:
               - Supports partial name matching when creativeName is provided
               - Case-insensitive search
               - Returns all creatives matching the search term
               - Automatically URL encodes the search name
               - When creativeName is omitted, returns all creatives in the library
               - Supports optional content type filtering (IMAGE, VIDEO, GIF, DOCUMENT)
               - Use lower number in the size parameter. Preference for 5 or 10 max.

               PAGINATION:
               - Supports pagination with `page` and `size` parameters.
               - Defaults: page=0, size=10 (server-side default in
                 `MetadataAPIClient.search_library_creatives_by_name`).
               - Page numbering starts at 0.
               - The platform returns Spring `PageResponse` shape
                 (`totalElements`, `totalPages`, `data`) so callers can
                 drive a paginator off the response.
               - Recommended size: 5-10 to keep LLM responses manageable.
                 Larger windows (up to ~25) are accepted; anything beyond
                 blows token budgets fast.
               - `sort` takes a Spring `field,direction` clause and defaults
                 to `id,desc`. Sort on `labelName` for the display name;
                 `name` holds the generated UUID.

               RETURNED DATA:
               - Creative asset ID and name
               - File properties (size, dimensions, format)
               - Upload and modification timestamps
               - Visibility status and permissions
               - Preview URLs and download links
               - Associated metadata and tags
               - Pagination metadata (total count, page info)

               USE CASES:
               - "List all images in the library"
               - "Find all images with 'product' in the name"
               - "Search for logo images in the library"
               - "Get image ID for 'campaign-hero-banner.jpg'"
               - "Find all images uploaded for the Q4 campaign"
               - "Browse images page by page (page=0, size=5)"
               - "List only videos: contentTypes=VIDEO"
               - "Filter for images and videos: contentTypes=IMAGE,VIDEO"
               - "Get all documents: contentTypes=DOCUMENT"
               - "Find all asset types: contentTypes=IMAGE,VIDEO,GIF,DOCUMENT"

               NOTE: This is the single tool for searching/listing ALL creative asset
               types. To restrict to a type, pass contentTypes (e.g. VIDEO for videos
               only); omit it to return every type. Use fetch_creative_details when you
               already have a specific creative id and want its full metadata.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Zero-based page index (default: 0).
`size`	No	Results per page (default: 10, recommended max: 10). Larger windows blow LLM token budgets — only request more when the caller actually needs it.
`sort`	No	Spring sort clause, 'field,direction' (default: 'id,desc'). The platform binds a full Pageable to this endpoint, so any ImageLibrary column works: labelName, createdDate, contentType, sizeInKb, width, height, status, id. WARNING: sort on labelName for the display name. 'name' holds the generated UUID that doubles as the S3 object key, so sorting on it produces an order no person can read.
`contentTypes`	No	Filter by content types (comma-separated). Supported values: IMAGE,VIDEO,GIF,DOCUMENT. Example: IMAGE,VIDEO or IMAGE%2CVIDEO%2CGIF%2CDOCUMENT
`creativeName`	No	Name or partial name of the creative to search for. Supports partial matching and is case-insensitive. Omit to list all creatives.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: case-insensitive partial matching, automatic URL encoding, server-side pagination defaults (page=0, size=10), Spring PageResponse shape, sort default id,desc, and a warning about sorting on labelName vs the UUID field. It also cautions about token budgets for large sizes. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely verbose, containing a large KEYWORDS discovery block, extensive USE CASES examples, and repeated information (e.g., contentTypes is described three times). While it is front-loaded with the core purpose, the overall length is excessive for an agent selecting and using the tool, and several sections (KEYWORDS, repetitive USE CASES) do not earn their 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?

Despite the verbosity, the description is thorough: it covers search behavior, pagination shape and defaults, sorting nuances, returned data fields, and use cases. It even references fetch_creative_details as an alternative. Given the tool complexity and no output schema, the description provides enough for an agent to call it correctly. Minor omissions like error handling or permissions are not critical for a read-only search tool.

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

Parameters3/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. The description does add extra guidance like 'Recommended size: 5-10' and reminds that sort on labelName is the display name, but these are largely behavioral or advisory rather than new parameter semantics. Most parameter meaning (partial matching, contentTypes values, defaults) is already in the schema descriptions, so the description adds only marginal value beyond that.

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?

The description clearly states the tool searches or lists creative assets by name across all content types (images, videos, GIFs, documents). It explicitly distinguishes itself from sibling tools like fetch_creative_details and asserts it is the general-purpose library search/list tool with no separate list/video tool, so an agent can correctly determine its scope.

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?

The 'WHEN TO USE' section lists eight specific scenarios (find by name, list all, filter by type, etc.) and the NOTE explicitly tells the agent to use fetch_creative_details when a specific creative id is already held. This provides clear when-to-use guidance and names the alternative, exceeding basic expectations.

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

All Metadata MCP Connector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?