Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
UE Blueprint MCP has 31 tools with decent schema coverage, but significant gaps in descriptions and parameter documentation. Most tool descriptions are adequate (average ~40 chars) but fall below the 194-char baseline for production tools. Parameter descriptions are present but often trivial (e.g., 'Name of the Blueprint' without context of format/constraints). Schemas are visible and typed across all tools, but lack structured output documentation. No tool annotations (readOnlyHint/destructiveHint) present despite risk levels being declared in metadata. Error handling is minimal, no guidance on what to do if operations fail. Several tools have unclear purposes or overlapping responsibilities (e.g., spawn_blueprint_actor vs spawn_actor). Security concerns: no validation hints in descriptions; no mention of permission requirements.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite risk levels being tracked in metadata. This prevents MCP clients from visually distinguishing safe vs. destructive operations.
Descriptions are consistently below production baseline (194 chars). Examples: 'Test connection to Unreal Engine' (33 chars), 'Get current editor context' (30 chars), 'Get a list of all actors in the current level' (45 chars). Many lack actionable context about when to use the tool or what happens on error.
Output schemas are not documented. Clients do not know what fields each tool returns, making it difficult for agents to plan downstream tool calls or extract needed data for follow-up operations.
Recommendations
Add toolAnnotations to the MCP server registration. For each tool, include readOnlyHint (boolean), destructiveHint (boolean), and idempotentHint (boolean) in the Tool definition. Example: { name: 'delete_actor', ..., readOnlyHint: false, destructiveHint: true, idempotentHint: false }.
Expand all tool descriptions to 150 - 250 characters. Include: (1) what the tool does, (2) when to use it vs. similar tools, (3) any prerequisites, (4) what happens if it fails. Example: 'Compile a Blueprint to check for syntax errors and validate node connections. Returns detailed error messages if compilation fails, including error line numbers and suggested fixes. Call this after editing Blueprint nodes to ensure they are valid before spawning instances.'
Document output schemas for every tool. In the tool descriptions or in a separate schema registry, specify what fields are returned. Example for get_actors_in_level: 'Returns {actors: [{name: string, class: string, location: [x, y, z], rotation: [pitch, yaw, roll]}], total_count: int}'.
Convert free-form string parameters to enums. For 'domain' in create_material, add enum: ['Surface', 'PostProcess', 'DeferredDecal', 'LightFunction', 'UI']. For 'component_type', enumerate valid Unreal component classes: ['StaticMeshComponent', 'BoxComponent', 'SphereComponent', 'CapsuleComponent', 'CylinderComponent', 'SkelMeshComponent', 'AudioComponent', 'LightComponent', 'ParticleSystemComponent', 'SkeletalMeshComponent'].
Add validation rules to parameter descriptions. Example for location/rotation/scale arrays: 'Array of exactly 3 numbers [x, y, z]. Location is in Unreal world units (1 unit ≈ 1 cm). Rotation is in degrees (0 - 360). Scale should be positive (default 1.0).' For color in create_colored_material: '[R, G, B] as floats in range [0.0, 1.0]. Example: [1.0, 0.0, 0.0] for red.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling guidance. Tools that could fail (e.g., compile_blueprint, create_blueprint, spawn_actor) provide no hints on recovery steps, making it hard for agents to self-correct on failure.
Parameter descriptions lack validation constraints. Examples: 'property_value' is just 'Value to set' with no format/type guidance; location arrays have no bounds checking hints; component_type accepts free-form strings with no enum of valid types (StaticMeshComponent, BoxComponent, etc.).
Semantic overlap between tools. 'spawn_blueprint_actor' and 'spawn_actor' serve similar purposes but with different inputs; agents must guess which to use. 'set_blueprint_property' and 'set_component_property' could be confused if parameter names are similar.
No pagination support for list operations (get_actors_in_level, find_actors_by_name). Large levels with thousands of actors would overflow context and crash agents.
Parameter type definitions are inconsistent. 'color' in create_colored_material is [R, G, B] (3 elements) but 'scale' in add_component_to_blueprint is [x, y, z] (also 3). No validation that arrays have exactly 3 elements or that values are in range [0, 1].
No idempotency guarantees documented. Tools like 'create_blueprint', 'spawn_actor', and 'create_material' could silently create duplicates if retried, but this is not stated, preventing safe agent retry logic.
Material domain and blend mode parameters accept free-form strings with no enum. Description says 'Surface, PostProcess, DeferredDecal, LightFunction, UI' but does not enforce it, allowing invalid inputs like 'surface' (lowercase) or 'SurfaceX'.
Add error recovery hints to descriptions of tools that could fail. Example for compile_blueprint: 'Returns success: true if compilation succeeds. If compilation fails, returns success: false, errors: [{message: string, line_number?: int}]. If errors occur, use get_context to review the Blueprint graph, then edit the problematic nodes and retry.'
Document idempotency for creation tools. Add to descriptions: 'Idempotent: calling this multiple times with the same parameters returns the same result without creating duplicates. Safe to retry on transient failures.' For non-idempotent tools (e.g., spawn_actor if names must be unique), clarify: 'Non-idempotent: calling twice with the same name will fail on the second attempt with error "Actor name already exists". Use find_actors_by_name first to check availability.'
Clarify overlapping tool purposes. Add to spawn_actor and spawn_blueprint_actor descriptions: 'spawn_actor creates a generic actor instance of a given type. spawn_blueprint_actor creates an instance of an already-defined Blueprint class. Use spawn_blueprint_actor if you have a Blueprint (created via create_blueprint), otherwise use spawn_actor.'
Add permission/scope declarations to tool descriptions (even if not enforced yet). Example: 'Requires: write:blueprints, write:level'. This documents what access is needed and enables least-privilege agent configurations.
Validate numeric ranges early and return clear error messages. Example: if limit > 100 in get_actors_in_level, return 'Invalid limit: 150. Must be 1 - 100.' instead of a generic error.
For tools that accept free-form property names (set_blueprint_property, set_actor_property, set_component_property), add guidance: 'property_name must be a valid Unreal Engine property name on the target object. If unsure, call get_actor_properties first to see available properties.'
Add context dependencies to descriptions. Example for find_actors_by_name: 'pattern is case-sensitive and supports wildcards (* and ?). If you only have a partial name, call get_actors_in_level first to see all actor names in the current level.'
Return IDs and references needed for chaining. Ensure get_actors_in_level returns actor names that can be passed directly to set_actor_property, focus_viewport, and delete_actor. Verify material creation tools return material names for downstream compile_material calls.