What can you do with this server?

This server enables AI agents to automate Unreal Engine 5 through 72+ tools covering the entire game development lifecycle. * Project & Engine Management: List engine installations and templates; create, find, and inspect projects; enable/disable plugins; configure project settings. * Editor Control: Open/close/monitor the editor; save levels; read logs; execute Python and console commands. * C++ Development: Generate C++ classes with properties and replication boilerplate; perform full builds or Live Coding; manage build processes. * Game Packaging: Start and monitor the packaging process into standalone executables. * Asset Management: Import 3D models (glTF, FBX) and audio; list, search, delete, rename, duplicate assets; create folders; download CC0 assets from Poly Haven, ambientCG, Kenney, and URLs. * Level Building: Create/open levels; spawn, transform, attach/detach, and delete actors; list actors and components; set properties. * Blueprints: Create Blueprints from any parent class; add components and variables; set class defaults; compile; reparent to C++ classes. * Materials: Create PBR material graphs and material instances; assign materials to actors. * Audio: Import sounds; create MetaSound sources and Sound Cues. * Networking: Configure Blueprint replication; set up multi-client Play In Editor sessions; start/stop PIE. * Rendering: Capture editor viewport screenshots; render Level Sequences via Movie Render Queue. * Camera & Viewport: Get/set camera position; focus on actors; capture screenshots for visual feedback.

Which integrations are available for this server?

Allows AI agents to drive Unreal Engine 5, including creating projects, importing assets, building levels and Blueprints, configuring replication, compiling C++, running Play In Editor, and packaging the game.

How do I use Unreal Engine MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Unreal Engine MCP Create a new third-person project with starter content" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Unreal Engine MCP

by FFZackFair92

Overview Schema Source Related Servers Discussions Admin

Python

Local

Unreal Engine MCP

Python License: MIT

Italiano

An MCP server that lets an AI agent drive Unreal Engine 5: create projects, import assets, build levels and Blueprints, configure replication, compile C++, run Play In Editor and package the game.

No C++ plugin to compile. It uses two plugins that already ship with the engine — Python Editor Script Plugin and Remote Control API — and talks to the editor over local HTTP.

                    ┌─ LOCAL layer  ── processes + public HTTP
                    │    UnrealEditor.exe, UnrealBuildTool, RunUAT, asset downloads
Agent ──stdio──▶ MCP │
                    └─ EDITOR layer ── HTTP :30010 (Remote Control API)
                         └─ ExecutePythonCommandEx → running editor

The local layer exists because the Remote Control API only works against an editor that is already running: creating a project, launching it, compiling and packaging all have to happen at the process level.

162 tools and 5 resources — full reference
435 tests, none of which need Unreal installed
Unreal automation notes — the API traps found the hard way

Requirements

Unreal Engine 5.0 or newer (developed and tested against 5.8 — see version compatibility)
Python 3.10+
Windows, Linux or macOS. Development happens on Windows, which is where the local layer is exercised most; the Linux and macOS paths (Build.sh, RunUAT.sh, pgrep) are implemented and covered by CI, but less battle-tested. The editor layer is platform-neutral.

Unreal version compatibility

The server detects what the running engine supports at startup of each call — ue_status reports it under capabilities — and fails with an explicit message instead of a cryptic Python error when a feature is missing:

Feature	Works on
Actors, levels, spawn/transform, PIE, project settings, build & packaging, Sound Cues	5.0+
Blueprint creation, components (`SubobjectDataSubsystem`), reparenting	5.0+
Materials, material instances, screenshots, C++ class generation	5.0+
glTF/`.glb` import via Interchange	5.2+ (earlier: enable the glTF Importer plugin; the tool tells you when that is the problem)
Blueprint member variables + per-variable replication (`ue_add_variable`)	5.4+ (no Python API before that — the tool says so explicitly)
MetaSounds	any 5.x with the MetaSound plugin enabled

Custom engine builds are fine: detection is based on the actual Python API surface, not on the version number.

Related MCP server: Hayba

Install

pip install unreal-engine-mcp

Or run it without installing anything, if you have uv:

uvx unreal-engine-mcp

Or from source, to hack on it:

git clone https://github.com/FFZackFair92/unreal-engine-mcp.git
cd unreal-engine-mcp
pip install -e .

Connect it to your client

The server speaks standard MCP over stdio, so any MCP-capable client works — Claude, Cursor, VS Code, Windsurf, OpenAI Codex, custom agents. The command is always the same; only where the config lives differs.

Claude Desktop / Cowork

Settings ▸ Developer ▸ Edit Config, then add to mcpServers:

{
  "mcpServers": {
    "unreal-mcp": {
      "command": "python",
      "args": ["-m", "unreal_mcp.server"],
      "env": { "UE_MCP_PORT": "30010" }
    }
  }
}

Claude Code

claude mcp add unreal-mcp -- python -m unreal_mcp.server

Cursor

~/.cursor/mcp.json (global) or .cursor/mcp.json in the project — same JSON shape as Claude Desktop (mcpServers root key).

VS Code (Copilot agent mode)

.vscode/mcp.json — note the root key is servers here:

