Skip to main content
Glama

add_clamp_node

Add a Clamp node in an Unreal Blueprint to restrict a value between specified minimum and maximum limits.

Instructions

Add a 'Clamp' node to constrain a value within a range.

Used throughout the book (Ch.6, 8): Clamps health, stamina, ammo values between min and max so they never exceed valid ranges.

Args: blueprint_name: Blueprint name operand_type: "Float" or "Integer" min_value: Minimum allowed value max_value: Maximum allowed value node_position: Optional [X, Y] graph position

KB: see knowledge_base/01_BLUEPRINT_FUNDAMENTALS.md#overview Example: add_clamp_node(blueprint_name="/Game/MCP_Test/BP_Example")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_valueNo
min_valueNo
operand_typeNoFloat
node_positionNo
blueprint_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description makes the mutation explicit ('Add a Clamp node') and discloses the optional graph-position placement. It doesn't mention non-behaviors like auto-connecting or compiling, but nothing hidden or surprising remains for a node-creation operation.

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 compact and each section earns its place: purpose, usage context, parameter meanings, KB pointer, and a concrete example. It is front-loaded and scannable.

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?

An agent has everything needed to call it correctly: all parameter semantics, a required path format example, and a KB reference. An output schema exists, so return-value details don't need to be in the description.

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?

Every parameter gets a plain-language explanation in the Args block, including the allowed operand_type values and the optional [X,Y] node_position. Since schema descriptions are absent, this fully compensates and adds real meaning.

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 names the exact node ('Clamp'), the action (add/constrain), and the domain (value range clamping). This separates it from sibling add_* node tools even before opening the schema.

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 gives concrete use context (clamp health/stamina/ammo between min and max) and a chapter reference, which tells an agent when this tool is relevant. It doesn't name alternatives or exclusion conditions, so it stops short of a 5.

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