Skip to main content
Glama

add_component_event

Checks a level actor component event and returns the appropriate Blueprint binding call when the event is a bindable delegate; it never creates live bindings.

Instructions

Checks an event of a level actor's component; it never creates a binding (success is always false). A binding made on a live level-actor component would not persist: a handler belongs in a Blueprint's event graph. When the actor comes from a Blueprint and the event is a bindable delegate, the reply carries suggested_call: the add_component_bound_event call that authors it, with its parameters filled in.

Returns: { actor_name: string, component_name: string, event_name: string, event_category: string, event_description: string, event_function_signature: string, success: bool, binding_created: bool, is_bindable_delegate: bool, delegate_property_name: string, bound_handler_count: int, message: string, error: string, component_class: string, component_category: string, component_tooltip: string, component_display_name: string, component_is_active: bool, component_is_registered: bool, component_owner: string, component_creation_method: string, suggested_call?: { tool: string, params: { blueprint_name, component_name, delegate_name } } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actor_nameYesName of the actor containing the component
event_nameYesName of the event to add (must be one of: BeginPlay, EndPlay, Tick, Activate, Deactivate, Register, Unregister, TransformUpdated, OnClicked, OnBeginCursorOver, OnEndCursorOver, OnInputTouchBegin, OnInputTouchEnd, OnInputTouchEnter, OnInputTouchLeave)
component_nameYesName of the component

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4/5.0
Behavior4/5

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

Beyond the annotations, the description discloses the non-obvious failure semantics ('success is always false'), the reason a live-actor binding would not persist, and the suggested_call hand-off mechanism — genuinely useful behavioral context. It does not reconcile this no-op framing with the readOnlyHint=false / idempotentHint=false annotations, leaving the safety profile ambiguous.

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

Conciseness4/5

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

The three prose sentences are dense but front-loaded, leading with the surprising truth that no binding is created. The long enumerated return-shape block is bulky, but with no output schema it is a legitimate necessity rather than padding.

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?

For a semantics-heavy tool with no output schema, the description covers the return payload field-by-field, the guaranteed failure outcome, the persistence rationale, and the redirect to the correct authoring tool. An agent has everything needed to call it and interpret the result correctly.

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% and all three parameters are documented there, so the baseline is 3. The prose adds some conditional meaning (the actor must come from a Blueprint and the event must be a bindable delegate for a suggested_call to appear), but it says nothing about parameter formats or the delegate-vs-event distinction that would materially change what an agent passes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource ('Checks an event of a level actor's component') and immediately disambiguates from the similarly named sibling by declaring it 'never creates a binding' and naming add_component_bound_event as the authoring counterpart. The only friction is that the tool name says 'add_' while the described action is a check/validation, so an agent selecting by name alone gets a mild jolt that the prose then resolves.

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

Usage Guidelines4/5

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

It clearly explains when this tool is useful (actor sourced from a Blueprint and the event is a bindable delegate, in which case the reply carries a filled-in suggested_call) and explicitly routes authoring work to add_component_bound_event. It does not spell out the converse case (non-Blueprint actors, non-delegate events) beyond implication, and it never says why you would run the check in the first place, so it stops short of a full when/when-not statement.

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