{
  "servers": {
    "unreal-mcp": { "type": "stdio", "command": "python", "args": ["-m", "unreal_mcp.server"] }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json — same mcpServers shape as Claude Desktop.

OpenAI Codex CLI

~/.codex/config.toml:

[mcp_servers.unreal-mcp]
command = "python"
args = ["-m", "unreal_mcp.server"]

OpenAI Agents SDK (custom agents)

from agents.mcp import MCPServerStdio

unreal = MCPServerStdio(params={"command": "python", "args": ["-m", "unreal_mcp.server"]})

Restart the client completely after editing its config. In every case python must be the interpreter where you ran pip install -e . — use an absolute path if in doubt.

Note: ChatGPT's connector UI only accepts remote MCP servers. This server is stdio/local by design (it drives processes on your machine), so use it from clients with stdio support — the ones above — or wrap it with an MCP proxy if you really need HTTP.

Set up the Unreal side

Starter project — zero setup, zero builds

Copy StarterProject/ wherever you like and open the .uproject with any UE 5.0+: plugins enabled, security config in place, web server auto-started. Being Blueprint-only with engine plugins, there is nothing to compile — unlike starters that bundle a C++ plugin.

New project — nothing to do by hand

Ask the agent to run ue_project_create. It writes the .uproject with the required plugins enabled, the security flags Remote Control needs, and an init_unreal.py that starts the web server on every editor launch.

ue_engine_list  →  ue_project_create  →  ue_editor_open  →  ue_status

Existing project — two steps

Enable the plugin: Edit ▸ Plugins → Python Editor Script Plugin. Restart when prompted.
Tick one box: Edit ▸ Project Settings → search Python → check Enable Remote Execution.

That is the whole setup. The server discovers the editor over the engine's own Python remote execution channel — no config file, no HTTP port.

The native channel finds the editor with a UDP multicast ping on the local machine. That is the easy path, but it does not cross a subnet, and some corporate networks and VPN adapters swallow multicast entirely. In those cases — or with the editor on another machine — use the Remote Control API instead, with UE_MCP_TRANSPORT=remotecontrol.

Enable the plugins: Python Editor Script Plugin and Remote Control API. Restart when prompted.
Allow remote Python. Create Config/DefaultRemoteControl.ini:
```
[/Script/RemoteControlCommon.RemoteControlSettings]
bAutoStartWebServer=True
bAutoStartWebSocketServer=True
RemoteControlHttpServerPort=30010
bEnableRemotePythonExecution=True
bAllowAnyRemoteFunctionCall=False
+CustomAllowedRemoteFunctionCalls=(ClassPath="/Script/PythonScriptPlugin.PythonScriptLibrary")
bAllowConsoleCommandRemoteExecution=False
```
These are two separate gates — one unlocks the object, the other the function call — and they fail with different errors. DefaultEngine.ini is the wrong file: URemoteControlSettings is declared UCLASS(config = RemoteControl). Restart the editor.
On engines that predate some of these keys they are simply ignored — older versions did not gate those calls in the first place.
The server listens on 127.0.0.1 only, so remote Python execution is not reachable from outside the machine.
What the server can do once connected, and how to open it up safely if you really need to reach the editor from another machine, is in SECURITY.md.
bAllowConsoleCommandRemoteExecution stays off. It enables ExecuteConsoleCommand through the web API, which this server never calls — the console commands it does need (LiveCoding.Compile, WebControl.StartServer, HighResShot) are issued from inside Python via unreal.SystemLibrary.execute_console_command and do not go through that gate. Older versions of this project set it to True; existing projects can flip it to False without losing anything.
Check it: open http://127.0.0.1:30010/remote/info in a browser. JSON back means you are connected.

Which transport is in use

ue_status reports it. By default (UE_MCP_TRANSPORT=auto) the server tries the native channel first and falls back to HTTP, so a project set up either way just works. Set pyremote or remotecontrol to pin one.

What it can do

Area	Highlights
Projects	Find engine installs, create projects from a spec, manage plugins
Editor lifecycle	Open (waiting for the bridge), status, clean shutdown
C++	Generate compilable classes with the boilerplate written correctly, then reparent Blueprints onto them
Build	Compile C++ in the background; `ue_live_compile` recompiles with the editor open via Live Coding
Package	`RunUAT BuildCookRun` → standalone executable, with phase reporting
Assets	Import `.glb`/`.gltf`/`.fbx`/`.wav`, list and search the Content Browser
Levels	Create and open levels, spawn/move/delete actors, batch spawn, set properties on placed actors
Materials	Build material graphs, wire PBR textures, material instances, assign to actors
Blueprints	Create, add components, typed variables with replication, class defaults, reparent, compile
Networking	Replication flags, multi-client PIE, project settings
Audio	Import wavs, MetaSound sources, Sound Cues
Free assets	Poly Haven, ambientCG and Kenney downloads (all CC0), plus any direct URL
Feedback	`ue_screenshot` captures the viewport, so the agent can see what it built

Full parameter list in docs/TOOLS.md.

Reaching the server from claude.ai on the web

Local clients launch the server over stdio and need nothing else. claude.ai runs on Anthropic's machines, which cannot reach yours, so it needs an HTTP endpoint and a tunnel of your own in front of it:

python -m unreal_mcp.server --http

That binds 127.0.0.1:8000; the URL to paste into Settings → Connectors → Add custom connector is the tunnel's public address with /mcp appended.

A tunnel publishes a server exposing ue_exec_python to the internet — arbitrary code execution inside your editor. Keep it up for the length of the test and don't share it, or put Cloudflare Access (or equivalent) in front of the hostname before leaving it running.

Authoring Blueprint graphs

Blueprint node graphs are scriptable on UE 5.8+. Start with ue_bp_graph_info, which returns the node object names every other tool takes as a key, then ue_bp_add_call_function, ue_bp_add_branch, ue_bp_add_custom_event, ue_bp_add_variable_node, or ue_bp_add_node_by_name with ue_bp_list_palette for anything else. Wire with ue_bp_connect, set literals with ue_bp_set_pin_value. Event nodes are addressed by the alias event:ReceiveBeginPlay.

EdGraph.Nodes is still protected and pins are still unexposed — the route is unreal.BlueprintGraphEditor, which edits the graph from the outside the way the editor does. Details in docs/UNREAL-NOTES.md.

Check ue_status → capabilities.blueprint_graph_authoring first. On an engine without that API the tools fail with an explanation, and the older route still applies: put the logic in a C++ parent class. The Blueprint stays the container for components and tweakable values; the behaviour is inherited.

ue_cpp_class_create      # writes the class, and the whole C++ module if the
                         # project was Blueprint-only
ue_editor_close
ue_build_start           # poll ue_build_status until running=false
ue_editor_open
ue_reparent_blueprint    # the Blueprint now inherits the behaviour

Blueprint variables whose names match a UPROPERTY on the new parent are absorbed by it, so values set in the editor survive the move. Functions marked BlueprintCallable become callable from the graph — an agent can build the vocabulary the designer then wires up by hand.

Material graphs are fully scriptable too: ue_create_material really does create and connect the nodes.

Other limits

Compiling C++ needs the editor closed, unless the change only touches function bodies — then ue_live_compile works with it open.
Packaging always needs the editor closed: the build step rewrites the DLLs the editor holds in memory.
Feature availability varies with the engine version — see the compatibility table; ue_status reports what the running engine supports.
Fab/Marketplace content has no public API. Those tools shell out to the community client legendary, or install a folder/zip you already downloaded yourself (preset_fab_install).

Configuration

Variable	Default	Purpose
`UE_MCP_TRANSPORT`	`auto`	`auto`, `pyremote` (native channel) or `remotecontrol` (HTTP)
`UE_MCP_HOST` / `UE_MCP_PORT`	`127.0.0.1` / `30010`	Remote Control endpoint
`UE_MCP_TIMEOUT`	`180`	Per-call timeout in seconds
`UE_MCP_PROJECT`	—	Which project to drive when several editors are open
`UE_MCP_MULTICAST_GROUP` / `_PORT`	`239.0.0.1` / `6766`	Discovery endpoint for the native channel
`UE_MCP_MULTICAST_BIND`	`0.0.0.0`	Interface the discovery ping goes out of — set it when several adapters (VPN, WSL, Hyper-V) hide the editor
`UE_MCP_MULTICAST_TTL`	`0`	Keeps discovery on this machine. Raising it exposes arbitrary code execution to the network
`UE_MCP_ENGINE_DIRS`	—	Extra folders to search for engine installs
`UE_MCP_LIBRARY`	`~/UnrealAssetLibrary`	Where downloaded assets land
`UE_MCP_MAX_DOWNLOAD`	4 GiB	Per-file download cap
`UE_MCP_HTTP`	—	`1` serves over HTTP instead of stdio, same as `--http`. Distinct from `UE_MCP_TRANSPORT`, which picks the channel to the editor
`UE_MCP_HTTP_PORT`	`8000`	Port the HTTP server listens on. Distinct from `UE_MCP_PORT`, which is Remote Control's
`UE_MCP_ALLOWED_HOSTS`	`*`	Comma-separated `Host` allowlist in HTTP mode. The default accepts any host because a tunnel's public hostname isn't knowable in advance; set it to lock the server to a known domain

If the engine sits somewhere unusual, you can also drop an mcp_engine.txt next to the .uproject containing its path, or pass engine_root explicitly.

Development

The test suite runs without Unreal installed: tests/fake_unreal.py stands in for the unreal module and tests/fake_server.py emulates the Remote Control API while actually executing the generated snippets — so the whole chain tool → snippet → harness → result is covered.

pip install -e ".[dev]"
pytest -q

Adding a tool: a reusable helper in src/unreal_mcp/ue_side.py (editor side), an @mcp.tool() function in server.py, and a test in tests/. See CONTRIBUTING.md for the conventions worth knowing.

ue_side.py is installed into the running editor as a module and keyed by a hash of its source, so editor-side changes take effect on the next call without restarting the server — and every other call is just a small snippet that imports it. Changes to server.py or local.py need a client restart.

Troubleshooting

Symptom	Cause
`No response from http://127.0.0.1:30010`	Editor closed, or the web server never started → console: `WebControl.StartServer`
`Object Default__PythonScriptLibrary cannot be accessed remotely`	Missing `bEnableRemotePythonExecution` in `DefaultRemoteControl.ini`
`Executing function 'ExecutePythonCommandEx' is not allowed`	Missing `CustomAllowedRemoteFunctionCalls` entry
`404 on /remote/object/call`	Remote Control API plugin not enabled
`NameError: name 'unreal' is not defined`	Python Editor Script Plugin not enabled
`Unable to build while Live Coding is active`	`LiveCodingConsole.exe` outlives the editor — kill it (the build tools do this automatically)
`No Unreal Engine installation found`	Set `UE_MCP_ENGINE_DIRS`, add `mcp_engine.txt`, or pass `engine_root`
`ModuleNotFoundError: No module named 'mcp.server.fastmcp'`	`mcp` 2.x is installed; this server targets the 1.x line. `pip install "mcp<2"` — reinstalling the package does it for you

Licence

MIT — see LICENSE.

References

Available Tools

163 tools

preset_download_ambientcgB

Scarica ed estrae un asset ambientCG (CC0).

Args: asset_id: es. "PavingStones036". variant: es. "1K-JPG", "2K-JPG", "4K-PNG".

ParametersJSON Schema

Name	Required	Default
`variant`	No	2K-JPG
`asset_id`	Yes
`destination`	No

TDQS

B3.3/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 disclose behavioral traits. It mentions downloading and extracting but omits critical details like network dependency, file overwrite behavior, storage location, or time expectations. This is insufficient for a mutation tool.

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 brief and front-loaded, with a clear breakdown of arguments. It avoids unnecessary words, though the formatting of arg descriptions could be more structured. Overall efficient.

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

Completeness2/5

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

For a tool with 3 parameters, no output schema, and no annotations, the description leaves significant gaps. It does not explain the return value, side effects (e.g., file creation), or the role of the destination parameter. The tool's complexity requires more detail.

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 coverage is 0%, so the description adds value by providing examples for asset_id and variant. However, it completely ignores the destination parameter, leaving its purpose unclear. The examples are helpful but not comprehensive.

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 uses specific verbs 'Scarica ed estrae' (download and extract) and identifies the resource as ambientCG assets, clearly distinguishing it from siblings like preset_download_url (URL-based) and preset_extract_archive (archive extraction).

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

Usage Guidelines3/5

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

The description implies usage for ambientCG assets but provides no explicit guidance on when to use this tool versus alternatives like preset_search_ambientcg or preset_download_polyhaven. No exclusions or prerequisites are given.

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

preset_download_kenneyB

Scarica ed estrae un pack Kenney (CC0) risolvendo il link dalla pagina.

Args: slug: ultima parte dell'URL, es. "mini-characters-1" per kenney.nl/assets/mini-characters-1.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes
`destination`	No

TDQS

B3.1/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 cover behavioral details. It mentions resolving the link from the page but does not disclose side effects, permissions, or error scenarios. The behavioral disclosure is minimal.

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

Conciseness3/5

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

The description is short but includes an Args section. However, it is in Italian, which may reduce clarity for some users. It is reasonably concise but could be more structured.

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

Completeness3/5

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

The tool is simple, and the description covers the core functionality and slug usage. Missing details on the destination parameter and potential side effects make it slightly incomplete for a tool with no output schema or annotations.

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 0%, requiring the description to explain parameters. The slug parameter is explained with an example, adding meaning beyond the schema. However, the destination parameter is not described, leaving a gap.

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 tool downloads and extracts a Kenney pack by resolving the link from the page. It specifies the resource (Kenney CC0 pack) and the action (download and extract), distinguishing it from sibling tools like preset_download_url which handle generic URLs.

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

Usage Guidelines3/5

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

The description implies usage for downloading Kenney packs but does not explicitly state when to use or not use this tool versus alternatives like preset_download_polyhaven. No exclusion criteria or prerequisites are mentioned.

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

preset_download_polyhavenA

Scarica un asset Poly Haven (CC0) nella libreria locale.

Args: asset_id: id dell'asset, es. "brick_wall_02". resolution: "1k" | "2k" | "4k" | "8k". formats: ["jpg"] per texture, ["gltf"] per modelli, ["hdr"] per HDRI. destination: cartella alternativa alla libreria.

ParametersJSON Schema

Name	Required	Default
`formats`	No
`asset_id`	Yes
`resolution`	No	2k
`destination`	No

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the asset is downloaded to a local library and specifies parameter options, but it does not mention side effects (e.g., overwriting, errors on invalid IDs), rate limits, or any output details.

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 concise and front-loaded with the main purpose. The Args section could be formatted as bullet points for quicker scanning, but every sentence is necessary and there is no redundancy.

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 4 parameters, no output schema, and no annotations, the description covers all parameters with allowed values. It lacks information on return values (e.g., success/failure) and error handling, but provides sufficient detail for correct invocation.

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?

Schema description coverage is 0%, so the description compensates fully. It explains each parameter: asset_id with an example, resolution with enumerated values (1k, 2k, 4k, 8k), formats with type-specific examples (jpg for texture, gltf for models, hdr for HDRI), and destination as an alternative folder. This adds critical meaning beyond the bare schema.

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 states the specific action: 'Scarica un asset Poly Haven (CC0) nella libreria locale' (Download a Poly Haven asset into the local library). It includes a verb (download) and a resource (Poly Haven asset), clearly distinguishing it from siblings like preset_download_ambientcg or preset_download_kenney.

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

Usage Guidelines3/5

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

The description implies usage for Poly Haven assets but does not explicitly state when to use this tool versus other download tools (e.g., for different sources) or search tools. No exclusions or alternative suggestions are provided.

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

preset_download_urlB

Scarica un file da un URL diretto (zip, glb, fbx, wav) nella libreria locale.

Se è un archivio zip/tar e extract=True, lo estrae subito.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`extract`	No
`filename`	No
`destination`	No

TDQS

B3.3/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 carry the full burden of behavioral disclosure. It mentions download location and extraction, but does not address side effects like overwriting, size limits, network usage, or caching. This is insufficient for a tool with no annotations.

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 two well-structured sentences with no filler. The main purpose is front-loaded, and the extraction condition is clearly stated. Every sentence serves a purpose.

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

Completeness3/5

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

Given the tool has 4 parameters, no output schema, and no annotations, the description covers the main behavior and two parameters partially. It misses explanations for 'filename' and 'destination', and does not fully specify the behavior of the tool. Sibling tools like preset_extract_archive are related but not cross-referenced.

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 0%, so the description must add meaning. It explains the 'url' parameter (direct URL, file types) and 'extract' (default true, extracts archives). However, 'filename' and 'destination' are left unexplained, leaving gaps despite partial compensation.

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 tool downloads a file from a direct URL into the local library, listing supported file types (zip, glb, fbx, wav). It distinguishes from siblings like preset_library_list and preset_extract_archive by focusing on URL-based downloads, but does not explicitly differentiate from other preset_download_* tools.

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

Usage Guidelines3/5

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

The description implies usage for direct URL downloads and explains extraction behavior when extract=True. However, it lacks guidance on when not to use this tool or mention alternatives like downloading from specific sources (e.g., preset_download_polyhaven).

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

preset_extract_archiveB

Estrae un archivio zip/tar già presente sul disco (i .rar non sono supportati).

ParametersJSON Schema

Name	Required	Description	Default
`archive`	Yes
`destination`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions the action and format constraint. It fails to disclose side effects (e.g., whether the archive is deleted, overwriting behavior) or any other behavioral traits.

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 a single, clear sentence with no unnecessary words, making it highly concise and front-loaded with key information.

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

Completeness2/5

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

Given the lack of annotations and output schema, and the presence of two parameters, the description is too brief. It does not explain the destination parameter, return values, or how the extraction behaves, leaving significant gaps.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the parameters 'archive' or 'destination', leaving the agent without guidance on what values to provide.

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 clearly states the action (extract) and the resource (zip/tar archive), and includes an explicit unsupported format (.rar), distinguishing it from sibling tools like preset_download_*.

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 specifies that the archive must already be on disk and that .rar is not supported, providing clear context for when to use the tool. However, no explicit alternatives or exclusions are given.

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

preset_fab_downloadB

Scarica un asset del vault Epic tramite legendary.

Args: app_name: identificativo restituito da preset_fab_list_vault.

ParametersJSON Schema

Name	Required	Description	Default
`app_name`	Yes
`destination`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description lacks details on side effects, authentication needs, whether downloads are synchronous, or any constraints. It only states the basic action.

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 very short and to the point, with the purpose in the first sentence. However, it could be improved by also briefly explaining the destination parameter.

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

Completeness2/5

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

Given the tool's role in a workflow (downloading from vault) and no output schema, the description lacks details on expected outcomes, error cases, and how destination affects behavior. It only covers the bare minimum.

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

Parameters2/5

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

The description explains the app_name parameter (identifier from preset_fab_list_vault) but does not mention the destination parameter, which is optional with default null. With 0% schema coverage, the description should cover both parameters.

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 explicitly states the tool downloads an asset from the Epic vault using 'legendary', with a clear verb and resource. It differentiates from sibling tools like preset_fab_list_vault.

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

Usage Guidelines3/5

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

The description implies the tool should be used after preset_fab_list_vault by noting that app_name comes from that tool, but it doesn't explicitly state when to use this tool versus alternatives like preset_download_url.

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

preset_fab_list_vaultA

Elenca il contenuto Unreal acquistato sull'account Epic (Fab/Marketplace).

Non esiste un'API pubblica: serve il client community legendary (pip install legendary-gl + legendary auth). Senza di esso il tool spiega come procedere dall'Epic Games Launcher.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It transparently states that no public API exists and describes the dependency on the legendary client or manual steps from Epic Games Launcher, which is adequate for a read-only listing 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 highly concise, consisting of two short sentences that front-load the core purpose and immediately follow with critical setup information. Every sentence adds value without redundancy.

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?

Given no parameters and no output schema, the description fully covers the tool's purpose and setup requirements. It is complete for a listing tool with external dependencies, leaving no obvious gaps.

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?

The input schema has no parameters, so the description adds no parameter details. However, the baseline for zero parameters is 4, and the description provides useful context about the tool's operation and prerequisites.

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 tool lists purchased Unreal content from the Epic account (Fab/Marketplace). The verb 'elenca' (list) and resource are specific, and it distinguishes from sibling 'preset_fab_download' which handles downloads, though not explicitly mentioned.

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

Usage Guidelines3/5

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

The description explains the prerequisite (legendary client) and provides installation instructions, but does not explicitly state when to use this tool versus alternatives like 'preset_fab_download' or other preset tools. Usage context is implied but not differentiated.

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

preset_library_listA

Elenca i file già scaricati nella libreria locale (default: ~/UnrealAssetLibrary).

I percorsi restituiti si passano direttamente a ue_import_assets.

ParametersJSON Schema

Name	Required	Description	Default
`subfolder`	No
`extensions`	No

TDQS

A3.6/5.0

Behavior3/5

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

Since no annotations are provided, the description carries full burden. It states the tool lists files, implying a read-only operation, but does not explicitly confirm no side effects, destructive actions, or other behavioral traits. For a simple list operation, this is adequate but not thorough.

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 two sentences long, front-loading the purpose and adding a practical usage hint. No redundant or unnecessary information is present.

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

Completeness3/5

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

The description covers the core purpose and output usage, but lacks explanation of parameters and does not provide examples or edge cases. Given the low schema coverage, more detail on parameter behavior would improve completeness.

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

Parameters1/5

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

The schema has two optional parameters (subfolder, extensions) with 0% description coverage. The description does not explain what these parameters do or how they affect the listing. It only mentions the default library path, failing to add meaning beyond the schema.

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 clearly states the tool lists downloaded files in the local library and specifies the default path. It also explains that the returned paths are intended for use with ue_import_assets, distinguishing it from download or other listing tools among siblings.

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 implicitly guides usage by stating that returned paths can be fed to ue_import_assets, making it clear when to use this tool (when needing to import previously downloaded assets). However, it does not explicitly state when not to use it or mention alternatives, but the context with siblings is sufficiently distinct.

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

preset_search_ambientcgB

Cerca materiali/HDRI/modelli CC0 su ambientCG.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	No
`asset_type`	No	Material

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral traits. It lacks any disclosure about authentication, rate limits, return format, or behavior on missing results. Only basic search functionality is described.

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?

Description is brief (two sentences) and front-loaded with the main purpose. It efficiently communicates the tool's function and key parameters, though it could include more detail without becoming verbose.

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

Completeness2/5

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

Given no output schema, no annotations, and 3 parameters, the description is incomplete. It omits return format, pagination, error handling, and any prerequisites. The tool is simple but description lacks contextual details needed for robust use.

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 0%, so description must compensate. It explains 'query' with an example ('concrete') and lists allowed values for 'asset_type'. However, 'limit' parameter is not described, only its default is in schema. Description adds moderate value.

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?

Description clearly states the tool searches for CC0 materials/HDRI/models on ambientCG. The verb 'cerca' (search) and resource 'ambientCG' are specific, and it distinguishes from siblings like preset_search_polyhaven and preset_download_ambientcg.

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 explicit guidance on when to use this tool vs alternatives. The description implies its domain (ambientCG) but does not mention when-not-to-use or alternative tools for other sources.

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

preset_search_polyhavenA

Cerca asset CC0 su Poly Haven.

Args: asset_type: "hdris" | "textures" | "models". categories: filtri, es. ["brick"], ["outdoor"]. limit: massimo di risultati.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`asset_type`	No	textures
`categories`	No

TDQS

A3.7/5.0

Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits such as authentication, rate limits, or what happens with invalid inputs. It only states the basic purpose.

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 very short and front-loaded: two lines plus an Args section. Every sentence is necessary and no extraneous information exists.

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

Completeness3/5

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

Given no output schema and no annotations, the description lacks details on search behavior, sorting, pagination, or error handling. However, for a simple search tool with 3 parameters, it is minimally adequate.

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?

The schema coverage is 0%, so the description compensates by explaining asset_type values (hdris, textures, models), categories as filters with examples, and limit as max results. This adds meaning beyond the schema defaults.

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 clearly states the tool searches CC0 assets on Poly Haven, distinguishing it from siblings like preset_search_ambientcg and preset_download_polyhaven.

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

Usage Guidelines3/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. Usage is implied by the name and siblings, but no when-not-to or prerequisite information is given.

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

ue_actor_hierarchyB

Albero padre/figli degli attori del livello.

Args: label: se indicato, parte da quell'attore invece che dalle radici.

ParametersJSON Schema

Name	Required	Description	Default
`label`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/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 disclose behavioral traits. It only states the tool returns a hierarchy, but does not mention if it is read-only, recursive, how the tree is structured, or any side effects. This is insufficient for a tool with no annotational safety hints.

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 concise with two sentences covering purpose and parameter guidance. No redundant information. However, it is in Italian, which may be less accessible for English-centric agents, slightly reducing effectiveness.

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

Completeness3/5

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

The tool is simple with one optional parameter and an output schema exists, so the description need not detail return values. However, it omits behavioral context (e.g., whether the tree includes all actors or only spawned ones, depth limit). Adequate but could be more complete.

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?

The single parameter 'label' is described as 'se indicato, parte da quell'attore invece che dalle radici' (if provided, starts from that actor instead of roots). This adds clear meaning beyond the schema, which only defines type and default. Schema description coverage is 0%, so the description compensates well.

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 'Albero padre/figli degli attori del livello' (parent/child tree of level actors), which clearly indicates the tool retrieves the actor hierarchy. It distinguishes from sibling tools like ue_list_actors (flat list) and ue_spawn_actor, but lacks an explicit verb like 'get' or 'list', slightly reducing clarity.

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?

The description explains the label parameter for specifying a start actor, but provides no guidance on when to use this tool versus alternatives (e.g., ue_list_actors). No explicit when-to-use or when-not-to-use context is given.

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

ue_add_componentA

Aggiunge un componente a un Blueprint e lo ricompila.

Args: blueprint_path: es. "/Game/MyGame/Blueprints/BP_Door". component_class: es. "StaticMeshComponent", "BoxComponent", "PointLightComponent". name: nome del componente nel Blueprint.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`blueprint_path`	Yes
`component_class`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions adding and recompiling. It fails to disclose prerequisites (e.g., blueprint must be open), side effects, or failure modes.

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 brief, front-loaded with the main action, and structured with Args. No unnecessary sentences.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description lacks important context such as prerequisites, return values, and potential delays due to recompilation.

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 coverage is 0%, but the description adds valuable examples for blueprint_path and component_class (e.g., 'StaticMeshComponent'), and explains that 'name' is the component's name in the blueprint, which enhances understanding beyond the schema.

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 clearly states it adds a component to a Blueprint and recompiles it, using a specific verb and resource. It distinguishes from sibling tools like ue_create_blueprint or ue_add_variable.

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

Usage Guidelines3/5

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

The description implies usage for adding components to blueprints but does not provide explicit guidance on when to use this tool versus alternatives like ue_add_variable or ue_compile_blueprint.

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

ue_add_variableA

Aggiunge una variabile membro a un Blueprint e ricompila. Richiede UE 5.4+ (l'API Python per le variabili non esiste nei motori precedenti; ue_status riporta in capabilities cosa supporta il motore corrente).

Args: blueprint_path: path del Blueprint. var_name: nome variabile, es. "OccupiedBy". var_type: bool | int | int64 | float | string | name | text | struct | object | class. sub_type: per struct ("Vector", "Rotator", "Transform", "LinearColor") o per object/class il nome della classe ("Actor", "PlayerState"). replicated: marca la variabile come replicata (networking). instance_editable: esposta e modificabile sulle istanze nel livello. default_value: valore di default scritto nei Class Defaults (solo tipi semplici).

ParametersJSON Schema

Name	Required	Default
`sub_type`	No
`var_name`	Yes
`var_type`	No	float
`replicated`	No
`default_value`	No
`blueprint_path`	Yes
`instance_editable`	No

TDQS

A4/5.0

Behavior2/5

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

The description discloses that the tool recompiles the blueprint and requires a specific engine version, but for a mutation tool with no annotations, it lacks details on side effects (e.g., saving, breaking references) and error conditions. This leaves the agent without full understanding of behavioral implications.

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 concise with two well-structured paragraphs: one for purpose/requirement, one for parameter explanations. Every sentence adds value, and key info is front-loaded.

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

Completeness3/5

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

The description covers inputs and requirements well but lacks output schema information and error handling. For a tool with 7 parameters and no annotations, it is adequate but not fully complete.

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 description adds significant value beyond the schema by explaining each parameter with examples and clarifying sub_type usage for structs/objects and class names. Given 0% schema description coverage, this fully compensates.

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 clearly states the tool adds a member variable to a Blueprint and recompiles it, using specific action verbs and resource. It distinguishes from sibling tools like ue_create_blueprint or ue_add_component by specifying its unique function.

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 includes a requirement (UE 5.4+) and suggests checking ue_status for capabilities, providing context for when to use. However, it does not explicitly state when not to use or provide direct alternatives, though no similar sibling exists.

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

ue_anim_sequence_infoB

Durata, notify, sync marker e curve di un AnimSequence.

Args: anim_path: es. "/Game/MyGame/Characters/Hero/Animations/Idle".

ParametersJSON Schema

Name	Required	Description	Default
`anim_path`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It lists the output data categories, but does not explicitly state that the operation is read-only or describe any side effects, error conditions, or return format. This is a bare minimum.

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 extremely concise, with one line for the data types and one for the argument example. It is front-loaded and contains no fluff.

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

Completeness3/5

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

Given there is no output schema or annotations, the description provides some output details (the four data categories) but lacks deeper context such as return types, whether the asset must exist, or any related info. It is adequate for a simple retriever but not rich.

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?

The only parameter, anim_path, is given a concrete example path, which clarifies the expected format. However, the description doesn't explain the parameter's meaning beyond its name and example, leaving some ambiguity.

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 indicates the tool retrieves duration, notifications, sync markers, and curves from an AnimSequence. It identifies the resource type explicitly, though it lacks an explicit verb like 'get' and doesn't contrast with sibling tools, so a 4 is appropriate.

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 provided on when to use this tool versus other info tools such as ue_sequence_info. There are no exclusions, prerequisites, or alternative recommendations mentioned.

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

ue_assign_materialA

Assegna un materiale a un attore piazzato.

Args: label: etichetta dell'attore nell'Outliner. material_path: es. "/Game/MyGame/Materials/M_Brick". slot: indice dello slot materiale sulla mesh. component: componente su cui scrivere; default il primo MeshComponent.

ParametersJSON Schema

Name	Required	Description	Default
`slot`	No
`label`	Yes
`component`	No
`material_path`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears the full burden. It does not disclose behavioral traits such as required permissions, side effects (e.g., asset modification), or conditions (e.g., actor must have a mesh). Only the basic action is stated.

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 short, combining an Italian title line with English parameter documentation. It is structured but uses two languages, which could be streamlined. Every line adds value without unnecessary verbosity.

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

Completeness3/5

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

The description explains the action and parameters but omits return behavior, error conditions, and prerequisites. Given no output schema or annotations, a bit more context (e.g., 'returns nothing on success') would improve completeness.

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?

The input schema has 0% description coverage, but the tool's description provides clear explanations for all 4 parameters: label (actor label), material_path (path), slot (index with default 0), component (default first MeshComponent). This adds significant meaning beyond the schema's type/title-only fields.

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 clearly states 'Assegna un materiale a un attore piazzato' (assign a material to a placed actor), specifying the verb and resource. It distinguishes from sibling tools like ue_set_actor_property or ue_create_material by being material-specific.

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

Usage Guidelines3/5

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

The description implies usage when a material needs to be assigned to an actor, but provides no explicit guidance on when not to use it or alternatives. No differentiation from other actor manipulation tools.

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

ue_attach_actorA

Aggancia un attore a un altro: muovendo il padre si muove il figlio.

È il modo in cui si compone una scena (le luci a un lampione, le casse su un pallet) invece di lasciare oggetti slegati da riposizionare uno per uno.

Args: child_label: label dell'attore da agganciare. parent_label: label dell'attore padre. socket: nome del socket sul padre, se ne ha. attach_rule: "KEEP_WORLD" (resta dov'è), "KEEP_RELATIVE" o "SNAP_TO_TARGET" (si allinea al padre).

ParametersJSON Schema

Name	Required	Default
`socket`	No
`attach_rule`	No	KEEP_WORLD
`child_label`	Yes
`parent_label`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It explains the basic behavior (moving parent moves child) and the attach_rule parameter, but does not disclose what happens if the child is already attached to another parent, or any error conditions. Partially adequate.

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 concise with two sentences of context and a clear Args list. Every sentence serves a purpose, and the key concept is front-loaded.

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

Completeness3/5

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

Given the tool's complexity and lack of output schema, the description is adequate but incomplete. It does not mention return values, error handling, or prerequisites like whether the actor needs to be in the level. Some gaps remain.

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?

The description adds meaning beyond the schema by explaining socket ('nome del socket sul padre, se ne ha') and listing the three possible values for attach_rule. All four parameters are covered, though schema coverage is technically 0% because the description is separate.

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 clearly states the tool attaches one actor to another, with the concrete example 'moving the parent moves the child'. It also distinguishes from the sibling 'ue_detach_actor' by implication and provides a use case for composing a scene.

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 explains when to use the tool (composing a scene by parenting objects) and contrasts it with leaving objects unlinked. It does not explicitly list when not to use it or mention alternative siblings like 'ue_spawn_actor', but the context is clear.

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

ue_blackboard_add_keyA

Aggiunge una chiave a un Blackboard Data esistente.

ParametersJSON Schema

Name	Required	Default
`key_name`	Yes
`key_type`	No	object
`blackboard_path`	Yes

TDQS

A3.8/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 disclose behavioral traits on its own. It only lists parameters and examples, without mentioning side effects, duplicate key handling, error behavior, or success signaling.

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 front-loaded with the purpose, followed by a cleanly organized Args section. Every sentence and line contributes directly to understanding the tool, with no redundant information.

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

Completeness3/5

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

For a simple 3-parameter mutation tool without annotations or output schema, the description covers parameter semantics well. However, it misses important context such as the requirement that the blackboard already exists, potential failure modes, and what the outcome of adding a key looks like.

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 schema has 0% description coverage, but the description compensates fully by explaining each parameter with concrete examples. It provides an example path for blackboard_path, an example key name, and the full list of allowed key_type values, adding significant meaning beyond the bare schema.

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 clearly states the action: 'Aggiunge una chiave a un Blackboard Data esistente' (adds a key to an existing Blackboard Data). This specific verb-object pairing distinguishes it from sibling tools like ue_create_blackboard, which creates a new blackboard.

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

Usage Guidelines3/5

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

The word 'esistente' implies the blackboard must already exist, providing a subtle prerequisite. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria or mention of related operations like ue_blackboard_info.

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

ue_blackboard_infoA

Elenca le chiavi di un Blackboard Data esistente.

ParametersJSON Schema

Name	Required	Description	Default
`blackboard_path`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It states the tool lists keys of an existing blackboard, implying a read-only operation, but does not disclose return format, error handling, or prerequisites beyond existence. This is minimal but not misleading.

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 one sentence with no unnecessary words, front-loading the action and resource. It is appropriately sized for the tool's simplicity.

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

Completeness3/5

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

The tool is simple with one parameter and no output schema, but the description lacks details that would make it fully self-contained, such as what exactly is returned (key names vs values) or any prerequisites beyond existing blackboard. Given the lack of annotations, a bit more context would be helpful.

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

Parameters2/5

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

The schema has one parameter, blackboard_path, with no description (0% coverage). The tool description does not explain the parameter's format or meaning, relying solely on the parameter name. Given the low schema coverage, the description should have compensated but did not.

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 uses a specific verb 'Elenca' (lists) and a clear resource 'chiavi di un Blackboard Data esistente' (keys of an existing Blackboard Data). This clearly distinguishes it from sibling tools like ue_blackboard_add_key (adds a key) and ue_create_blackboard (creates a blackboard).

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

Usage Guidelines3/5

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

The description implies usage for inspecting an existing blackboard's keys but does not explicitly state when to use it vs alternatives. No exclusions or conditions are mentioned, leaving the when-to-use guidance implicit.

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

ue_bp_add_branchC

Aggiunge un nodo Branch (if/then/else): pin Condition in ingresso, then e else in uscita.

ParametersJSON Schema

Name	Required	Default
`position`	No
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only describes the node's structural pins but does not disclose side effects, error conditions, permissions, or what happens to existing graph connections. This leaves significant ambiguity about the tool's behavior beyond the simple act of adding a node.

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 a single, concise sentence that immediately states the core function and pin layout. It is well-structured for quick scanning, though it sacrifices necessary depth for brevity.

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

Completeness2/5

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

For a tool that adds a node to a Blueprint graph, the description omits critical context: which graph is affected, how position is specified, and any prerequisites like an open blueprint. With no output schema or annotations, the description is the only source of information, and it is insufficient for reliable invocation.

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

Parameters1/5

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

The schema has three parameters with zero description coverage, and the description does not compensate. It never explains blueprint_path, graph_name, or position, and the pin names mentioned (Condition, then, else) refer to node pins, not the tool's parameters. The agent gets no help understanding required arguments or their formats.

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 clearly states the tool adds a Branch node (if/then/else) and specifies the pin layout (Condition input, then/else outputs). This is a specific verb+resource and distinguishes it from sibling tools like ue_bp_add_call_function or ue_bp_add_node_by_name, which add different node types.

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 provided on when to use this tool versus other Blueprint node addition tools. It doesn't mention alternatives, prerequisites, or the target graph context, leaving the agent to infer usage from the tool name alone.

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

ue_bp_add_call_functionA

Aggiunge un nodo di chiamata a funzione e restituisce i suoi pin.

Args: blueprint_path: Blueprint da modificare. function_path: "/Script/.:", per esempio "/Script/Engine.KismetSystemLibrary:PrintString" o "/Script/Engine.GameplayStatics:GetPlayerPawn". graph_name: grafo di destinazione. position: {"x": .., "y": ..} o [x, y], solo estetica.

ParametersJSON Schema

Name	Required	Default
`position`	No
`graph_name`	No	EventGraph
`function_path`	Yes
`blueprint_path`	Yes

TDQS

A4/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 burden of disclosing behavior. It clearly states the mutation (adds a node) and the return value (pins). However, it does not disclose potential failure modes, permissions, or side effects like compilation/saving, leaving some behavioral ambiguity.

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 concise and well-structured: a one-sentence summary front-loaded, followed by an Args list. Every line contributes useful information with no redundant filler.

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

Completeness3/5

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

The description covers the tool's purpose and parameters well, but since there is no output schema, the return value ('restituisce i suoi pin') is under-specified. It does not describe the pin structure, error behavior, or any prerequisites for the target graph. These are notable gaps for an agent correctly using the returned pins.

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?

Schema description coverage is 0%, but the description compensates thoroughly. It explains each parameter: blueprint_path ('BluePrint da modificare'), function_path with format and examples, graph_name ('grafo di destinazione'), and position ('solo estetica'). This adds significant meaning beyond the bare schema.

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 clearly states a specific action: 'Aggiunge un nodo di chiamata a funzione' (adds a function call node) and mentions returning its pins. This distinguishes it from sibling tools like adding a branch, custom event, or function graph, which are named differently.

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

Usage Guidelines3/5

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

Usage context is implied by the description: it is for adding a function call node in a blueprint graph, which differentiates it from adding other node types. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, so the agent must infer the appropriate context.

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

ue_bp_add_custom_eventA

Aggiunge un Custom Event. Solo nei grafi evento: una funzione non può contenerne.

ParametersJSON Schema

Name	Required	Default
`position`	No
`event_name`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the key constraint that custom events can only be added in event graphs and not functions. However, it does not disclose other behavioral aspects such as side effects, required permissions, or error conditions, so it is helpful but not exhaustive.

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 extremely concise, consisting of two short sentences that are front-loaded with the core purpose. Every word earns its place with no redundancy or filler.

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

Completeness2/5

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

For a tool with 4 parameters, no annotations, and no output schema, this description is too minimal. It lacks any explanation of the parameters, expected values, or what happens after adding the event. The description provides the essential scope but leaves significant gaps for an agent to operate correctly.

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

Parameters2/5

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

Schema description coverage is 0%, and the description provides no information about any of the parameters (blueprint_path, event_name, graph_name, position). While the schema shows required fields and defaults, the description fails to compensate for the lack of parameter documentation, leaving the agent to infer meanings from the tool name alone.

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 clearly states the verb 'Aggiunge' (adds) and the resource 'Custom Event', and further specifies that it only applies to event graphs, not functions. This distinguishes it from sibling tools like ue_bp_add_function_graph.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: 'Solo nei grafi evento: una funzione non può contenerne' (Only in event graphs: a function cannot contain one). This provides clear exclusions and context for appropriate usage.

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

ue_bp_add_event_overrideA

Aggiunge (o ritrova) il nodo di un evento ereditato overridabile nell'event graph.

Restituisce il path del nodo e i suoi pin — l'unico modo per riferirsi a quel nodo in seguito con ue_bp_connect_pins, dato che il grafo non elenca i propri nodi via Python.

Args: blueprint_path: es. "/Game/MyGame/BP_Player". event_name: nome dell'evento ereditato, es. "ReceiveBeginPlay", "ReceiveTick", "ReceiveEndPlay". Vedi ue_bp_list_events per i nomi disponibili su questo Blueprint. x: posizione orizzontale del nodo nel grafo (solo visuale). y: posizione verticale del nodo nel grafo (solo visuale).

ParametersJSON Schema

Name	Required	Description	Default
`x`	No
`y`	No
`event_name`	Yes
`blueprint_path`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: it returns the node path and pins, notes this is the only way to reference the node, and clarifies that x/y are purely visual. It also mentions the add-or-find behavior. It doesn't discuss permissions or error cases, but covers essential operational context.

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 moderately sized with a clear first sentence and an Args section. Each sentence adds value, though some detail could be trimmed without losing clarity.

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?

It includes return values, relationship to connect_pins, and references to related tools. In the absence of an output schema, it sufficiently explains the result. Some error scenarios are not covered, but overall it's complete for its complexity.

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?

The description provides meaningful parameter guidance: blueprint_path examples, event_name with examples and a pointer to ue_bp_list_events, and x/y clarified as visual-only. Since schema has no descriptions, this compensates well.

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 clearly states it adds or finds the node of an inherited overridable event in the event graph, with a specific verb and resource. It distinguishes from sibling tools like ue_bp_add_custom_event by focusing on overridable inherited events.

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 explains the tool is needed to obtain a node path for later use with ue_bp_connect_pins, since the graph doesn't list nodes via Python. It also directs users to ue_bp_list_events for available event names, providing clear context. However, it doesn't explicitly name alternative tools or exclusion conditions.

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

ue_bp_add_function_graphA

Crea un grafo funzione vuoto (nodi Entry/Return di default).

I nodi interni non sono raggiungibili da qui: il corpo va scritto a mano nel Blueprint Editor, o lasciato vuoto come slot da riempire in seguito.

Args: blueprint_path: es. "/Game/MyGame/BP_Player". func_name: es. "ApriPorta".

ParametersJSON Schema

Name	Required	Description	Default
`func_name`	Yes
`blueprint_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses key behavioral traits: the graph is created empty with default Entry/Return nodes, and internal nodes cannot be manipulated via this tool, requiring manual editing in the Blueprint Editor. This sets accurate expectations, though it does not mention error cases or side effects on existing functions.

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 concise and well-structured: a one-sentence purpose, a clear limitation note, and an Args block with examples. Every sentence adds value and there is no redundancy or filler.

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?

For a simple two-parameter tool with no annotations or output schema, the description covers the primary purpose, key limitations, and parameter formats. It does not explain return values or prerequisite conditions (e.g., blueprint existence), but these are secondary given the tool's simplicity and the provided context.

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 descriptions are entirely absent (0% coverage), but the description compensates by providing concrete examples for both parameters: blueprint_path as '/Game/MyGame/BP_Player' and func_name as 'ApriPorta'. This clarifies the expected format and content beyond the bare schema properties.

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 clearly states the tool's function with the verb 'Crea' and a specific resource (empty function graph with default Entry/Return nodes). It distinguishes itself from sibling tools that manipulate nodes or events by focusing on graph creation and explicitly noting that internal nodes are not accessible from here.

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 provides explicit context on when to use this tool: to create an empty function graph. It also states a clear exclusion: internal nodes are not reachable, and the body must be written manually or left empty, implying that node-adding operations belong to other tools. However, it does not name specific alternative tools.

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

ue_bp_add_node_by_nameA

Aggiunge un nodo qualunque dalla palette, per "Categoria|Nome".

Ultima spiaggia per i nodi che non hanno un tool dedicato. I nomi sono localizzati come l'editor: su un editor italiano il Branch è "Utilità|ControlloDiFlusso|Ramo", non "Utilities|FlowControl|Branch". Cerca la stringa esatta con ue_bp_list_palette prima di chiamare questo, o usa i tool tipizzati che non hanno il problema.

ParametersJSON Schema

Name	Required	Default
`position`	No
`node_name`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, but the description discloses a critical behavioral trait: node names are localized exactly as in the editor (e.g., Italian Branch is 'Utilità|ControlloDiFlusso|Ramo'). It also cautions that names must be exact and pre-searched, making the tool's failure mode clear. However, it does not mention mutation side effects or permissions, but the verb 'Aggiunge' implies modification.

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 compact and front-loaded: first sentence states the core purpose, followed by usage guidance and warnings. It contains no redundant phrases, though it is slightly longer than necessary due to the example and alternative mention.

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?

Despite no output schema and no annotations, the description is reasonably complete for the tool's purpose. It explains the main parameter, gives usage context, and includes a concrete example of localization pitfalls. It lacks explicit instructions for other parameters, but the tool's scope is narrow and the core usage is well covered.

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 0%, so the description must compensate. It adds critical semantics for node_name (must be 'Category|Name' and localized), but does not describe blueprint_path, graph_name, or position. These remaining params are left to inference, though graph_name has a default and position defaults to null.

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 states a specific verb ('Aggiunge' = adds), the resource ('un nodo qualunque dalla palette' = any node from the palette), and the format ('Categoria|Nome'). It differentiates from siblings by explicitly labeling itself as the 'Ultima spiaggia' (last resort) for nodes without a dedicated tool, and points to typed tools as alternatives.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: use only for nodes lacking a dedicated tool, and avoid if a typed tool exists. It also instructs to search the exact string with ue_bp_list_palette beforehand, and warns that typed tools do not have the localization issue.

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

ue_bp_add_variable_nodeA

Aggiunge un nodo Get o Set per una variabile membro.

La variabile dev'essere già stata creata con ue_add_variable.

Args: blueprint_path: Blueprint da modificare. variable_name: nome della variabile. mode: "get" o "set". graph_name: grafo di destinazione. position: {"x": .., "y": ..} o [x, y]. class_path: per leggere una variabile di un'altra classe; vuoto = questo Blueprint.

ParametersJSON Schema

Name	Required	Default
`mode`	No	get
`position`	No
`class_path`	No
`graph_name`	No	EventGraph
`variable_name`	Yes
`blueprint_path`	Yes

TDQS

A4.1/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 of behavioral disclosure. It adds context about the prerequisite (variable must exist) and the class_path behavior for reading another class's variable. However, it does not disclose potential side effects, error conditions, or whether the blueprint must be saved/recompiled, leaving some ambiguity.

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 well-structured: one introductory sentence plus a bulleted list of arguments with brief explanations. It conveys all necessary information without redundant text, matching the efficiency of high-quality examples.

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

Completeness3/5

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

The tool has 6 parameters, no annotations, and no output schema. The description covers prerequisites and all parameters, but does not explain expected return values or failure modes (e.g., what happens if the variable doesn't exist). This is a notable gap for a mutation tool, preventing a higher score.

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 must compensate. It provides a meaningful line for each of the 6 parameters, including the format for position ({x,y} or [x,y]) and the meaning of class_path (empty = current Blueprint). While some entries are terse, this is strong compensation given the schema gap.

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 'Aggiunge un nodo Get o Set per una variabile membro' (Adds a Get or Set node for a member variable), clearly specifying the verb (adds) and resource (variable node). This is specific enough to distinguish from sibling tools like ue_bp_add_call_function or ue_bp_add_branch, focusing solely on variable access 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 a prerequisite: the variable must already be created via ue_add_variable. It also clarifies the mode parameter ('get' or 'set'), guiding correct invocation. However, it does not explicitly mention when not to use the tool or compare it with alternatives for creating other node types, so it falls short of a full 5.

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

ue_bp_break_pinB

Stacca tutti i collegamenti di un pin, e riporta quanti erano.

ParametersJSON Schema

Name	Required	Default
`pin`	Yes
`node`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses the primary behavior (disconnecting all connections) and the return value (count), which is beyond what annotations provide (none). However, it does not mention reversibility, permissions, or failure modes, so transparency is partial.

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 a single, focused sentence that states the action and outcome with no unnecessary words. It is front-loaded and efficient.

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

Completeness2/5

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

With 4 parameters, no annotations, and no output schema, the description is too sparse. It covers the core action and return count but omits essential context for the parameters, making it incomplete for reliable autonomous use.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only mentions 'pin'. It does not explain the meaning of 'node', 'graph_name', or 'blueprint_path', leaving the agent to infer their purpose. The description fails to compensate for the lack of schema details.

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 clearly states the specific action ('Stacca tutti i collegamenti di un pin') and the result ('riporta quanti erano'), using a specific verb and resource. This distinguishes it from sibling tools like ue_bp_connect or ue_bp_remove_node.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with sibling tools such as ue_bp_connect, leaving the agent without explicit usage direction.

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

ue_bp_connectA

Collega un pin di uscita di un nodo a un pin di ingresso di un altro.

Args: blueprint_path: Blueprint da modificare. from_node: nome oggetto del nodo di partenza, o event:<NomeMembro> (es. "event:ReceiveBeginPlay") per un nodo evento. from_pin: pin di uscita, es. "then" per il filo di esecuzione. to_node: nome oggetto del nodo di arrivo. to_pin: pin di ingresso, es. "execute". graph_name: grafo su cui lavorare.

Se i tipi non sono compatibili il tool lo dice, riportando i due tipi invece di fallire in silenzio.

ParametersJSON Schema

Name	Required	Default
`to_pin`	Yes
`to_node`	Yes
`from_pin`	Yes
`from_node`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that the tool modifies the Blueprint and reports type mismatches with the involved types instead of failing silently. However, it does not mention side effects, return values, or error handling for other failures.

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 concise, with a clear purpose statement, a structured list of parameters, and a brief note about type incompatibility. Every part adds value, and it is not overly verbose.

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

Completeness3/5

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

The tool has no output schema and no annotations, so the description should cover return behavior and common errors. It explains the type mismatch error but does not mention success output, prerequisites (e.g., node existence, blueprint compilability), or whether changes are saved. Given the moderate complexity, the description is adequate for the parameters but leaves some behavioral gaps.

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 description provides a detailed explanation for each of the six parameters, including examples for from_node and from_pin (event:ReceiveBeginPlay, 'then'). This adds substantial meaning beyond the bare string schema, covering the 0% schema coverage.

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 first sentence clearly states the action: connecting an output pin to an input pin of another node. It specifies the resource (Blueprint) and distinguishes from other Blueprint editing tools like adding nodes or events.

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

Usage Guidelines3/5

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

The description does not explicitly mention when to use this tool versus alternatives such as ue_bp_break_pin or adding nodes. Usage is implied by the function's purpose and the parameter list, but there is no guidance on prerequisites or when not to use it.

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

ue_bp_graph_infoA

Nodi, pin, connessioni ed errori di compilazione di un grafo Blueprint.

È il punto di partenza: dà i nomi oggetto dei nodi da usare in tutti gli altri tool, e errors/warnings dicono se il grafo compila.

Args: blueprint_path: es. "/Game/MyGame/BP_Player". graph_name: nome oggetto del grafo ("EventGraph", "UserConstructionScript", o il nome di una funzione), non il titolo tradotto. ue_bp_list_graphs li elenca.

ParametersJSON Schema

Name	Required	Description	Default
`graph_name`	No		EventGraph
`blueprint_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the returned data (nodes, pins, connections, errors/warnings) and that errors/warnings indicate compilation status, but it does not explicitly state that the tool is read-only or has no side effects, which is implied but not guaranteed.

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 appropriately sized, front-loaded with the core information, and structured with a clear 'Args' section. Every sentence adds value, though it could be slightly more concise by combining the first two sentences.

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 no output schema, the description adequately covers the main return content (nodes, pins, connections, errors/warnings) and the primary use case. It lacks details on output format, but for an informational tool with well-explained parameters, this is sufficient.

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?

Schema description coverage is 0%, but the description fully compensates by explaining both parameters. It gives an example for blueprint_path and clarifies that graph_name is the object name rather than the translated title, and it directs users to ue_bp_list_graphs for valid values.

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 what the tool provides—nodes, pins, connections, and compilation errors of a Blueprint graph—though it lacks an explicit verb like 'retrieves' or 'gets.' It distinguishes itself by positioning as the starting point for other tools, which separates it from sibling ue_bp_* tools.

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 says 'È il punto di partenza' (it's the starting point) and explains that it provides object names needed for all other tools, which is clear when-to-use guidance. It also references ue_bp_list_graphs for listing graphs, offering an alternative for that specific need.

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

ue_bp_list_eventsA

Elenca gli eventi visibili su un Blueprint: custom, ereditati overridabili, di interfaccia.

is_implemented dice se esiste già un nodo per quell'evento nel grafo.

Args: blueprint_path: es. "/Game/MyGame/BP_Player".

ParametersJSON Schema

Name	Required	Description	Default
`blueprint_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

Since no annotations are provided, the description carries the full burden. It explains that 'is_implemented' indicates whether an event node already exists in the graph, which is useful output-related behavior. However, it does not explicitly state that the tool is read-only or mention any side effects, though listing events strongly implies a non-destructive 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 well-structured: a one-line purpose statement, a brief clarification of the output field 'is_implemented', and a clear args section. Every sentence earns its place, and the key information is front-loaded.

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?

For a simple list tool with one parameter and no output schema, the description provides adequate context by describing what events are listed and explaining a key part of the output. It could be more detailed about the full return structure, but the essential usage is clear.

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?

There is only one parameter, blueprint_path, and the schema provides just its type. The description adds a concrete example ('/Game/MyGame/BP_Player') and clarifies its purpose as the path to the Blueprint. This meaningfully supplements the 0% schema description coverage.

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 starts with a clear verb and resource: 'Elenca gli eventi visibili su un Blueprint' (Lists the visible events on a Blueprint), and explicitly enumerates the event types (custom, inherited overridable, interface). This specificity distinguishes it from sibling tools like ue_bp_list_graphs or ue_bp_add_custom_event.

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

Usage Guidelines3/5

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

The description implies use when needing to see a Blueprint's events, but does not provide explicit guidance on when to use this tool versus alternatives like ue_bp_list_graphs or ue_bp_add_event_override. It gives context but no exclusions or alternative recommendations.

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

ue_bp_list_graphsB

Elenca i grafi di un Blueprint (EventGraph, UserConstructionScript, funzioni...).

Args: blueprint_path: es. "/Game/MyGame/BP_Player".

ParametersJSON Schema

Name	Required	Description	Default
`blueprint_path`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the listing action but does not disclose the output format, whether the Blueprint must be loaded/compiled, or any side effects. The read-only nature is implied but not explicitly stated.

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 a single sentence with a clear purpose and an example. It is highly concise, front-loaded, and contains no extraneous information.

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

Completeness3/5

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

The tool is simple (one parameter, no output schema), but with no annotations and no schema descriptions, the short description is the only documentation. It covers the purpose and path format, yet misses return structure and usage context. This is adequate but leaves gaps.

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?

The input schema has 0% description coverage, but the description provides a concrete example value for blueprint_path ('/Game/MyGame/BP_Player'), which communicates the expected Unreal asset path format. However, it does not elaborate on the parameter's meaning beyond that example.

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 clearly states the verb 'Elenca' (lists) with a specific resource: the graphs of a Blueprint, including examples (EventGraph, UserConstructionScript, functions). This distinguishes it from sibling tools like ue_bp_list_events, which lists events, and ue_bp_graph_info, which provides info on a single graph.

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?

The description provides no guidance on when to use this tool versus alternatives such as ue_bp_list_events or ue_bp_graph_info. It only states what the tool does, without mentioning exclusions, prerequisites, or typical use cases.

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

ue_bp_list_paletteA

Cerca fra i nodi aggiungibili a un grafo, filtrando per sottostringa.

La palette completa ha migliaia di voci e segue la lingua dell'editor: filtrare è l'unico modo pratico di trovare il nome esatto da passare a ue_bp_add_node_by_name.

Args: blueprint_path: Blueprint di riferimento. graph_name: grafo di cui si vuole la palette. contains: sottostringa da cercare, senza distinzione di maiuscole. limit: quante corrispondenze restituire.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`contains`	No
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses key behaviors: the palette follows the editor's language, contains thousands of entries, the substring search is case-insensitive, and filtering is the only practical way to find names. These are meaningful behavioral traits beyond the basic 'search' 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 concise: a two-sentence intro followed by a bulleted Args list. Every sentence adds value, and the structure is clean with the purpose front-loaded. There is no filler or redundant information.

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?

It covers the tool's purpose, the scale and language-dependence of the palette, and all parameter semantics. The only missing detail is the explicit return format, but the intended use with `ue_bp_add_node_by_name` implies the results are node names. Given no output schema, a bit more detail on return structure would improve completeness.

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 schema has zero description coverage, but the description's Args section defines all four parameters: blueprint_path (Blueprint of reference), graph_name (target graph), contains (case-insensitive substring), and limit (max number of results). This fully compensates for the schema's lack of descriptions.

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 states a specific verb ('Cerca' = search) and resource ('nodi aggiungibili a un grafo' = nodes addable to a graph), with a clear method (filtering by substring). It also distinguishes itself from sibling tools by explicitly referencing the follow-up tool `ue_bp_add_node_by_name`, clarifying its role in the Blueprint node workflow.

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 explains when to use this tool: to find the exact node name for `ue_bp_add_node_by_name`, especially given that the full palette has thousands of entries and is language-dependent. This is a clear usage context, though it does not explicitly exclude alternatives or mention when not to use it.

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

ue_bp_remove_nodeC

Cancella un nodo dal grafo, con tutti i suoi collegamenti.

ParametersJSON Schema

Name	Required	Default
`node`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

There are no annotations, so the description must carry full behavioral disclosure. It does disclose that the node is removed along with all its connections, which is a meaningful side effect. However, it does not mention permanence, reversibility, required permissions, or behavior when the node does not exist, leaving significant gaps.

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 a single, concise sentence with no wasted words. It is front-loaded with the action. However, it is extremely brief, bordering on under-specification, but for the core action it is efficient.

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

Completeness2/5

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

For a mutation tool with no annotations, no output schema, and a 0% schema description coverage, this description is insufficient. It does not explain how the blueprint_path or graph_name parameters are used, nor does it provide any context about the blueprint graph environment or expected results. The description is too minimal for a complex editor operation.

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

Parameters1/5

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

The input schema has zero description coverage for its three parameters, and the tool description does not explain the meaning or format of 'blueprint_path', 'graph_name', or 'node'. The description only says 'a node' without connecting it to the parameters, so it fails to compensate for the schema gap.

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 clearly states the action: 'Cancella un nodo dal grafo' (delete a node from the graph), and distinguishes it from sibling tools that add or connect nodes. It also specifies the scope 'con tutti i suoi collegamenti' (with all its connections), making the purpose unambiguous.

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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The usage is only implied by the action verb, but no explicit context or alternative tools are referenced.

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

ue_bp_set_pin_valueA

Scrive il valore letterale di un pin di ingresso non collegato.

Unreal non valida il valore: verificato dal vivo che scrivere "non_un_bool" su un pin booleano viene accettato e memorizzato così com'è. Per questo il tool rilegge sempre il pin dopo la scrittura e restituisce il valore vero — controllalo, invece di fidarti del successo.

ParametersJSON Schema

Name	Required	Default
`pin`	Yes
`node`	Yes
`value`	Yes
`graph_name`	No	EventGraph
`blueprint_path`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral disclosure. It explicitly warns that Unreal does not validate values (an example is given), and that the tool re-reads the pin after writing to return the true value, advising users to check it rather than trust success. This is valuable, non-obvious behavioral context.

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 short and front-loaded: the first sentence states the purpose, the second provides a crucial warning. Every sentence earns its place; no filler or redundancy.

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?

For a tool with no annotations and no output schema, the description covers the essential behavior: the write action, the non-validation caveat, and the read-back verification. It does not describe parameter formats or return structure, but those are partially implied by the schema and the behavior description.

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?

The schema has 0% description coverage, so the description needs to compensate. It adds meaning for 'pin' (input pin) and 'value' (literal, unvalidated), but does not explain blueprint_path, node, or graph_name beyond their self-evident names. The compensation is partial.

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 clearly states the tool's function: 'Scrive il valore letterale di un pin di ingresso non collegato' (writes the literal value of an unconnected input pin). This distinguishes it from sibling tools like ue_bp_connect or ue_bp_break_pin, which deal with connections rather than setting literal values.

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 provides a clear usage context: setting literal values on unconnected input pins. It does not explicitly mention alternatives or exclusionary cases (e.g., connected pins), but the 'non collegato' qualifier implicitly warns against using it on connected pins.

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

ue_bt_add_decoratorA

Aggiunge un decorator (condizione) al child link di un nodo.

Args: bt_path: path del Behavior Tree. node_path: path del nodo (non può essere "root": la radice non ha un child link proprio), es. "0" o "0.1". decorator_class: es. "BTDecorator_Blackboard", "BTDecorator_Cooldown".

ParametersJSON Schema

Name	Required	Description	Default
`bt_path`	Yes
`node_path`	Yes
`decorator_class`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation modifies the asset in-place, requires saving, or is reversible. It only describes the action itself, similar to the 'update_drive' example. The node_path constraint ('cannot be root') is a parameter constraint, not a behavioral trait.

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 concise and front-loaded: the first sentence states the purpose, followed by a well-organized Args list. Each line adds value, with examples and constraints, and there is no unnecessary fluff.

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?

For a simple tool with three parameters and no output schema, the description provides enough information to select and invoke it correctly. It covers the purpose and all parameters. However, it lacks explicit guidance on when to use it versus other BT tools, which would make it more complete.

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% coverage, leaving the description entirely responsible for explaining parameters. It does so fully: bt_path is described as the path of the Behavior Tree, node_path is described with a clear constraint (cannot be 'root') and examples ('0' or '0.1'), and decorator_class is given concrete examples like 'BTDecorator_Blackboard' and 'BTDecorator_Cooldown'. This adds significant meaning beyond the raw schema.

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 clearly states a specific action: adding a decorator (condition) to a node's child link in a Behavior Tree. It uses a specific verb and resource, and the mention of 'child link' distinguishes it from sibling tools like ue_bt_add_node or ue_bt_set_node_property.

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

Usage Guidelines3/5

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

The description implies usage by explaining what the tool does, but it does not explicitly state when to use it versus alternatives (e.g., when to use ue_bt_add_service instead). No exclusions or alternative recommendations are provided, so guidance is only implied.

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

ue_bt_add_nodeA

Aggiunge un nodo (composite o task) come figlio di un nodo composite esistente.

Il tipo di nodo (composite vs task) è dedotto dalla classe: se eredita da BTCompositeNode va in ChildComposite, altrimenti in ChildTask. Usa ue_bt_info per vedere i path esistenti prima di aggiungere.

Args: bt_path: path del Behavior Tree. parent_path: "root" per la radice, oppure un path tipo "0" o "0.1" (indici dei figli separati da punto, restituiti da questa stessa funzione o da ue_bt_info). node_class: es. "BTComposite_Sequence", "BTTask_Wait", "BTTask_MoveTo". index: posizione tra i figli esistenti (in coda se omesso).

ParametersJSON Schema

Name	Required	Description	Default
`index`	No
`bt_path`	Yes
`node_class`	Yes
`parent_path`	Yes

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 carries the transparency burden. It discloses the key behavioral trait that node type is inferred from class inheritance (BTCompositeNode → ChildComposite, else ChildTask), and explains parent_path/index semantics. However, it does not mention return values or error conditions.

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: a one-sentence purpose, a type-inference note, a prerequisite tip, and a bulleted Args list. Every sentence adds functional value, with no fluff or redundancy.

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 mutation tool with 4 parameters, no output schema, and no annotations, this is notably complete. It covers purpose, type inference, path formats, index positioning, and even points to `ue_bt_info` as a companion tool, making it self-sufficient for an agent.

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?

Schema coverage is 0%, so the description compensates fully. The Args section explains every parameter: bt_path, parent_path with examples, node_class with concrete example classes, and index with default behavior (append if omitted). This goes well beyond the bare schema.

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 and object: 'Aggiunge un nodo (composite o task) come figlio di un nodo composite esistente' (adds a composite/task node as child of an existing composite node). It clearly distinguishes from sibling tools like ue_bt_add_decorator and ue_bt_add_service by focusing on adding composite/task 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 advises using `ue_bt_info` to see existing paths before adding, and explains parent_path formats ('root', '0', '0.1'). It provides solid contextual guidance but does not explicitly state alternatives or when not to use this tool.

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

ue_bt_add_serviceA

Aggiunge un service a un nodo composite (solo Selector/Sequence, non i task).

Args: bt_path: path del Behavior Tree. node_path: "root" o un path tipo "0" — deve essere un nodo composite. service_class: es. "BTService_DefaultFocus".

ParametersJSON Schema

Name	Required	Description	Default
`bt_path`	Yes
`node_path`	Yes
`service_class`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

With no annotations, the description carries full transparency burden. It reveals the composite-node constraint but omits key behavioral traits: whether the change is saved, what happens on invalid input, any prerequisites (e.g., loaded asset), or return behavior. For a mutation tool, this is a significant gap.

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 concise and well-structured: a clear one-line purpose followed by a compact Args list. Every sentence adds value, with no filler or repetition.

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

Completeness3/5

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

The tool has 3 parameters, no output schema, and no annotations. The description covers the action and parameter semantics adequately, but it doesn't mention return values, error handling, or any pre/post conditions. For a simple add operation this is borderline acceptable, yet some guidance on expected outcome is missing.

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?

The schema provides 0% coverage, but the Args section compensates well: bt_path defined as 'path del Behavior Tree', node_path given format examples ('root' or '0') plus the composite constraint, and service_class shown with an example ('BTService_DefaultFocus'). This adds real meaning beyond the schema.

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 clearly states the tool's function with a specific verb ('Aggiunge') and resource ('service a un nodo composite'), explicitly limiting to Selector/Sequence nodes and excluding tasks. This differentiates it from sibling tools like ue_bt_add_decorator and ue_bt_add_node.

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 provides clear context: it is for adding services to composite nodes only, with explicit 'solo Selector/Sequence, non i task' and the arg note 'deve essere un nodo composite'. While it doesn't name alternative tools, it offers enough guidance on when to use and when not.

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

ue_bt_infoB

Dump ricorsivo dell'albero di un Behavior Tree (nodi, decorator, service, path).

ParametersJSON Schema

Name	Required	Description	Default
`bt_path`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations provided, the description must carry the full burden of disclosing side effects and behavior. It discloses the recursive nature and the included content types, which is useful, but it does not explicitly state that the tool is read-only or describe any prerequisites, error conditions, or output format. The term 'dump' hints at a read operation, but explicit transparency is lacking.

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 a single, compact sentence that immediately conveys the core purpose and content. It is front-loaded with the action ('Dump ricorsivo') and specifies the resource and relevant details without any filler or redundancy.

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

Completeness2/5

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

Given the tool's simplicity (one parameter, no output schema), the description provides the core action but misses essential details. It does not clarify the expected format of 'bt_path' or the structure of the returned dump (e.g., string, JSON, hierarchy layout). An agent would struggle to invoke it correctly and interpret the result, especially in the absence of annotations or an output schema.

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

Parameters1/5

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

The schema has one parameter 'bt_path' with no description (0% schema description coverage), and the tool description does not mention the parameter at all. This leaves the expected path format ambiguous—whether it is an asset path, file path, or something else—forcing the agent to guess. The description fails to compensate for the schema gap, making this a critical deficiency.

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 clearly states the tool performs a recursive dump of a Behavior Tree's hierarchy, explicitly listing nodes, decorators, service, and path. This establishes a specific verb and resource, distinguishing it from sibling mutation tools like ue_bt_add_node or ue_bt_add_decorator. It is unambiguous that this is an info/read operation.

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

Usage Guidelines3/5

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

The description implies usage for inspecting a Behavior Tree structure, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Sibling tools include other BT operations, but there is no direct guidance on scenarios where ue_bt_info would be preferred or not, leaving usage inferred rather than explicit.

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

ue_bt_set_node_propertyA

Imposta una proprietà su un nodo del Behavior Tree.

Gestisce in automatico i campi bindable da blackboard (es. BTTask_Wait.WaitTime, uno struct FValueOrBBKey_Float): scrive nel valore di default fisso invece che nella chiave blackboard.

Args: bt_path: path del Behavior Tree. node_path: "root" o un path tipo "0.1". property_name: nome della proprietà UE (es. "WaitTime", "BlackboardKey"). value: valore JSON da scrivere (segue le stesse regole di ue_set_actor_property).

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes
`bt_path`	Yes
`node_path`	Yes
`property_name`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals an important, non-obvious behavior: automatic handling of blackboard-bindable fields (e.g., FValueOrBBKey_Float) and writes to the fixed default value. This is valuable transparency, though it does not cover all potential side effects, return values, or error conditions.

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 concise and well-structured. The main action is front-loaded in the first sentence, followed by a brief note on special behavior, and then a clean argument list. Every sentence provides useful information without redundancy.

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 moderate complexity and lack of output schema or annotations, the description covers the essential context: what it does, special blackboard behavior, and parameter meanings. It could be more complete by adding concrete examples or edge-case notes, but it is sufficiently detailed for an agent to use the tool correctly in most cases.

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%, but the description compensates by listing all four arguments with brief explanations. For instance, node_path is described as 'root' or a path like '0.1', and value is said to follow the rules of ue_set_actor_property. This adds meaning beyond the bare schema, even if value's description relies on external knowledge.

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 clearly states the tool's function: 'Imposta una proprietà su un nodo del Behavior Tree' (sets a property on a Behavior Tree node). This is specific and distinguishes it from sibling tools like ue_set_actor_property or ue_pcg_set_node_property.

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 explains a key usage nuance: it handles blackboard-bindable fields automatically by writing to the default value instead of the blackboard key. It also references that 'value' follows the rules of ue_set_actor_property, giving context. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions.

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

ue_build_startA

Avvia la compilazione del modulo C++ del progetto (in background).

L'editor deve essere chiuso: con Live Coding attivo UnrealBuildTool si rifiuta di scrivere le DLL, e per un modulo nuovo Live Coding non è sufficiente. Sequenza tipica: ue_editor_close -> ue_build_start -> ue_build_status (finché running=false) -> ue_editor_open.

Args: uproject: percorso del file .uproject. engine_version: forza una versione del motore diversa da quella associata. target: default "Editor". configuration: "Development" | "DebugGame" | "Shipping". engine_root: percorso del motore, quando non è registrato nel sistema e la ricerca automatica non lo trova. force: avvia anche se risulta già una compilazione in corso. Serve solo quando la precedente è rimasta bloccata e ne hai chiuso i processi: due Build.bat insieme si accodano sullo stesso mutex.

ParametersJSON Schema

Name	Required	Default
`force`	No
`target`	No
`uproject`	Yes
`engine_root`	No
`configuration`	No	Development
`engine_version`	No

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries full burden. It discloses that the build runs in background, that the editor must be closed, that force is for stuck builds, and that builds queue on a mutex. This provides rich behavioral context beyond the name and schema.

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 well-structured with a header, a bolded warning, a typical sequence, and a bulleted argument list. It is informative without being verbose. However, the argument descriptions could be slightly more concise (e.g., 'forza una versione del motore diversa da quella associata' is a bit wordy). Still, it is well-organized and front-loaded.

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 6 parameters, no output schema, and no annotations, the description provides comprehensive context: preconditions, sequence, parameter details, and force usage. It lacks an explicit statement about the return value (e.g., a build ID), but the sibling ue_build_status implies the agent can check progress. Slightly more detail on the immediate result of starting a build would make it a 5.

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?

Schema description coverage is 0%, so the description must compensate. It explains each parameter: uproject (path to .uproject), engine_version (force different engine version), target (default '<Progetto>Editor'), configuration (lists three values), engine_root (path when engine not registered), force (use only when previous build stuck). This adds meaningful semantics beyond the schema's types and defaults.

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 clearly states 'Avvia la compilazione del modulo C++ del progetto (in background).' This specifies the verb 'avvia' (starts), the resource 'compilazione del modulo C++', and the context 'in background'. It distinguishes the tool from siblings like ue_build_status (which checks status) and ue_build_unblock (which unblocks).

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

Usage Guidelines5/5

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

Explicitly states 'L'editor deve essere chiuso' and explains why (Live Coding prevents DLL writing). Provides a typical sequence: ue_editor_close -> ue_build_start -> ue_build_status -> ue_editor_open. Also clarifies when force should be used: only when previous build is stuck and processes are closed. This gives clear when-to-use and when-not-to-use guidance.

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

ue_build_statusA

Stato della compilazione avviata con ue_build_start: in corso, errori, coda del log.

Args: tail_lines: quante righe finali del log restituire. uproject: a quale progetto si riferisce; se omesso, l'ultima compilazione avviata. wait_seconds: se > 0 attende la fine della compilazione fino a questo limite, riportando l'avanzamento, invece di restituire subito. Una build completa dura minuti: meglio un'attesa sola che venti letture.

ParametersJSON Schema

Name	Required	Description	Default
`uproject`	No
`tail_lines`	No
`wait_seconds`	No

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that wait_seconds causes blocking and progress reporting, and that uproject defaults to the last build. This adds behavioral context beyond the schema.

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 concise: a single introductory sentence followed by clearly structured parameter descriptions. Every sentence adds value, no redundancy. It is front-loaded with purpose.

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 (3 optional parameters, no output schema), the description covers the purpose and key behaviors adequately. It mentions return aspects like status and log lines but does not detail error handling or prerequisites. Slightly incomplete, but sufficient for an experienced user.

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?

Despite 0% schema coverage, the description thoroughly explains each parameter: tail_lines (number of final log lines), uproject (project reference, defaults to last build), wait_seconds (waits and reports progress if >0). This compensates fully for the lack of schema descriptions.

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 clearly states it checks the status of a compilation started with ue_build_start, mentioning specific states like 'in corso' (in progress), errori, and coda del log. It distinguishes itself from siblings like ue_build_start and ue_build_unblock.

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 implicitly tells when to use it (after starting a build) and gives guidance on using wait_seconds to avoid multiple reads ('meglio un'attesa sola che venti letture'). It does not explicitly mention when not to use it or alternatives, but the context is clear.

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

ue_build_unblockA

Trova — e se vuoi termina — i processi che tengono occupato il lock di build.

Serve quando ue_build_status riporta blocked: gli script di Epic prendono un lock globale e un'istanza rimasta orfana non lo rilascia mai, quindi Build.bat aspetta all'infinito e ogni nuovo tentativo si accoda.

La ricerca è sulla riga di comando, non sul nome dell'immagine: su UE 5 UnrealBuildTool è un assembly .NET dentro dotnet.exe e gli script girano dentro cmd.exe, quindi nessuno dei due si trova con taskkill /IM UnrealBuildTool.exe — ed è il motivo per cui il lock sembra inestirpabile.

Args: dry_run: con True (default) elenca soltanto. La ricerca per riga di comando può intercettare un dotnet.exe che sta facendo altro: guarda l'elenco prima di terminarlo. engine_version, engine_root: quale motore, per sapere quale file di lock controllare (%TMP%\<percorso di Build.bat>.lock).

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No
`engine_root`	No
`engine_version`	No

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: searches by command line, terminates processes, handles dotnet/cmd, checks lock file, and warns about potential false positives.

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 thorough and well-organized, but slightly verbose. Every sentence adds value, so it remains efficient for a complex tool.

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 no output schema, the description adequately explains behavior, output (list of processes), and logic. Could mention output format explicitly, but sufficient for agent operation.

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?

The schema has 0% description coverage, but the description provides detailed semantics for dry_run (default true, safe), engine_version and engine_root (to locate lock file). However, format expectations are not given.

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 clearly states the verb (find and optionally terminate), resource (processes holding build lock), and differentiates from siblings like ue_build_status by specifying the exact use case when builds are blocked.

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

Usage Guidelines5/5

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

Explicitly states when to use ('Serve quando ue_build_status riporta blocked'), explains why alternatives like taskkill don't work, and provides dry_run recommendation for safety.

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

ue_compile_blueprintB

Compila e salva un Blueprint. Usare dopo modifiche manuali nell'editor.

ParametersJSON Schema

Name	Required	Description	Default
`blueprint_path`	Yes

TDQS

B3.3/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 carry the full burden. It states the basic action (compile and save) but lacks details about side effects, error states, or success indicators.

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 extremely concise at two sentences, with the key instruction front-loaded. Every word serves a purpose, with no redundancy.

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

Completeness3/5

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

For a simple compile-and-save operation, the description is adequate but lacks details on return values, error handling, and precise path requirements. Given no output schema, more context would improve usability.

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

Parameters2/5

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

The input schema has 0% description coverage, and the tool description adds no information about the blueprint_path parameter, such as format, source, or valid values. The parameter remains minimally documented.

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 tool compiles and saves a Blueprint, using a specific verb and resource. However, it does not differentiate from siblings like ue_create_blueprint or ue_save_all.

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 advises using the tool after manual modifications in the editor, providing clear context. However, it does not mention when not to use it or alternatives.

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

ue_component_physics_infoC

Stato fisica/collisione attuale di un componente.

ParametersJSON Schema

Name	Required	Description	Default
`actor`	Yes
`component`	Yes

TDQS

C2.8/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 carry the full burden. It only states the tool's purpose without disclosing any behavioral traits such as read-only-ness, return format, or potential side effects. While the name suggests a simple query, the description does not explicitly confirm it is non-destructive.

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 a single concise sentence with no filler words. It is front-loaded with the main idea ('Stato' indicates a state query). It is appropriately brief for a simple info tool, though it lacks detail (penalized elsewhere).

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

Completeness2/5

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

The tool has annotations, an output schema, or detailed parameters; the description is minimal. It doesn't describe what information is returned, the structure of the result, or any additional context needed to use the tool effectively. Given the lack of output schema, the description is insufficient for an agent to fully understand the tool's behavior.

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

Parameters2/5

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

The input schema has only 'actor' and 'component' with no descriptions. The description does not explain what these parameters should contain (e.g., names, paths, IDs) or how they relate. With 0% schema description coverage, the description should compensate but does not.

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 it inspects the current physics/collision state of a component. It clearly identifies the resource (component) and the informational nature, distinguishing it from sibling tools like ue_set_component_physics. However, it lacks a verb and doesn't specify exactly what fields are returned, so it's clear but not maximal.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or when not to use it. The only sibling connection is implicit (e.g., before modifying physics with ue_set_component_physics).

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

ue_configure_pieA

Configura il Play In Editor multi-client, per provare il multiplayer in locale.

Args: num_players: numero di finestre client (server incluso in listen_server). net_mode: "standalone" | "listen_server" | "client". one_process: True = più finestre nello stesso processo (più veloce da avviare).

ParametersJSON Schema

Name	Required	Default
`net_mode`	No	listen_server
`num_players`	No
`one_process`	No

TDQS

A3.8/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 disclose behavioral traits. It explains what parameters do but does not mention side effects, whether the editor must be open, or if settings persist. This is insufficient for a configuration tool.

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 concise: one introductory sentence followed by three bullet-point-like args. No unnecessary fluff, well-structured, and front-loaded.

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 simplicity (3 optional parameters, no output schema), the description covers the purpose and parameters well. However, it lacks mention of side effects or how this action integrates with sibling tools like ue_start_pie.

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 coverage is 0%, but the description compensates by explaining each parameter: num_players, net_mode (with valid values), and one_process. This adds significant meaning beyond the schema's basic types.

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 clearly states the tool configures multi-client Play In Editor for local multiplayer testing. It distinguishes from sibling tools like ue_start_pie by focusing on configuration rather than execution.

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

Usage Guidelines3/5

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

The description explains the parameters but does not explicitly state when to use this tool vs alternatives (e.g., ue_start_pie). No guidance on prerequisites or when not to use is provided.

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

ue_console_commandA

Esegue un comando della console dell'editor e restituisce ciò che stampa.

I comandi di console non restituiscono valori: scrivono nel log. Questo tool misura il log prima e dopo e riporta solo le righe nuove, altrimenti la risposta sarebbe "fatto" e nient'altro.

Utile per stat unit, r.ScreenPercentage 50, showflag.*, DumpConsoleCommands. Passa dall'interprete Python dell'editor, non dal gate bAllowConsoleCommandRemoteExecution della Remote Control API, che resta spento: da qui si può fare tutto quello che si fa dalla console, quit compreso.

Args: command: il comando, es. "stat fps". wait_seconds: quanto attendere che il motore scriva nel log.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes
`wait_seconds`	No

TDQS

A4.8/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It explains that console commands write to log, not return values, and the tool captures new log lines. It warns that it can execute 'quit' and passes through Python interpreter, not the remote API, giving full behavioral context.

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 with a clear one-liner, behavioral explanation, usage examples, technical detail, and parameter descriptions. Each sentence adds value, and it is front-loaded with the purpose.

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?

Given no annotations or output schema, the description fully covers return behavior, execution mechanism, and potential dangers. It is complete for the tool's complexity.

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?

Schema description coverage is 0%, but the description fully explains both parameters: 'command' with example 'stat fps', and 'wait_seconds' as wait time for log output. This adds significant meaning beyond the schema.

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 clearly states it executes an editor console command and returns its output. It distinguishes from sibling tools like ue_exec_python and ue_read_log by explaining it captures new log lines from command execution. The verb 'execute' and resource 'console command' are specific.

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 provides explicit examples of when to use (e.g., 'stat unit', 'r.ScreenPercentage') and contrasts with the remote execution API. It does not explicitly list when not to use or compare to siblings like ue_exec_python, but the context is clear.

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

ue_cpp_class_createA

Genera una classe C++ compilabile nel modulo del progetto.

È la risposta al limite principale di questo MCP: i grafi Blueprint non sono scrivibili da Python, ma la logica può stare in C++ e arrivare ai Blueprint per ereditarietà. Flusso completo:

ue_cpp_class_create -> ue_editor_close -> ue_build_start ->
ue_build_status (finché running=false) -> ue_editor_open ->
ue_reparent_blueprint

Se il progetto è Blueprint-only, il modulo C++ (Build.cs, Target.cs, IMPLEMENT_PRIMARY_GAME_MODULE, voce Modules nel .uproject) viene creato.

Args: uproject: percorso del file .uproject. class_name: nome senza prefisso, es. "DoorBase" -> ADoorBase. parent_class: "Actor", "Pawn", "Character", "ActorComponent", "GameModeBase", "PlayerState", ... module: nome del modulo C++; default il nome del progetto. properties: lista di dict con name, type (es. "float", "FVector", "TObjectPtr"), e opzionali category, default, replicated, rep_notify, read_only. Le proprietà replicate generano anche GetLifetimeReplicatedProps e i DOREPLIFETIME. functions: lista di dict con name, return_type, params, specifiers (default BlueprintCallable), body. Le funzioni BlueprintCallable diventano chiamabili dai grafi Blueprint. with_tick: abilita il Tick (di default è spento, come conviene). force: sovrascrive i file se esistono già.

ParametersJSON Schema

Name	Required	Default
`force`	No
`module`	No
`uproject`	Yes
`functions`	No
`with_tick`	No
`class_name`	Yes
`properties`	No
`parent_class`	No	Actor

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden. It thoroughly discloses behavior: generation of C++ files, creation of module files (Build.cs, etc.) for Blueprint-only projects, overwrite behavior via 'force', replication handling for properties, and BlueprintCallable function generation. No contradictions with annotations (none exist). This is exemplary transparency.

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 relatively long but well-structured. It begins with the primary purpose, then provides workflow context, then parameter details. Every sentence adds value, though the workflow is repeated in both prose and bullet list. Could be slightly more concise, but overall effective and front-loaded.

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 complexity (8 parameters, nested objects for properties and functions, no output schema), the description covers all major aspects: each parameter, replication, BlueprintCallable, module creation, file overwriting. It does not mention error handling or return values, but these are minor gaps. The description is sufficiently complete for an AI agent to use the tool effectively.

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?

Schema description coverage is 0%, so the description must add meaning. It explains every parameter in detail: uproject path, class_name naming convention, parent_class options, module default, properties structure (with replication effects), functions structure (with BlueprintCallable default), with_tick default, and force. It goes beyond schema by providing examples and behavioral implications, fully compensating for the empty schema descriptions.

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 clearly states the tool creates compilable C++ classes in the project module. It explains the limitation of Blueprint graphs (not writable in Python) and positions this tool as the solution, distinguishing it from Blueprint creation tools. The verb 'genera' (create) and resource 'classe C++' are explicit.

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 provides context for when to use this tool (when logic cannot be expressed in Blueprint graphs) and outlines a full workflow (ue_cpp_class_create -> ue_editor_close -> ... -> ue_reparent_blueprint). It also notes that if the project is Blueprint-only, the C++ module will be created. However, it does not explicitly state when not to use it or compare to alternatives like ue_create_blueprint.

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

ue_create_anim_blueprintA

Crea l'asset Anim Blueprint associato a uno Skeleton.

L'AnimGraph non è raggiungibile da qui (stesso limite del grafo Blueprint): va disegnato a mano nell'Anim Blueprint Editor.

Args: package_path: es. "/Game/MyGame/Characters/Hero". name: es. "ABP_Hero". skeleton_path: Skeleton a cui l'Anim Blueprint è associato. parent_class: nome esposto ai binding Python (default "AnimInstance") o percorso completo di una classe C++ del progetto.

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`package_path`	Yes
`parent_class`	No	AnimInstance
`skeleton_path`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It adds the AnimGraph limitation and parameter details, but doesn't disclose what happens if the asset already exists, whether it overwrites, or what the success/failure response format is. This is a creation/mutation tool, so more behavioral detail would be helpful.

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: a one-sentence purpose, a useful note about the AnimGraph limitation, and a clear Args list. It is concise, front-loaded, and every sentence adds value.

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

Completeness3/5

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

For a creation tool with no annotations and no output schema, the description covers the purpose and parameters well, but omits expected return behavior and edge cases like existing assets or validation of skeleton_path. The AnimGraph note adds context, but more completeness is needed.

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?

Schema description coverage is 0%, but the description's Args section provides detailed explanations and examples for each parameter, including the default for parent_class. This fully compensates for the schema's lack of parameter descriptions.

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 clearly states the tool creates an Anim Blueprint asset associated with a Skeleton, using the verb 'Crea' and a specific resource. It distinguishes from generic blueprint creation and sibling tools like ue_create_blueprint by explicitly targeting Anim Blueprint and mentioning the requirement of a skeleton.

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 provides a clear limitation: the AnimGraph is not reachable from this tool and must be drawn manually in the Anim Blueprint Editor. This tells the agent when not to expect graph editing capabilities, though it doesn't name alternative tools or explicitly state when to use this versus other creation tools.

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

ue_create_anim_montageA

Crea un AnimMontage a partire da un AnimSequence esistente.

Args: package_path: es. "/Game/MyGame/Characters/Hero/Animations". name: es. "AM_Attack". source_animation_path: AnimSequence da incapsulare nel montage.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes
`source_animation_path`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It reveals that the tool creates a montage from a source animation but does not mention side effects like asset creation in the content browser, overwrite behavior, path validation, or failure conditions. This leaves key behavioral aspects undisclosed.

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 extremely concise, front-loaded with the core purpose, and includes a clear Args section with examples. Every sentence earns its place, with no redundant content.

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

Completeness3/5

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

The tool is a straightforward creation operation with three required string parameters. The description defines the inputs and purpose adequately, but because there is no output schema and no annotations, it does not disclose what happens on success or failure, whether the asset is saved, or any error conditions. This leaves some gaps for an agent to anticipate outcomes.

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 must compensate. It provides illustrative examples for package_path and name, and explains source_animation_path as the AnimSequence to encapsulate. This adds meaningful semantics beyond the raw parameter names, though it could be slightly clearer on path formats.

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 clearly states the tool creates an AnimMontage from an existing AnimSequence, using a specific verb (Crea) and resource. This differentiates it from sibling animation-related creation tools like ue_create_anim_blueprint or ue_create_blend_space_1d.

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

Usage Guidelines3/5

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

The description implies usage when you have an existing AnimSequence to encapsulate, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. No sibling differentiation or alternative guidance is provided.

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

ue_create_behavior_treeA

Crea un Behavior Tree con un nodo radice già impostato (Selector o Sequence), opzionalmente collegato a un Blackboard.

Args: package_path: es. "/Game/MyGame/AI". name: es. "BT_Guard". blackboard_path: Blackboard da collegare (opzionale). root_composite: "BTComposite_Selector" | "BTComposite_Sequence" | qualunque classe composite valida.

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`package_path`	Yes
`root_composite`	No	BTComposite_Selector
`blackboard_path`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It explains the creation action (creates a BT with a preset root node, optionally links a Blackboard) but does not mention what happens if the asset already exists (e.g., overwrite), whether the package path must already exist, or any failure modes. It also does not describe return values, though this is a creation tool.

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 short and efficiently structured: a single intro sentence followed by a clear list of arguments with examples. There is no redundant or filler content; every sentence serves a purpose.

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?

For a creation tool with 4 parameters and no output schema, the description covers the essential details for invocation: what it creates, the required parameters, and the optional Blackboard link. It lacks a deeper explanation of the difference between Selector and Sequence, and how the Blackboard path is actually applied, but these are not critical for basic use.

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?

With schema description coverage at 0%, the description partially compensates by giving example values for package_path and name, clarifying that blackboard_path is optional, and listing valid values for root_composite ('BTComposite_Selector', 'BTComposite_Sequence', or any valid composite class). This adds meaning beyond the schema, though it does not explain the name format constraints or the exact semantic of linking a Blackboard.

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 clearly states it 'Crea un Behavior Tree con un nodo radice già impostato (Selector o Sequence), opzionalmente collegato a un Blackboard' – a specific verb and resource, with details on the root node and optional Blackboard linkage. It distinguishes itself from sibling tools like ue_bt_add_node (which modifies an existing tree) and ue_create_blackboard (which creates a Blackboard asset).

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

Usage Guidelines3/5

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

The context of use is implied: you use this to create a new Behavior Tree asset. However, there is no explicit 'when to use' or 'when not to use' guidance, nor any mention of alternatives like ue_bt_add_node for further editing. It is clear enough but lacks explicit differentiation.

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

ue_create_blackboardC

Crea un asset Blackboard Data vuoto (solo la chiave "SelfActor" di default).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The description discloses the default key behavior but omits critical details: no mention of whether the asset overwrites, is saved, requires a package, or has other side effects. With no annotations, this lack of disclosure is significant.

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 a single concise and front-loaded sentence that efficiently conveys the action and a key detail. No unnecessary words.

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

Completeness2/5

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

Without annotations, an output schema, or parameter details, the description is insufficient for correct invocation. It does not relate to sibling blackboard tools or explain the expected workflow.

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

Parameters1/5

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

With 0% schema description coverage, the description does not explain the 'name' and 'package_path' parameters. The agent gains no additional meaning beyond the field names.

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 clearly states the tool creates an empty Blackboard Data asset and specifies the default SelfActor key, making the purpose unambiguous and distinguishing it from siblings like ue_blackboard_add_key.

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 provided on when to use this tool versus alternatives. For instance, it does not mention that adding keys should be done with ue_blackboard_add_key or that this tool is for initial asset creation.

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

ue_create_blend_space_1dA

Crea un BlendSpace1D con un asse e, opzionalmente, i suoi sample.

Solo 1D per ora: BlendSpace (2D) usa la stessa struttura dati ma non è stata verificata dal vivo in questa fase.

Args: package_path: es. "/Game/MyGame/Characters/Hero/Animations". name: es. "BS_Locomotion". skeleton_path: Skeleton a cui il BlendSpace è associato. axis_name: nome dell'asse, es. "Speed". axis_min: valore minimo dell'asse. axis_max: valore massimo dell'asse. grid_num: numero di suddivisioni della griglia. samples: lista di {"value": float, "animation": path}, es. [{"value": 0, "animation": ".../Idle"}, {"value": 300, "animation": ".../Running"}].

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`samples`	No
`axis_max`	No
`axis_min`	No
`grid_num`	No
`axis_name`	No	Speed
`package_path`	Yes
`skeleton_path`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the creation behavior and the 1D-only limitation, but it does not mention side effects such as resource overwriting, save behavior, or permission requirements, which would be expected for a mutation tool.

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 with a brief introduction followed by a clear Args list. Every line adds value, and examples are included without excessive verbosity.

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?

Although no output schema exists, the description covers the essential parameters and the 1D/2D caveat. It could be improved by noting what happens after creation (e.g., asset saving) or potential errors, but overall it is quite complete for a creation tool.

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?

With 0% schema description coverage, the description fully compensates by documenting all 8 parameters with examples, including the samples structure. This adds substantial meaning beyond the bare schema.

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 clearly states 'Crea un BlendSpace1D con un asse e, opzionalmente, i suoi sample' – a specific verb and resource. It also distinguishes from 2D BlendSpace by noting the 1D-only limitation, which differentiates it from potential sibling tools.

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 provides context that only 1D is supported and notes that 2D BlendSpace uses the same data structure but is unverified, which guides usage. However, it does not explicitly name alternative tools or give when-not-to-use scenarios beyond the 1D/2D caveat.

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

ue_create_blueprintB

Crea un Blueprint.

Args: package_path: cartella, es. "/Game/MyGame/Blueprints". name: nome asset, es. "BP_CornerSlot". parent_class: "Actor", "Character", "Pawn", "GameModeBase", "PlayerState", "GameStateBase", "AIController" o un path completo.

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`package_path`	Yes
`parent_class`	No	Actor

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states 'Crea un Blueprint' without disclosing side effects, requirements (e.g., editor state), error conditions, or return behavior. Minimal insight into tool behavior beyond creation.

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?

Description is very short (two lines) and efficiently lists arguments with examples. It is well-structured with Args section. Could potentially be more concise by combining into a single sentence, but current form is clear.

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

Completeness2/5

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

For a creation tool, the description omits important context: what happens after creation (e.g., asset appears in browser), error handling (e.g., duplicate names), and dependencies (e.g., open project). Incomplete for an AI agent to use without trial and error.

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?

Given 0% schema description coverage, the description adds significant value by providing examples for package_path and name, and listing common values for parent_class. This aids understanding but lacks format constraints like required path prefix.

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 'Crea un Blueprint' clearly states the tool's function (create a blueprint). It is specific and distinguishable from siblings like ue_cpp_class_create or ue_create_material. However, it does not specify the type of blueprint (e.g., Blueprint Class) explicitly, relying on parameter examples.

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 on when to use this tool versus alternatives. The description lacks prerequisites, context (e.g., requires open project), or any indication of when this tool is appropriate. Sibling tools are not referenced or distinguished.

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

ue_create_eqs_assetA

Crea un asset Environment Query (EQS) vuoto.

Le query (Options, generator, test) non sono raggiungibili da qui — stesso limite del grafo Blueprint, del WidgetTree e dell'emitter stack Niagara. Va costruito a mano nell'EQS Editor.

Args: package_path: es. "/Game/MyGame/AI". name: es. "EQS_FindCover".

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations exist, so the description carries behavioral disclosure. It states the asset is 'empty' and that queries/options/generators/tests are inaccessible, adding an analogy to similar Unreal Editor limitations. This sets accurate expectations for the tool's capabilities, though it doesn't mention side effects like overwriting or return values.

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: one sentence for purpose, one for limitation, and a short args list with examples. Every sentence adds value, and it is front-loaded with the most important information.

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?

For a two-parameter, no-output-schema creation tool, the description covers the essential purpose, limitations, and parameter formats. It doesn't mention overwrite behavior or return values, but those are less critical for an asset creation tool; still, a small gap remains.

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?

The schema defines 'name' and 'package_path' only as strings with no descriptions. The description compensates by providing concrete examples ('/Game/MyGame/AI' for package_path, 'EQS_FindCover' for name), clarifying expected formats and typical usage, though it doesn't fully explain path semantics or naming rules.

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 'Crea un asset Environment Query (EQS) vuoto', a specific verb (create) and resource (empty EQS asset). This clearly distinguishes it from sibling asset-creation tools like ue_create_blackboard or ue_create_behavior_tree.

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 implies usage for creating EQS assets and explicitly warns that query details can't be configured here, directing users to the EQS Editor. However, it doesn't name specific alternative tools or state when not to use it, so it provides clear context but no explicit exclusions.

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

ue_create_foliage_spawnerA

Crea un ProceduralFoliageSpawner con dentro i suoi FoliageType.

Lo spawner è la ricetta (quali specie, con quale competizione fra loro); il volume creato da ue_foliage_spawn_volume è dove viene applicata.

Args: package_path: es. "/Game/MyGame/Foliage". name: es. "PFS_Bosco". foliage_types: path dei FoliageType da includere. tile_size: lato della tile di simulazione in cm (default 10000).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`tile_size`	No
`package_path`	Yes
`foliage_types`	No

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It explains the conceptual role and the default tile size, but it does not disclose whether the asset is overwritten, whether package paths must already exist, or what the tool returns. This is a partial behavioral disclosure but not a complete one.

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?

Two short sentences plus a clean Args list with examples. Every sentence adds meaning, no filler, and it is front-loaded with the primary action.

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 simple schema (4 flat parameters, no output schema), the description covers the asset being created, its relationship to the volume, and all parameter details. It lacks return value and save behavior, but for this simplicity it is nearly complete.

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?

Schema coverage is 0%, yet the description explains all four parameters with concrete examples ('/Game/MyGame/Foliage', 'PFS_Bosco'), clarifies foliage_types as paths to FoliageTypes to include, and gives tile_size with default value and unit (cm). This fully compensates for the schema's lack of documentation.

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 clear verb+resource: 'Crea un ProceduralFoliageSpawner con dentro i suoi FoliageType' (Creates a ProceduralFoliageSpawner with its FoliageTypes inside). It also distinguishes this tool from the sibling volume tool by explaining the spawner is the 'recipe' and the volume is where it is applied.

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 contrasts the spawner as the recipe and the volume created by ue_foliage_spawn_volume as the application area, telling the agent when to use this tool versus the volume. It provides example paths for package_path and name, but does not mention exclusions for other foliage tools like ue_create_foliage_type.

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

ue_create_foliage_typeA

Crea un FoliageType a partire da una static mesh.

Il FoliageType è la "specie": dice quale mesh piazzare e con quali regole (densità, scala casuale, allineamento alla normale, collisione). Le istanze si piazzano poi con ue_foliage_add_instances o ue_foliage_scatter.

Args: package_path: es. "/Game/MyGame/Foliage". name: es. "FT_Erba". mesh_path: la static mesh, es. "/Game/Meshes/SM_Erba". properties: proprietà iniziali, es. {"density": 300, "random_yaw": True}.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`mesh_path`	Yes
`properties`	No
`package_path`	Yes

TDQS

A4.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains the concept of FoliageType and the inputs, but it does not disclose behavioral details such as whether the asset is saved automatically, whether it overwrites existing assets, or any permission requirements. This is a notable gap for a creation tool.

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 with a clear definition, an explanation of the FoliageType concept, and a concise Args list with examples. Every sentence adds value, and it remains brief enough to scan quickly.

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?

The description provides good context by explaining the FoliageType concept, giving path and property examples, and referencing the follow-up placement tools. However, it does not mention return values or error behavior, though these may be less critical given the tool's straightforward creation role.

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?

Schema description coverage is 0%, but the description compensates fully by listing each parameter with a meaningful example: package_path as '/Game/MyGame/Foliage', name as 'FT_Erba', mesh_path as '/Game/Meshes/SM_Erba', and properties with a sample dictionary. This adds significant meaning beyond the bare schema.

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 clearly states the tool's purpose: 'Crea un FoliageType a partire da una static mesh' (Creates a FoliageType from a static mesh). It uses a specific verb and resource, and differentiates itself from sibling tools like ue_foliage_add_instances and ue_foliage_scatter by explaining that instances are placed later.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool (to define the 'species' of foliage) and mentions that instances are subsequently placed with ue_foliage_add_instances or ue_foliage_scatter, providing clear alternatives and workflow context.

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

ue_create_gameplay_abilityA

Crea un GameplayAbility Blueprint (asset dedicato, non un Blueprint generico).

La logica dell'abilità (ActivateAbility, i suoi nodi) resta un EdGraph come tutti i grafi Blueprint — non scriptabile, va disegnata a mano. Le proprietà dati invece si impostano già qui.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes
`instancing_policy`	No
`net_execution_policy`	No

TDQS

A4.4/5.0

Behavior4/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 clearly discloses that the ability logic (ActivateAbility, nodes) remains an EdGraph that is not scriptable and must be drawn by hand, while data properties are set at creation. This is key behavioral context that helps set expectations. However, it does not mention side effects like asset creation details or the need for an open project.

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, starting with a clear purpose, followed by a brief explanation of the logic/data split, and a clean list of arguments with examples. Every sentence adds value; it is concise without unnecessary filler.

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 (4 parameters, no annotations, no output schema), the description covers the essential context: what asset type is created, how it differs from generic Blueprints, what is and isn't automated, and all parameter value options. It lacks a bit on interpretation of policy choices or what the tool returns, but overall it is substantially complete.

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?

The schema has zero property descriptions, so the parameter semantics depend entirely on the description. The description provides example values for package_path and name, and explicitly lists the allowed enum values for instancing_policy and net_execution_policy. This adds significant meaning beyond the raw schema, though it does not explain the meaning of each policy option.

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 explicitly states 'Crea un GameplayAbility Blueprint (asset dedicato, non un Blueprint generico)' which clearly identifies the action (create) and the resource (GameplayAbility Blueprint), and differentiates it from a generic Blueprint. This distinguishes it from sibling tools like ue_create_blueprint.

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 provides clear context by specifying it is for a dedicated GameplayAbility asset, not a generic Blueprint. It implicitly tells the agent when to use it (for GameplayAbility creation) and when not (for generic Blueprints), but does not explicitly name alternative sibling tools. It also explains that ability logic must be drawn manually, helping the agent understand the tool's scope.

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

ue_create_gameplay_effectA

Crea un GameplayEffect Blueprint (Blueprint generico con parent GameplayEffect).

Args: package_path: es. "/Game/MyGame/Effects". name: es. "GE_Damage". duration_policy: "Instant" | "HasDuration" | "Infinite". period: intervallo di applicazione in secondi (per effetti periodici).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`period`	No
`package_path`	Yes
`duration_policy`	No

TDQS

A3.6/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 carry full disclosure. It states the creation action but does not mention whether existing assets are overwritten, whether the asset is saved/compiled, or any error/return behavior.

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?

Two-line purpose plus a compact arg list; every element adds information, with examples and enum-style values.

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

Completeness3/5

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

All four parameters are documented, but the description lacks output/return expectations and does not explain the relationship between duration_policy and period (e.g., whether period only applies with HasDuration). Without annotations or output schema, this leaves minor but real gaps.

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?

Schema descriptions are 0% and the description compensates with concrete examples for package_path and name, explicit allowed values for duration_policy, and the unit/meaning of period (seconds for periodic effects).

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?

Description opens with 'Crea un GameplayEffect Blueprint' — a specific verb (create) and resource (GameplayEffect Blueprint) with parent type, distinguishing it from sibling creation tools like ue_create_blueprint and ue_create_gameplay_ability.

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 on when to use this tool versus alternatives; it never mentions related tools (e.g., ue_ge_add_modifier) or prerequisites. Usage is only implied by the tool name and creation context.

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

ue_create_level_sequenceA

Crea una Level Sequence vuota.

Args: package_path: es. "/Game/MyGame/Cinematics". name: es. "LS_Intro". fps: frame rate di visualizzazione (default 30). length_frames: durata in frame; imposta il range di playback da 0.

ParametersJSON Schema

Name	Required	Description	Default
`fps`	No
`name`	Yes
`package_path`	Yes
`length_frames`	No

TDQS

A3.7/5.0

Behavior3/5

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

Without annotations, the description carries the burden of behavioral disclosure. It mentions that the sequence is empty and that length_frames sets playback range from 0, plus a default fps of 30. However, it does not disclose side effects like whether the asset is saved, opened, or could overwrite an existing asset.

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 concise: a single-sentence purpose followed by a clean argument list. No fluff or redundant information. Every line serves a purpose.

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

Completeness3/5

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

For a simple creation tool, it covers the basic behavior and parameters, but lacks contextual details about post-creation actions (e.g., saving, opening) and how it fits among the many sequence-related sibling tools. Given no annotations or output schema, a bit more context would be warranted.

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%, but the description adds value by providing examples for package_path and name, and semantics for fps (display frame rate, default 30) and length_frames (duration in frames, sets playback range). This compensates well for the missing schema descriptions.

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 clearly states 'Crea una Level Sequence vuota' (creates an empty Level Sequence), using a specific verb and resource. This distinguishes it from sibling tools that edit or query sequences, such as ue_sequence_add_actor or ue_sequence_info.

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?

The description does not provide when-to-use guidance or mention alternatives. It simply states what the tool does and lists arguments, with no context about when to choose this over other sequence or creation tools.

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

ue_create_materialA

Crea un materiale collegando le texture ai canali PBR.

A differenza dei grafi Blueprint, il grafo materiale è pienamente scriptabile: qui i nodi vengono creati e collegati davvero.

Args: package_path: cartella, es. "/Game/MyGame/Materials". name: nome asset, es. "M_Brick". textures: mappa canale -> path della texture importata. Canali: base_color, normal, roughness, metallic, ambient_occlusion, emissive, opacity. Usa la chiave "auto" con il path per far dedurre il canale dal nome file (convenzioni ambientCG/Poly Haven). scalars: costanti sui canali senza texture, es. {"roughness": 0.4}. two_sided: disattiva il backface culling.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`scalars`	No
`textures`	No
`two_sided`	No
`package_path`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It reveals that the tool actually creates and connects nodes in the material graph, not just sets parameters. However, it omits details like authentication requirements, side effects, or limits.

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 short and front-loaded with the core purpose, followed by a brief clarification. Every sentence adds value, with no repetition or fluff.

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 moderate complexity (5 parameters, no nested objects) and lack of output schema, the description covers all parameter semantics and basic behavior. It could mention the return value (e.g., created asset path), but this is not critical for a creation tool.

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, but the description's Args section explains every parameter in detail: package_path, name, textures (with channel list and 'auto' key), scalars, and two_sided. This fully compensates for the schema gap.

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 clearly states that the tool creates a material by connecting textures to PBR channels, and contrasts it with Blueprint graphs to highlight its full scriptability. This distinctly separates it from sibling tools like ue_create_material_instance and ue_assign_material.

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

Usage Guidelines3/5

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

The description implies that this tool is for full material graph creation (as opposed to Blueprint graphs), but it does not explicitly specify when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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

ue_create_material_instanceA

Crea una Material Instance da un materiale padre e ne imposta i parametri.

Variare un materiale via istanza non ricompila il grafo: è la via economica per avere molte varianti dello stesso materiale.

Args: package_path: cartella di destinazione. name: es. "MI_Brick_Red". parent_path: materiale padre, es. "/Game/MyGame/Materials/M_Brick". parameters: mappa nome -> valore. Numero = scalare, dict {"r","g","b"} = colore, bool = static switch, path /Game/... = texture.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`parameters`	No
`parent_path`	Yes
`package_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that instancing does not recompile the shader graph, a key behavioral trait. However, it lacks details on side effects, authorization needs, or error handling.

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 concise, with purpose and benefit front-loaded, followed by parameter details. It is not verbose but could better separate general description from parameter listing.

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

Completeness3/5

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

Given no output schema or annotations, the description should include return behavior or post-creation effects. It does not mention what the tool returns or whether the instance is automatically saved. Adequate but incomplete.

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?

With 0% schema coverage, the description compensates by listing each parameter with its purpose and value types (scalar, color, bool, texture). This adds significant meaning beyond the bare schema, though exact formats for complex types could be more precise.

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 clearly states the tool creates a material instance from a parent material and sets parameters, using specific verb and resource. It distinguishes from sibling tools like ue_create_material by emphasizing that instancing avoids shader recompilation.

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 explains when to use (for multiple variants without recompilation) but does not explicitly state when not to use or name alternative tools. However, context implies alternatives like ue_create_material for new materials.

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

ue_create_metasound_sourceC

Crea un asset MetaSound Source vuoto (richiede il plugin MetaSound attivo).

Il grafo va poi popolato nell'editor MetaSound o via ue_exec_python.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No		MS_Source
`package_path`	No		/Game/Audio

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions the plugin requirement and that the asset is empty, but does not disclose error scenarios, whether creation can overwrite existing assets, permissions needed, or if the operation is synchronous. For a creation tool, this is minimal behavioral disclosure.

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 concise: two sentences covering purpose, prerequisite, and next step. It is front-loaded with the main action. However, it could be slightly improved by including parameter details, but overall it is efficient.

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

Completeness2/5

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

Given the tool's simplicity (2 parameters, no output schema), the description is incomplete. It fails to clarify what the function returns, whether it's blocking, or what happens if the asset already exists. The post-creation guidance is helpful, but the overall context for an agent is insufficient.

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

Parameters1/5

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

The input schema has two parameters (name and package_path) with defaults and 0% schema description coverage. The description does not reference these parameters at all, providing no additional meaning about what they control or how they affect the creation. This is a significant gap.

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 'Crea un asset MetaSound Source vuoto' (Create an empty MetaSound Source asset), specifying the verb and resource. It distinguishes this from sibling create tools by naming the specific asset type, though it does not explain what a MetaSound Source is or how it differs from other audio assets.

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

Usage Guidelines3/5

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

The description provides a clear next step: 'Il grafo va poi popolato nell'editor MetaSound o via ue_exec_python.' (The graph must then be populated in the MetaSound editor or via ue_exec_python.) However, it does not specify when to use this tool versus alternatives like ue_create_sound_cue, nor does it state any preconditions beyond the plugin requirement.

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

ue_create_niagara_systemA

Crea un asset Niagara System vuoto.

L'emitter stack (aggiungere emitter, moduli, parametri) non è raggiungibile da qui — stesso limite del grafo Blueprint e del WidgetTree di UMG. Va costruito a mano nel Niagara Editor.

Args: package_path: es. "/Game/MyGame/VFX". name: es. "NS_Explosion".

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an above-average job by revealing that emitter stack editing is inaccessible and comparing this limitation to Blueprint graph and UMG WidgetTree constraints. It does not mention overwrite behavior or save semantics, but for a simple asset creation tool, the disclosed limitation is meaningful and adds real value beyond the schema.

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 concise and well-structured. It leads with the primary action, adds only essential limitation context, and lists arguments with examples. Every sentence earns its place; there is no repetition of schema information or filler content.

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?

For a simple creation tool with only two required string parameters and no output schema, the description covers the core purpose, a critical limitation, and parameter examples. It lacks details about failure cases or whether the asset is saved automatically, but these are minor gaps given the tool's simplicity and the strong contextual information already provided.

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 must compensate. It provides concrete examples for both parameters: package_path as '/Game/MyGame/VFX' and name as 'NS_Explosion'. These examples clarify expected formats and naming conventions, which is valuable given the schema only provides field names and types.

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 combination: 'Crea un asset Niagara System vuoto' (Create an empty Niagara System asset). This clearly distinguishes it from sibling creation tools like ue_create_material or ue_create_blackboard, and the 'vuoto' qualifier adds precision about the asset's initial state.

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 a key limitation: the emitter stack cannot be configured from this tool and must be built manually in the Niagara Editor. It provides practical context for when to use this tool, though it does not name alternative MCP tools for further editing (e.g., none exist). This is clear contextual guidance, but lacks an explicit 'use this when' statement.

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

ue_create_pcg_graphB

Crea un asset PCGGraph vuoto — con i suoi nodi Input e Output già dentro.

Args: package_path: es. "/Game/MyGame/PCG". name: es. "PCG_Foresta".

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`package_path`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden of disclosing behavior. It does add one useful detail (Input and Output nodes already included), but it omits important traits such as whether the asset is saved immediately, what happens if the asset already exists, or whether the package path must exist. This is a significant gap for a mutation tool.

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 concise and front-loaded. The main purpose is stated in a single sentence, followed by a compact argument list with examples. No filler or redundant information is present.

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

Completeness3/5

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

For a simple creation tool, the description conveys the core purpose and parameter examples, but it lacks usage context, safety, or error-condition information. Given the absence of annotations and an output schema, more detail about preconditions and effects would be expected for a complete description.

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?

The schema has zero description coverage, but the description compensates by providing concrete examples for both parameters (package_path and name). However, it does not fully explain the semantics, such as whether package_path is a folder or full asset path or if name should include an extension. The examples help but leave room for interpretation.

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 clearly states the tool's purpose: it creates an empty PCG Graph asset, and specifically notes that Input and Output nodes are already included. This distinguishes it from sibling tools like ue_pcg_add_node and ue_pcg_graph_info, and the verb 'Crea' provides a clear action.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used before adding nodes or any context about typical workflows. The example argument values are helpful but do not explain the tool's role among similar PCG tools.

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

ue_create_sound_cueB

Crea un Sound Cue, opzionalmente già collegato a un SoundWave importato.

Args: package_path: es. "/Game/MyGame/Audio". name: es. "SC_Explosion". wave_path: path del SoundWave, es. "/Game/MyGame/Audio/explosion".

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`wave_path`	No
`package_path`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided. The description only mentions the optional link to a SoundWave. It does not disclose side effects like overwriting existing assets, or any required engine states.

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?

Two clear paragraphs: a one-line purpose and an Args section with examples. Every sentence is informative, and the structure is efficient.

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

Completeness3/5

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

Adequate for a creation tool with 3 parameters and no output schema. Explains main use and parameters, but lacks description of return value, error handling, or what a Sound Cue is relative to other audio assets.

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 coverage is 0%; description compensates with brief explanations and concrete examples for each parameter (e.g., '/Game/MyGame/Audio' for package_path). This adds value over bare schema field 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 it creates a Sound Cue, optionally linked to an imported SoundWave. The sibling tools include ue_import_audio and ue_create_metasound_source, so this is distinct but not explicitly differentiated.

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

Usage Guidelines3/5

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

Provides parameter examples for package_path, name, and optional wave_path. It mentions the optional connection to a SoundWave, giving context on when to use wave_path. However, it lacks explicit guidance on when to use this tool vs alternatives like ue_create_metasound_source, and does not mention prerequisites.

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

ue_create_widget_blueprintA

Crea un asset Widget Blueprint (UMG) vuoto.

L'albero nasce senza radice, e WidgetTree.RootWidget non è scrivibile da Python: per costruire un layout con i tool ue_umg_* parti invece da ue_duplicate_asset di un Widget Blueprint che una radice ce l'ha già, e svuotalo con ue_umg_remove_widget. Questo tool va bene quando la radice la metti a mano nel Widget Designer, o quando il Widget Blueprint serve solo come asset da riempire dopo.

Args: package_path: es. "/Game/UI". name: es. "WBP_MainMenu". parent_class: nome esposto ai binding Python (es. "UserWidget") o percorso completo di una classe C++ del progetto, per la via BindWidget. editor_utility: True per un Editor Utility Widget (tool per l'editor, non per il gioco) invece di un Widget Blueprint normale.

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`package_path`	Yes
`parent_class`	No	UserWidget
`editor_utility`	No

TDQS

A4.6/5.0

Behavior4/5

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

Poiché non ci sono annotazioni, la descrizione divulga il comportamento critico: 'L'albero nasce senza radice' e 'WidgetTree.RootWidget non è scrivibile da Python', cosa non ovvia e utile all'agente. Inoltre spiega la differenza tra editor_utility e normale. Non menziona eventuali rischi aggiuntivi o valori di ritorno, ma i punti chiave sono coperti.

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?

La descrizione è in italiano, con una frase introduttiva, un paragrafo di avvertimento e un elenco Args strutturato. Ogni frase è rilevante, nessuna ridondanza; la lunghezza è giustificata dalla complessità del tool.

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?

Non è presente output schema né annotazioni, e la descrizione copre scopo, parametri, avvertimenti comportamentali e alternative. Manca il ritorno del tool (nessuna menzione di cosa restituisce), ma il resto è trattato in modo sufficiente per l'uso corretto.

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?

La copertura dello schema dello 0% costringe la descrizione a compensare; lo fa con esempi per package_path e name, e spiegazioni semantiche per parent_class (bindings Python o percorso C++) e editor_utility. Tutti i 4 parametri sono descritti con esempi.

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?

La descrizione inizia con 'Crea un asset Widget Blueprint (UMG) vuoto', identificando chiaramente verbo e risorsa. Distingue da altre tool di creazione (ue_create_blueprint, ue_duplicate_asset) specificando la natura 'vuoto' e collegando i tool ue_umg_*.

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

Usage Guidelines5/5

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

Il testo indica esplicitamente quando usare questo tool ('quando la radice la metti a mano...' o 'quando il Widget Blueprint serve solo come asset da riempire dopo') e quando non usarlo, suggerendo un'alternativa concreta: partire da ue_duplicate_asset e svuotare con ue_umg_remove_widget. Fornisce quindi criteri d'uso e alternative.

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

ue_delete_actorB

Elimina dal livello corrente l'attore con la label indicata.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits, but it only says 'deletes'. It does not mention what happens if the label is not found, whether children are affected, or if it is reversible.

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 a single concise sentence, front-loaded with the action. However, it sacrifices important details for brevity.

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

Completeness3/5

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

For a simple one-parameter destructive tool, the description gives the basic purpose but omits error cases and return behavior. It is minimally complete but would benefit from more context.

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

Parameters2/5

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

The 'label' parameter has 0% schema description coverage, and the tool description adds no extra meaning beyond 'the indicated label', leaving format, case sensitivity, and validation unspecified.

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 clearly states the action (delete), the resource (actor), and the scope (current level) using the specific label. It distinguishes from sibling tools like 'ue_spawn_actor' or 'ue_list_actors'.

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 provided on when to use this tool versus alternatives, no prerequisites (e.g., actor must exist), no mention of error handling or side effects.

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

ue_delete_assetA

Elimina un asset o una cartella dal Content Browser.

Serve per rimediare a un import sbagliato senza aprire l'editor a mano. Di default rifiuta la cancellazione se qualcosa referenzia l'asset: cancellarlo comunque lascia riferimenti rotti nei livelli e nei Blueprint.

Args: path: es. "/Game/Imported/rock_01" oppure una cartella "/Game/Imported". force: cancella anche se referenziato.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`force`	No

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description discloses default rejection of deletion if referenced and the risk of broken references. However, it does not cover error handling, undoability, or permission requirements, which would be helpful for a deletion tool.

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 concise, front-loads the action, and lists parameters simply. Every sentence adds value, with no unnecessary fluff.

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 no output schema or annotations, the description covers the tool's primary behavior and parameters adequately. It lacks details on return values or error scenarios but is sufficient for basic usage.

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 coverage is 0%, but the description adds concrete examples for path (e.g., '/Game/Imported/rock_01') and explains the force parameter's effect, compensating for the lack of schema descriptions.

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 states it deletes an asset or folder from the Content Browser, provides a specific use case (remedying a wrong import), and distinguishes itself from sibling tools like rename or duplicate by focusing on deletion.

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 says when to use (to fix an import mistake) and explains default refusal on reference detection. It does not explicitly mention alternatives or when not to use, but the risk of broken references serves as a caution.

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

ue_detach_actorB

Sgancia un attore dal suo padre.

Args: label: label dell'attore. keep_world: mantiene la posizione nel mondo invece di quella relativa.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes
`keep_world`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description is the sole source. It mentions the detach action and keep_world behavior, but lacks details on edge cases (e.g., invalid label, actor without parent) or side effects. Insufficient for a mutation tool.

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 extremely concise, using a single line for the purpose and two lines for parameters. No redundant information; front-loaded with the core action.

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

Completeness3/5

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

Given the simple tool (2 params, no output schema), the description covers the essential purpose and parameter meanings. However, it omits common usage contexts like error handling, prerequisites (actor must have a parent), and return value (success/failure). It is minimally complete.

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 must add value. It does so by explaining both parameters: 'label' is the actor's label, and 'keep_world' maintains world position. This clarifies the boolean's behavior beyond the schema's title.

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 'Sgancia un attore dal suo padre' (detaches an actor from its parent), which is a specific verb and resource. It is distinct from siblings like ue_attach_actor, but does not explicitly differentiate itself.

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

Usage Guidelines3/5

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

The description implies usage for detaching actors from parents but provides no explicit guidance on when to use it versus alternatives, prerequisites, or the implication of keep_world parameter. It assumes the actor already has a parent.

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

ue_duplicate_assetC

Duplica un asset: la via rapida per crearne una variante da modificare.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`new_path`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It only states 'duplicate' but does not disclose side effects (e.g., dependency copying, asset loading requirements, overwrite behavior). The context of creating a 'variant' implies modification, but details are lacking.

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 very short (one sentence) and front-loaded with the core action. However, it is too minimal for the tool's needs, missing parameter details. It earns points for being concise but loses for under-specification.

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

Completeness2/5

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

Given the tool's simplicity (2 required string params, no output schema), the description is incomplete. It does not explain the path semantics, whether it creates a new asset or replaces an existing one, or any prerequisites like asset must be loaded.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description provides no explanation of the two parameters ('path', 'new_path'). No information on format (absolute, relative, content browser paths) or expected values, leaving the agent with no guidance beyond the schema names.

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 clearly states the tool duplicates an asset to create a variant for modification, using a specific verb ('duplica') and resource ('asset'). It distinguishes from sibling tools like ue_delete_asset or ue_rename_asset by focusing on duplication.

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 explicit guidance on when to use this tool versus alternatives. The phrase 'la via rapida' hints at a faster method but does not specify when not to use it or mention any alternative duplication methods.

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

ue_editor_closeA

Chiude l'editor.

Prima tenta la chiusura pulita (salvataggio + quit_editor via bridge); se fallisce o se force=True, termina il processo.

Args: save_all: salva livello e asset modificati prima di chiudere. force: salta il tentativo pulito e termina direttamente il processo.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`save_all`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the two-phase approach (clean close attempt then process termination) and the effect of each parameter. However, it does not mention what happens if save_all=False and clean close fails (still terminates), which is somewhat ambiguous.

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 concise with two short paragraphs. The purpose is stated first, followed by a clear explanation of the two-step process and parameter descriptions. No redundant information.

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 no output schema, the description covers the essential behavior (close modes, parameter effects). It could mention return value or prerequisites (editor must be open), but these are implied. Complete enough for a close tool.

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 coverage is 0%, so the description must explain parameters. It does so effectively: save_all saves level/assets before closing, force skips clean close and terminates directly. This adds meaning beyond the schema's boolean names.

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 clearly states the tool closes the editor, specifying a two-step process (clean close then force terminate). It distinguishes from sibling tools like ue_editor_open (open) and ue_save_all (save).

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

Usage Guidelines3/5

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

The description explains when to use force (if clean close fails or force=True), but does not explicitly mention when not to use this tool or suggest alternatives (e.g., use ue_save_all for saving only). The usage context is implied rather than explicit.

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

ue_editor_openA

Apre un progetto nell'editor e attende che il bridge risponda.

L'attesa predefinita è breve di proposito: molti client MCP interrompono una richiesta dopo 60 secondi, e un wait_seconds più lungo faceva fallire la chiamata con "Request timed out" anche quando l'editor era partito benissimo. Se il bridge non è ancora pronto la risposta lo dice e basta richiamare ue_editor_status finché running diventa bridge_ready.

Args: uproject: percorso del file .uproject. engine_version: forza una versione del motore diversa da quella associata. wait_seconds: quanto attendere il bridge. Il primo avvio compila gli shader e può volerci molto di più: in quel caso non alzarlo oltre il timeout del client, si fa polling con ue_editor_status. extra_args: argomenti aggiuntivi per la riga di comando dell'editor. engine_root: percorso del motore, quando non è registrato nel sistema. skip_module_check: lancia anche se i moduli C++ non corrispondono al motore (l'editor resterà bloccato su una modale dietro allo splash).

ParametersJSON Schema

Name	Required	Description	Default
`uproject`	Yes
`extra_args`	No
`engine_root`	No
`wait_seconds`	No
`engine_version`	No
`skip_module_check`	No

TDQS

A4.6/5.0

Behavior4/5

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

Discloses that the tool waits for bridge response, that default wait is short due to client timeout, and that if bridge not ready, the response indicates so. Mentions shader compilation and potential modal blockage due to skip_module_check. However, no annotations provided, and the description could be more explicit about side effects (e.g., editor launch) but is still informative.

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 front-loaded with the main purpose. The following paragraph and Args list are well-organized, though slightly verbose. Every sentence adds value, but the entire text could be slightly more concise.

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?

Lacks explicit return value details (no output schema), but the description implies the tool returns status about bridge readiness and refers to ue_editor_status for detailed polling. For a tool with 6 parameters and no output schema, it provides good contextual information, but missing exact response structure for completeness.

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?

Parameter descriptions in the Args section add significant meaning beyond the schema (which only has titles and defaults). Each parameter is explained: uproject (path), engine_version (force version), wait_seconds (with caveats), extra_args (command-line args), engine_root (engine path), skip_module_check (warning about modal). With 0% schema coverage, the description fully compensates.

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 explicitly states 'Apre un progetto nell'editor e attende che il bridge risponda' which is a specific verb+resource. It clearly distinguishes from sibling tools like ue_editor_status (polling for bridge_ready) and ue_editor_close.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use polling (ue_editor_status) instead of increasing wait_seconds because of client timeout. Advises against raising wait_seconds beyond client timeout, especially on first launch with shader compilation.

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

ue_editor_statusA

Stato del processo editor avviato da questo MCP e del bridge Remote Control.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only mentions 'status' but does not disclose whether the operation is read-only, blocking, or what the output structure is. This is insufficient for a tool with zero annotation coverage.

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 a single concise sentence with no wasted words. It is front-loaded with the core purpose.

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

Completeness3/5

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

For a status tool with no parameters and no output schema, the description is somewhat vague. It does not specify what aspects of status are reported (e.g., running, idle, error) or how to interpret results. More detail would improve completeness.

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?

No parameters exist, so the input schema fully covers parameter semantics. The description adds no parameter information, but none is needed. Baseline score of 4 is appropriate.

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 clearly states it provides status of the editor process and Remote Control bridge, using a specific verb and resource. It distinguishes from sibling tools like ue_status or build_status by specifying the scope.

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 on when to use this tool versus alternatives. It does not specify prerequisites or exclude cases, leaving the agent without context for selection.

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

ue_engine_listA

Elenca le installazioni di Unreal Engine trovate sulla macchina.

Cerca in: variabile UE_MCP_ENGINE_DIRS, elenco dell'Epic Games Launcher, registro di Windows. Da chiamare per prima quando non c'è ancora un progetto.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It describes the search locations and that it lists installations. It does not mention side effects, but for a read‑only listing tool this is acceptable.

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 extremely concise with two sentences. The first states the core purpose, the second provides search context and usage guidance. No redundant information.

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?

For a parameterless tool without an output schema, the description covers its purpose, search scope, and when to call it. It does not detail the output format, but the tool is simple enough that this is not a critical omission.

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?

There are no parameters, so the schema coverage is trivially 100%. The description adds value by explaining the search locations (UE_MCP_ENGINE_DIRS, Epic Games Launcher, Windows registry), which is useful context beyond the empty schema.

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 clearly states the tool lists Unreal Engine installations on the machine. It specifies the verb 'list' and the resource 'engine installations', distinguishing it from project-focused siblings like ue_project_find.

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 says 'to be called first when there is no project yet', providing clear context for when to use this tool. It does not explicitly mention alternatives, but the context is sufficient given the sibling tools.

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

ue_engine_templatesC

Elenca i template ufficiali disponibili nell'installazione (TP_Blank, TP_ThirdPerson, ...).

ParametersJSON Schema

Name	Required	Description	Default
`engine_root`	No
`engine_version`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not explicitly state that this is a read-only operation. While implicit, it lacks explicit disclosure of side effects, permissions, or other behavioral traits beyond the single action of listing.

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 single-sentence description is concise and front-loaded with the core action. However, it could be structured more clearly (e.g., mentioning parameters) without adding much length.

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

Completeness2/5

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

Given the tool has two optional parameters of unclear purpose and no output schema, the description is incomplete. It fails to specify the role of the parameters or the return format, which are essential for proper usage.

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

Parameters1/5

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

Schema coverage is 0% and the description does not explain either of the two optional parameters ('engine_root', 'engine_version'). The description adds no value beyond what the bare schema provides, forcing the agent to infer parameter usage.

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 clearly states this tool lists official templates available in the installation, with specific examples (TP_Blank, TP_ThirdPerson). It distinguishes itself from sibling tools like 'ue_engine_list' which lists installed engines, not templates.

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 provided on when to use this tool versus alternatives among many sibling tools. There is no mention of prerequisites, context, or exclusions.

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

ue_exec_pythonA

Esegue codice Python arbitrario dentro l'editor Unreal (escape hatch).

Il modulo unreal e tutti gli helper mcp_* sono disponibili. Assegna il valore da restituire alla variabile result.

Args: code: snippet Python, es. "result = len(mcp_actor_subsystem().get_all_level_actors())".

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided. The description discloses it executes arbitrary Python and mentions the 'result' variable, but lacks details on side effects, error handling, or security implications. It gives some transparency but not full.

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 relatively concise, with the purpose stated in the first sentence. It includes a separate Args section. A bit more brevity could be achieved, but overall it is well-structured.

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

Completeness3/5

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

Given the complexity of arbitrary code execution and no output schema, the description should explain the return mechanism (result variable) and output format. It does mention 'result' but does not specify the return value type or behavior, leaving some gaps.

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?

With 0% schema coverage, the description adds meaningful context for the only parameter 'code' via an example, showing how to assign the return value. This compensates well for the lack of schema description.

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 clearly states it executes arbitrary Python code in the Unreal editor, using the verb 'esegue' and specifying the resource. This distinguishes it from sibling tools that perform other actions like saving, opening levels, or managing actors.

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

Usage Guidelines3/5

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

It mentions 'escape hatch' implying advanced use, and lists available modules, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Some guidance is present but not comprehensive.

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

ue_find_classesA

Elenca le classi (native e Blueprint) derivate da una classe base, base inclusa.

Copre il caso "che sottoclassi di Character esistono nel progetto?" o "elencami le luci disponibili": la Blueprint del progetto compare col suo nome generato (es. "BP_PlayerCharacter_C").

Args: parent: nome esposto ai binding Python (es. "Character", "Actor") o percorso completo (es. "/Script/Engine.Light", "/Game/.../BP_Nemico.BP_Nemico_C"). name_contains: filtro case-insensitive sul nome, opzionale. limit: massimo numero di risultati.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`parent`	Yes
`name_contains`	No

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden. It does disclose useful behavioral traits: 'base included', native and Blueprint classes, and the generated Blueprint name suffix ('BP_PlayerCharacter_C'). However, it does not explicitly state side-effect-free/read-only behavior, return format, or error conditions, which are typically expected from a query tool without annotations.

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 well-structured: a clear purpose sentence, two illustrative examples, then an Args block. It is slightly longer than necessary but each sentence adds value, especially given the lack of schema descriptions. No redundant filler or repetition of schema defaults.

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?

For a simple query tool with no annotations and no output schema, the description covers the tool's purpose, usage scenarios, and parameter syntax thoroughly. It implies the return value (a list of class names) but does not explicitly specify the return format or edge cases (e.g., empty results). Given the complexity, this is acceptable but leaves a small gap.

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?

With 0% schema description coverage, the description provides essential extra meaning for all three parameters: parent (Python binding name or full path with examples), name_contains (case-insensitive filter, optional), and limit (maximum results). This goes far beyond the bare schema and is critical for effective invocation.

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: 'Lists the classes (native and Blueprint) derived from a base class, base included.' This clearly distinguishes it from sibling tools like ue_list_assets (assets) and ue_find_structs (structs). Concrete examples ('what subclasses of Character exist in the project?', 'list the available lights') further solidify the purpose.

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 provides clear usage context via the question examples ('what subclasses of Character exist?', 'list the available lights'), which tell the agent when to call this tool. However, it does not explicitly mention alternatives or when not to use it (e.g., for structs use ue_find_structs), 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.

ue_find_structsA

Elenca gli struct derivati da uno struct base, base incluso.

Args: parent: nome esposto ai binding Python (es. "Vector") o percorso completo (es. "/Script/CoreUObject.Vector"). name_contains: filtro case-insensitive sul nome, opzionale. limit: massimo numero di risultati.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`parent`	Yes
`name_contains`	No

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that this is a read-only operation, whether the search is recursive (all descendants) or direct children only, or what the output list contains (names, paths, etc.). The verb 'Elenca' implies a listing but does not confirm safety or result format.

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 exceptionally concise: a one-sentence purpose followed by a clean, organized Args list. Every word earns its place, with no redundancy or extraneous information.

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

Completeness3/5

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

While the description covers parameters and scope well, it omits the return value format (e.g., list of names vs. paths) and error behavior. Since there is no output schema to clarify these, the description leaves a moderate gap in what the agent can expect from the tool.

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?

Schema description coverage is 0%, but the description's Args section thoroughly explains all three parameters: parent accepts either a Python-bound name or a full path with examples, name_contains is case-insensitive, and limit caps results. This adds crucial meaning beyond the raw schema types, fully compensating for the lack of schema-level descriptions.

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 clearly states 'Elenca gli struct derivati da uno struct base, base incluso' (Lists structs derived from a base struct, base included), providing a specific verb and resource. This distinguishes it from siblings like ue_find_classes by focusing on structs rather than classes.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like ue_find_classes or clarify when to choose struct discovery over class discovery, leaving the agent to infer usage from the parameter descriptions alone.

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

ue_flow_runA

Esegue una sequenza di chiamate a tool descritta in YAML (o JSON).

Serve quando la stessa scena si costruisce con dieci o venti chiamate sempre uguali: il flow le descrive una volta e le esegue in un colpo solo, restituendo il riassunto invece di venti risposte intere.

Forma di un flow::

variables:
  base: {x: 0, y: 0, z: 100}
steps:
  - tool: ue_spawn_actor
    args: {class_name: StaticMeshActor, location: "${base}", label: Cubo}
    save: cubo
  - tool: ue_set_actor_transform
    args: {label: "${cubo.label}", scale: [2, 2, 2]}
  - tool: ue_screenshot
    when: {exists: cubo.label}

Ogni passo accetta tool, args, save (nome della variabile in cui mettere il risultato), when (booleano, ${riferimento}, o {equals: [a,b]} / {not_equals: [a,b]} / {exists: percorso}), continue_on_error e name.

Nei valori, ${nome} e ${nome.chiave.0} riprendono quello che un passo precedente ha salvato. Una stringa fatta solo di riferimento conserva il tipo del valore (un dict resta un dict); dentro una frase viene interpolata come testo.

Non ci sono cicli né espressioni, ed è voluto: la logica sta in chi scrive il flow, non nel flow.

Args: flow: il testo YAML/JSON, oppure il path di un file .yaml/.json. variables: variabili iniziali, che si sommano a quelle del flow. dry_run: valida forma, nomi dei tool e riferimenti senza eseguire niente. Da usare sempre la prima volta che un flow gira. stop_on_error: fermarsi al primo passo fallito. Con False prosegue e riporta gli errori nel riassunto (un singolo passo può comunque dichiarare continue_on_error: true).

ParametersJSON Schema

Name	Required	Description	Default
`flow`	Yes
`dry_run`	No
`variables`	No
`stop_on_error`	No

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and meets it: it details step semantics (tool, args, save, when, continue_on_error), variable interpolation rules, the return of a summary instead of full responses, and the behavior of dry_run (validates without executing) and stop_on_error (stop vs. continue). It explicitly states the intentional lack of loops/expressions, making the tool's execution model transparent.

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 long but every section earns its place: purpose, when-to-use, an illustrative flow example, step field semantics, variable interpolation rules, explicit constraints, and parameter documentation. It is front-loaded with the core purpose and structured with headings and code example, making it easy to scan without redundant filler.

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?

Given the tool's complexity (a flow interpreter with conditional steps and variable references), the description is remarkably complete: it covers the YAML/JSON format, step fields, variable notation with type preservation, dry_run validation, error handling options, and the summary output behavior. No output schema exists, but the description sufficiently explains what the agent can expect.

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?

Although schema coverage is 0%, the description's 'Args' section fully compensates by explaining each parameter: flow (YAML/JSON text or file path), variables (initial variables merged with the flow's), dry_run (validate without executing, 'Da usare sempre la prima volta'), and stop_on_error (stop at first failure or continue and report errors). This adds meaning well beyond the raw schema types.

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 and resource: 'Esegue una sequenza di chiamate a tool descritta in YAML (o JSON)' — it clearly states that the tool executes a sequence of tool calls defined in YAML/JSON. This distinguishes it from the many direct UE-operation siblings by framing it as an orchestration/meta-tool, and the use case of building a scene with repeated identical calls further clarifies its role.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: 'Serve quando la stessa scena si costruisce con dieci o venti chiamate sempre uguali' (use when the same scene requires ten or twenty identical calls). It also states a clear exclusion: 'Non ci sono cicli né espressioni, ed è voluto' — no loops or expressions, so complex logic is out of scope. This gives the agent clear decision-making criteria.

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

ue_focus_actorA

Inquadra un attore con la camera, come il tasto F nell'editor.

È il complemento di ue_screenshot: senza, si fotografa quello che la camera stava già guardando, che di rado è quello appena costruito.

Args: label: attore da inquadrare; se omesso usa la selezione corrente. distance: distanza della camera in cm (default 500).

ParametersJSON Schema

Name	Required	Description	Default
`label`	No
`distance`	No

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It explains that the tool moves the camera to focus on an actor, similar to the F key, and that using the selection when no label is given. However, it does not disclose potential side effects like persistence of camera position or any constraints.

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 concise, with two short paragraphs followed by an Args section. It front-loads the purpose and context, and each sentence adds value. Could be slightly more compact, but overall efficient.

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 simplicity of the tool (2 optional parameters, no output schema), the description covers the essential aspects: what it does, how parameters work, and relationship to a sibling tool. It is complete enough for an agent to select and 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 coverage is 0%, so the description must add meaning for parameters. It does so effectively: label is 'actor to focus; if omitted uses current selection,' and distance is 'camera distance in cm (default 500).' This provides clear guidance beyond the schema's type and default.

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 clearly states the tool focuses an actor with the camera, analogous to the F key in the editor. It distinguishes from sibling ue_screenshot by explaining that without it, the screenshot captures whatever the camera was already looking at, which is rarely the newly built object.

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 provides clear context on when to use this tool: as a complement to ue_screenshot to frame the actor before capturing. It implies that without this, the screenshot may not capture the intended actor. However, it does not explicitly state cases where the tool should not be used.

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

ue_foliage_add_instancesA

Piazza istanze di foliage alle trasformate date, nel livello corrente.

Args: foliage_type_path: path dell'asset FoliageType. transforms: lista di {"location": {...}, "rotation": {...}, "scale": {...}} — oppure di sole posizioni ([x,y,z] o {"x":..}) quando rotazione e scala non interessano. Le posizioni sono in cm: se il livello è costruito lontano dall'origine, leggi prima un attore di riferimento con ue_list_actors.

ParametersJSON Schema

Name	Required	Description	Default
`transforms`	Yes
`foliage_type_path`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

The description discloses the current-level scope and the coordinate system caveat, which adds behavioral context. However, with no annotations provided, it does not mention whether the operation is additive or replaces existing instances, nor does it discuss permissions, error handling, or the return value.

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 concise, well-structured with an Args section, and every sentence adds value. It is front-loaded with the primary purpose and then provides necessary parameter details without redundancy.

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?

For a two-parameter tool with no output schema or annotations, the description covers the essential usage context: what the tool does, parameter format, and coordinate origin concerns. It omits return value and error behaviors, which would be useful but are not critical for basic selection and invocation.

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?

Schema coverage is 0%, so the description fully compensates by explaining both parameters in detail. It defines `foliage_type_path` as the asset path and `transforms` as a list of either full transform objects or just positions, including the cm unit and origin reference tip.

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 clearly states the verb ('Piazza' / places), the resource (foliage instances), and the scope ('nel livello corrente' / in the current level). It distinguishes from sibling tools like `ue_foliage_scatter` by specifying 'alle trasformate date' (at the given transforms).

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 provides clear context on when to use the tool (when placing at specific transforms) and includes a practical tip about coordinate units (cm) and using `ue_list_actors` for reference if the level is far from the origin. It does not explicitly mention alternatives, but the purpose clarity implies the distinction.

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

ue_foliage_listA

Il foliage piazzato nel livello: mesh, componente e numero di istanze.

Elenca quello che c'è davvero nel livello, non i FoliageType come asset (per quelli usa ue_list_assets).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool lists only what is genuinely placed in the level (not assets), and describes the return content. However, it does not explicitly state side effects, permission requirements, or error behavior, but for a simple listing tool, the disclosed scope is adequate.

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?

Two concise sentences, front-loaded with the main purpose. The second sentence adds critical differentiation from a sibling tool. No wasted words, effectively structured.

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?

The tool is simple (no params, no output schema), but the description fully covers what the agent needs to know: what is listed (mesh, component, instance count) and the scope (level instances not asset definitions). It is complete given the tool's complexity.

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?

The input schema has zero parameters, and schema coverage is 100% (trivially). Per guidelines, a description with no params gets a baseline of 4. The description adds no redundant parameter details, but its mention of the output fields helps set expectations for the tool's behavior.

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 clearly states it lists foliage placed in the level, specifying the output fields (mesh, component, instance count). It explicitly contrasts with ue_list_assets for FoliageType assets, distinguishing it from a sibling tool. The verb 'Elenca' is specific and the resource is well-defined.

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

Usage Guidelines5/5

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

The description provides explicit guidance: use this tool to see actual level foliage, not asset definitions. It names the alternative tool (ue_list_assets) for the asset-focused case, making the when-to-use vs. when-not-to-use clear.

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

ue_foliage_queryA

Le istanze di un FoliageType dentro una sfera, con le loro trasformate.

Args: foliage_type_path: path dell'asset FoliageType. center: centro della sfera in cm. radius: raggio in cm. limit: quante trasformate restituire al massimo (il conteggio totale è sempre esatto).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`center`	Yes
`radius`	Yes
`foliage_type_path`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must carry the transparency burden. It discloses the limit behavior (max transforms returned, but total count always exact), which is useful. However, it doesn't clarify whether the operation is read-only, potential error conditions, or the exact return structure, leaving gaps.

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 concise and front-loaded: a short purpose statement followed by a compact Args list. Every sentence earns its place with no redundant content.

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

Completeness3/5

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

The description covers the main intent and all parameters, but because there is no output schema, it does not detail the structure of the returned transforms or handle edge cases like missing foliage types or empty results. This leaves some context incomplete.

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?

Given 0% schema description coverage, the description's Args section adds important meaning: units for center and radius (cm), and the semantic of limit (maximum transforms, total count exact). It enriches most parameters, though the format for 'center' (array vs object) is not specified.

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 clearly states the tool's function: it returns foliage instances of a FoliageType inside a sphere, including their transforms. This is specific and distinct from sibling tools like ue_foliage_list or ue_foliage_add_instances.

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

Usage Guidelines3/5

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

The description implies usage by defining a spherical query scope, but it does not explicitly mention when to prefer this tool over alternatives or any exclusions. It gives parameter context but no direct alternatives or when-not-to-use guidance.

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

ue_foliage_removeA

Toglie istanze di foliage: tutte, o solo quelle dentro una sfera.

Senza center e radius cancella tutte le istanze di quel FoliageType nel livello.

ParametersJSON Schema

Name	Required	Description	Default
`center`	No
`radius`	No
`foliage_type_path`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of disclosing behavior. It transparently states that without 'center' and 'radius' it removes all instances, which is key destructive behavior. However, it does not mention irreversibility, potential side effects on the level, error handling, or whether confirmation is needed. The description is honest but minimal.

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 two concise sentences with no filler. It front-loads the main action and then explains the conditional behavior, making efficient use of words while remaining clear.

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

Completeness3/5

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

The description covers the two main use cases (remove all, remove within sphere) but omits edge cases like specifying only one of center/radius. It also does not mention return values, coordinate space, or any prerequisites. For a simple tool with 3 parameters and no output schema, this is adequate but leaves notable gaps.

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 0%, so the description must compensate. It explains that 'center' and 'radius' define a sphere and that omitting both removes all instances, which adds meaning to the schema. However, it does not clarify the data format for 'center' (e.g., vector, coordinates), units for 'radius', or the behavior when only one of the two is provided. Partial compensation.

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 clearly states the tool's action: 'Toglie istanze di foliage' (removes foliage instances), identifying the specific resource (foliage instances) and distinguishing it from sibling tools like ue_foliage_add_instances and ue_foliage_list. It also clarifies the two modes: all instances or only those within a sphere, making the purpose specific and unambiguous.

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?

The description does not provide guidance on when to use this tool versus other foliage tools. It lacks explicit comparisons or exclusions, and the conditional behavior based on parameters is more about parameter semantics than usage context. There is no mention of scenarios where an alternative should be preferred.

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

ue_foliage_scatterA

Sparge N istanze a caso in un cerchio, appoggiandole al terreno.

È il tool da usare per riempire una zona: ue_foliage_add_instances vuole ogni trasformata scritta a mano.

Args: foliage_type_path: path dell'asset FoliageType. center: centro del cerchio in cm. radius: raggio in cm. count: quante istanze. seed: seme del generatore — passalo per ottenere due volte lo stesso risultato. align_to_ground: appoggia ogni istanza a terra con un line trace dall'alto. Senza, restano tutte alla quota del centro. z_offset: alza (o abbassa) di tanto ogni istanza dopo l'appoggio.

ParametersJSON Schema

Name	Required	Description	Default
`seed`	No
`count`	Yes
`center`	Yes
`radius`	Yes
`z_offset`	No
`align_to_ground`	No
`foliage_type_path`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: random scattering in a circle, optional ground alignment via line trace from above, z-offset adjustment, and seed for reproducibility. However, it does not specify whether instances are added to existing foliage or replace them, nor the coordinate space for the center point.

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 concise and well-structured: a one-sentence summary, a brief usage note, and a compact argument list. Every sentence earns its place, and the information is front-loaded.

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?

For a 7-parameter tool with no output schema and no annotations, the description covers the main purpose, usage context, and parameters thoroughly. However, it leaves a few gaps: the exact format of the 'center' point (object/array) is not explained, and it doesn't mention whether the operation overwrites existing instances or is purely additive.

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 description includes an Args section that explains every parameter in plain Italian: foliage_type_path (asset path), center (circle center in cm), radius, count, seed (for reproducible results), align_to_ground (line trace from above), z_offset (adjust after placement). This fully compensates for the 0% schema description coverage and provides meaning beyond the raw schema types and defaults.

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 clearly states the tool scatters N instances randomly in a circle and places them on the ground. It uses a specific verb ('sparge' / scatters) and resource (foliage instances in a circle), and distinguishes itself from sibling `ue_foliage_add_instances` by noting that the alternative requires hand-written transforms.

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

Usage Guidelines5/5

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

The description explicitly says 'È il tool da usare per riempire una zona' (this is the tool to use to fill an area) and contrasts it with `ue_foliage_add_instances`, which requires every transform to be written by hand. This gives clear when-to-use and when-not-to-use guidance.

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

ue_foliage_simulateA

Fa simulare il foliage procedurale di un volume — o lo azzera con clear=True. Da chiamare dopo aver cambiato lo spawner.

ParametersJSON Schema

Name	Required	Description	Default
`clear`	No
`label`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the clear=True reset behavior and the simulation trigger after spawner changes, but does not mention side effects of reset (e.g., destructive), whether simulation is async, or any required editor state.

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?

Single, efficient sentence that front-loads the main action. No wasted words, and the secondary behavior (clear) is appended clearly.

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

Completeness2/5

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

Despite being a simple tool, the description leaves critical context unexplained: what label refers to, what 'simulate' actually does in the engine, whether clear is irreversible, and what preconditions exist beyond 'after changing the spawner'. The brevity creates ambiguity for agent decision-making.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains clear=True but says nothing about the required 'label' parameter, leaving its meaning and usage entirely undocumented. This is a significant gap for an essential parameter.

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 clearly states the tool simulates procedural foliage for a volume, and also describes the clear=True reset behavior. It uses a specific verb (simulate) and resource (volume foliage), distinguishing it from sibling tools like scatter or generate.

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?

Provides explicit context: 'Da chiamare dopo aver cambiato lo spawner' (to call after changing the spawner). However, it does not mention alternatives or when not to use, so it lacks the full exclusions of a 5.

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

ue_foliage_spawn_volumeB

Piazza un ProceduralFoliageVolume con lo spawner già collegato.

Args: spawner_path: path del ProceduralFoliageSpawner. label: nome dell'attore nel livello. location: centro del volume in cm (occhio all'origine del mondo). size: dimensioni in cm. Default 200×200×200.

ParametersJSON Schema

Name	Required	Description	Default
`size`	No
`label`	No
`location`	No
`spawner_path`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It clearly states the result (places a volume with connected spawner), but does not mention side effects, required permissions, inherited transforms, behavior when spawner_path is invalid, or any details about what happens after placement. This is a thin disclosure for a placement command.

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 concise with a one-line purpose followed by a compact list of parameters. No redundant information, front-loaded, and every sentence contributes meaning. This is an efficient and well-structured description.

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

Completeness3/5

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

Given 4 parameters, no annotations, and no output schema, the description covers the essential purpose and parameter semantics but lacks usage context and potential caveats. It is sufficient for a simple placement tool, but misses guidance on prerequisites and failure modes, leaving it incomplete for an agent to use confidently.

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 0%, so the description must compensate. It provides units (cm) and a default for size, and explains the semantic meaning of each parameter (e.g., label is the actor name in the level). However, it does not explain the expected structure of location/size (e.g., Vector vs array), which limits the added value.

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 specific verb 'Piazza' (Places) and a concrete resource (ProceduralFoliageVolume), and clarifies that the spawner is already connected. This distinguishes it from siblings like ue_create_foliage_spawner, which creates a spawner asset, though it doesn't explicitly name the alternative.

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?

The phrase 'con lo spawner già collegato' implies that a spawner must exist beforehand, but there is no explicit guidance on when to use this tool versus alternatives such as ue_create_foliage_spawner or ue_pcg_spawn_volume. No exclusions or alternative tool references are provided.

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

ue_ge_add_componentA

Aggiunge un GameplayEffectComponent (es. "AssetTagsGameplayEffectComponent", "TargetTagRequirementsGameplayEffectComponent", "ChanceToApplyGameplayEffectComponent") a un GameplayEffect. Solo l'aggiunta: configurare tag/condizioni al suo interno non è coperto, usa ue_exec_python o l'editor.

ParametersJSON Schema

Name	Required	Description	Default
`ge_path`	Yes
`component_class`	Yes

TDQS

A4.2/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 discloses a key limitation ('Solo l'aggiunta') but omits details such as whether the GameplayEffect asset is saved, how duplicates are handled, or error behavior on invalid paths.

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 two sentences long, front-loaded with the core action, and contains no redundant information. Every word earns its place.

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 simple 2-parameter tool with no output schema, the description adequately covers purpose, scope, and alternative guidance. It would benefit from explicit ge_path semantics and persistence behavior, but the overall picture is functional for an agent.

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?

The input schema has 0% coverage, so the description must compensate. It provides example values for component_class and implies ge_path is the path to the GameplayEffect, but it does not explicitly define ge_path's format or the precise relationship between the two parameters.

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 states a clear action ('Aggiunge' - adds) and target ('a un GameplayEffect'), provides concrete examples of component classes, and explicitly limits scope to addition only, distinguishing it from sibling tools like ue_ge_add_modifier.

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

Usage Guidelines5/5

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

The description explicitly states when not to use the tool: configuring tags/conditions is not covered, and it directs the user to 'ue_exec_python o l'editor' as alternatives. This gives clear when/when-not guidance.

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

ue_ge_add_modifierA

Aggiunge un modifier a un GameplayEffect: collega un attributo di un AttributeSet Blueprint esistente, un'operazione e un valore fisso.

Aggira un limite della Python API di UE (vedi nota sopra): il modo normale di costruire un modifier è bloccato, questo tool lo aggira con una tecnica di serializzazione testuale. Solo ScalableFloat costante, niente curve o attribute-based magnitude per ora.

Args: ge_path: path del GameplayEffect Blueprint. attribute_set_path: path dell'AttributeSet Blueprint che possiede l'attributo. attribute_name: nome della variabile GameplayAttributeData su quell'AttributeSet (es. "Health"). modifier_op: "add" | "add_final" | "multiply" | "divide" | "multiply_compound" | "override". magnitude: valore fisso applicato (es. -10 per un danno di 10).

ParametersJSON Schema

Name	Required	Description	Default
`ge_path`	Yes
`magnitude`	Yes
`modifier_op`	Yes
`attribute_name`	Yes
`attribute_set_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses a textual serialization workaround and only supports constant ScalableFloat, which are important behavioral traits. It doesn't mention whether the asset is saved or what happens to existing modifiers, but the workaround detail adds transparency beyond a generic 'adds a modifier'.

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 well-structured with a summary, workaround note, and parameter list. Each sentence adds value. The reference 'vedi nota sopra' (see note above) is a minor issue because no note appears in the provided input, slightly hurting standalone clarity.

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?

With 5 parameters and no output schema, the description explains the purpose, mechanism, limitations, and all arguments. It lacks explicit return-value behavior and prerequisites (e.g., asset must exist), but overall it covers the essential context for an agent to invoke the tool correctly.

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?

Schema description coverage is 0%, but the description documents every parameter with meaning: ge_path, attribute_set_path, attribute_name with example ('Health'), modifier_op with allowed values, and magnitude with a usage example ('-10 per un danno di 10'). This fully compensates for the schema's lack of descriptions.

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 starts with a specific verb and resource: 'Aggiunge un modifier a un GameplayEffect' (Adds a modifier to a GameplayEffect), then explains what it links (attribute, operation, value). This clearly distinguishes it from sibling tools like ue_ge_add_component (components) and ue_create_gameplay_effect (creation).

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 explains why this tool exists (bypasses a blocked Python API) and explicitly states limitations ('Solo `ScalableFloat` costante, niente curve o attribute-based magnitude per ora'), which tells the agent when not to use it. It doesn't name alternative tools for curved magnitudes, but the exclusion is clear.

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

ue_ge_infoB

Duration policy, periodo, modifier (attributo/operazione/valore) e GameplayEffectComponent di un GameplayEffect esistente.

ParametersJSON Schema

Name	Required	Description	Default
`ge_path`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

The description lists the exact data fields returned, which goes beyond a generic 'get info' statement. However, with no annotations, it does not explicitly state read-only behavior, potential errors, or prerequisites, leaving some ambiguity about side effects or required permissions.

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 a single, compact sentence that efficiently lists all relevant return fields. Every word earns its place, and the structure is easy to parse. No fluff or redundancy.

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

Completeness3/5

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

The tool is simple (one parameter, no output schema) and the description lists the return fields, which is helpful. However, it does not explain the parameter's purpose or any edge cases. For a read/info tool, this is adequate but not complete; the agent may need to infer path conventions.

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

Parameters2/5

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

The single parameter 'ge_path' is not described in the schema or description. Although the name is self-explanatory, the description does not add any additional context about path format, supported asset types, or required precisions. With 0% schema coverage, more compensation was expected.

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 identifies the resource (existing GameplayEffect) and the specific information returned (Duration policy, period, modifiers, components). It is distinct from sibling tools like ue_create_gameplay_effect or ue_ge_add_modifier, though it lacks an explicit verb like 'Get' or 'Retrieve'.

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

Usage Guidelines3/5

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

Usage is implied by the tool name and description (inspect a GameplayEffect), but it does not explicitly state when to use against alternatives or mention exclusions. The distinction from creation/modification tools is clear from sibling names, but no direct guidance is provided.

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

ue_get_cameraA

Posizione e orientamento della camera della viewport dell'editor.

Da chiamare prima di spawnare: i livelli veri sono spesso costruiti a migliaia di unità dall'origine, e un attore messo a [0,0,0] finisce fuori campo, invisibile a chi guarda l'editor.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/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 states the tool gets camera data and provides timing advice, but does not disclose details like return format, potential blocking, or read-only nature. It is adequate but not thorough.

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 composed of two concise sentences: the first states the purpose, the second provides a usage guideline. No unnecessary words.

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?

For a simple getter with no parameters and no output schema, the description captures the core function and critical usage advice. It could optionally mention the return data type, but overall it is complete enough.

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?

The input schema has no parameters, so schema coverage is 100%. Baseline is 3 as the description adds no parameter-specific detail, which is acceptable.

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 clearly states the tool obtains the camera's position and orientation ("Posizione e orientamento della camera"), which is a specific verb+resource combination. It distinguishes itself from sibling tools like ue_set_camera by being a getter.

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 advises calling this tool before spawning actors ("Da chiamare prima di spawnare") and explains why actors at origin may be off-screen. It does not mention alternatives or when not to use, but the context is clear.

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

ue_import_assetsA

Importa file 3D/audio (.glb, .gltf, .fbx, .wav) nel Content Browser.

I .glb/.gltf passano dal framework Interchange nativo. Per i personaggi con scheletro usare .fbx con import_as_skeletal=True.

Args: files: percorsi assoluti sul disco (es. ["C:/Assets/Rocks/rock_01.glb"]). destination: cartella Unreal di destinazione (/Game/...). replace_existing: sovrascrive asset con lo stesso nome. import_as_skeletal: per .fbx, importa come Skeletal Mesh con animazioni.

ParametersJSON Schema

Name	Required	Default
`files`	Yes
`destination`	No	/Game/Imported
`replace_existing`	No
`import_as_skeletal`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 carries the full burden. It mentions that GLB/GLTF go through Interchange and that replace_existing controls overwriting. This gives a clear behavioral picture without contradictions.

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 concise and well-structured, starting with a main line, followed by technical notes, and then a clear parameter listing with examples. Every sentence adds value.

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?

Given the tool's complexity (multiple formats, skeletal handling), the description covers all necessary aspects: supported formats, framework usage, parameter semantics, and intent. No gaps remain.

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?

Despite 0% schema coverage, the description explains each parameter in detail, including absolute paths, destination folder, and the role of import_as_skeletal for FBX. This fully compensates for the lack of schema descriptions.

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 clearly states that the tool imports 3D/audio files into the Content Browser, listing specific formats. The verb 'import' and resource 'assets' are explicit, and it distinguishes itself from sibling tools like ue_import_audio by being more general.

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 provides specific guidance for when to use import_as_skeletal with FBX files and mentions the Interchange framework for GLB/GLTF. It lacks explicit 'when not to use' statements, but the sibling tools list implies specialization.

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

ue_import_audioB

Importa file .wav come SoundWave nel Content Browser.

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes
`destination`	No		/Game/Audio

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, placing the burden on the description. The description does not disclose behavioral traits such as overwrite behavior, permissions required, error handling, or side effects. It only states the basic action.

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

Conciseness3/5

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

The description is extremely concise at one sentence in Italian. While not verbose, it is under-specified for a tool requiring parameter clarification. It lacks structure or any elaboration beyond the core purpose.

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

Completeness2/5

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

Given the tool has 2 parameters and an output schema (not shown), the description should complement these. It does not mention what the tool returns (e.g., asset path, success status) or provide context beyond the import action. The description is insufficient for the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must clarify parameter semantics. It does not explain what the 'files' array expects (e.g., file paths or names) or how the 'destination' path is relative. The default value is mentioned in the schema but not elaborated in the description.

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 clearly states the tool imports .wav files as SoundWave assets into the Content Browser. It specifies the file type, target asset type, and destination, distinguishing it from sibling tools like ue_import_assets and ue_create_sound_cue.

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

Usage Guidelines3/5

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

The description implies usage for importing audio files but does not explicitly state when to use this tool versus alternatives like ue_import_assets or when not to use it. No comparative guidance is provided.

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

ue_landscape_export_heightmapA

Esporta l'heightmap del landscape come immagine sul disco.

Il formato del file lo decide il render target: RGBA8 esce in PNG, i formati float in HDR.

Args: output_dir: cartella locale di destinazione. file_name: nome del file, estensione compresa. label: quale landscape, se il livello ne ha più di uno. resolution: lato del render target in pixel (quadrato). rt_format: "RGBA8" | "RGBA16f" | "RGBA32f". into_rg_channel: comprime i 16 bit di altezza nei canali R e G.

ParametersJSON Schema

Name	Required	Default
`label`	No
`file_name`	Yes
`rt_format`	No	RGBA8
`output_dir`	Yes
`resolution`	No
`into_rg_channel`	No

TDQS

A3.9/5.0

Behavior3/5

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

The description adds useful behavioral context by explaining that RGBA8 outputs PNG while float formats output HDR, and that into_rg_channel packs 16-bit height data into R and G channels. However, it does not disclose side effects like file overwriting, directory creation, or behavior when the specified landscape doesn't exist. With no annotations, the description carries the burden but leaves some gaps.

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 concise and well-structured: a single-sentence purpose, a brief note on format behavior, then a clean list of parameter explanations. No wasted words; each sentence earns its place.

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?

The description covers all parameters and key format behavior, making it largely complete for a 6-parameter export tool with no annotations. However, it omits some contextual details such as whether the output directory is created automatically, whether existing files are overwritten, or how errors are handled when the landscape is missing. These are non-critical gaps given the thorough parameter documentation.

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?

All six parameters are explicitly described with clear semantics: output_dir is the local destination folder, file_name includes the extension, label selects the landscape, resolution sets the square render target side, rt_format enumerates accepted values, and into_rg_channel explains the channel packing. This fully compensates for the 0% schema description coverage.

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 clearly states the tool's purpose: 'Esporta l'heightmap del landscape come immagine sul disco' (exports the landscape heightmap as an image to disk). It uses a specific verb and resource, and is easily distinguished from siblings like ue_landscape_import_heightmap.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, context, or exclusions. It only states what the tool does, leaving the agent to infer usage from the name and purpose.

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

ue_landscape_import_heightmapA

Sovrascrive l'heightmap di un landscape con un'immagine dal disco.

L'immagine viene importata come texture e disegnata in un render target temporaneo, che è l'unica forma in cui Unreal accetta un heightmap da script. Sovrascrive il terreno esistente: non è annullabile oltre l'undo dell'editor.

Args: image_path: file locale (PNG, EXR, TGA…). Va portato alla risoluzione del landscape prima: il render target non lo riscala. label: quale landscape, se il livello ne ha più di uno. rt_format: "RGBA8" (8 bit, 256 livelli di altezza) | "RGBA16f" | "RGBA32f". Per un heightmap a 16 bit serve un formato float. from_rg_channel: solo per i formati float — legge l'altezza dai canali R e G invece che dal solo R, che è come Unreal codifica i 16 bit.

ParametersJSON Schema

Name	Required	Default
`label`	No
`rt_format`	No	RGBA8
`image_path`	Yes
`from_rg_channel`	No

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly: it warns that the tool overwrites existing terrain and is not undoable beyond editor undo, explains the render-target mechanism, and notes format-specific behavior like the R/G channel reading for 16-bit heightmaps.

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: a one-sentence purpose, a short technical explanation, and a clear Args list. Every sentence adds value and there is no 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?

Given no annotations and no output schema, the description still provides everything an agent needs to select and invoke the tool: purpose, mechanism, prerequisites, parameter semantics, and destructive behavior. Minor edge cases like label omission are not covered, but the core selection and invocation context is complete.

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 Args section explains every parameter despite 0% schema coverage: image_path local file types and resolution prerequisite, label disambiguation, rt_format options with bit-depth implications, and from_rg_channel behavior for float formats. This fully compensates for the schema.

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 action: 'Sovrascrive l'heightmap di un landscape con un'immagine dal disco' (overwrites a landscape's heightmap with an image from disk). This clearly distinguishes it from sibling tools such as ue_landscape_export_heightmap and ue_landscape_import_weightmap.

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 provides clear usage context: the image must be at the landscape's resolution because the render target won't rescale, and it explains the render-target approach is the only way Unreal accepts a heightmap via script. It doesn't explicitly name alternatives or when not to use this tool, so it isn't a 5.

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

ue_landscape_import_weightmapA

Dipinge un layer del landscape da un'immagine in scala di grigi (bianco = layer al massimo, nero = assente).

Il layer deve già esistere: i target layer nascono dal materiale del landscape, ue_landscape_info li elenca.

ParametersJSON Schema

Name	Required	Default
`label`	No
`rt_format`	No	RGBA8
`image_path`	Yes
`layer_name`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must cover behavior. It discloses the color mapping (white=max, black=absent) and prerequisite that the layer must pre-exist. However, it does not mention potential overwriting, image format/size requirements, or result reporting, leaving notable behavioral gaps.

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 two sentences, front-loaded with the main action, and ends with the key prerequisite. Every word earns its place with no fluff or repetition.

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

Completeness3/5

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

Given the tool's moderate complexity, no annotations, no output schema, and 0% schema description coverage, the description provides essential context (color mapping, prerequisite) but omits critical operational details like supported image formats, overlay behavior, and any return values. It is minimally viable but not comprehensive.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It implicitly relates layer_name (target layer) and image_path (immagine), but does not explain the rt_format or label parameters at all. The coverage is incomplete and not explicit enough for an agent to confidently fill all parameters.

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 clearly states it paints a landscape layer from a grayscale image, using an explicit verb (Dipinge) and resource (layer del landscape). It distinguishes from sibling tools like ue_landscape_import_heightmap by focusing on weightmap layers rather than heightmaps.

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 provides clear context: the layer must already exist and lists where to find available layers via ue_landscape_info. It does not explicitly mention when to avoid this tool or directly compare with alternatives like the heightmap importer, but the precondition and reference to a sibling tool give solid guidance.

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

ue_landscape_infoA

Componenti, materiale, target layer di pittura ed edit layer di un landscape. Con un solo landscape nel livello label si può omettere.

ParametersJSON Schema

Name	Required	Description	Default
`label`	No

TDQS

A3.6/5.0

Behavior3/5

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

The description discloses the types of information returned (components, material, paint/edit layers), giving some insight into the tool's output. However, with no annotations, it does not explicitly state read-only behavior, side effects, or what happens if the label is invalid or no landscape exists. The 'info' name implies read-only, but the description does not confirm it.

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 two short sentences, front-loaded with the core purpose and a practical usage tip. There is no redundant information, and every sentence contributes to understanding the tool.

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

Completeness3/5

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

For a simple info tool with one optional parameter, the description lists the key return categories but does not specify the structure of the response (no output schema exists). It also lacks error handling behavior or preconditions. While adequate for basic use, it leaves gaps for edge cases and return format clarity.

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?

The input schema only defines label as an optional string/null without explanation. The description adds meaningful context by explaining that label can be omitted when there is only one landscape in the level. This goes beyond the schema's default null and helps the agent decide when to pass the parameter, though it does not clarify the label format or how to obtain it.

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 identifies the tool as retrieving landscape information (components, material, paint target layer, edit layer). It distinguishes from sibling tools like ue_landscape_list or ue_landscape_import_heightmap, which handle listing/importing. The resource (landscape) and the specific info fields are named, making the purpose understandable.

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

Usage Guidelines3/5

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

There is a useful usage note: 'Con un solo landscape nel livello label si può omettere' indicates when the label parameter can be omitted. However, there is no explicit guidance on when to use this tool vs alternatives, nor any exclusion criteria. The context is implied by the tool type but not directly stated.

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

ue_landscape_listA

I landscape presenti nel livello corrente.

Se la lista è vuota il livello non ha terreni, e nessun altro tool di questa famiglia ha su cosa lavorare: aggiungine uno dall'editor con Landscape Mode (Python non può crearlo).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/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 discloses that the tool lists current-level landscapes, defines what an empty list means, and reveals a key limitation: Python cannot create landscapes. It does not describe the exact return format, but that is a minor gap for a simple listing tool.

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 two sentences with no filler. The first sentence states the core purpose, and the second adds a crucial empty-list caveat and a workaround. Every sentence earns its place.

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 parameterless list tool with no output schema and no annotations, the description is complete: it states what is listed, how to interpret the result, implications for sibling tools, and how to proceed if no landscapes exist. An agent can confidently select and invoke this tool.

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?

The tool has zero parameters, so there is nothing to explain. The description's reference to 'livello corrente' effectively defines the implicit scope, and no parameter details are needed.

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 identifies the resource ('landscape presenti nel livello corrente') and clearly implies a list operation, reinforced by 'Se la lista è vuota'. However, the first sentence is a noun phrase rather than an explicit verb phrase like 'Elenca i landscape', so it is slightly less direct.

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

Usage Guidelines5/5

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

The description explicitly tells the agent when to use this tool: check if landscapes exist before using other landscape tools, because 'nessun altro tool di questa famiglia ha su cosa lavorare'. It also gives the alternative action (add landscapes from the editor in Landscape Mode) and explains that Python cannot create them.

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

ue_landscape_set_grassB

Accende o spegne il grass system del landscape (l'erba procedurale generata dal materiale).

ParametersJSON Schema

Name	Required	Description	Default
`label`	No
`enabled`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the core toggle behavior and defines what the grass system is, but does not disclose whether the change is persistent, whether a landscape must be selected, what side effects occur, or what the return value is. This is insufficient for a mutating tool with no annotations.

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 a single concise, front-loaded sentence with no filler. It efficiently communicates the action and the domain of the effect.

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

Completeness3/5

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

This is a simple tool with two optional parameters and no output schema, so the description doesn't need to be extensive. It covers the core operation, but leaves gaps around the label parameter and behavioral side effects, making it minimally adequate rather than complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate. It implicitly maps 'enabled' to the on/off action, but it does not explain the 'label' parameter at all, and neither parameter's semantics are explicitly described beyond what the schema already shows.

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 uses a clear action ('Accende o spegne' / turns on or off) and a specific resource ('grass system del landscape'), and clarifies that this is procedural grass generated by the material. This distinguishes it from sibling landscape tools like ue_landscape_set_material or ue_landscape_import_heightmap.

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

Usage Guidelines3/5

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

The usage context is implied: use this tool when you want to enable or disable the landscape's procedural grass. However, it does not explicitly mention when to prefer this over alternatives or any exclusions/prerequisites, so guidance is minimal.

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

ue_landscape_set_materialA

Assegna il materiale al landscape. È il materiale che definisce quali target layer si possono dipingere: cambiarlo cambia la lista.

ParametersJSON Schema

Name	Required	Description	Default
`label`	No
`material_path`	Yes

TDQS

A3.8/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 discloses a key behavioral side effect: 'cambiarlo cambia la lista' (changing it changes the list of paintable layers), which adds useful context. However, it omits other relevant behavioral details such as prerequisites (e.g., landscape selection), reversibility, or whether painted layers are affected, leaving gaps for a mutation tool.

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 two short sentences in Italian, immediately stating the action and then adding the crucial context about target layers. Every word earns its place; there is no waste or repetition, and it is appropriately front-loaded.

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

Completeness3/5

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

For a simple set-material operation, the description covers the essential side effect and provides some context. However, it lacks explanation of the label parameter, does not mention any prerequisites or conditions, and with no output schema it leaves the return behavior unspecified. It is adequate but has clear gaps.

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

Parameters2/5

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

The schema has no descriptions for the two parameters (material_path and label), and the description only indirectly references material_path through the concept of 'material'. The label parameter is completely unexplained, and the description does not compensate for the 0% schema coverage. This leaves the agent guessing about label's purpose and format.

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 uses a specific verb ('Assegna' = assigns) and resource ('materiale al landscape'), clearly stating the tool's function. It further distinguishes itself from sibling landscape tools by explaining the material's role in defining paintable target layers, which is unique to this operation.

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 provides clear context for when to use this tool: when you need to assign a material that determines the paintable target layers. It doesn't explicitly name alternatives or exclusions, but it implies the use case by explaining the consequence of changing the material. This meets the 'clear context, no exclusions' level.

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

ue_list_actor_componentsA

Elenca i componenti di un attore piazzato, con nome e classe.

Serve a sapere cosa passare come component a ue_set_actor_property.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the tool lists components but does not explicitly state it is safe/read-only, rate limits, or any side effects. Basic information is present but incomplete.

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?

Two sentences conveying essential purpose and usage. No unnecessary words, front-loaded with core action.

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 no output schema, the description states the tool returns name and class, which is sufficient for a list tool. It does not describe ordering or filtering, but for this simple tool it is largely complete.

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 coverage is 0%. The description adds that the `label` parameter identifies a placed actor, but does not explain format or constraints beyond that. It adds some meaning but not enough to fully compensate for the missing schema descriptions.

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 clearly states it lists components of a placed actor with name and class, and identifies the purpose: to know what to pass as `component` to ue_set_actor_property. This verb+resource phrasing distinguishes it from sibling tools.

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 tells when to use it (to get component names for ue_set_actor_property) but does not provide explicit when-not-to-use or alternatives. Given the context of sibling tools, it is clear enough.

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

ue_list_actorsA

Elenca gli attori del livello corrente, con filtri opzionali su nome e classe.

ParametersJSON Schema

Name	Required	Description	Default
`name_contains`	No
`class_contains`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the main behavior (listing actors of current level with filters) but does not detail side effects, performance, or read-only nature. Adequate for a simple query tool.

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?

A single sentence that front-loads the main action and filters. Every part is essential, no wasted words.

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 simplicity (2 optional params, no required ones) and the presence of an output schema, the description is nearly complete. It could mention the default behavior (lists all actors) but is sufficient.

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 coverage is 0%, so the description must compensate. It maps 'name' and 'class' to the parameters but does not clarify substring matching or case sensitivity. Partially helpful but lacks specifics.

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 clearly states the tool lists actors of the current level with optional filters, distinguishing it from sibling tools like ue_list_assets (which lists assets) and ue_actor_hierarchy (which shows hierarchy).

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

Usage Guidelines3/5

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

No explicit guidance on when to use vs alternatives; the context implies it is for listing actors with filters, but no when-not or alternative tools are mentioned.

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

ue_list_assetsA

Elenca gli asset presenti sotto un path del Content Browser.

Args: path: cartella Unreal (es. "/Game/MyGame"). recursive: include le sottocartelle. class_filter: filtro parziale sul nome classe (es. "Blueprint", "StaticMesh").

ParametersJSON Schema

Name	Required	Default
`path`	No	/Game
`recursive`	No
`class_filter`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits beyond the basic listing action. It fails to mention that the tool is read-only, whether there are limits on recursion depth, or performance considerations, leaving gaps for the agent.

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 concise, with three sentences for purpose and parameter explanations. It front-loads the main action and uses a structured args list, though some details could be integrated into the schema.

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

Completeness3/5

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

The description covers the essential usage but lacks details on default behavior (e.g., recursive=true), output format, and edge cases. Given the output schema exists, return values are covered, but additional context like case-sensitivity of class_filter would improve completeness.

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?

With 0% schema description coverage, the description adds significant value by explaining each parameter: path (example '/Game/MyGame'), recursive (include subfolders), and class_filter (partial class name filter). This compensates for the lack of schema descriptions.

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 states 'Elenca gli asset presenti sotto un path del Content Browser' (list assets under a path of the Content Browser), providing a specific verb (list) and resource (assets under a path). This clearly distinguishes it from sibling tools like ue_delete_asset or ue_import_assets.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. While it implies usage for listing assets, it lacks exclusions or context that would help an agent decide between this and similar tools like ue_list_actors.

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

ue_live_compileA

Ricompila il C++ senza chiudere l'editor, tramite Live Coding.

È la via veloce per iterare: nessuna chiusura, nessun riavvio, il gioco riparte con il codice nuovo. Funziona però solo sulle modifiche al corpo delle funzioni: aggiungere o cambiare UCLASS, UFUNCTION o UPROPERTY altera i dati di reflection e richiede ue_build_start a editor chiuso.

Args: max_wait_seconds: quanto attendere l'esito prima di restituire "in corso" (la compilazione prosegue comunque).

ParametersJSON Schema

Name	Required	Description	Default
`max_wait_seconds`	No

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It explains that the tool does not close the editor, is fast, but limited to function bodies. It does not mention error handling or return values, but the core behavioral constraints are well communicated.

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 very concise, with no redundant sentences. It front-loads the main purpose and uses a clear structure. Every sentence adds value.

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?

Given the single parameter and no output schema, the description provides sufficient context: when to use, limitations, and alternative tool. It is complete enough for an agent to correctly select and invoke this tool.

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 coverage is 0%, so description must compensate. The Args section explains max_wait_seconds: it controls how long to wait for result before returning 'in corso' (in progress), with compilation continuing. This adds context beyond the default value in schema.

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 clearly states that this tool recompiles C++ without closing the editor (Live Coding), and distinguishes itself from full rebuilds by specifying it only works on function body changes. It explicitly names the alternative tool ue_build_start for structural changes.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool (for fast iteration on function body changes) and when not to use it (for changes that alter reflection data like UCLASS/UFUNCTION/UPROPERTY, which require ue_build_start with editor closed). This provides clear guidance.

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

ue_make_folderA

Crea una cartella nel Content Browser. Idempotente.

Args: path: es. "/Game/MyGame/Meshes".

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses idempotency, a key behavioral trait, and the example implies nested folder creation. However, it does not cover error cases or permission requirements.

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 extremely concise (two sentences plus args), with no unnecessary words. The main purpose is stated first, and the example is efficiently placed.

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 simplicity (one parameter, no output schema) and the idempotency guarantee, the description covers essential use. It could mention that the path is relative to the /Game root, but the example makes that clear.

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 coverage is 0%, but the description adds meaning by providing an example path format ('/Game/MyGame/Meshes') that clarifies the expected structure beyond the schema's simple string type.

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 explicitly states 'Crea una cartella nel Content Browser' (creates a folder in the Content Browser), clearly identifying the verb, resource, and context. No sibling tool performs this function, so differentiation is inherent.

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 usage is straightforward: create a folder. The idempotency note and example path provide practical guidance. While no explicit 'when to use' is given, the tool's uniqueness among siblings makes it implied.

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

ue_nav_find_pathA

Calcola un percorso sul navmesh tra due punti (pathfinding sincrono, non serve il PIE in esecuzione).

Args: start, end: {"x":.., "y":.., "z":..} in centimetri.

ParametersJSON Schema

Name	Required	Description	Default
`end`	Yes
`start`	Yes

TDQS

A3.8/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 burden of behavioral disclosure. It adds that the operation is synchronous and independent of PIE, which is valuable. However, it does not describe the return format (e.g., list of path points) or behavior when no path is found, leaving significant gaps without an output schema.

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 extremely concise, using two short sentences to convey purpose, behavioral traits, and parameter structure. It is front-loaded with the main action and avoids any filler, every sentence earning its place.

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

Completeness3/5

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

The description gives core information for invocation (coordinates, no PIE, synchronous) but omits return value details and failure scenarios. Given there is no output schema and no annotations, the description alone is insufficient for a fully informed agent expecting to handle results or errors gracefully.

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?

The schema provides only generic object types with additionalProperties, so the description's explicit specification of 'start, end: {"x":.., "y":.., "z":..} in centimetri' is essential. It compensates for the 0% schema coverage by clarifying the coordinate format and units, making parameter usage clear.

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 tool computes a path on the navmesh between two points ('Calcola un percorso sul navmesh tra due punti'). It uses a specific verb and resource, making the primary purpose evident. However, it does not explicitly distinguish itself from sibling tools like ue_nav_query_point, though the path-vs-point distinction is implicit.

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 provides useful context by noting that pathfinding is synchronous and does not require PIE to be running ('non serve il PIE in esecuzione'). This helps the agent understand when it can be called. No alternatives or exclusions are mentioned, so it falls short of a full comparison.

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

ue_nav_query_pointA

Trova un punto raggiungibile a caso sul navmesh entro un raggio da un'origine.

Args: origin: {"x":.., "y":.., "z":..} in centimetri. radius: raggio di ricerca in centimetri.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes
`radius`	No

TDQS

A3.9/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 behavior. It mentions the random reachable nature and units (centimetri), but does not describe the return value, failure modes (e.g., if no point is found), or any side effects. This is a significant gap for a tool with no output schema.

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 extremely concise: a single imperative sentence followed by a brief argument list. Every sentence serves a purpose, and the key behavior is front-loaded. No waste.

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

Completeness3/5

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

As a simple query tool, the description covers the core action and arguments, but it lacks return-value information, which is essential given there is no output schema. It also does not discuss edge cases or prerequisites. Overall, it is adequate for basic understanding but has clear gaps in completeness.

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?

The input schema provides only types and a default, with 0% parameter descriptions. The description compensates by explaining that 'origin' is a dict of x,y,z in centimeters and that 'radius' is in centimeters, adding meaningful semantic detail beyond the schema. It does not, however, elaborate on radius's default or acceptable ranges.

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 clearly states the tool's function: 'Trova un punto raggiungibile a caso sul navmesh entro un raggio da un'origine' (find a random reachable point on the navmesh within a radius from an origin). It specifies a unique verb (find), resource (navmesh point), and scope (radius from origin), distinguishing it from siblings like ue_nav_find_path and ue_nav_rebuild.

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 implies its usage context: when a random reachable navmesh point is needed. It does not explicitly mention exclusions or alternatives, but the unique 'random' and 'reachable' qualifiers provide clear context that differentiates it from pathfinding or rebuilding tools. No explicit alternatives are stated, but the function is self-evident.

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

ue_nav_rebuildA

Rigenera il navmesh del livello corrente (equivalente al comando console RebuildNavigation). Serve almeno un NavMeshBoundsVolume nel livello: piazzalo con ue_spawn_actor (classe "NavMeshBoundsVolume").

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses the essential behavioral trait that this is a regeneration operation equivalent to a known console command, and it surfaces the critical precondition about NavMeshBoundsVolume. It does not detail potential side effects, failure modes, or output behavior, but for a zero-parameter rebuild action this is reasonably transparent.

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 two sentences: the first states the core action and equivalent command, the second gives the necessary setup requirement and a cross-reference to another tool. Every sentence serves a purpose, and the most important information is front-loaded.

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 tool with no parameters and no output schema, this description is complete: it explains what the tool does, the scope (current level), the equivalent console command, the required precondition, and how to satisfy that precondition using a sibling tool. There are no significant gaps given the tool's simplicity.

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?

The tool has no parameters, so there is nothing to describe beyond the schema. The baseline for zero-parameter tools is 4, and the description appropriately focuses on prerequisites and action semantics rather than parameter details.

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 clearly states the tool 'Rigenera il navmesh del livello corrente' (regenerates the current level's navmesh), with a specific verb and resource. It also distinguishes itself from sibling navigation tools like ue_nav_query_point and ue_nav_find_path by focusing on rebuilding rather than querying or pathfinding.

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 provides an explicit prerequisite (at least one NavMeshBoundsVolume) and even directs the user to the appropriate sibling tool (ue_spawn_actor) to place it. It equates the action to the console command RebuildNavigation, giving clear context, though it does not explicitly state when not to use it or how it compares to alternative navigation tools.

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

ue_net_infoC

Stato di rete completo di un Blueprint: replication, dormancy, frequenze, priorità, relevancy e quali componenti replicano.

ParametersJSON Schema

Name	Required	Description	Default
`blueprint_path`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description fails to explicitly state that this is a read-only query or discuss any side effects, error conditions, or requirements. It only lists the contents of the output, which is useful context but not full behavioral disclosure.

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 a single concise sentence with a clear list; no redundant words. It is front-loaded with the main subject.

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

Completeness2/5

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

Given no output schema and no annotations, the description lacks guidance on the return format, parameter usage, and any prerequisites. It provides a useful overview of the data content but is insufficient for correct invocation.

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

Parameters1/5

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

Schema coverage is 0%, and the description never explains the required 'blueprint_path' parameter. It mentions 'a Blueprint' but does not clarify whether the path should be a file path or asset name, leaving the agent without needed semantics.

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 indicates the tool retrieves a Blueprint's network state, listing specific attributes (replication, dormancy, frequencies, priorities, relevancy, and which components replicate). It distinguishes from sibling setter tools like ue_set_replication, though it lacks an explicit verb like 'get' or 'list'.

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 provided on when to use this tool instead of siblings; it does not mention alternatives or prerequisites such as having a loaded Blueprint. Usage is only implied by the word 'info' in the name.

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

ue_new_levelA

Crea un nuovo livello e lo apre.

Args: path: path completo del livello, es. "/Game/MyGame/Levels/L_Main". template: livello sorgente da duplicare (opzionale).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`template`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It mentions creation and opening, but does not disclose potential side effects, such as what happens if the path already exists or any authorization needs.

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 extremely concise: a one-sentence purpose followed by parameter documentation in a standard docstring format. No wasted words.

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 low schema coverage and no output schema, the description provides essential coverage for purpose and parameters. However, it omits behavioral details like error handling or return value indication. Adequate but with minor gaps.

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 coverage is 0%, but the description adds meaning by providing an example path format and explaining that the template parameter is optional and used for duplication. This compensates well for the missing schema descriptions.

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 clearly states it creates a new level and opens it, using a specific verb and resource. Among sibling tools like ue_open_level and ue_save_all, this tool is distinct.

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

Usage Guidelines3/5

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

The description implies usage for creating new levels, but does not explicitly differentiate from alternatives or state when not to use it. No when-to-use or when-not-to-use guidance is provided.

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

ue_niagara_system_infoA

Emitter e parametri esposti (user parameters) di un Niagara System esistente.

Funziona a livello di asset: non serve un PIE in esecuzione né un componente istanziato in scena.

Args: system_path: es. "/Game/MyGame/VFX/NS_Explosion".

ParametersJSON Schema

Name	Required	Description	Default
`system_path`	Yes

TDQS

A3.9/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 of behavioral disclosure. It adds a valuable detail that the tool operates on the asset directly without requiring a running game instance, but it does not explicitly state whether the operation is read-only, nor does it describe the return format or any side effects.

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 concise, with no filler. It leads with the core purpose and immediately provides the key usage caveat (asset-level, no PIE). The argument example is clearly separated under 'Args:', making the structure easy to scan.

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?

For a simple one-parameter info tool without an output schema, the description covers the essential aspects: what is returned, the asset-level operation mode, and a parameter example. It stops short of specifying whether the asset must already exist or how errors are handled, but is overall adequate for the tool's simplicity.

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?

The schema provides only the parameter name and type (string), while the description supplements it with an example path ('/Game/MyGame/VFX/NS_Explosion'). This gives practical meaning to the expected format, though it doesn't exhaustively detail path validation or allowed patterns.

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 tool returns emitter and user parameter information for a Niagara System asset. It specifies the resource (Niagara System) and the type of info (emitters and exposed parameters), but does not explicitly differentiate from sibling info tools like ue_pcg_graph_info or ue_anim_sequence_info.

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 gives a clear usage context: it works at asset level and does not require an active PIE session or an instanced scene component. This helps the user understand when it's appropriate to call the tool, though it does not mention alternatives or explicit exclusions.

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

ue_open_levelC

Apre un livello esistente nell'editor.

Args: path: es. "/Game/MyGame/Levels/L_Main".

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

C2.9/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 convey behavioral traits. It only states it opens an existing level, without disclosing side effects like closing the current level, handling unsaved changes, or requiring the level to exist. The description is insufficient for a tool with no annotations.

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

Conciseness3/5

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

The description is very short, consisting of one line plus a parameter example. It is front-loaded with the action but lacks structure (no title, no sections). While concise, it is under-specified for a useful tool description.

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

Completeness2/5

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

Given no annotations or output schema, the description should be more thorough. It omits details about return values, error handling, and behavioral nuances (e.g., does it reload the level?). The minimal information is inadequate for a tool in a complex environment like UE.

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?

The description adds a docstring with a concrete example for the 'path' parameter ('/Game/MyGame/Levels/L_Main'), which provides meaningful guidance beyond the schema's type and title. With 0% schema coverage, this compensates well.

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 it opens an existing level in the editor (verb+resource). The sibling tools include ue_new_level, which creates a new level, distinguishing the purpose. However, it does not explicitly differentiate from other tools.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like ue_new_level or ue_spawn_actor, nor does it mention prerequisites or conditions.

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

ue_package_startA

Crea il pacchetto giocabile del gioco (cook + build + stage + pak).

Produce un eseguibile autonomo, avviabile senza l'editor. Operazione lunga (decine di minuti al primo giro, molto meno dopo): parte in background, lo stato si consulta con ue_package_status.

L'editor deve essere chiuso. Sequenza: ue_editor_close -> ue_package_start -> ue_package_status (finché running=false).

Args: uproject: percorso del file .uproject. configuration: "Development" (con log e console, per il prototipo) o "Shipping" (ottimizzato, senza log, per la distribuzione). maps: mappe da cuocere, es. ["/Game/MyGame/Levels/L_Main"]. Se omesso cuoce secondo le impostazioni di progetto, che è più lento. output_dir: cartella di destinazione; default /Packaged. dedicated_server: produce anche un server dedicato per le partite LAN. engine_root: percorso del motore, se la ricerca automatica non lo trova. target_platform: "Win64" | "Linux" | "Mac"; default la piattaforma corrente.

ParametersJSON Schema

Name	Required	Default
`maps`	No
`uproject`	Yes
`output_dir`	No
`engine_root`	No
`configuration`	No	Development
`engine_version`	No
`target_platform`	No
`dedicated_server`	No

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: long operation, background execution, editor must be closed, produces standalone executable. It does not cover failure modes or concurrency limits, but the details are sufficient for safe use.

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 well-structured: first paragraph covers purpose and key traits, second gives usage flow, then parameter list. It is somewhat long but every sentence adds value, and important details are front-loaded.

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 (8 parameters, no output schema, no annotations), the description covers purpose, usage flow, parameter details, and behavioral traits. It lacks return value info but references ue_package_status for monitoring, making it fairly complete.

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?

Schema coverage is 0%, but the description explains 7 of 8 parameters (all except engine_version) with defaults, examples, and usage notes. This adds significant meaning beyond the empty schema, e.g., maps notes on omission and slower cooking.

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 clearly states the tool's purpose: 'Crea il pacchetto giocabile del gioco (cook + build + stage + pak)' and specifies it produces a standalone executable. It distinguishes from sibling tools like ue_build_start (which only builds) and ue_package_status (which monitors).

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 provides clear context: it runs in background, is long, and must follow ue_editor_close and precede ue_package_status. However, it does not explicitly state when not to use it (e.g., for only building use ue_build_start), so it lacks explicit alternatives.

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

ue_package_statusA

Stato del packaging avviato con ue_package_start.

Riporta la fase corrente (Cook, Stage, Package, Archive), gli errori e, a fine corsa, il percorso dell'eseguibile prodotto.

Args: tail_lines: quante righe finali del log restituire. uproject: a quale progetto si riferisce; se omesso, l'ultimo packaging avviato. wait_seconds: se > 0 attende la fine del packaging fino a questo limite, riportando la fase corrente, invece di restituire subito.

ParametersJSON Schema

Name	Required	Description	Default
`uproject`	No
`tail_lines`	No
`wait_seconds`	No

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that it returns current phase, errors, and final executable path, and describes wait behavior. No contradictions.

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 concise: a short introductory sentence, then parameter explanations in a structured format. No redundant text.

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 no output schema, the description adequately covers return values (phase, errors, executable path). It could be more explicit about the return format, but it is sufficient for a status tool. Context with sibling tools is clear.

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?

Schema description coverage is 0%, but the description explains all three parameters clearly: tail_lines (lines of log to return), uproject (project reference, defaults to last packagestart), and wait_seconds (wait limit if >0). This adds meaning beyond schema types.

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 clearly states it reports status of packaging started with ue_package_start, listing phases (Cook, Stage, Package, Archive), errors, and final executable path. This distinguishes it from sibling tools like ue_build_status.

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 implies when to use (checking packaging progress) and explains wait_seconds behavior (if >0 waits, else returns immediately). However, it does not explicitly state when not to use or provide alternative tool suggestions.

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

ue_pcg_add_nodeA

Aggiunge un nodo al grafo PCG e restituisce i suoi pin.

In PCG il tipo di un nodo è la sua classe di settings: un SurfaceSampler è un nodo con PCGSurfaceSamplerSettings, uno spawner di mesh ha PCGStaticMeshSpawnerSettings. La convenzione è sempre PCG<Nome>Settings.

Args: graph_path: path dell'asset PCGGraph. settings_class: es. "PCGSurfaceSamplerSettings", "PCGStaticMeshSpawnerSettings", "PCGCreatePointsGridSettings", "PCGDensityFilterSettings". position: posizione nell'editor del grafo, {"x": .., "y": ..} o [x, y]. Serve solo alla leggibilità per chi apre il grafo a mano.

ParametersJSON Schema

Name	Required	Description	Default
`position`	No
`graph_path`	Yes
`settings_class`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool returns the node's pins and that the position parameter only affects visual readability. However, it does not mention whether the graph asset is saved, potential errors, or side effects. This is useful but not comprehensive behavioral disclosure.

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 concise and well-structured: a one-sentence summary, a short explanatory paragraph about the PCG convention, and an Args block. Every sentence adds value, and it is not bloated.

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?

The description covers the essential steps for adding a node, including the critical concept of settings_class and the meaning of position. It lacks explicit mention of which parameters are required (though schema shows two required) and does not describe the structure of the returned pins. Still, it is largely complete for the tool's purpose.

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?

Schema description coverage is 0%, so the description must compensate. It explains each parameter: graph_path as the asset path, settings_class with concrete examples (PCGSurfaceSamplerSettings, etc.), and position with accepted formats and its purely readability-oriented role. This is exactly the semantic richness needed.

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 'Aggiunge un nodo al grafo PCG e restituisce i suoi pin' (Adds a node to the PCG graph and returns its pins), clearly stating the action and resource. It further distinguishes itself by explaining the settings_class convention and how it relates to PCG node types, differentiating this add-node tool from sibling PCG tools like ue_pcg_connect or ue_pcg_remove_node.

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 gives clear context on how to use the tool: you specify a settings_class, and it provides examples of valid values. It explains that the node type is its settings class, giving a mental model. However, it does not explicitly mention when not to use it or compare with alternatives, 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.

ue_pcg_cleanupB

Cancella quello che il PCG ha generato su un attore, lasciando il grafo e il volume al loro posto.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes
`remove_components`	No

TDQS

B3.3/5.0

Behavior3/5

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

In the absence of annotations, the description discloses a key behavioral trait: the operation leaves the graph and volume in place. However, it does not explain the full scope of what gets deleted (actors, components, etc.) or the effect of the 'remove_components' parameter, leaving behavioral transparency incomplete.

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 a single, focused sentence that front-loads the main verb and states the core behavior without extraneous information. It earns its place.

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

Completeness2/5

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

This is a mutation tool with no annotations and no output schema, but the description provides only a single sentence and omits parameter semantics and additional side-effect details. It is not complete enough for an agent to fully understand the operation's scope.

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

Parameters1/5

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

With 0% schema description coverage, the description was expected to clarify the parameters. It does not mention 'label' or 'remove_components', so the agent gets no additional meaning about what inputs to provide.

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 uses a specific verb ('Cancella' = deletes) and clearly identifies the resource (PCG-generated content on an actor) while noting what is preserved (graph and volume). This distinguishes it from sibling tools like ue_pcg_generate and ue_pcg_spawn_volume.

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

Usage Guidelines3/5

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

The description implies the use case—cleaning up after PCG generation while keeping the graph and volume—but it does not explicitly state when to use this tool vs alternatives or provide exclusions. No sibling tools are mentioned.

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

ue_pcg_connectA

Collega l'uscita di un nodo PCG all'ingresso di un altro.

from_node e to_node accettano il nome del nodo (come lo restituisce ue_pcg_add_node) oppure gli alias "input" e "output" per i due nodi che ogni grafo ha già. I nomi dei pin sono quelli elencati da ue_pcg_add_node / ue_pcg_graph_info, spazi compresi ("Bounding Shape").

ParametersJSON Schema

Name	Required	Description	Default
`to_pin`	Yes
`to_node`	Yes
`from_pin`	Yes
`from_node`	Yes
`graph_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

The description goes beyond the schema by documenting that node names can be aliases and pin names may contain spaces (e.g., 'Bounding Shape'), which prevents common errors. However, it does not disclose behavior for existing connections or consequences of invalid inputs, and there are no annotations to provide this context.

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 three terse sentences, front-loading the purpose in the first sentence and then providing necessary parameter detail. No redundant information.

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?

With five required parameters and no output schema, the description covers the essential semantics for successfully invoking the tool, including obscure formatting details. It is slightly incomplete regarding edge cases like overwriting connections, but overall adequate.

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 descriptions are absent (0% coverage), but the description adds semantics for from_node, to_node, from_pin, and to_pin by explaining valid values and the alias system. Only graph_path is left to inference from its name, which is sufficient.

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 first sentence clearly states the tool connects the output of one PCG node to the input of another, using a specific verb and resource. This distinguishes it from sibling tools like ue_pcg_disconnect (reverse operation) and ue_bp_connect (blueprint graphs).

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 provides clear context by specifying the accepted formats for from_node/to_node (node names from ue_pcg_add_node or the aliases 'input'/'output') and pin names (from ue_pcg_add_node/ue_pcg_graph_info, including spaces). It implies this tool should be used for PCG node connections, not blueprint connections, but does not explicitly mention alternatives or when not to use.

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

ue_pcg_disconnectC

Rimuove un collegamento fra due nodi del grafo PCG.

ParametersJSON Schema

Name	Required	Description	Default
`to_pin`	Yes
`to_node`	Yes
`from_pin`	Yes
`from_node`	Yes
`graph_path`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action without revealing side effects, such as whether the connection must exist, whether node pins become invalid, or how errors are handled. The mutation nature is implied but safety and edge-case behavior are absent.

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

Conciseness3/5

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

The description is a single concise sentence, but it is under-specified for a tool with five required parameters and no annotations. It contains no waste but fails to include necessary detail, making it insufficiently informative despite its brevity.

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

Completeness2/5

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

Given the tool's moderate complexity (5 required parameters), no output schema, and no annotations, the description is too sparse. It does not explain graph_path, how to identify nodes/pins, or how this operation relates to other PCG tools, leaving the agent without enough context to use it correctly.

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

Parameters2/5

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

Schema coverage is 0% and the description does not elaborate on any of the five parameters. While parameter names like from_node and to_pin are self-explanatory, the critical graph_path parameter lacks any explanation, and the description adds no meaning beyond the schema's bare titles.

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 clearly states the tool removes a connection between two PCG graph nodes, using a specific verb and resource. This distinguishes it from sibling tools like ue_pcg_connect (which creates connections) and ue_pcg_remove_node (which removes nodes entirely).

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 alternatives. There is no mention of prerequisites, such as the graph being loaded, or scenarios where removing a node instead of disconnecting might be appropriate. The description implies a simple disconnection but lacks any context or exclusions.

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

ue_pcg_generateA

Fa rigenerare il PCG di un attore (un PCGVolume o qualunque attore con un PCGComponent). Da chiamare dopo aver modificato il grafo.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`label`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the action (regenerate) and the target (actor with PCGComponent), which is transparent about the core behavior. However, it does not disclose potential side effects (e.g., overwriting existing generated data) or any prerequisites beyond the graph modification.

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 two concise sentences, front-loaded with the main action, and contains no redundant information. Every word contributes to the meaning.

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

Completeness2/5

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

The core purpose and timing are clear, but the tool has no annotations, no output schema, and the parameters are left unexplained. Given the complexity of a PCG regeneration tool, more context about parameters and result expectations would be needed for full completeness.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain the 'force' or 'label' parameters. With low coverage, the description must compensate, but it provides no additional meaning beyond the raw schema fields.

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 uses a specific verb 'Fa rigenerare' (regenerates) and clearly states the resource: the PCG of an actor (a PCGVolume or any actor with a PCGComponent). This distinguishes it from sibling tools like ue_pcg_cleanup or ue_pcg_graph_info.

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 says when to call: 'Da chiamare dopo aver modificato il grafo' (to be called after modifying the graph). It provides clear context but does not explicitly mention alternatives or exclusions, though the sibling list suggests this is the intended action for regeneration.

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

ue_pcg_graph_infoA

Nodi (nome, classe di settings, pin, posizione) e archi di un grafo PCG.

È il modo di sapere come si chiamano i pin prima di collegarli.

ParametersJSON Schema

Name	Required	Description	Default
`graph_path`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It implies a read-only inspection by stating 'prima di collegarli', but does not explicitly confirm no side effects, prerequisites, or required asset state. This leaves some behavioral ambiguity.

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 two sentences long, with the first listing output contents and the second offering a practical use case. It is compact and front-loaded, though the first sentence is slightly dense with parentheses.

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?

The description enumerates the returned data (nodes with name, settings class, pin, position; and edges) and provides a concrete workflow context. It lacks details on graph_path format or error behavior, but for a simple info query with one parameter, it covers the essential aspects.

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

Parameters2/5

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

The graph_path parameter has no schema description (0% coverage), and the description does not explain its expected format (e.g., asset path, object path, or full path). It only implies it refers to a PCG graph, which is already evident from the tool name.

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 states it returns nodes (name, settings class, pin, position) and edges of a PCG graph, using a specific verb+resource pattern. This clearly distinguishes it from sibling tools like ue_bp_graph_info, which targets Blueprint graphs.

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 second sentence explicitly indicates the use case: knowing pin names before connecting them, aligning with tools like ue_pcg_connect. It does not mention alternatives or exclusions, but provides clear context for when to use.

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

ue_pcg_remove_nodeB

Toglie un nodo dal grafo PCG, con tutti i suoi collegamenti.

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes
`graph_path`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The description discloses one key behavior (removing all connections), which is valuable. However, with no annotations, it fails to mention other important traits such as destructiveness, undoability, required permissions, or error conditions, leaving the agent underinformed for a mutation tool.

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 a single, concise sentence that immediately states the action and its key side effect. Every word contributes to the meaning, with no fluff or redundancy.

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

Completeness2/5

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

The tool is a simple mutation with two parameters and no output schema, but the description is too minimal. It omits parameter explanations, prerequisites, error handling, and behavioral details beyond connection removal, making it incomplete for safe autonomous use.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no explanation of the 'graph_path' and 'node' parameters. The parameter names offer some hint, but the description adds no semantic detail, failing to compensate for the missing schema descriptions.

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 clearly states the tool's action: 'Remove a node from the PCG graph, with all its connections.' It uses a specific verb ('remove') and identifies the resource ('PCG graph'), and the mention of connections distinguishes it from related tools like ue_pcg_connect or ue_pcg_disconnect.

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

Usage Guidelines3/5

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

The description implies usage context (removing nodes from PCG graphs) but provides no explicit guidance on when to use this tool vs alternatives like ue_bp_remove_node. There are no exclusions or alternative suggestions.

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

ue_pcg_set_node_propertyA

Imposta una proprietà sulle settings di un nodo PCG.

Args: graph_path: path del grafo. node: nome del nodo. property_name: es. "points_per_squared_meter" su un SurfaceSampler, "seed" su quasi tutti i nodi. value: valore JSON; i path "/Game/..." vengono caricati come asset.

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes
`value`	Yes
`graph_path`	Yes
`property_name`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden of disclosure. It adds useful context: value is JSON and /Game/ paths are loaded as assets. However, it does not disclose whether the property must already exist, whether changes are immediate, or any failure behavior or side effects of mutation.

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 very concise: a one-sentence purpose followed by a structured parameter list. Every line adds value, with no fluff or redundancy.

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?

For a 4-parameter, no-output-schema tool with no annotations, the description covers the essential context: purpose, all parameters with examples, and value special handling. It lacks details on prerequisites or error behavior, but for a simple property setter this is nearly complete.

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 compensates well. It explains each parameter in the Args list, including concrete examples for property_name ('points_per_squared_meter', 'seed') and clarifies the special JSON behavior of value with asset path loading.

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 clearly states the tool's function: 'Imposta una proprietà sulle settings di un nodo PCG' (sets a property on PCG node settings). The verb 'imposta' with the resource 'proprietà... nodo PCG' is specific and distinguishes this from sibling tools like ue_bt_set_node_property.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., node must already exist), or when not to use it. The examples for property_name imply typical use but do not provide clear usage boundaries.

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

ue_pcg_spawn_volumeA

Piazza un PCGVolume nel livello con il grafo già collegato.

Il volume è il dominio in cui il grafo lavora: senza, il grafo non ha niente su cui generare.

Args: graph_path: grafo da collegare. label: nome dell'attore nel livello. location: centro del volume in cm. Attenzione al centro del mondo: se il livello è costruito lontano da [0,0,0], lì il volume è fuori campo — leggi prima un attore di riferimento con ue_list_actors. size: dimensioni in cm, {"x":..,"y":..,"z":..}. Default 200×200×200.

ParametersJSON Schema

Name	Required	Description	Default
`size`	No
`label`	No
`location`	No
`graph_path`	Yes

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 discloses a key behavioral caveat about the volume being out of scope if the level is far from the origin, and explains the volume's necessity. However, it does not address mutation side effects (e.g., overwriting existing volumes), error behavior, or required permissions.

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 concise and well-structured: a one-sentence purpose, a brief explanatory line, and a bulleted argument list. Every sentence contributes useful information without redundancy.

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?

For a tool with no annotations, no output schema, and four parameters, the description covers the essential purpose, usage context, and all parameter semantics. It lacks explicit return value information and alternative-tool guidance, but given the tool's simplicity, it is largely complete.

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?

Schema description coverage is 0%, so the description must compensate. It explains all four parameters: graph_path, label, location (with a critical warning about world coordinates), and size (with default 200×200×200). This adds significant meaning beyond the bare schema.

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 clearly states the tool's function: 'Piazza un PCGVolume nel livello con il grafo già collegato' (Places a PCGVolume in the level with the graph already connected). It also explains the volume's role as the domain in which the graph works, distinguishing this spawn tool from graph-creation or generation siblings.

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 gives practical usage context, warning about the world center and suggesting to read a reference actor with `ue_list_actors` first. It implies when to use the tool (when a graph needs a volume) but does not explicitly mention alternatives or exclusions.

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

ue_project_createA

Crea un progetto Unreal da specifica, pronto per il bridge MCP.

Scrive .uproject (con PythonScriptPlugin, RemoteControl e Metasound già abilitati), Config/DefaultEngine.ini con l'autostart del web server Remote Control, Config/DefaultGame.ini e Content/Python/init_unreal.py.

Args: name: nome progetto (identificatore valido, es. "MyGame"). directory: cartella genitore, es. "C:/UnrealProjects". engine_version: es. "5.4"; se omesso usa la più recente installata. template: "blank" (generato da zero) o il nome di un template del motore (vedi ue_engine_templates), es. "TP_ThirdPerson". blueprint_only: esclude la cartella Source del template (niente compilazione C++). plugins: plugin extra da abilitare oltre a quelli di default. default_map: mappa di avvio, es. "/Game/MyGame/Levels/L_Main". default_game_mode: GameMode di default (path della classe ..._C). force: procede anche se la cartella di destinazione esiste già. engine_root: percorso del motore, quando la ricerca automatica non lo trova (es. "C:/Program Files/Epic Games/UE_5.8").

ParametersJSON Schema

Name	Required	Default
`name`	Yes
`force`	No
`plugins`	No
`template`	No	blank
`directory`	Yes
`default_map`	No
`description`	No
`engine_root`	No
`blueprint_only`	No
`engine_version`	No
`default_game_mode`	No

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses many behaviors: writing multiple files, enabling specific plugins, autostart server, force overwrite, default engine version handling, and blueprint-only exclusion. However, it does not mention error handling or prerequisites.

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 concise and well-structured: a single-sentence purpose, a paragraph listing created files, then a bulleted list of parameters. Every sentence adds value, and it is front-loaded with the key action.

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 11 parameters and no output schema, the description covers the purpose, created files, and all parameters. It lacks details on return values and potential errors, but it is mostly complete.

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?

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 11 parameters, adding meaning beyond the schema (e.g., valid name format, parent directory, engine lookup behavior).

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 clearly states it creates an Unreal project from specification, listing the files it writes. It distinguishes itself from sibling tools like ue_project_find, ue_project_info, etc., by being the creation tool.

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 implies usage for creating a new project but does not explicitly state when to use it over alternatives or when not to use it. The parameter explanations give context, but no exclusions or alternatives are mentioned.

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

ue_project_findC

Cerca file .uproject sotto una cartella.

ParametersJSON Schema

Name	Required	Description	Default
`directory`	Yes
`max_depth`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states the search action, without mentioning safety (e.g., read-only), errors, or side effects. The agent cannot infer if this is a safe operation.

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

Conciseness3/5

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

The description is concise (one sentence) and front-loaded with the core action. However, it is too brief to provide necessary details, making it under-informative rather than efficiently scoped.

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

Completeness2/5

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

Given the simple two-parameter schema and no output schema, the description should at least mention return format (list of paths) and that max_depth controls recursion depth. It lacks completeness for effective use.

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

Parameters1/5

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

The description adds no meaning beyond the schema. It does not explain that 'directory' is the root path or that 'max_depth' limits recursion. With 0% schema description coverage, the description fails to compensate.

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 tool searches for .uproject files under a folder. The verb 'Cerca' (search) and resource '.uproject' are specific. However, it does not differentiate from sibling tools like ue_project_info or ue_project_create, which have distinct purposes.

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 provided on when to use this tool versus alternatives like ue_project_info or ue_project_create. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent without decision context.

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

ue_project_infoA

Legge un .uproject: versione motore associata, plugin attivi e se il bridge è pronto.

ParametersJSON Schema

Name	Required	Description	Default
`uproject`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden of disclosure. It specifies the main behavior (reading a .uproject file and returning engine version, plugins, bridge status) and adds context beyond the schema. However, it does not mention error handling, permissions, or side effects.

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 a single sentence that conveys all essential information without any fluff. It is front-loaded with the action and resource, making it efficient for an agent to scan.

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?

For a simple tool with one parameter and no output schema, the description explains what the tool reads and what data it returns. It is mostly complete, though it could mention the output format (e.g., JSON) and potential error cases (e.g., file not found).

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 coverage is 0%, so the description must clarify the parameter. It states the tool reads a .uproject file, implying 'uproject' is a file path. However, it lacks details about path format (absolute/relative), file extension, or existence requirements, which are needed for correct invocation.

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 clearly states the verb 'Legge' (reads) and the resource '.uproject', and lists specific information retrieved: engine version, active plugins, and bridge readiness. This distinguishes it from sibling tools like ue_project_create or ue_project_find.

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

Usage Guidelines3/5

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

The description implies usage for inspecting a .uproject file but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Context from sibling names provides some differentiation, but the description itself lacks guidance.

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

ue_project_set_pluginsB

Abilita/disabilita plugin scrivendo nel .uproject (utile su progetti esistenti).

Per usare il bridge servono almeno PythonScriptPlugin e RemoteControl. L'editor va riavviato se era già aperto.

ParametersJSON Schema

Name	Required	Description	Default
`enable`	Yes
`disable`	No
`uproject`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It mentions writing to .uproject (a file modification) and the need for editor restart. It lacks details on permissions, idempotency, error conditions, or return values. The provided info is useful but incomplete for full transparency.

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 three short sentences with no wasted words. It front-loads the main action and then adds important context and a note. Perfectly concise for the information provided.

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

Completeness2/5

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

Given no annotations, no output schema, and 0% schema coverage, the description is insufficient for a complete understanding. It does not explain parameters, potential errors, or the exact modifications to the .uproject. The bridge use case and restart note are helpful but not enough.

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

Parameters1/5

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

Schema description coverage is 0%, meaning the description must explain parameters. However, it does not describe 'enable', 'disable', or 'uproject' at all. The description only covers the overall action, leaving parameter semantics completely unaddressed.

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 tool enables/disables plugins by writing to the .uproject file. It specifies it's useful on existing projects, which gives context. However, it does not explicitly distinguish from siblings since no direct sibling exists for plugin management, but the action is clear and specific.

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 provides a concrete use case: enabling PythonScriptPlugin and RemoteControl for the bridge. It also advises that the editor needs restarting if already open. It does not give explicit when-not-to-use or alternatives, but the context is helpful for decision-making.

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

ue_read_logA

Legge la coda del log di Unreal: è il modo per vedere cosa è andato storto dopo un'operazione che non ha sollevato eccezioni.

Args: lines: quante righe finali restituire (default 80). only_errors: se True filtra solo righe con Error/Warning.

ParametersJSON Schema

Name	Required	Description	Default
`lines`	No
`only_errors`	No

TDQS

A3.8/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 disclose behavior fully. It indicates a read-only operation (reading log tail) but does not explicitly state it has no side effects, nor does it cover error conditions, permissions, or output format. This leaves important behavioral traits unspecified.

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 short, front-loaded with purpose, then lists parameters in a clear structured format. Every sentence adds value, no wasted words.

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

Completeness3/5

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

For a simple read tool with no output schema, the description lacks explicit mention of return format (e.g., string or list). However, parameters and use case are covered. Given the simplicity, it is moderately complete but could specify the output type for the agent.

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, but the description fully explains both parameters: 'lines' (number of final lines to return, default 80) and 'only_errors' (filter to Error/Warning only). This adds significant meaning beyond the schema's titles and defaults.

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 clearly states it reads the tail of the Unreal log for debugging after non-exceptional operations. The verb 'legge' and resource 'coda del log di Unreal' are specific and distinct from sibling tools, which focus on other Unreal actions.

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

Usage Guidelines3/5

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

The description provides context for use ('after an operation that didn't throw exceptions') but does not explicitly state when not to use it or mention alternatives. Since no sibling tool reads logs, the guidance is adequate but lacks explicit exclusions or comparisons.

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

ue_reflect_enumA

Elenca nome, valore numerico e display name di un enum nativo del motore.

Il nome va passato senza il prefisso "E" delle UENUM C++: "CollisionChannel", non "ECollisionChannel". Non copre gli enum definiti come Blueprint asset (UserDefinedEnum in /Game/...): quelli non hanno un binding Python generato, vanno letti con ue_exec_python e unreal.load_asset(path).

Args: enum_name: es. "CollisionChannel", "ObjectTypeQuery".

ParametersJSON Schema

Name	Required	Description	Default
`enum_name`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the tool's limitation (does not cover UserDefinedEnum Blueprint assets) and the reason, plus the naming convention requirement. However, it does not mention error behavior if the enum is not found or confirm absence of side effects, though the read-only nature is implied.

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 concise yet complete, with a clear first sentence stating purpose, followed by essential naming/limitation guidance and an Args section. Every sentence adds value, and it is appropriately sized for a single-parameter reflection tool.

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?

Given no output schema, the description compensates by stating what the tool returns (name, numeric value, display name). It also covers parameter usage, limitations, and the alternative path for unsupported enum types, making the tool fully understandable for correct invocation.

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?

Schema coverage is 0%, so the description must compensate, and it does thoroughly. It explains the enum_name parameter through explicit 'E' prefix rule and examples ('CollisionChannel', 'ObjectTypeQuery'), adding far more meaning than the bare schema property. This fully clarifies how to construct the argument.

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 clearly states the tool lists name, numeric value, and display name of a native engine enum, with the specific verb 'Elenca'. It differentiates itself from related tools by explicitly excluding Blueprint asset enums and directing to ue_exec_python for those, making the purpose distinct.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: use for native engine enums, pass names without the 'E' prefix, and provides concrete examples. It also gives a clear when-not-to-use with an alternative tool (ue_exec_python) for UserDefinedEnum assets, which is exemplary contextual direction.

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

ue_rename_assetA

Sposta o rinomina un asset aggiornando i riferimenti.

Args: path: percorso attuale, es. "/Game/Imported/SM_rock". new_path: percorso nuovo, es. "/Game/MyGame/Meshes/SM_Roccia".

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`new_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

The description mentions that references are updated, adding behavioral context beyond the schema. However, it does not detail error handling, consequences of invalid paths, or undo behavior. With no annotations, more transparency would be better.

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 concise: one sentence plus a brief parameter list with examples. Every part is essential and well-structured.

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?

For a simple tool with two parameters and no output schema, the description covers purpose and parameter format. It lacks mention of return value or failure modes, but is still reasonably complete.

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 coverage is 0%, so the description compensates by providing examples for both parameters, indicating the expected format (e.g., '/Game/Imported/SM_rock'). This adds significant meaning beyond bare property names.

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 clearly states the tool moves or renames an asset while updating references, which is a specific verb-resource combination. It distinguishes from sibling tools like ue_delete_asset and ue_duplicate_asset.

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

Usage Guidelines3/5

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

Usage is implied (use when needing to move/rename with reference updates), but the description lacks explicit guidance on when not to use it or alternatives. No comparison to other asset tools.

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

ue_render_sequenceA

Renderizza una Level Sequence con la Movie Render Queue, in background.

Gira in un processo UnrealEditor-Cmd headless, non nell'editor aperto: la MRQ in-editor è asincrona e terrebbe l'editor occupato per tutta la durata, senza un modo pulito di attenderla dal bridge. Come per le build, si avvia e si consulta ue_render_status.

Args: uproject: percorso del file .uproject. sequence: la Level Sequence, es. "/Game/Cinematics/LS_Intro". config: preset di Movie Pipeline salvato, es. "/Game/Cinematics/MRQ_Preset". È il modo di scegliere formato, risoluzione e cartella di uscita: senza, la MRQ usa le impostazioni predefinite del progetto e potrebbe non scrivere nulla. map_path: livello da caricare; default quello di avvio del progetto. output_dir: dove cercare i file prodotti; default /Saved/MovieRenders. resolution: [larghezza, altezza]; default [1920, 1080]. force: avvia anche se risulta già un render in corso.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`config`	No
`map_path`	No
`sequence`	Yes
`uproject`	Yes
`output_dir`	No
`resolution`	No
`engine_root`	No
`engine_version`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses it runs in UnrealEditor-Cmd headless, is asynchronous (start and check status), and warns that without config, output may be missing. It could mention return value or non-destructive nature explicitly.

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 well-structured: first sentence states purpose, then context, then Args list. It is appropriately sized for the complexity, though slightly verbose. Front-loaded with key information.

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

Completeness3/5

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

While it covers purpose, behavioral context, and most parameters, it does not describe the tool's return value (e.g., success indicator, job ID). Given no output schema, this is a gap. It also omits two parameters.

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 has 0% description coverage, so the description adds significant value. It explains 7 of 9 parameters (e.g., config format, resolution default, output_dir default). engine_root and engine_version are undocumented, but coverage is high and explanations are clear.

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 clearly states the tool renders a Level Sequence with Movie Render Queue in background. The verb 'Renderizza' and resource 'Level Sequence' are specific, and it distinguishes from sibling tools like ue_render_status by focusing on initiating renders.

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 explains the tool runs in a headless process to avoid blocking the editor, and directs to ue_render_status for progress. While it doesn't explicitly list alternatives or exclusions, the context is sufficient for when to use this tool.

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

ue_render_statusA

Stato del render avviato con ue_render_sequence.

succeeded guarda i file prodotti, non il codice di uscita: la MRQ headless può chiudere con 0 senza aver scritto un fotogramma, se la config non aveva nodi di output.

Args: tail_lines: quante righe finali del log restituire. uproject: a quale progetto si riferisce; se omesso, l'ultimo render avviato. wait_seconds: se > 0 attende la fine fino a questo limite riportando l'avanzamento, invece di restituire subito.

ParametersJSON Schema

Name	Required	Description	Default
`uproject`	No
`tail_lines`	No
`wait_seconds`	No

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description discloses important behavior: success checking based on files, and wait_seconds parameter causing waiting and progress reporting. It doesn't mention permissions or side effects, but it's a read-only operation implied by 'stato'.

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 short, front-loaded with the purpose, and uses a clear bullet-like format for arguments. Every sentence adds value without redundancy.

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 3 parameters and no output schema, it explains parameters and key behavior. It doesn't specify the return format, but the concept of 'succeeded' and log lines is sufficient. Could be slightly more explicit about return values, but overall adequate.

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?

Schema description coverage is 0%, but the tool description provides detailed meaning for all three parameters: tail_lines (log lines), uproject (project reference, defaults to last), wait_seconds (wait and report progress). This fully compensates and adds clarity.

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 clearly states it checks the status of a render started with ue_render_sequence, with a specific nuance about success based on files rather than exit code. This distinguishes it from sibling tools that start rendering or check other statuses.

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 explicitly mentions the tool is for render status after ue_render_sequence, and explains the behavior of wait_seconds. However, it doesn't compare to other status tools like ue_status, but the context is clear enough for usage.

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

ue_reparent_blueprintA

Riassegna il parent di un Blueprint, tipicamente a una classe C++.

È la via per dare logica eseguibile a un Blueprint: i grafi non sono scrivibili da Python, ma la logica può stare nella classe C++ padre (creata con ue_cpp_class_create) mentre il Blueprint resta il contenitore di componenti e valori.

Le variabili del Blueprint con lo stesso nome di una UPROPERTY del nuovo padre vengono assorbite; le altre sopravvivono rinominate con _0.

Args: blueprint_path: es. "/Game/MyGame/Blueprints/BP_Door". new_parent: nome o path della nuova classe padre, es. "ADoorBase" oppure "/Script/MyGame.DoorBase". remove_unused_variables: ripulisce le variabili rimaste orfane.

ParametersJSON Schema

Name	Required	Description	Default
`new_parent`	Yes
`blueprint_path`	Yes
`remove_unused_variables`	No

TDQS

A4.5/5.0

Behavior4/5

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

Describes variable absorption/renaming and the optional cleanup of unused variables. No annotations provided, so description carries full burden. Lacks details on reversibility or post-actions like compilation, but covers main aspects.

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?

Front-loaded with main action, well-structured with bullet points for args. Slightly verbose but efficient overall.

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

Completeness3/5

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

Lacks description of return value or post-conditions (e.g., if blueprint is saved/compiled). Input parameters are well described, but missing outcome details for a modification tool.

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?

Adds significant meaning beyond schema (which has 0% coverage): provides examples for blueprint_path and new_parent, explains the format, and clarifies the remove_unused_variables parameter.

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 clearly states the tool reassigns the parent of a Blueprint to a C++ class, with the purpose of giving executable logic. It distinguishes from siblings like ue_cpp_class_create.

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

Usage Guidelines5/5

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

Explicitly explains when to use (to give executable logic to a Blueprint), mentions alternatives (ue_cpp_class_create), and describes variable behavior. Provides clear context.

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

ue_save_allA

Salva il livello corrente e tutti gli asset modificati.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavior. It only says it saves, but does not explain whether it overwrites files, requires user confirmation, or triggers a dialog. The effect on unsaved changes is implied but not explicit.

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 a single, seven-word sentence in Italian. It is extremely concise with no unnecessary words, front-loading the purpose effectively.

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 has no parameters and no output schema, the description is fairly complete for a save action. It could mention immediate results or feedback, but the core functionality is covered.

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?

There are no parameters, so the schema coverage is 100% by default. The description does not need to add parameter meaning, and its simplicity is appropriate for a parameterless save operation.

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 clearly states the tool saves the current level and all modified assets. The verb 'save' and the resources 'level' and 'modified assets' are specific, and it distinguishes from sibling tools like ue_open_level or ue_spawn_actor which perform different actions.

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?

The description provides no guidance on when to use this tool versus alternatives, such as other save-related tools (if any) or conditions like needing to save before closing. No exclusions or context for use are mentioned.

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

ue_screenshotA

Cattura la viewport dell'editor e restituisce l'immagine all'agente.

Senza questo l'agente costruisce alla cieca: è l'unico modo per verificare davvero com'è venuta una scena invece di dedurlo dalle coordinate. Il file resta in /Saved/Screenshots/MCP.

La risoluzione predefinita è volutamente modesta: il PNG viaggia in base64 dentro la risposta, e a 1280x720 costa spesso più contesto di quanto l'immagine ne faccia risparmiare. Alzala quando serve leggere un dettaglio.

Args: filename: nome file; se omesso ne genera uno con il timestamp. width, height: risoluzione della cattura. return_image: se False restituisce solo il percorso, senza allegare il PNG.

ParametersJSON Schema

Name	Required	Description	Default
`width`	No
`height`	No
`filename`	No
`return_image`	No

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the file is saved to <Progetto>/Screenshots/MCP, that the default resolution is modest to avoid large base64 responses, and that return_image=False only returns the path. These details go beyond the bare minimum.

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 front-loaded with the core purpose and includes a rationale, storage info, resolution advice, and parameter documentation. It is slightly verbose but every sentence adds value; no waste.

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 simple screenshot tool with 4 parameters, the description covers all necessary aspects: what it does, why it's needed, file persistence, resolution considerations, and parameter details. No output schema exists, but the tool's return type (image or path) is adequately described.

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?

With 0% schema description coverage, the description fully documents all 4 parameters: filename, width, height, and return_image. It explains default behaviors (timestamp, resolution trade-offs) and the effect of return_image, adding significant meaning beyond the schema types.

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 clearly states 'Cattura la viewport dell editor e restituisce l immagine all agente', which translates to capturing the editor viewport and returning the image. This verb+resource combination is specific and distinct from sibling tools like ue_set_camera or ue_render_sequence.

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 explains that without this tool the agent builds blindly and it is the only way to verify the scene visually, providing clear context for when to use it. It also warns about resolution trade-offs but does not explicitly mention alternatives or when not to use it.

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

ue_sequence_add_actorB

Aggiunge un attore del livello alla sequenza.

Args: sequence_path: path della Level Sequence. label: label dell'attore nel livello. spawnable: se True la sequenza si porta dietro una copia dell'attore e la crea e distrugge da sé (cinematica autonoma); se False anima l'attore che è già nel livello.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes
`spawnable`	No
`sequence_path`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

The description explains the critical behavioral difference of the spawnable parameter, clarifying that True makes the sequence manage its own copy while False animates the existing actor. However, with no annotations, it does not disclose side effects, prerequisites (e.g., sequence must exist), or failure modes.

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 concise with a single-sentence summary followed by a clear Args list. No redundant information, though the Italian language might limit accessibility for non-Italian users.

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

Completeness3/5

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

The description covers the core operation and parameter semantics but omits prerequisites (e.g., whether the sequence must already exist), return type, and error handling. Given the lack of output schema and annotations, this leaves the agent to infer some operational context.

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?

With 0% schema description coverage, the description compensates by explaining all three parameters in the Args block. It gives meaningful semantic context for spawnable and labels, though sequence_path could be more specific about valid path format.

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 tool adds a level actor to a sequence with the verb 'Aggiunge' (adds). It includes parameter details that reinforce the purpose, though it doesn't explicitly differentiate from sibling sequence tools like ue_sequence_add_track.

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 on when to use this tool versus alternatives like ue_spawn_actor or ue_sequence_add_track. The description only explains what the tool does, not context or exclusions.

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

ue_sequence_add_keyA

Mette una chiave su un canale e rilegge tutte le chiavi del canale.

Args: sequence_path: path della Level Sequence. binding: nome o indice del binding. channel: nome del canale senza suffisso numerico — "Location.Z", "Rotation.Y", "Scale.X". Il suffisso che Unreal appiccica ("Location.Z_3") cambia da una creazione all'altra: elencali con ue_sequence_info. frame: numero di frame. value: valore (float, int o bool a seconda del canale). track: indice della track nel binding. Se il binding ne ha una sola, si può omettere. track_type: in alternativa a track, il tipo di track da cercare. section: indice della sezione nella track (default 0). interpolation: AUTO, USER, BREAK, LINEAR, CONSTANT.

ParametersJSON Schema

Name	Required	Description	Default
`frame`	Yes
`track`	No
`value`	Yes
`binding`	Yes
`channel`	Yes
`section`	No
`track_type`	No
`interpolation`	No
`sequence_path`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are present, so the description carries the burden. It discloses the side-effect of re-reading all keys and the instability of Unreal's numeric suffix, which is valuable context. However, it doesn't mention overwrite behavior, errors, or return format.

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 front-loaded with the purpose and then provides an organized Args list. It is appropriately detailed for 9 parameters with no wasted words.

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 9 parameters are explained with enough detail to invoke the tool correctly. The only notable gap is the return value from the re-read operation, which is mentioned but not described.

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?

Schema coverage is 0%, but the description explains every parameter in detail, including channel format examples, track vs track_type alternatives, section default, and interpolation enum. This fully compensates for the empty schema descriptions.

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 clearly states it adds a key to a channel and re-reads all channel keys. The verb 'mette una chiave' and resource 'canale' are specific, distinguishing it from siblings like ue_sequence_add_track and ue_sequence_add_actor.

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 provides implicit usage context and a cross-reference to ue_sequence_info for listing channels, but it doesn't explicitly compare against alternatives or specify when not to use. It does give prerequisite guidance on channel naming and track selection.

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

ue_sequence_add_trackA

Aggiunge una track a un binding, con la sua prima sezione già dentro.

Args: sequence_path: path della Level Sequence. binding: nome del binding (di norma la label dell'attore) o il suo indice. track_type: alias comodo — "transform", "visibility", "audio", "animation", "camera_cut", "event", "fade" — oppure il nome esatto della classe (es. "MovieSceneFloatTrack"). start: primo frame della sezione (default: inizio del playback). end: ultimo frame della sezione (default: fine del playback).

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No
`binding`	Yes
`track_type`	Yes
`sequence_path`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the track is added with its first section already included, and it explains default start/end behavior ('default: inizio del playback', 'default: fine del playback'). However, it does not mention side effects, permissions, error conditions, or what happens on duplicate tracks, leaving some behavioral gaps.

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 concise and well-structured: a single purpose sentence followed by an Args block. Each piece of information earns its place, and the layout makes it easy to scan.

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?

The description covers the core functionality and all parameters, which is strong given no output schema. However, it omits preconditions (e.g., whether the sequence must be open) and error behavior, so it is not fully complete for an agent that might need to handle failures.

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?

Schema description coverage is 0%, but the description fully compensates by detailing every parameter: sequence_path, binding (including the convention of actor label or index), track_type (listing valid aliases and the option of an exact class name), and start/end with defaults. This adds substantial meaning beyond the schema's bare titles.

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 clearly states the tool's action: 'Aggiunge una track a un binding' (adds a track to a binding), with the added detail that it includes the first section. This is a specific verb+resource+scope, distinguishing it from sibling tools like ue_sequence_add_actor or ue_sequence_add_key.

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

Usage Guidelines3/5

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

The usage is implied: you use this tool when you need to add a track to a binding. However, there is no explicit mention of when to use it versus alternatives, nor any exclusions or prerequisites. The parameter descriptions give some context but not alternative guidance.

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

ue_sequence_infoA

Binding, track, sezioni e canali di una Level Sequence.

Chiamalo prima di mettere chiavi: è il modo di sapere come si chiamano i canali e quali indici usare per track e sezioni.

ParametersJSON Schema

Name	Required	Description	Default
`sequence_path`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses what information is returned (bindings, tracks, sections, channels, indices) but does not mention side effects, error behavior, or path requirements. As a read-only info tool, the lack of safety warnings is somewhat mitigated, but more detail would be better.

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?

Two sentences, front-loaded with the core purpose, and no wasted words. It efficiently conveys both what the tool does and when to use it.

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?

The tool is simple with one parameter and no output schema. The description covers what info is returned and the timing of use. It doesn't specify the exact return format, but for a simple info tool, the key details are present.

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

Parameters2/5

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

Schema description coverage is 0%, and the description doesn't mention sequence_path at all. The parameter name gives a hint, but no path format, examples, or guidance are provided, so the description fails to compensate for the schema's lack of detail.

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 clearly states that the tool provides bindings, tracks, sections, and channels of a Level Sequence, and explains it reveals channel names and track/section indices. It distinguishes itself from sibling sequence tools (e.g., ue_sequence_add_key, ue_sequence_add_track) by focusing on metadata retrieval.

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?

Explicitly instructs to call it before adding keys ('Chiamalo prima di mettere chiavi') and explains it's the way to know channel names and indices. No alternatives are named, but the context makes the usage clear.

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

ue_sequence_openA

Apre la sequenza nell'editor del Sequencer (o la chiude con close=True).

I tool scrivono sull'asset e basta: questo è il modo di vedere il risultato senza cercare l'asset a mano nel Content Browser.

ParametersJSON Schema

Name	Required	Description	Default
`close`	No
`sequence_path`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool opens/closes the Sequencer editor and does not modify the asset, using 'I tool scrivono sull'asset e basta' to set expectations. This is a transparent disclosure of the tool's effect, though it omits details like error handling or prerequisites.

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 concise, consisting of two sentences that efficiently convey the tool's purpose, the close parameter, and the broader context of why the tool exists. It is front-loaded with the primary action and contains no redundant words.

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 simplicity, no output schema, and no annotations, the description adequately covers the tool's purpose, usage context, and behavior. It explains that the tool is for viewing results of asset-modifying tools and can also close the editor. It could be more complete by specifying that the sequence must already exist, but for the context, this is sufficient.

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?

The description explains the 'close' parameter (close=True closes the editor) but offers no explicit meaning for 'sequence_path', aside from the tool name implying it's the path to the sequence. With 0% schema coverage, the description should compensate more by specifying the expected path format (e.g., full asset path vs. asset name), leaving a gap in parameter understanding.

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 clearly states the tool opens a sequence in the Sequencer editor and can also close it with close=True. It distinguishes its purpose from sibling tools by emphasizing that it is for visualizing assets that other tools modify, rather than modifying the asset itself.

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 explains when to use this tool: 'I tool scrivono sull'asset e basta: questo è il modo di vedere il risultato senza cercare l'asset a mano nel Content Browser.' This gives a clear usage context—use this after making changes with other tools to view the result in the editor. It does not explicitly name an alternative, but the context makes the use case clear.

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

ue_sequence_removeA

Toglie una track da un binding — o l'intero binding, se non indichi né track né track_type.

ParametersJSON Schema

Name	Required	Description	Default
`track`	No
`binding`	Yes
`track_type`	No
`sequence_path`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals a non-obvious consequence: if neither `track` nor `track_type` is provided, the whole binding is removed. This is crucial destructive behavior that goes beyond the schema's default null values.

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 a single, focused sentence that front-loads the action ('Toglie una track...') and then clarifies the alternative behavior. No unnecessary words or redundancy.

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?

Despite no annotations or output schema, the description adequately covers the primary decision logic (track vs. whole binding removal). It omits details like error handling or return values, but the core usage is sufficiently clear for an agent.

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?

The description adds meaning to `track` and `track_type` by explaining their role in the removal logic, which is valuable given 0% schema description coverage. However, it does not elaborate on `sequence_path` or `binding`, though their purpose is partially inferable from their names.

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 uses a specific verb ('remove') and clearly specifies the resource ('track from a binding' or 'entire binding'), distinguishing between two operation modes. It differentiates from sibling tools like `ue_sequence_add_track` and `ue_sequence_info` by its clear removal intent.

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 provides clear usage context by explaining the two scenarios: specifying either `track` or `track_type` removes a track, while omitting both removes the entire binding. It does not explicitly name alternative tools, but the guidance on parameter selection effectively directs usage.

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

ue_sequence_set_rangeB

Cambia il range di playback e/o il frame rate della sequenza.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`fps`	No
`start`	No
`sequence_path`	Yes

TDQS

B3.3/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 disclose behavioral traits. It only states the action without describing side effects, mutability, prerequisites, or return values. For a tool that modifies a sequence, this is insufficient.

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?

One concise sentence that covers the tool's function without waste. It is appropriately sized, though in Italian.

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

Completeness2/5

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

Given the tool has 4 parameters, no annotations, and no output schema, the description is too brief. It does not explain how to specify the range, whether the sequence must be open, or what happens on invocation. The agent would need to infer too much from the schema.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It maps 'range di playback' to start/end and 'frame rate' to fps, but does not specify units, whether parameters are required together, or how they interact. The schema provides parameter names/types but no 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 clearly states the tool changes the playback range and/or frame rate of the sequence, using a specific verb ('cambia') and resource. This distinguishes it from other sequence tools like add/info/open/remove.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives is provided. The description implies its usage through the action, but there is no mention of exclusions or alternative tools.

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

ue_set_actor_propertyA

Imposta proprietà su un attore già piazzato, o su un suo componente.

Copre tutto ciò che non sono i Class Defaults di un Blueprint: assegnare una mesh a uno StaticMeshActor, l'intensità di una luce, il raggio di un trigger. I valori seguono il JSON: un vettore è {"x":0,"y":0,"z":0}, un colore {"r":1,"g":0,"b":0}, e il path di un asset (/Game/...) viene caricato in automatico.

Args: label: etichetta dell'attore nell'Outliner. properties: mappa nome_proprieta -> valore. component: nome o classe del componente su cui scrivere (es. "StaticMeshComponent"); se omesso scrive sull'attore.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes
`component`	No
`properties`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses JSON formats for vectors, colors, and auto-loading of asset paths. It explains the 'component' parameter's purpose. However, it does not mention potential side effects, required permissions, or whether changes are persistent. Overall, it adds significant context beyond the schema.

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 well-structured with a clear purpose statement, elaboration, and an Args section. It is slightly verbose but remains focused. Every sentence adds value. It could be slightly more concise, but it is effective.

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 absence of annotations and output schema, the description covers parameter details, behavior, and examples. It lacks information about return values or error handling, which would be helpful. However, it is sufficiently complete for a property-setting tool.

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?

Schema description coverage is 0%, so the description must compensate. It explains all three parameters: 'label' (actor label), 'properties' (map with JSON formats), and 'component' (optional, name or class). Examples are provided for vector and color formats. This adds substantial meaning beyond the schema's type-only definitions.

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 clearly states the tool's purpose: setting properties on an actor or its component. It distinguishes itself from 'Class Defaults' (handled by a sibling tool) and provides concrete examples (mesh, light intensity, trigger radius). The verb 'imposta' (set) and resource 'attore' (actor) are specific, and the description differentiates from sibling tools like ue_set_actor_transform.

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 explains the scope ('everything except Class Defaults'), which implies when to use this tool vs. alternatives. It does not explicitly list exclusions or mention specific sibling tools, but the context is clear. A score of 4 reflects good implied guidance without explicit when-not-to-use.

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

ue_set_actor_transformC

Modifica posizione/rotazione/scala di un attore identificato dalla sua label.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes
`scale`	No
`location`	No
`rotation`	No

TDQS

C2.9/5.0

Behavior2/5

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

The description lacks behavioral details beyond the basic action. It does not specify whether the transform is absolute or relative, the coordinate system, units, or what happens if the label is not found. With no annotations, the description carries the full burden but fails to disclose these traits.

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

Conciseness3/5

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

The description is a single concise sentence, which is front-loaded and efficient, but it sacrifices necessary detail. It could be slightly longer without losing conciseness.

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

Completeness2/5

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

Given the complexity of a transform tool (4 parameters, no output schema, no annotations), the description is incomplete. It fails to specify transformation mode, coordinate system, error handling, or default behavior for omitted parameters.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate. It only explains the 'label' parameter (actor identified by label) but does not add meaning for location, rotation, or scale (e.g., array format, expected units). The parameter names are merely repeated.

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 clearly states the verb 'Modifica' (modify) and specifies the resources 'posizione/rotazione/scala' (position/rotation/scale) of an actor identified by label, distinguishing it from sibling tools like ue_set_actor_property.

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 usage guidance is provided; there is no mention of when to use this tool versus alternatives like ue_spawn_actor or ue_set_actor_property, nor any prerequisites or exclusions.

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

ue_set_cameraB

Sposta la camera della viewport.

Args: location: [x, y, z] in cm. rotation: [pitch, yaw, roll] in gradi.

ParametersJSON Schema

Name	Required	Description	Default
`location`	No
`rotation`	No

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It does not disclose side effects, such as whether the camera movement is temporary or persistent, or if a level must be open. The description only states the basic action without behavioral details.

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 extremely concise, consisting of a one-line purpose and two parameter explanations. No superfluous content; every part is necessary.

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

Completeness2/5

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

Given the lack of output schema and annotations, the description is too brief. It does not explain the return value, prerequisites, or whether the camera applies to the current viewport or a specific one. Essential context is missing for a tool with 2 optional parameters.

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?

The description adds meaning beyond the schema by specifying that location is [x, y, z] in cm and rotation is [pitch, yaw, roll] in degrees. This compensates for 0% schema description coverage, though more detail (e.g., coordinate system, relative vs absolute) could improve clarity.

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 'Sposta la camera della viewport' (Move the viewport camera), which clearly indicates the verb and resource. It distinguishes from sibling tools like ue_get_camera (read-only) and ue_set_actor_transform (for actors), but does not explicitly call out differentiation.

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 provided on when to use this tool versus alternatives (e.g., ue_set_actor_transform for actors). The description does not specify prerequisites or context of use.

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

ue_set_class_defaultsC

Imposta i Class Defaults (CDO) di un Blueprint.

Args: blueprint_path: path del Blueprint. properties: mappa nome_proprieta -> valore, es. {"replicates": true}.

ParametersJSON Schema

Name	Required	Description	Default
`properties`	Yes
`blueprint_path`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behaviors. It only states the operation, but fails to mention side effects, persistence, triggers for compilation, or whether it affects existing instances. Critical behavioral traits are missing.

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 concise with a clear structure (function statement followed by argument list). It avoids unnecessary words and uses an efficient format. However, the use of Italian may limit accessibility for English-speaking agents.

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

Completeness2/5

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

Given the lack of annotations, output schema, and detailed schema descriptions, the description is too minimal. It does not explain return values, prerequisites, or how this tool differs from similar ones like ue_set_actor_property, leaving the agent underinformed.

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?

The description adds meaning for both parameters: blueprint_path as 'path of the Blueprint' and properties as a map with an example. However, it does not elaborate on path format, valid property names, or type constraints, which would be helpful given the 0% schema coverage.

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 tool's function: setting the Class Defaults (CDO) of a Blueprint. The verb 'set' and resource 'Class Defaults' are specific, and it is distinguishable from sibling tools like ue_set_actor_property.

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 provided on when to use this tool versus alternatives like ue_set_actor_property or ue_compile_blueprint. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without usage direction.

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

ue_set_component_defaultA

Scrive una proprietà sul template di un componente di un Blueprint, non su un'istanza piazzata nel livello.

È la via per le proprietà EditDefaultsOnly, che Unreal rifiuta di scrivere su un attore spawnato ("cannot be edited on instances") — per esempio SensesConfig di un AIPerceptionComponent. Per gli attori già nel livello usa invece ue_set_actor_property.

Args: blueprint_path: Blueprint che contiene il componente. component_name: nome come si vede nell'editor. property_name: nome della proprietà (snake_case o PascalCase secondo quanto accetta la classe). value: valore JSON; dict con x/y/z, pitch/yaw/roll o r/g/b vengono convertiti nei tipi Unreal corrispondenti, e i path /Game/... vengono caricati come asset.

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes
`property_name`	Yes
`blueprint_path`	Yes
`component_name`	Yes

TDQS

A4.7/5.0

Behavior4/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 discloses the key behavioral trait (template vs instance) and the error scenario ("cannot be edited on instances"), plus value conversion behavior. It could go further by noting persistence to the asset or effects on existing instances, but it already provides substantial unexpected behavior context.

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 front-loaded, with the core distinction stated first, followed by practical guidance, a concrete example, and a compact parameter list. Every sentence earns its place with no redundancy or filler.

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 simplicity and the rich parameter documentation, the description is nearly complete. It lacks an explicit mention of success/error return types, but for a property setter this is a minor gap. The alternative tool reference and the example make it highly usable in context.

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?

Schema description coverage is 0%, but the description compensates fully by explaining each parameter: blueprint_path names the containing Blueprint, component_name is as seen in the editor, property_name accepts snake_case or PascalCase, and value includes detailed JSON conversion rules (vectors, rotators, colors, asset paths). This is strong added value beyond the bare schema.

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 clearly states a specific action: writing a property on a component's template inside a Blueprint, explicitly contrasted with editing an instance in the level. It distinguishes itself from related tools like ue_set_actor_property and focuses on a precise Unreal concept (EditDefaultsOnly).

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use this tool: for EditDefaultsOnly properties that Unreal rejects on instances, with a concrete example. It also names the alternative tool (ue_set_actor_property) for actors already in the level, making the decision clear.

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

ue_set_component_physicsC

Fisica e collisione di un componente (StaticMesh/Skeletal/Primitive).

Args: actor: etichetta dell'attore nell'Outliner. component: nome o classe del componente (es. "StaticMeshComponent"). simulate_physics: attiva/disattiva la simulazione fisica. collision_enabled: "NoCollision" | "QueryOnly" | "PhysicsOnly" | "QueryAndPhysics" | "QueryAndProbe" | "ProbeOnly" (case/underscore insensitive, es. va bene anche "query_and_physics"). collision_profile: nome profilo collisione (es. "PhysicsActor", "BlockAll").

ParametersJSON Schema

Name	Required	Description	Default
`actor`	Yes
`component`	Yes
`simulate_physics`	No
`collision_enabled`	No
`collision_profile`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must disclose side effects and preconditions. It does not mention what happens when physics simulation is toggled, whether changes are persistent, or if any component type restrictions exist beyond the examples. This is a significant gap for a mutation tool.

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 compact and well-organized as a parameter list. It includes an intro line and detailed args with no redundant text. The intro could be a verb phrase, but overall it is efficient and scannable.

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

Completeness2/5

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

The description is essentially a parameter list without an overall explanation of the operation's effect, when to use it, or any side effects. Given that annotations and output schema are absent, this is insufficient for a complete understanding of the tool's context and behavior.

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 description provides rich meanings for all five parameters, including allowed values, case-insensitivity, and examples (e.g., collision_enabled values and collision_profile names). This fully compensates for the schema's 0% description coverage.

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

Purpose3/5

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

The description is a noun phrase ('Fisica e collisione di un componente') that names the topic but lacks an explicit verb such as 'set' or 'configure'. It identifies the resource (component) and scope (StaticMesh/Skeletal/Primitive), but relies on the tool name to convey the action, making it a vague standalone purpose.

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 provided about when to use this tool versus alternatives like ue_component_physics_info. There are no prerequisites, exclusions, or conditions described. The description is purely parameter documentation.

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

ue_set_component_replicationA

Attiva la replication di un singolo componente di un Blueprint.

Un attore replicato non replica automaticamente i suoi componenti: le proprietà di un componente arrivano ai client solo se il componente è marcato come replicato.

Args: blueprint_path: Blueprint che contiene il componente. component_name: nome come si vede nell'editor (il suffisso _GEN_VARIABLE dei template è gestito da solo). replicates: True per attivare.

ParametersJSON Schema

Name	Required	Description	Default
`replicates`	No
`blueprint_path`	Yes
`component_name`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses key behavioral details: component replication is not automatic, the tool handles the '_GEN_VARIABLE' suffix automatically, and the 'replicates' parameter activates replication. It does not cover permissions or side effects like blueprint compilation, but it provides meaningful insight into how the tool behaves.

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 concise and well-organized: a one-sentence purpose, a brief conceptual note, and a clear Args list. Every sentence adds value, with no redundancy or filler.

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 no output schema and no annotations, the description covers purpose, usage context, and all parameters. It lacks details on potential side effects (e.g., whether the blueprint needs saving or compilation), but for a targeted configuration tool it is quite complete.

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?

The schema has 0% description coverage, but the description's Args section explains all three parameters: blueprint_path, component_name (including the special suffix handling), and replicates. This compensates well for the schema gap, though blueprint_path format is not fully specified (e.g., relative to /Game).

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 clearly states the tool's action: 'Attiva la replication di un singolo componente di un Blueprint.' It uses a specific verb (attiva) and resource (componente di Blueprint), and distinguishes itself from the sibling tool ue_set_replication by emphasizing 'singolo componente' and explaining the actor-vs-component replication nuance.

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 provides strong contextual guidance: 'Un attore replicato non replica automaticamente i suoi componenti' implies when this tool is needed (when component replication is required after actor replication). It does not explicitly name alternatives or exclusions, but the context effectively communicates the use case.

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

ue_set_foliage_propertyB

Scrive una proprietà su un FoliageType e rilegge il valore risultante.

Args: foliage_type_path: path dell'asset FoliageType. property_name: es. "density", "radius", "random_yaw", "align_to_normal", "scale_x", "collision_with_world", "cull_distance". value: valore JSON; i path "/Game/..." vengono caricati come asset.

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes
`property_name`	Yes
`foliage_type_path`	Yes

TDQS

B3.4/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 of behavioral disclosure. It usefully discloses that the tool both writes and reads back the resulting value, and that '/Game/...' paths in the 'value' parameter are loaded as assets. However, it omits critical mutation-related details such as permissions, reversibility, or failure behavior, which is a notable gap for a write 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 well-organized. It opens with a clear one-sentence function summary, then uses a structured Args list for parameter details. There is no redundant jargon or filler, making it easy to scan and parse.

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

Completeness3/5

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

The description covers the core action and parameter semantics, but lacks information about the return value format, error conditions, or any prerequisites. Since there is no output schema and no annotations, the absence of return-value or error details leaves agents partially blind. For a mutation tool, this is a moderate gap, but the provided information is sufficient for basic invocation.

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?

The schema provides no descriptions (0% coverage), so the description's Args section fully compensates. It explains each parameter: foliage_type_path, property_name with concrete examples, and value with a note about JSON and asset path handling. This is meaningful guidance that goes beyond the bare schema, though it could elaborate on the expected structure of the JSON value for properties beyond examples.

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 tool's action: 'Scrive una proprietà su un FoliageType e rilegge il valore risultante' (writes a property on a FoliageType and reads back the resulting value). It names the specific resource (FoliageType) and the verb, making it distinct from other 'set' tools in the sibling list. It could be a 5 if it explicitly differentiated from sibling tools like ue_set_actor_property, but the resource focus is clear.

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?

The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where another tool might be more appropriate. It simply describes the action without situational context, leaving the agent to infer applicability.

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

ue_set_net_configA

Regola quanto costa in banda un attore replicato: dormancy, frequenza di aggiornamento, priorità e relevancy. ue_set_replication decide se replicare, questo decide con che intensità.

Solo i parametri passati vengono toccati, gli altri restano come sono.

Args: blueprint_path: Blueprint Actor da configurare. dormancy: "awake" | "initial" | "dormant_all" | "dormant_partial" | "never". "initial" è la scelta giusta per attori di scena che non cambiano mai dopo lo spawn: smettono di consumare banda finché non li si risveglia. net_update_frequency: aggiornamenti al secondo quando è rilevante (default UE 100). min_net_update_frequency: minimo a cui l'engine può scendere (default UE 2). net_priority: peso relativo nella coda di replication (default UE 1.0). net_cull_distance: distanza in cm oltre la quale il client smette di riceverlo (default UE 15000). Scritta come quadrato, che è come Unreal la memorizza. only_relevant_to_owner: replica solo al client che lo possiede. net_use_owner_relevancy: eredita la relevancy dall'owner. net_load_on_client: se False l'attore non viene creato sui client al caricamento del livello.

ParametersJSON Schema

Name	Required	Description	Default
`dormancy`	No
`net_priority`	No
`blueprint_path`	Yes
`net_cull_distance`	No
`net_load_on_client`	No
`net_update_frequency`	No
`only_relevant_to_owner`	No
`net_use_owner_relevancy`	No
`min_net_update_frequency`	No

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations, the description carries the burden and largely succeeds. It discloses that only provided parameters are touched, lists default values for several fields, notes that net_cull_distance is stored squared, and explains the effect of net_load_on_client. It does not mention persistence or side effects like requiring a save/recompile, so not a 5.

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 with a summary, a key caveat, and a clear Args list. Every sentence adds value, and the formatting makes it easy to scan. It is appropriately detailed for nine parameters without unnecessary fluff.

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?

Given the tool's complexity (9 params, no parameter descriptions in schema, no output schema, no annotations), the description covers all necessary aspects: what it does, how it differs from siblings, parameter semantics, defaults, and edge-case storage behavior. It is fully sufficient for an agent to select and invoke the tool correctly.

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?

Schema description coverage is 0%, but the description compensates fully. It explains every parameter's meaning, valid values for dormancy, default values for frequency/priority/cull distance, and special behavior for cull distance and load-on-client. This goes far beyond the schema's bare type definitions.

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 clearly states the tool regulates 'how much bandwidth a replicated actor costs' via dormancy, update frequency, priority, and relevancy. It explicitly contrasts with sibling tool ue_set_replication, which decides whether to replicate, making the purpose unambiguous.

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

Usage Guidelines5/5

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

It gives explicit usage guidance: only passed parameters are modified, others remain unchanged. It also names the direct alternative (ue_set_replication) and explains the division of responsibility, plus provides a specific recommendation for dormancy='initial' with non-changing actors.

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

ue_set_project_settingA

Scrive un'impostazione nei file Config/Default.ini del progetto.

Args: section: es. "/Script/EngineSettings.GameMapsSettings". key: es. "GlobalDefaultGameMode". value: es. "/Game/MyGame/Blueprints/BP_MyGameMode.BP_MyGameMode_C". config: "Game" | "Engine" | "Input".

Nota: alcune impostazioni richiedono il riavvio dell'editor per avere effetto.

ParametersJSON Schema

Name	Required	Default
`key`	Yes
`value`	Yes
`config`	No	Game
`section`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool modifies config files and that some changes require restart, but does not specify whether values are appended/overwritten, error handling, or persistence behavior (e.g., if the file is created if missing). This leaves gaps.

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 short and well-structured, using a clear 'Args' list with examples. It avoids redundancy and is easy to scan. Minor improvement could be more compact formatting, but it's already efficient.

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

Completeness3/5

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

Given 4 parameters, no output schema, and no annotations, the description covers the parameters and adds a restart note. However, it lacks details on return values, side effects (e.g., auto-save), or error scenarios, which would make it more complete for an AI agent.

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?

The description compensates for 0% schema coverage by listing each parameter with real-world examples (e.g., '/Script/EngineSettings.GameMapsSettings') and specifying allowed values for 'config' ('Game' | 'Engine' | 'Input'). This adds significant meaning beyond the schema's basic types.

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 clearly states the tool writes a setting to project config files, with a specific verb (scrive/un'impostazione) and resource (file Config/Default<config>.ini). It provides detailed parameter examples, making the purpose unambiguous and distinct from sibling tools like ue_set_actor_property, which operate on different targets.

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

Usage Guidelines3/5

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

The description includes a note about requiring editor restart for some settings, giving a practical usage hint. However, it does not explicitly state when to use this tool versus alternatives (e.g., for runtime vs. persistent settings) or what prerequisites exist, limiting guidance.

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

ue_set_replicationB

Configura la replication di un Blueprint: se e come viene sincronizzato fra server e client in una partita in rete.

ParametersJSON Schema

Name	Required	Description	Default
`replicates`	No
`blueprint_path`	Yes
`always_relevant`	No
`replicate_movement`	No

TDQS

B3/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 disclose behavioral traits. It mentions synchronization context but omits critical details like whether changes are persistent, permissions needed, or side effects.

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 a single, well-structured sentence that front-loads the tool's purpose and context with no unnecessary words.

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

Completeness1/5

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

Despite having 4 parameters and no output schema or annotations, the description only provides a high-level purpose, lacking details on return values, parameter roles, and behavioral completeness for effective use.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description does not explain any of the four parameters (e.g., replicates, always_relevant, replicate_movement, blueprint_path), leaving the agent without guidance on how to set replication behavior.

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 clearly specifies the tool configures Blueprint replication for network synchronization, distinguishing it from sibling tools like ue_set_actor_property which address different aspects.

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

Usage Guidelines3/5

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

The description implies usage in network game contexts but provides no explicit guidance on when to use this tool over alternatives or when not to use it.

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

ue_skeleton_infoA

Elenca ossa e socket di uno Skeleton, dalla reference pose.

Args: skeleton_path: es. "/Game/MyGame/Characters/Hero/Hero_Skeleton".

ParametersJSON Schema

Name	Required	Description	Default
`skeleton_path`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations are absent, so the description carries the burden. It adds one useful behavioral detail wasser: 'dalla reference pose' (from the reference pose), which clarifies that results come from the base pose rather than the current animation pose. However, it does not disclose return format, error behavior, or whether the asset is loaded/modified, but as a read-only listing tool this is a moderate omission.

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 concise and front-loaded: a one-sentence purpose statement followed by a single well-formed param block. Every element is necessary and no words are wasted. The structure is clean and immediately scannable.

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

Completeness3/5

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

Given its simplicity (one parameter, no output schema), the description covers the core purpose and parameter adequately. However, it does not describe the output structure (e.g., does it return separate lists, a map, etc.) nor any potential failure modes. While not a complex tool, these gaps leave minor ambiguity for an agent invoking it.

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?

Schema coverage is 0% and the schema only provides a title. The description's 'Args' section clarifies the parameter 'skeleton_path' with a concrete example path ('/Game/MyGame/Characters/Hero/Hero_Skeleton'), explicitly indicating the expected format is a game content path. This adds meaning well beyond the bare schema.

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 clearly states the tool's function: 'Elenca ossa e socket di uno Skeleton, dalla reference pose' (Lists bones and sockets of a Skeleton, from the reference pose). This specific verb+resource combination distinguishes it from sibling info tools like ue_anim_sequence_info or ue_pcg_graph_info, which target other asset types.

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

Usage Guidelines3/5

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

The description implies when to use the tool (when you need to inspect a skeleton's bones/sockets) but provides no explicit alternatives or exclusions. There is no guidance on how this differs from other 'info' tools in the same family, though the resource focus makes the usage context reasonably clear.

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

ue_spawn_actorA

Spawna un attore nel livello corrente.

Args: class_ref: "StaticMeshActor", "/Script/Engine.PointLight", "/Game/MyGame/BP_Enemy", oppure il path di uno StaticMesh importato (spawn diretto della mesh). location: [x, y, z] in cm. rotation: [pitch, yaw, roll] in gradi. scale: [x, y, z] moltiplicatore. label: etichetta leggibile nell'Outliner (usata dagli altri tool per ritrovarlo).

ParametersJSON Schema

Name	Required	Description	Default
`label`	No
`scale`	No
`location`	No
`rotation`	No
`class_ref`	Yes

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries full burden. It explains parameters and notes that the label is used by other tools for retrieval. However, it does not disclose error handling, permission requirements, or side effects of spawning.

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 concise and well-structured in a bullet-like Args list. It is front-loaded with the main action and each parameter is explained briefly. Slightly verbose due to examples but overall efficient.

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 complexity of 5 parameters and no output schema, the description covers essential details for each parameter and explains the label's reuse. It lacks information on failure modes or coordinate systems, but is largely complete.

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?

With 0% schema description coverage, the description provides detailed semantics for all 5 parameters, including examples for class_ref and units for location and rotation. This adds significant value beyond the schema.

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 clearly states the tool spawns an actor in the current level, using a strong verb and resource. It distinguishes itself from the sibling 'ue_spawn_many' by implication (single vs many).

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

Usage Guidelines3/5

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

The description provides context on how to use the parameters but lacks explicit guidance on when to use this tool versus alternatives like 'ue_spawn_many'. It does not mention prerequisites or exclusions.

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

ue_spawn_manyA

Spawna molti attori in una sola chiamata e in una sola transazione undo.

Costruire un livello con ue_spawn_actor costa un round-trip HTTP per attore: per una scena di qualche decina di elementi conviene questo.

Args: actors: lista di dict con class_ref (obbligatorio) e, opzionali, location [x,y,z], rotation [pitch,yaw,roll], scale [x,y,z], label. Esempio: [{"class_ref": "PointLight", "location": [0,0,300]}].

ParametersJSON Schema

Name	Required	Description	Default
`actors`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that spawning is grouped into a single undo transaction, which is a key behavioral trait. However, it does not mention failure handling, permissions, limits on number of actors, or what happens to the spawned actors (e.g., naming, collision). The description is adequate but not thorough.

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, starting with a clear purpose, followed by a rationale, then a concise parameter breakdown. Every sentence adds value; there is no redundancy or filler. It is appropriately sized for the tool's simplicity.

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 single parameter and no output schema, the description covers input needs thoroughly. It explains the undo transaction and performance benefit. However, it does not describe the return value (e.g., success indication, spawned actor references) or maximum number of actors, leaving minor gaps for a complete understanding.

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 only defines 'actors' as an array of objects with no structure, while the description provides detailed semantics: required 'class_ref', optional 'location', 'rotation', 'scale', 'label', plus an example. This fully compensates for the 0% schema description coverage and is essential for correct invocation.

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 clearly states the tool spawns many actors in one call and one undo transaction, and explicitly contrasts with ue_spawn_actor which requires multiple HTTP round-trips. The verb 'spawna' and resource 'molti attori' are specific, and the sibling tool differentiation is clear.

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 advises using this tool when spawning 'qualche decina di elementi' (several tens of elements) due to cost savings over individual spawns. This implies a threshold for when to use this vs ue_spawn_actor, though it does not explicitly state when NOT to use it (e.g., for single actors).

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

ue_start_pieB

Avvia il Play In Editor con le impostazioni correnti.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states the action without disclosing potential side effects, required editor state, or safety implications.

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?

Single sentence, no fluff. It is efficient but could be better structured with additional context. Still above average for brevity.

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

Completeness2/5

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

For a simple zero-parameter tool with no output schema, the description is minimal but does not mention any contextual details like required editor state or that current settings are used. It leaves gaps for an AI agent.

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?

No parameters exist in the schema, and description coverage is 100%. The description adds no param info, which is appropriate. Baseline score of 4 applies.

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 tool starts Play In Editor with current settings. It is distinct from siblings like ue_stop_pie and ue_configure_pie, though no explicit differentiation is made.

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 on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring the editor to be open, or conditions when PIE cannot be started.

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

ue_statusA

Verifica la connessione all'editor Unreal e restituisce versione motore, progetto aperto, livello corrente, numero di attori e trasporto in uso. Da usare per prima.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It lists the return fields but does not explicitly state that the tool is read-only or non-destructive. However, given it is a status check, it is likely safe. The description could be more explicit about side effects or limitations.

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?

Two sentences, no wasted words. The first sentence states purpose and return values, the second gives usage priority. Front-loaded and efficient.

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 status check tool with no output schema, the description adequately lists all return fields. It also provides contextual guidance (use first). No additional information is needed.

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?

The input schema has zero parameters, so no parameter explanations are needed. Baseline score of 4 applies as the description does not need to add parameter 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 clearly states the tool checks Unreal Editor connection and returns specific status fields (engine version, open project, current level, actor count, transport). It distinguishes itself from sibling tools by being a diagnostic/status check rather than an action tool.

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

Usage Guidelines5/5

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

The description explicitly says 'Da usare per prima' (use it first), providing clear guidance on when to use this tool relative to siblings, implying it should be a preliminary step.

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

ue_stop_pieA

Ferma la sessione Play In Editor in corso.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states it stops the current session but does not disclose side effects (e.g., losing unsaved changes), requirements (e.g., a session must be running), or what happens if no session exists. Adequate for a simple stop command but lacks behavioral context.

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 a single short sentence with no wasted words. It is front-loaded and immediately communicates the tool's purpose.

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?

Given the tool has no parameters, no output schema, and performs a simple action, the description is sufficient. It fully explains what the tool does without needing additional context.

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?

The tool has zero parameters, and the input schema has 100% coverage (empty). Per guidelines, baseline for 0 parameters is 4. The description does not need to add parameter information.

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 uses a specific verb ('Ferma', stops) and resource ('sessione Play In Editor', Play In Editor session), clearly indicating the tool's action. It distinguishes from siblings like ue_start_pie which starts the session.

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

Usage Guidelines3/5

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

The description implies usage after starting a PIE session but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The context makes it somewhat clear, but it lacks direct usage instructions.

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

ue_umg_add_widgetA

Crea un widget e lo mette sotto un pannello dell'albero.

Args: widget_blueprint_path: es. "/Game/UI/WBP_MainMenu". widget_class: "TextBlock", "Button", "Image", "VerticalBox", "HorizontalBox", "CanvasPanel", "Overlay", "Border", "ProgressBar"… parent: nome del pannello che lo conterrà; se omesso, la radice. Dev'essere un PanelWidget: un TextBlock non può contenere nulla. name: nome del widget, quello che si vedrà in Hierarchy e che serve per BindWidget da C++. Se omesso lo sceglie Unreal. slot: layout dentro il pannello, applicato subito — le stesse chiavi di ue_umg_set_slot.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`slot`	No
`parent`	No
`widget_class`	Yes
`widget_blueprint_path`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: the widget is placed under the specified panel (or root if parent omitted), slot layout is applied immediately, and the name parameter affects C++ BindWidget and is auto-generated if omitted. It also notes the parent must be a PanelWidget. It does not mention error handling or whether the blueprint must be open, but covers the primary behavioral traits.

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 with a one-sentence summary followed by an Args block. Each bullet is directly useful, providing examples and constraints without redundant information. It is appropriately sized for the complexity of five parameters.

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 moderate complexity (5 params, no output schema), the description is quite complete. It explains all parameters, constraints, and immediate behavior. It does not mention possible error conditions or prerequisites beyond parent being a PanelWidget, but it is sufficient for an agent to invoke the tool correctly.

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 schema has 0% description coverage, with only types and titles. The description adds extensive meaning for every parameter: examples for widget_blueprint_path, a list of valid widget_class values, parent default behavior, name usage and auto-generation, and slot keys referencing ue_umg_set_slot. This fully compensates for the schema's lack of descriptions.

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 clearly states the tool's action with a specific verb+resource: 'Crea un widget e lo mette sotto un pannello dell'albero' (Creates a widget and puts it under a tree panel). This distinguishes it from siblings like ue_umg_remove_widget, ue_umg_set_widget_property, and ue_umg_set_slot, which operate on widgets differently.

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 gives clear context for when to use the tool: adding a widget to a UMG tree under a panel. It includes constraints (parent must be a PanelWidget) and references an alternative tool for setting slot properties (ue_umg_set_slot). However, it does not explicitly state when not to use it or mention other alternatives, so it is slightly below a perfect score.

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

ue_umg_remove_widgetA

Toglie un widget dall'albero, con tutto quello che contiene.

La radice non si può togliere (RootWidget non è scrivibile): per svuotare un albero, rimuovi i figli della radice.

ParametersJSON Schema

Name	Required	Description	Default
`widget`	Yes
`widget_blueprint_path`	Yes

TDQS

A3.6/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 for behavioral disclosure. It reveals that removal is recursive and that the root widget is not removable, which are useful traits. However, it lacks information about side effects such as undo behavior, error handling when the widget is not found, or whether it persists immediately. These gaps make the behavioral transparency partial.

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 extremely concise, consisting of two short sentences. The first sentence states the core purpose, and the second adds a critical constraint. It is front-loaded and every word earns its place, with no wasted content.

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

Completeness3/5

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

For a two-parameter removal tool, the description gives essential behavior and a key limitation, but it omits parameter semantics and potential side effects. There is no output schema and no annotations, so the tool is only moderately complete. An agent might successfully use it for simple cases but could struggle with exceptional scenarios or parameter correctness.

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

Parameters1/5

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

The schema provides no descriptions for the parameters, and the description does not explain 'widget_blueprint_path' or 'widget' beyond the tool's name. With 0% schema coverage, the description must compensate, but it offers no details about expected formats, how they identify the target, or how they relate to each other. This leaves the agent guessing about parameter values.

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 clearly states the action: 'Toglie un widget dall'albero' (removes a widget from the tree) and specifies the recursive scope 'con tutto quello che contiene' (with everything it contains). This distinguishes it from sibling tools like ue_umg_add_widget or ue_umg_set_widget_property, making the purpose unambiguous.

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 provides clear context for using the tool (removing widgets) and includes an important usage restriction (the root cannot be removed, and to empty a tree one should remove the root's children). It does not explicitly mention alternatives or when not to use it, but the usage context is sufficiently clear for an agent.

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

ue_umg_set_slotA

Imposta il layout di un widget dentro il suo pannello.

Le chiavi valide dipendono dal pannello che lo contiene, e ue_umg_tree_info riporta slot_class per saperlo:

CanvasPanelSlot: position [x, y], size [x, y], z_order, alignment, auto_size.
VerticalBoxSlot / HorizontalBoxSlot: padding (numero singolo, o [left, top, right, bottom], o {"left":…}), horizontal_alignment, vertical_alignment.

Le liste di 2 numeri diventano Vector2D, quelle di 4 un Margin.

ParametersJSON Schema

Name	Required	Description	Default
`widget`	Yes
`properties`	Yes
`widget_blueprint_path`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of explaining behavior. It details valid property keys per slot type and explains data transformations (2-number lists become Vector2D, 4-number lists become Margin). It does not mention permissions, error handling, or whether this replaces existing layout settings, but the core mutation behavior and accepted inputs are well disclosed.

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 with a concise opening sentence followed by a bulleted breakdown of valid keys per slot type. The format examples are compact and add value without redundancy. Every sentence contributes useful information.

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 moderate complexity and lack of output schema, the description covers the essential aspects: how to determine slot_class, what keys are valid, and how values are converted. It lacks details on error handling or prerequisites (e.g., widget must already exist in a panel), but the provided information is sufficient for typical usage.

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%, but the description heavily compensates by explaining the `properties` parameter in detail, including per-slot-class valid keys and value formats. The other two parameters (`widget` and `widget_blueprint_path`) are not described, but their purpose is reasonably inferable from their names.

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 clearly states the tool's function: setting the layout of a widget within its panel. It distinguishes itself from sibling tools like ue_umg_set_widget_property by focusing specifically on slot/layout properties, and it references ue_umg_tree_info to determine the slot class.

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 provides clear context for when to use the tool: when setting layout properties on a widget's slot. It explicitly instructs users to check ue_umg_tree_info for the slot_class before choosing valid keys, which gives strong usage guidance. It does not explicitly mention alternatives or exclusion cases, but the context is clear enough.

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

ue_umg_set_widget_propertyA

Imposta proprietà su un widget: testo, colore, visibilità, immagine.

Le proprietà di testo sono FText nel motore: passa una stringa normale, la conversione è automatica. I dict con x/y/z, pitch/yaw/roll o r/g/b diventano i tipi Unreal corrispondenti, e i path "/Game/..." vengono caricati come asset.

Restituisce applied e failed separati: una proprietà sbagliata non fa fallire le altre.

ParametersJSON Schema

Name	Required	Description	Default
`widget`	Yes
`properties`	Yes
`widget_blueprint_path`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses automatic FText conversion, dict-to-Unreal type mapping for vectors/colors, asset path loading, and the fact that a wrong property does not fail others. This is more transparent than typical mutation tools, but lacks details on persistence or side effects.

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?

Three compact sentences deliver purpose, conversion rules, and return behavior without redundancy. Every sentence contributes actionable information.

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?

The description covers the core function and error handling, which is commendable given the absence of an output schema. However, it does not enumerate supported properties beyond examples, nor clarify how widget identity is specified. The return contract of `applied` and `failed` is stated, which is sufficient for basic invocation.

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 coverage is 0%, so the description must compensate. It elaborates on the `properties` parameter via conversion rules, but provides no explanation for `widget_blueprint_path` or `widget` beyond their names. The properties dict is well-served; the other two required params are not.

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 states 'Imposta proprietà su un widget' (sets properties on a widget) and lists concrete examples (text, color, visibility, image). This clearly identifies a specific action and resource, distinguishing it from sibling tools like ue_umg_set_slot or ue_umg_add_widget.

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

Usage Guidelines3/5

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

The description provides context about type conversions and error handling, but does not explicitly state when to use this tool over alternatives (e.g., ue_umg_set_slot) or when not to use it. Usage is implied by the tool name and description.

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

ue_umg_tree_infoA

La gerarchia dei widget di un Widget Blueprint: nomi, classi, figli e tipo di slot.

root: null vuol dire albero vuoto — lì non si può aggiungere niente finché non c'è una radice.

ParametersJSON Schema

Name	Required	Description	Default
`widget_blueprint_path`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing exactly what info is returned (names, classes, children, slot type) and a special case (root: null means empty tree with no addable root). It does not describe error behavior or side effects, but for a read-only info tool this is adequate.

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 only two sentences, with the core purpose front-loaded in the first sentence and an important edge case in the second. Every word earns its place with no repetition or fluff.

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

Completeness3/5

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

For a simple 1-parameter read tool, the description covers the content of the returned hierarchy and the empty-tree case, which is good. However, it lacks parameter semantics and any mention of output format or error conditions, leaving some gaps for the agent.

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

Parameters2/5

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

The input schema has 0% description coverage, and the description does not mention widget_blueprint_path at all. The parameter name is somewhat self-explanatory, but the description should provide path format or examples, especially since schemas carry no descriptions.

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 the tool returns widget hierarchy information: names, classes, children, and slot type. It clearly identifies the resource (Widget Blueprint) and distinguishes from sibling tools like ue_umg_add_widget or ue_umg_remove_widget, though it lacks an explicit verb such as 'retrieves' or 'lists'.

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

Usage Guidelines3/5

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

The description implies a usage context by explaining that an empty tree (root: null) cannot accept additions until a root exists, suggesting this tool is for checking hierarchy structure before adding widgets. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

91 tool updatesv0.10.0Jul 31, 2026
- Addedue_anim_sequence_info
- Addedue_blackboard_add_key
- Addedue_blackboard_info
- Addedue_bp_add_branch
- Addedue_bp_add_call_function
- Addedue_bp_add_custom_event
- Addedue_bp_add_event_override
- Addedue_bp_add_function_graph
- Addedue_bp_add_node_by_name
- Addedue_bp_add_variable_node
- Addedue_bp_break_pin
- Addedue_bp_connect
- Addedue_bp_graph_info
- Addedue_bp_list_events
- Addedue_bp_list_graphs
- Addedue_bp_list_palette
- Addedue_bp_remove_node
- Addedue_bp_set_pin_value
- Addedue_bt_add_decorator
- Addedue_bt_add_node
- Addedue_bt_add_service
- Addedue_bt_info
- Addedue_bt_set_node_property
- Addedue_component_physics_info
- Addedue_create_anim_blueprint
- Addedue_create_anim_montage
- Addedue_create_behavior_tree
- Addedue_create_blackboard
- Addedue_create_blend_space_1d
- Addedue_create_eqs_asset
- Addedue_create_foliage_spawner
- Addedue_create_foliage_type
- Addedue_create_gameplay_ability
- Addedue_create_gameplay_effect
- Addedue_create_level_sequence
- Addedue_create_niagara_system
- Addedue_create_pcg_graph
- Addedue_create_widget_blueprint
- Addedue_find_classes
- Addedue_find_structs
- Addedue_flow_run
- Addedue_foliage_add_instances
- Addedue_foliage_list
- Addedue_foliage_query
- Addedue_foliage_remove
- Addedue_foliage_scatter
- Addedue_foliage_simulate
- Addedue_foliage_spawn_volume
- Addedue_ge_add_component
- Addedue_ge_add_modifier
- Addedue_ge_info
- Addedue_landscape_export_heightmap
- Addedue_landscape_import_heightmap
- Addedue_landscape_import_weightmap
- Addedue_landscape_info
- Addedue_landscape_list
- Addedue_landscape_set_grass
- Addedue_landscape_set_material
- Addedue_nav_find_path
- Addedue_nav_query_point
- Addedue_nav_rebuild
- Addedue_net_info
- Addedue_niagara_system_info
- Addedue_pcg_add_node
- Addedue_pcg_cleanup
- Addedue_pcg_connect
- Addedue_pcg_disconnect
- Addedue_pcg_generate
- Addedue_pcg_graph_info
- Addedue_pcg_remove_node
- Addedue_pcg_set_node_property
- Addedue_pcg_spawn_volume
- Addedue_reflect_enum
- Addedue_sequence_add_actor
- Addedue_sequence_add_key
- Addedue_sequence_add_track
- Addedue_sequence_info
- Addedue_sequence_open
- Addedue_sequence_remove
- Addedue_sequence_set_range
- Addedue_set_component_default
- Addedue_set_component_physics
- Addedue_set_component_replication
- Addedue_set_foliage_property
- Addedue_set_net_config
- Addedue_skeleton_info
- Addedue_umg_add_widget
- Addedue_umg_remove_widget
- Addedue_umg_set_slot
- Addedue_umg_set_widget_property
- Addedue_umg_tree_info

30 tool updatesv0.6.0Jul 30, 2026

Addedue_actor_hierarchy
Addedue_assign_material
Addedue_attach_actor

Changedue_build_start2 fields changed

addedInput schema / properties / engine_root

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Engine Root"
+}

addedInput schema / properties / force

Added value: +{
+  "default": false,
+  "title": "Force",
+  "type": "boolean"
+}

Changedue_build_status2 fields changed

addedInput schema / properties / uproject

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Uproject"
+}

addedInput schema / properties / wait_seconds

Added value: +{
+  "default": 0,
+  "title": "Wait Seconds",
+  "type": "number"
+}

Addedue_build_unblock
Addedue_console_command
Addedue_cpp_class_create
Addedue_create_material
Addedue_create_material_instance
Addedue_delete_asset
Addedue_detach_actor
Addedue_duplicate_asset

Changedue_editor_open3 fields changed

addedInput schema / properties / engine_root

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Engine Root"
+}

addedInput schema / properties / skip_module_check

Added value: +{
+  "default": false,
+  "title": "Skip Module Check",
+  "type": "boolean"
+}

changedInput schema / properties / wait_seconds / default
```
Previous value: -240New value: +50
```

Changedue_engine_templates1 field changed

addedInput schema / properties / engine_root

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Engine Root"
+}

Addedue_focus_actor
Addedue_get_camera
Addedue_list_actor_components
Addedue_make_folder

Changedue_package_start2 fields changed

addedInput schema / properties / engine_root

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Engine Root"
+}

addedInput schema / properties / target_platform

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Target Platform"
+}

Changedue_package_status2 fields changed

addedInput schema / properties / uproject

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Uproject"
+}

addedInput schema / properties / wait_seconds

Added value: +{
+  "default": 0,
+  "title": "Wait Seconds",
+  "type": "number"
+}

Changedue_project_create1 field changed

addedInput schema / properties / engine_root

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Engine Root"
+}

Addedue_rename_asset
Addedue_render_sequence
Addedue_render_status
Addedue_reparent_blueprint
Addedue_screenshot
Addedue_set_actor_property
Addedue_set_camera
Addedue_spawn_many

49 tool updatesv0.1.0Jul 28, 2026
- First observedpreset_download_ambientcg
- First observedpreset_download_kenney
- First observedpreset_download_polyhaven
- First observedpreset_download_url
- First observedpreset_extract_archive
- First observedpreset_fab_download
- First observedpreset_fab_list_vault
- First observedpreset_library_list
- First observedpreset_search_ambientcg
- First observedpreset_search_polyhaven
- First observedue_add_component
- First observedue_add_variable
- First observedue_build_start
- First observedue_build_status
- First observedue_compile_blueprint
- First observedue_configure_pie
- First observedue_create_blueprint
- First observedue_create_metasound_source
- First observedue_create_sound_cue
- First observedue_delete_actor
- First observedue_editor_close
- First observedue_editor_open
- First observedue_editor_status
- First observedue_engine_list
- First observedue_engine_templates
- First observedue_exec_python
- First observedue_import_assets
- First observedue_import_audio
- First observedue_list_actors
- First observedue_list_assets
- First observedue_live_compile
- First observedue_new_level
- First observedue_open_level
- First observedue_package_start
- First observedue_package_status
- First observedue_project_create
- First observedue_project_find
- First observedue_project_info
- First observedue_project_set_plugins
- First observedue_read_log
- First observedue_save_all
- First observedue_set_actor_transform
- First observedue_set_class_defaults
- First observedue_set_project_setting
- First observedue_set_replication
- First observedue_spawn_actor
- First observedue_start_pie
- First observedue_status
- First observedue_stop_pie

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-09-09 18:01 across 163 tools

Disambiguation4/5

Domain-prefixed families (ue_bp_, ue_umg_, ue_pcg_, ue_foliage_, ue_sequence_) make each tool's target resource obvious, and descriptions explicitly disambiguate near-neighbors like ue_set_replication vs ue_set_component_replication vs ue_set_net_config. A few pairs could still be confused on first pass — ue_import_assets already accepts .wav yet ue_import_audio duplicates it, ue_status vs ue_editor_status both report editor state, and ue_editor_open vs ue_open_level both use "open" for different targets — but these are rare exceptions across 163 tools.

Naming Consistency4/5

The dominant ue_<domain>_<verb>_<noun> pattern with coherent families (ue_create_*, ue_*_info, ue_*_list, ue_*_status, ue_bp_add_*, ue_bt_add_*) is highly predictable and makes tool discovery feasible at this scale. Minor deviations exist — ue_make_folder breaks the create_* convention, the preset_* family uses a different prefix, and tools like ue_read_log, ue_reflect_enum, and ue_live_compile don't fit the standard verb set — but they are rare and internally readable.

Tool Count2/5

163 tools is more than six times the 25+ threshold and will overwhelm an agent's selection space even with good naming, so the set is too large for practical use in a single MCP server. The scope is genuinely broad (project management, C++ build, Blueprint graphs, UMG, AI, GAS, PCG, foliage, landscape, sequencer, networking, asset acquisition), which prevents a score of 1, but the count reflects roughly fifteen sub-domains packed into one surface and includes partial duplicates like ue_import_audio and ue_spawn_many.

Completeness4/5

Coverage is exceptional: nearly every sub-domain has create + inspect + modify operations, and Blueprint graph editing, PCG, foliage, AI, and sequencer are unusually deep, with no obvious dead ends in the core asset/actor/project workflows. The remaining gaps are documented engine-level limits with workarounds — Niagara emitter stacks, EQS query internals, UMG root widgets, and AnimGraphs cannot be scripted, landscape creation requires the editor, and there is no undo tool — so agents can route around them via ue_exec_python, ue_cpp_class_create, or manual editor steps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ChiR24-unreal_mcp_serverOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Developer Tools App Automation Software Architecture
2873
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
ChiR24-unreal_mcpOAuth
ai.smithery
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Developer Tools App Automation Multimedia Processing
2873

Related MCP Servers

soft-ue-cli
Developer Tools Autonomous Agents
softdaddy-o
A
license
Not graded
quality
A
maintenance
MCP server for controlling Unreal Engine 5 from AI agents, providing 120+ commands for spawning actors, editing Blueprints, managing assets, and more via CLI or MCP.
Updated a month ago (2026-08-03 13:09 UTC)
54 PyPI
209
MIT
Hayba
Design Tools Autonomous Agents Developer Tools
zajalist
A
license
Not graded
quality
C
maintenance
An MCP server enabling AI agents to author Unreal Engine 5 scenes directly, with tools for spawning actors, building PCG graphs, validating physics, generating terrain, and more through a single MCP connection.
Updated 11 days ago (2026-09-06 17:03 UTC)
13
MIT
unreal-engine-mcp
Developer Tools Autonomous Agents
harn3ss
A
license
B
quality
C
maintenance
An MCP server that gives AI agents broad control over Unreal Engine 5.7, enabling actor/asset/level management, Blueprint and material creation, screenshots, automation, and arbitrary editor Python execution.
Updated 3 months ago (2026-06-13 04:24 UTC)
35
MIT
Unreal-MCP-Ghost
Developer Tools Games & Gamification Autonomous Agents
CrispyW0nton
A
license
Not graded
quality
C
maintenance
Enables AI clients to control Unreal Engine 5 editor for automated Blueprint authoring, level inspection, actor spawning, and other editor workflows via a local Python MCP server and UE plugin.
Updated 14 days ago (2026-09-04 00:46 UTC)
3
AGPL 3.0