Skip to main content
Glama

net_set_function_rpc

Configure Unreal Engine Blueprint functions as networked RPC events. Set RPC type (server, client, multicast), reliability, and create missing custom events with optional typed inputs.

Instructions

Create or configure a Blueprint Custom Event as an RPC.

Args: blueprint_name: Actor Blueprint asset name or path. function_name: Custom Event/function name to configure. rpc_type: server, client, netmulticast, net_multicast, multicast, or none. reliable: Mark the RPC reliable when True. create_if_missing: Create the Custom Event if it does not already exist. inputs: Optional typed input pins, e.g. [{"name": "Damage", "type": "Float"}]. node_position: Optional [X, Y] graph position for newly created events. save: Save the Blueprint package after mutation. compile: Compile the Blueprint after mutation.

KB: see knowledge_base/20_NETWORKING_AND_REPLICATION.md#mcp-network-tools Example: net_set_function_rpc(blueprint_name="/Game/BP_Door", function_name="Server_RequestOpen", rpc_type="server")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNo
inputsNo
compileNo
reliableNo
rpc_typeNoserver
function_nameYes
node_positionNo
blueprint_nameYes
create_if_missingNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions save and compile but does not explicitly state that the tool mutates the Blueprint asset, whether existing RPC settings are overwritten, or if any prerequisites (e.g., blueprint must exist) apply. Side effects and potential risks are not disclosed.

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 description is structured as a clear list of arguments with brief explanations, an example, and a KB reference. It is reasonably concise despite covering 9 parameters, and the front-loaded action sentence helps orient the agent.

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?

Given the tool's complexity (9 params, many optional) and the presence of an output schema (though not shown), the description covers the necessary parameters and provides an example and KB link. It lacks explicit statements about error handling or prerequisites, but overall it is fairly complete for an agent to invoke correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description fully carries parameter explanations. It explains each parameter well, including allowed values for rpc_type, an example for inputs, and notes for node_position. This adds significant meaning beyond the bare schema types and titles.

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 clearly states the action ('Create or configure a Blueprint Custom Event as an RPC') with a specific resource and purpose. It distinguishes itself from sibling tools like net_configure_rpc and add_custom_event by focusing on RPC configuration of a specific function, though it does not explicitly contrast with those alternatives.

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 given on when to use this tool versus the many related networking tools (e.g., net_configure_rpc, net_create_rpc_event). The example implies a use case but does not state exclusions or conditions that would select this tool over siblings. The description relies on the name and schema to convey intent.

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