Skip to main content
Glama
Sign In
MCPBridge Server

MCPBridge Server

by RBG-WebDesign
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

asset_list

Lists Unreal Engine assets with optional filters for path, asset type, and name pattern, returning asset paths, types, and names for AI agents to manage editor resources.

Instructions

List assets with optional filters. Returns asset paths, types, and names.

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": "asset_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoPath prefix to search under (default: /Game/)
recursiveNoSearch recursively (default: true)
asset_typeNoFilter by asset type class name
name_patternNoFilter by name substring

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of safety disclosure. It says 'List' and states return fields, implying a read-only operation, but it does not explicitly confirm it is non-mutating or disclose potential side effects like asset loading. The verb provides some transparency but not a full safety profile.

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 description is two concise sentences, with the main action front-loaded and no filler words. Every word adds value, making it highly efficient.

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?

The tool is straightforward, and the schema covers parameters fully. The description states the return fields, which is important because no output schema exists. However, it omits context about default behavior (e.g., default path /Game/) and how filters interact, leaving some gaps in operational understanding.

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 coverage is 100%, giving complete descriptions for all four parameters. The description's mention of 'optional filters' adds no semantic value beyond what the schema already specifies, so the baseline of 3 applies.

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 uses a specific verb and resource: 'List assets' and explicitly states the output (paths, types, names). This distinguishes it from asset_info (which likely targets a single asset) and material_list (which targets materials only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like asset_info. There is no mention of exclusions, prerequisites, or when a different listing tool might be more appropriate.

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

Deploy Server

Other Tools