Unreal-MCP-Ghost

Overview Schema Source Related Servers Discussions Admin

add_blueprint_function_with_pins

Create or update a Blueprint function with typed input and output pins, enabling reusable gameplay logic in Unreal Engine.

Instructions

Create or update a Blueprint function graph with typed signature pins.

Use this when an agent needs a reusable gameplay function, not a call node in an existing graph. Each pin entry supports name, type, and an optional sub_type for object/class-backed pins.

Args: blueprint_name: Asset name of the Blueprint. function_name: Function graph to create or update. inputs: Function input pins, e.g. [{"name": "Amount", "type": "float"}]. outputs: Function output pins, e.g. [{"name": "Success", "type": "bool"}]. is_pure: Whether to mark the function as pure when supported.

Returns: Dict with graph_name, entry_node_id, result_node_id, inputs, and outputs.

KB: see knowledge_base/01_BLUEPRINT_FUNDAMENTALS.md#function-signature-authoring Example: add_blueprint_function_with_pins( blueprint_name="/Game/MCP_Test/BP_Example", function_name="ComputeDamage", inputs=[{"name": "BaseDamage", "type": "float"}], outputs=[{"name": "FinalDamage", "type": "float"}], )

Input Schema

TableJSON Schema

Name	Required	Description	Default
`inputs`	No
`is_pure`	No
`outputs`	No
`function_name`	Yes
`blueprint_name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

A4.3/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. It does communicate that the tool creates or updates and returns a dict, which implies a mutating operation. However, it does not disclose whether updating an existing function replaces pins, whether it requires the Blueprint asset to already exist, or whether compilation is needed afterward.

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 well-structured and efficient: a one-sentence summary, a usage guidance line, compact Args list, Returns line, KB pointer, and a complete example. Every section earns its place and is front-loaded appropriately.

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

Completeness4/5

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

All parameters, the return shape, and a worked example are provided, and the KB reference adds depth. It is nearly complete, but it omits edge-case behavior around updating an existing function graph and any prerequisites on the Blueprint asset itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage and its item schemas are generic objects, but the description fully compensates. It explains blueprint_name, function_name, inputs, outputs, and is_pure with examples and notes the optional sub_type for object/class-backed pins.

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 opens with a specific verb-resource pair: 'Create or update a Blueprint function graph with typed signature pins.' It further distinguishes itself from siblings by saying 'not a call node in an existing graph,' making it clear this is for authoring reusable function graphs rather than adding function-call nodes.

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?

The description explicitly states when to use it: 'Use this when an agent needs a reusable gameplay function, not a call node in an existing graph.' This gives a clear when-to-use and when-not-to-use signal, though it does not name the exact alternative sibling tool to use for call-node insertion.

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

Deploy Server