Skip to main content
Glama

find_assets_by_name

Read-onlyIdempotent

Search Unreal assets by name across all mounted content roots to find their object paths before reading or editing.

Instructions

Find assets by name across every mounted content root (/Game, /Engine, plugin mounts...): the broad "does anything called exist, and where?" search, with each hit's name, object path, class and package.

Use it before reading or writing an asset whose path you do not know: a hit's path is what get_object_info, set_properties and save_asset take. Other searches: get_assets_in_folder for a folder, get_assets_by_type for a class, get_assets_by_tag for an Asset Registry tag, and resolve_asset_by_name for one exact name with all its homonyms.

Examples: {"search_pattern": "Grass"} finds every name that contains Grass, in any case; {"search_pattern": "BP_*", "case_sensitive": true} only names that start with BP_, in that case. match_mode in the reply says whether the pattern ran as a substring or a wildcard. For a broad token, lower max_results and read results_truncated; keep wait_for_scan on right after the editor opens, while the registry may still be loading.

Returns: { assets: [{ name, path, class, package, is_loaded }], count: int, total_scanned: int, scan_was_pending: bool, search_pattern: string, match_mode: "substring"|"wildcard", case_sensitive: bool, max_results: int, results_truncated: bool }

Input Schema

NameRequiredDescriptionDefault
patternNoAlias of `search_pattern` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `search_pattern`.
max_resultsNoCap on number of matched assets (1..50000); defaults to 1000. WARNING: Hitting the cap ABORTS the enumeration, so `total_scanned` then counts only the assets visited before the early-out, not the whole registry.
wait_for_scanNoWhen true (default), force-completes the AssetRegistry scan before enumerating so a still-loading registry cannot report total_scanned:0. Set false to skip the (possibly blocking) wait.
case_sensitiveNoWhen true, match is case-sensitive; defaults to false
search_patternNoMatched against the asset NAME. Contains no `*`/`?` -> case-insensitive substring (FString::Contains). Contains `*` or `?` -> glob (FString::MatchesWildcard), ANCHORED at both ends: `*` matches any run including empty, `?` matches 0 or 1 character (UE semantics, not exactly 1). Not a regex.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as a safe, idempotent read, but the description adds operational behavior beyond them: match mode reporting, truncation behavior, scan-pending handling, and the warning that max_results can abort enumeration. These are meaningful behavioral traits an agent needs before invoking the tool.

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

Conciseness5/5

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

The first sentence front-loads purpose and scope, then usage guidance, alternatives, examples, and return shape follow in a logical order. Despite being fairly long, every section contributes useful information for a search tool with several matching modes and operational caveats.

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

Completeness5/5

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

The tool has five optional parameters and no output schema, so the description compensates by explaining return fields, match_mode, truncation indicators, and scan status. Combined with the fully documented input schema, an agent has enough information to invoke it correctly and interpret the response.

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 parameter meanings are already well documented in the input schema. The description still adds practical examples for search_pattern and case_sensitive, plus guidance on lowering max_results and using wait_for_scan after editor startup, though much of this overlaps with the schema's own parameter descriptions.

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 gives a specific verb and resource ("Find assets by name") and explicitly states scope across every mounted content root. It distinguishes the tool from related searches like get_assets_by_type and resolve_asset_by_name, so an agent can identify its role without opening schemas.

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?

It explicitly says to use this before reading or writing an asset whose path is unknown, and names the alternative search tools with their distinct selection criteria: folder, class, tag, and exact-name homonyms. The examples further clarify when substring versus wildcard matching applies.

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