Skip to main content
Glama

get_blueprint_components_list

Read-onlyIdempotent

Lists components a Blueprint declares in its own Simple Construction Script with class, flags, mobility, collision, and mesh data; inherited and native components are excluded.

Instructions

List the components a Blueprint declares in its OWN Simple Construction Script, each with class, root flag, scene/primitive flags, mobility, physics and collision state, and static-mesh path + material count when it has one. WARNING: it shows ONLY this Blueprint's own SCS: components inherited from a parent Blueprint and native components from the C++ CDO are INVISIBLE here, so a short list is not proof the component is missing -- get_blueprint_scs_tree returns native + own SCS + inherited, source-classified, and is the right call whenever the answer matters. Use get_actor_components for a live actor instance instead of an asset.

Returns: { blueprint_name: string, blueprint_path: string, components: [object], components_count: int, max_results: int, results_truncated: bool, has_simple_construction_script: bool, blueprint_valid: bool, ambiguous_matches?: [string] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_resultsNoMaximum components to return, 1..10000 (default 1000)
blueprint_nameNoBlueprint asset short name (exact) or full package name; an ambiguous bare name resolves to the first hit and lists the rest in `ambiguous_matches`
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
include_inheritedNoIGNORED: accepted and parsed but never used. Inherited components are never included here whatever you pass -- call get_blueprint_scs_tree for those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds crucial scope behavior beyond them: only this Blueprint's own SCS is shown, inherited and native CDO components are invisible, and a short list is misleading. It also lists the return shape, fully carrying the burden since no output schema exists.

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?

Purpose is front-loaded, followed immediately by the critical warning, the alternative tools, and the return shape. Every sentence earns its place, and the Returns block is necessary because there is no output schema.

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?

Given moderate complexity, full schema coverage, and no output schema, the description provides everything needed: scope, limitations, alternatives, and return fields. Nothing required to call or interpret the tool correctly is missing.

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 all four parameters are already documented, including the alias and the ignored include_inherited flag. The description adds no parameter syntax or format details beyond what the schema provides, making the baseline 3 appropriate.

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 with scope: 'List the components a Blueprint declares in its OWN Simple Construction Script.' It explicitly distinguishes itself from get_blueprint_scs_tree and get_actor_components, so an agent can route correctly without opening any 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 alternatives and the condition for each: get_blueprint_scs_tree 'is the right call whenever the answer matters' because it includes native, own SCS, and inherited components; get_actor_components is for live actor instances instead of assets. It also warns that a short list is not proof a component is missing.

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