Unreal Engine MCP

by FFZackFair92

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.10.0
Disambiguation4/5
With 163 tools spanning many subsystems, the use of domain prefixes (ue_bp_, ue_pcg_, ue_landscape_, etc.) and clear verb-first names keeps most tools easily distinguishable. A few pairs like ue_status and ue_editor_status could be confused, but their descriptions clearly differentiate editor-process status from general connection status. Overall, tool purposes are well-differentiated despite the large catalog.
Naming Consistency4/5
The dominant naming convention is verb_noun with ue_ prefix and optional subdomain prefixes (e.g., ue_list_actors, ue_spawn_actor, ue_pcg_add_node). Some exceptions like preset_library_list and ue_nav_query_point break the verb-first pattern, but they are relatively minor given the consistency of the vast majority. The hierarchical prefix system adds predictability and reduces ambiguity.
Tool Count1/5
At 163 tools, this server far exceeds even the 50+ threshold considered an extreme mismatch, making it overwhelming for an agent to navigate efficiently. While the scope mirrors Unreal Engine's complexity, such a large number of highly specialized tools is not well-scoped for typical MCP usage. Many could be consolidated or grouped without losing capability.
Completeness3/5
The server covers an impressively broad range: asset management, Blueprint metadata, AI (Behavior Trees, Blackboards, EQS), PCG, foliage, landscape, UMG, Gameplay Ability System, networking, and level sequences. However, several subsystems are only partially implemented—Blueprint graphs, AnimGraph, Niagara emitters, and EQS queries are explicitly not scriptable—leaving notable gaps in full workflow coverage. The availability of ue_exec_python and ue_console_command mitigates some limitations but does not make them first-class tools.
Average 3.8/5 across 145 of 163 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'quick way' but does not disclose side effects, reference handling, or permissions needed. Minimal behavioral insight.
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 one short sentence, which is concise, but it is too sparse for the tool's needs. It lacks structure and essential details.
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 asset duplication tool with two required parameters and no output schema, the description fails to explain what the parameters are or the behavior of the operation, leaving the tool under-specified.
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 does not mention the two parameters ('path' and 'new_path') or their meaning. Given the schema has 0% description coverage, 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 the action ('duplicate an asset') and the purpose ('quick way to create a variant to modify'). It distinguishes from sibling tools like 'ue_delete_asset' or 'ue_rename_asset' through the verb, but does not explicitly differentiate from potential copy operations.
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 such as asset import or creation. No context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states a simple import action. It omits crucial details such as whether files are from the filesystem, overwrite behavior, support for multiple files, path handling, or side effects on the Content Browser.
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 sentence, which is concise, but it is in Italian while the tool name is English, which may cause confusion. It lacks detail but is efficiently short.
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 complexity (2 parameters, no annotations, many siblings), the description is insufficient. It does not mention the output schema, behavior with invalid files, or differentiate from other audio-related tools.
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 parameters 'files' or 'destination'. It doesn't clarify what path format is expected (absolute, relative, content path) or the default value's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (import) and resource (.wav files) and result (SoundWave in Content Browser). It specifies the file type and asset type, distinguishing from sibling import tools. However, it doesn't contrast explicitly with ue_import_assets or other audio 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 guidance is provided on when to use this tool versus alternatives like ue_import_assets, ue_create_metasound_source, or ue_create_sound_cue. There are no prerequisites or scenario descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only mentions searching for .uproject files, omitting details like recursion behavior, error handling, or performance implications.
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 short sentence, which is concise but lacks structure. It is front-loaded but could include more information without being 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 the tool has two parameters and no output schema, the description is incomplete. It does not explain the output (file paths) or the behavior of `max_depth`.
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 hints at the directory parameter ('sotto una cartella') but does not explain `max_depth`. No additional meaning beyond parameter names.
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, which is a specific verb+resource pair. It distinguishes from sibling tools like ue_project_create or ue_project_info, as this is about finding existing files.
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 vs alternatives. The description only states what it does, without any context, exclusions, or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not state whether the tool is read-only, destructive, or safe. It merely describes the action without behavioral traits. Since it is a list operation, likely safe, but not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded and contains no fluff, but could benefit from additional details without becoming 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?
Given the simple tool with two optional params and an output schema, the description is adequate but lacks completeness: no mention of expected output format (though output schema exists), no error handling, and no mention of case sensitivity or wildcard 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?
Schema coverage is 0%, yet the description only vaguely mentions filters on name and class. It does not explain that parameters are substring matches (name_contains, class_contains) or any constraints like case sensitivity. The description adds minimal value beyond the parameter names.
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 actors of the current level, distinguishing it from sibling tools like ue_spawn_actor (create) and ue_delete_actor (delete). It is specific but lacks detail on scope beyond current level.
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 vs. alternatives (e.g., ue_list_assets for assets). No exclusions or prerequisites mentioned. The context signal shows many siblings, but the description does not help choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'download and extract' but provides no details on side effects, file destinations, overwrite behavior, or authentication needs. With no annotations, 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 very concise, with only two lines plus examples, and is front-loaded. It could include more structure but remains 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 is too sparse. It lacks details on return value, extraction process, and parameter constraints beyond examples.
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 gives example values for asset_id and variant, which adds value beyond the schema's type definitions. However, the destination parameter is not explained, and the coverage is only partial.
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 ambientCG assets with a specific resource type. However, it does not differentiate from sibling download tools like preset_download_polyhaven or preset_download_kenney, leaving ambiguity for the agent.
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, no prerequisites, and no exclusions. The agent must 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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is too brief. It does not disclose side effects (e.g., permanent deletion, undoability), required permissions, or behaviors like whether it fails silently or throws errors. The tool performs a mutation but no behavioral details are given.
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?
One efficient sentence with no wasted words, but too brief for the needed information. It is well-structured but under-specified.
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 deletion tool with one parameter and no output schema, it lacks critical context: how to identify the actor (label meaning), uniqueness, behavior on missing label, and whether the level must be active. Incomplete for confident invocation.
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 'label' has no description in the schema (0% coverage). The tool description only says 'with the given label', adding no additional meaning (e.g., what constitutes a label, whether case-sensitive, if it refers to actor name or tag). Does not compensate for 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?
Description clearly states 'Delete from the current level the actor with the given label.' It specifies the action (delete), resource (actor), scope (current level), and identifier (label). This distinguishes it from siblings like ue_list_actors and ue_spawn_actor.
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 provided on when to use this tool versus alternatives, prerequisites (e.g., level must be open, actor must exist), or what happens if the label is not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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 behavioral traits. It indicates mutation ('modifica') but fails to mention potential side effects, required permissions, whether the transform change is absolute or relative, or if it triggers any events. For a mutation tool, 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?
A single sentence that directly conveys the tool's purpose without any filler. The front-loading is effective—the core action and target are clear immediately.
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 too sparse for a tool with 4 parameters and no output schema. It does not explain the effect on other transform properties when some are omitted, error handling (e.g., if label not found), or any behavioral context like whether it works in play mode. Significant gaps remain.
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 maps Italian terms to parameters ('posizione/rotazione/scala' to location/rotation/scale) and clarifies that 'label' identifies the actor. However, it does not explain the expected format of the arrays (e.g., [x,y,z] units) or default behavior. With 0% schema coverage, this adds minimal value beyond the parameter names.
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 modifies the transform (position/rotation/scale) of an actor identified by its label. The verb+resource combination is specific, but it does not distinguish from sibling tools that also modify actors, such as ue_set_replication or ue_set_class_defaults.
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. There is no mention of prerequisites, context (e.g., must be in edit mode), or when not to use it. This leaves the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It mentions the archive must be on disk and rar unsupported, but lacks details on success/failure, overwriting behavior, destination default, or supported compression formats like .tar.gz. Minimal 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?
A single sentence that is front-loaded with the core action and constraints. Every word adds value. There is no fluff, making it highly concise and well-structured.
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 2 parameters with no schema descriptions, no output schema, and no annotations, the description is incomplete. It fails to explain the destination parameter, return values, error handling, or extraction behavior. For an AI agent, this is insufficient for correct invocation.
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 explain both parameters. It clarifies the 'archive' parameter must be a zip/tar file path, but says nothing about the 'destination' parameter (its purpose, format, or default). The description does not compensate for the missing schema 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 clearly states the tool extracts zip/tar archives already on disk and explicitly excludes rar. This differentiates it from potential sibling tools. The verb and resource are specific, but it doesn't explicitly distinguish from other extraction methods.
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 zip/tar archive is on disk and rar is not supported, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that the tool lists components with name and class, but does not specify whether it is read-only, any side effects, or required permissions. The behavioral scope 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each serving a clear purpose: stating the tool's action and its utility. No redundant 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 tool has one parameter and no output schema or annotations, the description should clarify the parameter and output format. It mentions output fields but not the input parameter. It also does not describe if components are direct or recursive, limiting completeness.
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 one parameter 'label' with no description and 0% schema coverage. The description does not explain what 'label' means (e.g., actor's label or identifier), leaving the agent to infer meaning.
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 specifies the verb (list), resource (components of a placed actor), and output fields (name and class). It distinguishes the tool by linking it to ue_set_actor_property, but does not explicitly differentiate from siblings.
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 states the tool's purpose is to know what to pass to ue_set_actor_property, giving implicit usage context. However, it does not provide when-to-use or when-not-to-use guidance, nor mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It indicates a mutation operation (setting defaults) but does not mention side effects, permissions, or whether changes are immediately applied. Minimal 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 short and to the point, with no unnecessary words or repetition. It efficiently communicates the tool's function and parameters.
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?
No output schema exists, and the description does not specify what the tool returns or any side effects. Lacks context about prerequisites (e.g., blueprint must exist) or success indication.
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?
Since schema coverage is 0%, the description compensates by describing each parameter meaning and providing an example for 'properties' (e.g., {'replicates': true}). This goes beyond the schema which only specifies types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('imposta' - sets) and the resource ('Class Defaults (CDO) di un Blueprint'). It distinguishes from siblings like 'ue_set_replication' which sets a specific property, but doesn't explicitly differentiate from other blueprint modification 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 guidance on when to use this tool versus alternatives (e.g., ue_set_replication). No mention of prerequisites or conditions under which the tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'downloads via legendary' without disclosing aspects like blocking behavior, overwrite policy, authentication needs, or progress indication. This is insufficient for a download 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 to the point, with a structured args section. It avoids unnecessary words but could include more detail without losing conciseness.
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?
Given no output schema, no annotations, and 0% schema coverage, the description is severely incomplete. It does not mention return values, error handling, file size limits, or any operational context, leaving the agent without crucial information.
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 that app_name is the identifier from preset_fab_list_vault, adding value beyond the schema. However, the destination parameter receives no explanation, and overall schema coverage is 0%, so the description only partially 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 it downloads an asset from the Epic vault using 'legendary', which is a specific verb and resource. It is distinct from sibling tools like preset_fab_list_vault (listing) and preset_download_url (different source).
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 indicates that app_name comes from preset_fab_list_vault, providing a prerequisite. However, it does not explicitly state when to use this tool over alternatives or when to avoid it, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects. It states the tool assigns a material (a mutation), but does not mention whether it overwrites existing materials, requires specific permissions, or what happens on errors (e.g., missing material path).
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 one-line purpose and line-separated arguments. The mixed language (Italian intro, English args) is a minor drawback but overall 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?
The description covers parameter meanings but lacks details on return values (likely none), error handling, or behavior when inputs are invalid. Given 4 parameters and no annotations, it is somewhat incomplete for a mutation 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?
With 0% schema description coverage, the description adds value by explaining each parameter: label (actor's Outliner label), material_path (example given), slot (default 0), component (default first MeshComponent). This clarifies usage beyond bare schema types.
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 assigns a material to a placed actor ("Assegna un materiale a un attore piazzato"). It is distinct from sibling tools like ue_spawn_actor or ue_create_material, though the use of Italian may reduce clarity for non-Italian speakers.
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_create_material or ue_set_actor_property). There is no mention of prerequisites or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavioral traits. It states the tool returns status but does not mention if it is read-only, if it requires authentication, or if it blocks. The description is minimal and leaves behavior largely unspecified.
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 concise at one sentence. It is front-loaded with the core purpose. However, it is in Italian, which may reduce accessibility, and could benefit from slight expansion.
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 zero parameters and no output schema, the description is fairly complete for a simple status tool. However, in the context of many sibling status tools, it could be more specific about what information is returned (e.g., running state, error codes) to 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 zero parameters, so the description does not need to add parameter meaning. The baseline for no parameters is 4. The description is adequate for this dimension.
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 provides status of the editor process and Remote Control bridge. It differentiates from sibling status tools like 'ue_status' and 'ue_build_status' by specifying 'editor process avviato da questo MCP'. However, the English translation is not provided, which may reduce clarity for non-Italian speakers.
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, such as whether the editor must be running, nor does it suggest when 'ue_status' or other status tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only listing operation by using 'elenca' (lists), but does not explicitly state safety or side effects. With no annotations provided, the description moderately covers behavior adequacy but lacks detail on requirements or restrictions.
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 front-loads the core purpose. Every word is necessary, and there is no redundant 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 tool has two undocumented parameters and no output schema, the description should at least hint at parameter meaning or return format. It omits this entirely, leaving the agent underinformed for proper 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 description does not mention the two parameters (engine_root, engine_version) that are optional with defaults. Schema coverage is 0%, so the agent has no clue what these parameters do or how to use them, which is a critical 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 it lists official templates available in the installation, with specific examples like TP_Blank and TP_ThirdPerson. This distinguishes it from sibling tools like ue_engine_list, which likely list engines rather than 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 such as ue_engine_list or preset_search_polyhaven. The agent receives no context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool modifies replication settings (a mutating action) but does not detail side effects, such as whether compilation is triggered or if existing connections are affected. Some transparency is present, but more depth would be beneficial.
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, efficient sentence that conveys the core purpose without any fluff. It is appropriately sized and front-loaded.
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 output schema, and no annotations, the description is too minimal. It does not cover parameter roles, expected input values, or return behavior, leaving the agent underinformed 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 description coverage is 0%, yet the description adds no individual parameter meaning. It does not mention 'replicates', 'always_relevant', 'replicate_movement', or 'blueprint_path'. The description fails to compensate 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 configures replication of a Blueprint, specifically synchronizing between server and client in a network game. It uses a specific verb ('Configura') and resource ('replication di un Blueprint'), and this purpose is distinct from sibling tools which deal with other UE operations.
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 gives no guidance on when to use this tool vs alternatives. It does not mention prerequisites, context, or exclude cases. Siblings are not referenced, and no when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It states the tool downloads and extracts (mutating behavior) but does not disclose side effects (e.g., file overwriting, network requirements, or any destructive actions). This is insufficient for safe agent selection.
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 front-loaded with the purpose. The slug example is clear and well-placed. The Args section is part of the description, adding structure. Every sentence earns its place, though the omission of destination is an issue.
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?
No output schema, no annotations. The tool downloads and extracts, but the description does not explain the output (e.g., success message, file location), error conditions, or prerequisites (e.g., internet connection). The destination parameter is not clarified, leaving 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?
Schema description coverage is 0%, so the description must explain all parameters. It only explains the 'slug' parameter with an example, leaving 'destination' undefined. The agent would not know what to pass for destination or its impact, resulting in incomplete 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 it downloads and extracts a Kenney pack (CC0) by resolving the link. It uses a specific verb for the resource ('Kenney pack') and distinguishes it from sibling download tools (polyhaven, ambientcg, etc.) by the specific source.
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 an example for the slug parameter, explaining it's the last part of the URL. However, it does not explicitly guide when to use this tool versus alternatives (e.g., when not to use it, or how to choose among Kenny/polyhaven/ambientcg tools). The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool creates a Blueprint but does not mention side effects (e.g., file creation, editor changes), prerequisites (e.g., open project, valid paths), or failure modes. The description is insufficient for an agent to understand the full impact.
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 sentence followed by a clear list of arguments with examples. No redundant information, every part serves a 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 3 parameters and no output schema, the description is minimal. It does not explain return values, error handling, or what happens when the Blueprint is created (e.g., editor opens, asset appears in content browser). This leaves gaps 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 no descriptions for parameters (0% coverage). The description adds value by providing example values for package_path and name, and listing valid parent_class options with 'o un path completo'. This partially compensates, but some parameters lack explanation of constraints or behavior.
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 Blueprint' (Creates a Blueprint) and lists parameters with examples, distinguishing it from sibling tools that create other assets or perform different operations.
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 examples for parameter values (e.g., package_path, name, parent_class), helping the agent understand when to use the tool. However, it lacks explicit guidance on when not to use it or alternatives, such as using ue_spawn_actor for spawning actors or ue_compile_blueprint for modifying existing Blueprints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the optional linking to a SoundWave, but does not specify side effects (e.g., asset creation, overwrite behavior), required permissions, or resource implications. This is insufficient 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 concise, front-loaded with the main action, and every sentence adds value. No redundant 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?
Given the complexity (3 params, no output schema, no annotations), the description covers the purpose and parameters adequately but misses details on return values or error handling. It is minimally complete but could enhance with output expectations.
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 value beyond the schema by providing examples for each parameter (e.g., package_path: '/Game/MyGame/Audio', name: 'SC_Explosion') and clarifying that wave_path is optional and links to a SoundWave. This 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.
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. This is a specific verb+resource combination. It distinguishes from sibling tools like ue_create_metasound_source, though not explicitly, but the tool name and context make it 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?
There is no guidance on when to use this tool versus alternatives such as ue_create_metasound_source or ue_import_audio. The description lacks any when-to-use or when-not-to-use indications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must bear the burden of behavioral disclosure. It only states creation and opening but omits critical details like whether existing levels are overwritten, required permissions, side effects on project state, or error conditions. This is insufficient for safe tool invocation.
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 extremely concise with two bullet points and no redundant information. It front-loads the main action. However, it could be slightly more detailed without losing conciseness, hence a 4 rather than 5.
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 simplicity (2 params, no output schema, no annotations), the description covers the basic operation but lacks completeness regarding error handling, default template behavior, and relationship to sibling tools. 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.
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 brief explanations: path is the full level path, template is an optional source level to duplicate. This adds meaning beyond the schema types but lacks format specifics or constraints (e.g., valid extensions). A 3 reflects adequate but not thorough param guidance.
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 'Crea un nuovo livello e lo apre' clearly states the verb (create and open) and resource (new level). It distinguishes from sibling 'ue_open_level' which opens an existing level, so purpose is 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?
No guidance on when to use this tool versus alternatives like 'ue_open_level' or 'ue_save_all'. The description does not specify prerequisites or contexts where creating a level is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 .uproject file and that the editor must be restarted if open. This is useful but does not detail persistence behavior 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 short and front-loaded with the core action. It uses efficient language to convey the main purpose and a key side effect. No unnecessary 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?
The description covers the main effect (modifying .uproject) and a key behavior (restart requirement). However, it lacks details about return values, error states, and the exact format of parameters. For a mutation tool with no output schema, this 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.
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 does not explain the parameters 'enable', 'disable', or 'uproject'. It only implies that plugins are enabled/disabled, but does not specify that parameters are arrays of plugin names or what the uproject parameter expects. This forces the agent to infer meaning from the tool name and context.
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, which is a specific verb+resource. It also notes it's useful for existing projects, providing context. However, it does not explicitly differentiate from sibling tools like ue_set_project_setting.
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 mentions that to use the bridge, PythonScriptPlugin and RemoteControl must be enabled, giving a specific use case. It also advises restarting the editor if already open. But it lacks explicit guidance on when to use this tool versus alternatives or prerequisites beyond the bridge scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral details. It only states the action without mentioning potential side effects, prerequisites, or state limitations (e.g., whether it stops existing PIE sessions).
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 very concise, but it could be slightly more informative (e.g., mentioning that it uses current engine settings). There is no unnecessary 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 the tool has no parameters and no output schema, the description is adequate for a simple command. However, it could mention typical use cases or prerequisites for 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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, but the baseline of 4 is appropriate as no additional info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (starting Play In Editor) and the scope (with current settings). It distinguishes from siblings like ue_configure_pie and ue_stop_pie, though it assumes familiarity with Unreal Engine terminology.
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, such as checking if PIE is already running or if configuration is needed first. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 extraction behavior but lacks details on file overwriting, permissions, error handling, size limits, or library location. Critical for a download 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?
Two sentences, front-loaded with purpose, no redundant words. Efficiently captures the core action and extraction condition.
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 output schema, and no annotations, the description is too sparse. Missing details on return values, side effects (e.g., overwrite behavior), and parameter interactions significantly reduces completeness for an AI 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?
Schema description coverage is 0%, yet the description only adds meaning for 'extract' and implicitly for 'url'. Parameters 'filename' and 'destination' are not explained. More parameter context is needed to compensate for the absent 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 downloads a file from a direct URL into the local library, lists supported formats (zip, glb, fbx, wav), and mentions extraction behavior. This distinguishes it from sibling tools like preset_download_polyhaven which target specific sources.
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 for direct URLs and extraction, but does not explicitly state when NOT to use it or mention alternatives like preset_download_polyhaven for marketplace assets. Guidance 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.
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 is read-only, authentication requirements, or rate limits. The description only mentions the search action without safety or side-effect information.
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: one line stating the purpose followed by a brief bullet-like breakdown of parameters. No redundant or extraneous 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?
The description lacks information about the return structure or results format, and does not mention that the search results can be used with sibling tools like preset_download_polyhaven for downloading assets. Given the absence of an output schema and annotations, the description should provide more workflow 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 description adds meaning beyond the schema by specifying allowed values for asset_type ('hdris', 'textures', 'models'), providing examples for categories (e.g., ['brick'], ['outdoor']), and explaining limit as 'massimo di risultati'. This compensates for 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 it searches CC0 assets on Poly Haven, and lists the search parameters. However, it does not differentiate itself from the sibling tool preset_search_ambientcg, which searches a different source.
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 searching Poly Haven assets but provides no explicit guidance on when to use this tool versus alternatives like preset_search_ambientcg or preset_download_polyhaven. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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 states the tool compiles and saves, but lacks details on whether overwriting occurs, error handling, or if it returns compilation results. This is minimal for a potentially destructive 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 extremely concise with two short sentences, front-loading the core action and usage hint. No superfluous 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 tool's complexity (compile-and-save with one parameter and no output schema), the description does not cover important details like compilation error reporting, success/failure feedback, or prerequisites. It is incomplete for an AI agent to use safely.
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 one parameter ('blueprint_path') with 0% description coverage, and the tool description does not explain the expected format or meaning beyond the parameter name. The agent gains no additional insight from 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 compiles and saves a Blueprint, specifying the verb (compile/save) and resource (Blueprint). It is distinct from siblings like 'ue_live_compile' which likely compiles without saving, and 'ue_save_all' which saves all 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 advises using after manual modifications in the editor, providing a usage context. However, it does not mention when not to use it (e.g., for automatic changes) or explicitly name alternatives like 'ue_live_compile'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It accurately states that the tool creates an empty asset and requires plugin activation, and that further editing is needed. It does not disclose potential side effects like overwriting existing assets, but given the non-destructive nature (creating a new asset), 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 concise with two sentences. The first sentence front-loads the main purpose and prerequisite. The second sentence adds necessary context about subsequent steps. 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?
Given the simplicity (2 parameters, no output schema, no annotations), the description should still cover what the tool returns (e.g., success status, asset path) and potential errors. It only mentions the creation and requirement, leaving the agent uncertain about the outcome.
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 does not explain the parameters. The input schema only provides names and defaults (name: 'MS_Source', package_path: '/Game/Audio') without any additional meaning. The description fails to add value, leaving the agent to infer parameter roles from the 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 'crea' (creates) and the resource 'asset MetaSound Source vuoto' (empty MetaSound Source asset). It also specifies the prerequisite active MetaSound plugin. This is specific and distinguishes from sibling tools, which do not create MetaSound 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 mentions a prerequisite (active MetaSound plugin) and notes that the graph must be populated later, implying after creation. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.
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 only states the basic action (spawn) and lists parameters, but does not disclose side effects (e.g., level modification), non-idempotency, potential errors, or what the tool returns (no output schema). Minimal 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 structured with a concise purpose line followed by a clear bullet list of parameters. No redundant information; each sentence is useful. Could be slightly more compact but is well-organized.
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 5 parameters and no output schema, the description adequately covers all inputs. However, it omits return value or success feedback, and does not mention prerequisites (e.g., open level) or error conditions. Enough for basic use but leaves gaps 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?
The description explains all five parameters in detail with units and examples (e.g., class_ref shows valid paths, location as [x,y,z] in cm, label used in Outliner). Schema coverage is 0% without this description, so it 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Spawna un attore nel livello corrente' (Spawn an actor in the current level), specifying the verb and resource. While it distinguishes spawning from other actor operations, it does not explicitly differentiate from sibling tools like ue_set_actor_transform or ue_delete_actor.
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, when-not-to-use, or contrasting scenarios with sibling tools like ue_create_blueprint or ue_list_actors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral transparency. It does not disclose whether the tool is read-only, requires network access, has rate limits, or returns results in a specific format. The description only states the basic function without any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. It uses bullet-like formatting for arguments. However, the Italian language may be redundant for an international AI, and the 'limit' parameter is omitted from the description. Overall, it is clear but slightly incomplete.
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 3 parameters, no output schema, and no annotations, the description covers the purpose and two parameters but lacks details on return format, pagination, or network requirements. It mentions CC0 licensing in the purpose, which is helpful. However, it is not fully complete for operational 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?
The schema has 3 parameters with 0% description coverage. The description adds meaning for two parameters (query, asset_type) by providing examples and listing possible values for asset_type. However, the 'limit' parameter is not explained. The added context partially 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 'Cerca materiali/HDRI/modelli CC0 su ambientCG' which is Italian for 'Search materials/HDRI/models CC0 on ambientCG.' The verb 'search' and the resource 'ambientCG' are specific, and the scope includes different asset types. The description distinguishes this tool from siblings like preset_search_polyhaven by specifying the source.
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 parameter usage (query and asset_type) but lacks explicit guidance on when to use this tool versus alternatives. The mention of 'ambientCG' implies the context, but no direct comparison or when-not-to-use instructions are given. The sibling tools (e.g., preset_search_polyhaven) are listed, but the description does not differentiate them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden on description. It states the output is a tree structure but does not disclose if it's a read operation, error behavior (e.g., invalid label), or side effects (e.g., potential performance for large hierarchies). Lacks safety and mutation 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?
Two sentences: first defines the core purpose, second explains the optional parameter. No wasted words, front-loaded, easy to parse. Adequately sized for a simple 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 tool with one optional parameter and existing output schema, the description covers the basic functionality. However, it misses behavioral context (safety, prerequisites) and edge cases. Without annotations, an agent might not know if the tool is safe or requires specific state.
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 well by explaining the 'label' parameter: starts from that actor instead of roots. This adds meaningful context beyond the schema's bare type 'string or null'. However, no further details (e.g., format, case sensitivity) are given, though the param is simple.
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 returns a parent/child tree (hierarchy) of level actors. The verb 'albero padre/figli' is specific and resource-oriented. It distinguishes from the flat list tool 'ue_list_actors' 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 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_list_actors or ue_spawn_actor. It does not mention prerequisites (e.g., level must be open) or exclude cases (e.g., no actors). The description only implies use for hierarchy viewing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only states the basic operation of detaching and briefly explains the 'keep_world' parameter. It omits details on side effects (e.g., transform changes if keep_world is false), reversibility, permissions, or whether it is 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 extremely concise: one sentence for purpose and two bullet points for parameters. Every word adds value, and the purpose appears first. There is no wasted text.
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 tool with 2 parameters and no output schema, the description covers the basic semantics but lacks broader context like prerequisites (actor must have a parent), behavioral changes (what happens to transforms), or how it relates to sibling tools. It is minimally viable 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?
Schema description coverage is 0%, so the description must compensate. It explains 'label' as the actor's label and 'keep_world' as preserving world position instead of relative position, with default true. This adds meaningful context beyond the schema's type and title, though it could clarify what 'relative' means.
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 'Detach an actor from its parent' (Italian: 'Sgancia un attore dal suo padre.'), which clearly identifies the action (detach) and the resource (actor from parent). This distinguishes it from sibling tools like ue_attach_actor (attach) and ue_delete_actor (delete).
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 when to detach vs. attach, or prerequisites like requiring an attached actor. No exclusions or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Does not disclose side effects, error handling, or requirements (e.g., must have a running session). No annotations provided to compensate.
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 sentence, no fluff, directly conveys the tool's 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?
Minimal but adequate for a parameterless tool; however, lacks behavioral context that would be expected given no annotations or output schema.
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 description adds no parameter info but schema coverage is 100%, meeting baseline.
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 it stops the Play In Editor session (verb 'Ferma', resource 'sessione Play In Editor'). Distinguishes from sibling tools like ue_start_pie and ue_configure_pie.
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 or not use this tool, no prerequisites or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the default library path and that paths are intended for import, but lacks details on whether filters (subfolder, extensions) are applied, recursion, or absolute paths. It provides basic transparency but is 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, front-loaded with the action, no wasted words. Efficiently communicates the core purpose and a critical usage hint about feeding paths to another 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?
The tool is simple with two optional params and no output schema. The description covers the basic use but is incomplete: it does not describe the return format beyond 'paths', and parameter semantics are missing. Partially compensates by linking to ue_import_assets.
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?
Input schema has 0% description coverage, and the description does not explain the 'subfolder' or 'extensions' parameters at all. Despite two optional parameters, the description omits their meaning or how they affect the listing, leaving the agent without guidance.
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 files already downloaded in the local library ('Elenca i file già scaricati nella libreria locale'), a specific verb+resource. It also mentions the default path and that returned paths can be passed to a sibling tool (ue_import_assets), distinguishing its 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?
The description provides context for when to use it: to list local library files before importing via ue_import_assets. It implicitly guides usage but does not explicitly mention when not to use or compare to sibling list tools like ue_list_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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 it affects the editor viewport or game view, or if it triggers events.
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 purpose, but the parameter details are in a separate args section, which is acceptable for a simple 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?
Given the tool's simplicity and lack of output schema or annotations, the description provides adequate context for basic usage but omits behavior when parameters are null.
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 by specifying units (cm for location, degrees for rotation) beyond the input schema, which only defines arrays of numbers. However, it does not cover all parameter aspects.
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 'Sposta la camera della viewport' clearly states the action (move) and the resource (viewport camera), distinguishing it from sibling tools like ue_get_camera.
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 versus alternatives; it is implied for setting camera position but lacks context on prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool requires external software (`legendary`) and provides fallback instructions. However, it does not explicitly state if the operation is read-only or if it has side effects, though 'list' implies read-only.
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, front-loading the purpose and then detailing prerequisites. 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 zero parameters, no output schema, and no annotations, the description adequately explains what the tool does and how to set it up. It could be more detailed about the format of the list or error handling, but it is sufficient 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?
The input schema has no parameters (0 params), so baseline is 4. The description adds context by explaining the tool's purpose and prerequisites, but since there are no parameters, no further semantics 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 clearly states the tool lists Unreal purchased content from the Epic account (Fab/Marketplace). It specifies the resource ('vault content') and action ('elenca' - list). However, it does not explicitly differentiate this tool from related siblings like preset_fab_download, relying on the user to infer the distinction.
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 setup instructions (requires `legendary` or Epic Games Launcher) but does not explicitly state when to use this tool versus alternatives like preset_fab_download. It implies a prerequisite but lacks explicit 'when-to-use' 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.
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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait of idempotency, which is valuable. However, it does not disclose what happens if the folder already exists, error cases, or success indicators. With no annotations, the description carries the full burden and is only partially 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 very concise, with two sentences and a bullet-like parameter line. It is front-loaded with the main purpose and idempotency, 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 simple tool with one parameter and no output schema, the description is mostly adequate but lacks details on whether parent folders are created automatically or must exist. The example helps, but important context 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 has no parameter description (0% coverage), so the description must compensate. It provides an example path '/Game/MyGame/Meshes', which clarifies the expected format and context. The example adds meaningful semantics beyond just the schema 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 clearly states the tool creates a folder in the Content Browser and mentions idempotency, which distinguishes it from sibling tools that deal with assets, actors, or levels. The purpose is 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?
No explicit guidance is provided on when to use this tool or prerequisites. The description does not explain if the folder's parent path must exist or how it relates to other operations like importing assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 key behavior of updating references, which is valuable. However, it does not mention potential destructiveness (original path becomes invalid), permissions, or undo capabilities. The added context is moderate.
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: one sentence for the action and two lines for parameters. It is front-loaded with the core purpose and contains no unnecessary words. Every sentence earns 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?
Given the tool's simplicity (2 required params, no annotations, no output schema), the description covers the main action and parameter examples. However, it lacks information about return values, prerequisites (e.g., asset must exist), and potential side effects. The description is mostly complete but has 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 coverage is 0%, so the description must compensate. It provides examples for both parameters (e.g., '/Game/Imported/SM_rock' and '/Game/MyGame/Meshes/SM_Roccia'), offering format hints. The Italian translations add some clarity but don't deeply explain constraints or formats beyond the example. This is adequate but not rich.
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: 'Sposta o rinomina un asset aggiornando i riferimenti' (Move or rename an asset updating references). This uses a specific verb+resource and differentiates from siblings like ue_delete_asset or ue_duplicate_asset by highlighting reference updates.
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 renaming or moving assets while maintaining references, but it lacks explicit when/when-not instructions or mention of alternatives like ue_duplicate_asset. The context is clear but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not disclose whether saving is automatic or prompts confirmation, whether it overwrites files, or what side effects occur. Basic description lacks behavioral depth.
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 concise sentence front-loading the purpose. Every word is necessary; 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?
Given zero parameters and no output schema, the description is minimal but adequate for a straightforward save action. However, lack of context about scope or side effects leaves some gaps for a complete understanding.
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, so schema coverage is 100%. Baseline for 0 parameters is 4. The description does not need to add parameter info, and no ambiguity arises.
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 'salva' and resource specification are explicit, and the tool distinguishes itself from siblings as the only save-related tool in the list.
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. While the action is implied to be used for saving, there is no mention of prerequisites, frequency, or comparison with other tools that might save data differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that moving parent moves child, and explains attach rules controlling initial position. However, it does not cover failure modes, permissions, or effects on existing children.
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 efficient: one sentence for purpose, one for usage context, then a list of args. No redundant information. It is well-structured for quick comprehension.
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 tool with 4 parameters and no output schema, the description covers purpose, usage, and parameter meanings adequately. It does not address error conditions, prerequisites (e.g., actors in same level), or detailed behavior for each attach rule, but is sufficient for common 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 the description must explain all parameters. It describes child_label, parent_label, socket, and attach_rule with examples. However, it does not explain the KEEP_RELATIVE attach rule, leaving one parameter's semantics incomplete.
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 'Aggancia' (attaches) and resource 'attore' (actor), explains the effect (moving parent moves child), and gives real-world examples (lights to lamppost). It distinguishes from sibling 'ue_detach_actor' by its nature of composing scenes.
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 this is for composing scenes instead of leaving objects unbound, implying when to use. It does not mention exclusions or prerequisites, but the sibling 'ue_detach_actor' implicitly provides the alternative use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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 mentions available modules and return value assignment, but does not disclose potential side effects, security implications, or limitations of arbitrary code execution.
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?
Description is two short paragraphs with clear front-loading of purpose. 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 tool has one parameter and no output schema, the description adequately covers purpose, parameter usage, and return mechanism. It lacks details on error handling or concurrency, but is generally complete for its 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?
Schema has 0% description coverage for the single parameter 'code'. The description adds meaning by explaining it expects Python code, can use 'unreal' and 'mcp_*' modules, and must assign result to 'result', including an 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 it executes arbitrary Python code inside Unreal Editor using specific verbs and resources. It distinguishes itself from sibling tools by being an 'escape hatch' for custom scripting, while other tools are for specific editor 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 implies usage as an escape hatch when other tools lack functionality, but does not explicitly state when to use it versus alternatives, nor provides exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it writes multiple files and lists parameter effects (e.g., force overwrite, blueprint_only excludes source). However, since no annotations are provided, the description carries full burden, but it lacks detail on error handling, success/failure indicators, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, file list, and parameter breakdown. It is sufficiently detailed for the number of parameters, though slightly verbose for a tool description.
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?
Covers all parameters and explains what files are created. Lacks explicit return value description and error handling details, but overall complete for a creation tool of this 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?
With 0% schema coverage, the description provides detailed explanations for all 11 parameters, including defaults, constraints (e.g., valid identifier for name), and cross-references (e.g., template from ue_engine_templates). This adds significant meaning beyond the schema's type and 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 creates an Unreal project from specification, ready for MCP bridge, with specific files written. This clearly distinguishes it from sibling tools like ue_project_find or ue_project_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?
No explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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 adds some behavioral info (one_process faster launch), but fails to disclose side effects, safety, idempotency, or what exactly is configured (e.g., project settings).
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: one sentence for purpose followed by bullet-point parameter explanations. No wasted words, and the purpose 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 configuration tool with 3 parameters, the description covers purpose and parameter semantics well. However, it lacks information about return values (likely void), error conditions, prerequisites (e.g., open project), or behavior when called multiple times. Reasonably complete but not exhaustive.
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 fully compensates. It explains each parameter's meaning: num_players as number of client windows, net_mode with enum-like explanation, one_process with performance implication. This adds critical 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 configures Play In Editor for multi-client local multiplayer testing. It uses specific verb 'configura' and resource 'Play In Editor multi-client'. Among siblings like ue_start_pie and ue_stop_pie, this tool is distinguished as the configuration step.
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 parameters (num_players, net_mode, one_process) which guide usage, but lacks explicit when-to-use vs alternatives like ue_start_pie or ue_stop_pie. No when-not 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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. However, it only states what the tool gets, with no mention of side effects, return value format, or read-only behavior. This is insufficient for a mutation-free 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?
Two sentences with no wasted words. The first sentence states the purpose, the second gives critical usage context. Perfectly front-loaded and succinct.
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 output schema, the description provides purpose and usage context. It doesn't detail the return data structure, but the core information is present. Slightly lacking in full specification.
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 schema coverage is 100% and no param description is needed. The description adds contextual value (timing of use) but doesn't add parameter-specific semantics. Baseline 4 is appropriate.
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 retrieves the editor viewport camera position and orientation. This is a specific verb+resource, but does not explicitly contrast with sibling 'ue_set_camera', 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before spawning actors, with a clear explanation of why (avoiding invisibility due to world origin offset). This is excellent guidance that distinguishes 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.
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.
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.
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.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it downloads assets and lists parameters, but omits details such as permissions needed, side effects (e.g., overwriting), network requirements, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences and a parameter list), front-loads the purpose, and contains no redundant information. Every element serves a clear 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?
The description covers parameters well but lacks information about the tool's return values, success/failure indicators, or error conditions. For a download tool, this leaves some uncertainty for an AI 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?
With 0% schema description coverage, the description adds substantial value by explaining all four parameters: it provides an example for asset_id, lists allowed resolution values, gives format examples per asset type, and clarifies the optional destination.
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 downloads a Poly Haven asset (specific verb and resource) and distinguishes it from sibling download tools like preset_download_ambientcg or preset_download_url.
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 indicates the tool downloads to the local library (implicit usage context). However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description assumes full burden. It discloses that nodes are actually created and connected (not just a Blueprint abstraction) and mentions the 'auto' key for texture channel inference. However, it does not mention side effects like automatic saving, required editor state, or whether textures must be pre-imported.
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 brief explanation followed by an Args section. It is concise but could be slightly tighter; still, it effectively communicates without waste.
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 creates a material but the description does not mention what the function returns (e.g., the asset path). Given no output schema, this is a notable gap. Additionally, it lacks context on prerequisites (e.g., textures must be imported first) or limitations, making it incomplete for the complexity of the operation.
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. It explicitly lists all parameters (package_path, name, textures, scalars, two_sided) and explains each, including the 'auto' key for textures and channel options. 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 it creates a material by connecting textures to PBR channels, and explicitly distinguishes from Blueprint graphs by noting full scriptability. This is specific and differentiates from siblings like ue_create_material_instance.
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 how to use parameters (textures map, scalars, two_sided) and clarifies the difference from Blueprint graphs. However, it does not explicitly state when to use this tool versus alternatives like creating a material instance or importing presets, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral transparency. It provides an example path format but does not disclose side effects (e.g., closing current level), required permissions, error states (e.g., level not found), or whether the tool is read-only vs. mutating. This is adequate for a simple open operation but lacks depth.
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 with no fluff: first states the primary action, second describes the parameter with an example. Every word earns its place, making it highly concise 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 open-level tool with one parameter and no output schema, the description covers the core behavior and parameter format. Minor gaps: no mention of error handling, prerequisites, or how the level is opened (e.g., in main editor vs. tabs). Nonetheless, it is 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?
The schema has 0% description coverage for the single required parameter 'path', but the description adds value by providing an example format ('/Game/MyGame/Levels/L_Main'). It does not explain the path semantics beyond the example, but this is sufficient for a typical user.
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 verb 'apre' (opens), resource 'livello esistente' (existing level), and target 'nell\'editor' (in the editor). This distinguishes it from sibling tools like ue_new_level (creates new level) and ue_editor_open (opens project), 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 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 versus alternatives such as ue_new_level. The description implies usage for opening existing levels, but does not provide exclusions, prerequisites, or context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It explains the key behavior of 'succeeded' based on file production, not exit code, and describes parameter effects (e.g., wait_seconds > 0 blocks and reports progress). Lacks mention of side effects or authorization, but acceptable for a status 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?
Description is concise, front-loaded with purpose, key behavioral note, then parameter details. Every sentence serves a purpose with 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?
No output schema, and the description does not explicitly state what the tool returns beyond referring to 'succeeded' checking. The parameter descriptions are clear, but the return value or status format is implied, not specified. 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?
Schema description coverage is 0%, but the description provides meaningful explanations for all three parameters (tail_lines, uproject, wait_seconds), adding context beyond type and default 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?
Description clearly states it provides status of a render started with ue_render_sequence, with a specific behavioral note about 'succeeded' checking files rather than exit code. It distinguishes from sibling tools by name and context, though a brief differentiation from ue_status would help.
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?
Indicates that this tool should be used after ue_render_sequence and explains the meaning of 'succeeded'. It does not explicitly state when not to use it or list alternatives, 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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool recompiles the Blueprint after adding the component, which is a notable side effect. However, it does not mention other behavioral aspects such as whether the operation is reversible, prerequisites, or error conditions. Compilation is a key behavioral trait 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 one-sentence action statement followed by bullet-point parameter explanations. Every sentence adds value, and the structure 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and parameter details adequately for a simple tool. However, it lacks information about return values (e.g., success/failure) and prerequisites (e.g., the Blueprint must exist). Given no output schema, these missing details slightly reduce 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 description provides clear examples for each parameter: blueprint_path (e.g., '/Game/MyGame/Blueprints/BP_Door'), component_class (e.g., 'StaticMeshComponent'), and name (explanation). Since the input schema has no descriptions (0% coverage), the description fully compensates by adding meaning and context.
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 'Aggiunge un componente a un Blueprint e lo ricompila', which specifies the action (adds a component) and the resource (Blueprint), distinguishing it 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 explicitly state when to use this tool vs alternatives, nor provide conditions or exclusions. No when-not or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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 explains that rendering runs in a separate headless process and that the force parameter can override an existing render. However, it does not detail side effects, error handling, or how results are obtained, nor does it confirm safety (e.g., destructive nature) beyond the background execution claim.
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, followed by a contextual note about headless vs in-editor, then a bullet-style parameter list with clear explanations. Every sentence adds value without 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?
Given 9 parameters, no output schema, and no annotations, the description covers core behavior and most parameters. However, it omits two parameters entirely (engine_root, engine_version) and does not specify return values or error handling. The suggestion to check ue_render_status is helpful but incomplete for a fully autonomous 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 input schema has 0% description coverage (only titles), so the description adds significant value. It explains 7 of 9 parameters with examples and defaults: uproject, sequence, config (stressing its importance), map_path, output_dir, resolution, and force. However, engine_root and engine_version are missing from the description, leaving them undocumented.
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 using the Movie Render Queue in background, headless via UnrealEditor-Cmd. It specifies the verb 'renderizza' and resource 'Level Sequence', and distinguishes from other tools like ue_render_status which is for checking 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 explains when to use it: for rendering sequences that would otherwise block the editor. It advises consulting ue_render_status to monitor progress. It does not explicitly say when not to use it or provide alternatives, but the context of background vs in-editor rendering is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It states that the tool adds a variable and recompiles, but does not mention side effects like overwriting existing variables or performance implications. More explicit behavioral details would improve 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 a single paragraph that is relatively concise and front-loaded with the main action and requirement. However, it could benefit from bullet points for parameters, and the Italian language may affect readability for some agents.
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 7 parameters and no output schema, the description covers all parameters and provides version context. It lacks mention of return values or error handling, but for a mutation tool this is acceptable.
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 provides explanations for all 7 parameters, including allowed types for var_type and sub_type, and notes that default_value works only with simple types. 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 the verb 'Aggiunge' (adds) and the resource 'variabile membro a un Blueprint' and specifies that it also recompiles. This distinguishes it from siblings like ue_add_component or 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 includes a note about UE 5.4+ requirement and references ue_status to check capabilities, which helps the agent decide when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains that commands don't return values but write to log, and the tool captures new log lines. Also notes it uses the editor's Python interpreter, not the Remote Control API, and can execute even 'quit'. No annotations provided, so description carries full burden and does well.
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?
Description is moderately concise, with multiple paragraphs that could be slightly tightened. However, it front-loads the main purpose and provides necessary details 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?
Given no output schema, the description explains the return value (new log lines) and covers all essential aspects: purpose, behavior, parameters, and useful examples. It is sufficiently complete for an 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds meaning: 'command' is illustrated with an example ('stat fps'), and 'wait_seconds' is explained as time to wait for log output. This 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?
Description clearly states it executes an editor console command and returns its output, with specific examples like 'stat unit' and 'r.ScreenPercentage 50'. Distinguishes from sibling tools like ue_exec_python by focusing on console commands.
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 examples of useful commands and contrasts with Remote Control API pathway. However, it does not explicitly state when not to use or suggest alternatives, though the context implies it's the preferred method for console commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('legge'), implying no side effects. It lists the return values, providing transparency. Without annotations, it carries the burden of disclosing behavior, and it adequately conveys that the tool 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, focused sentence that front-loads the purpose. No extraneous 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 tool with one parameter and no output schema, the description covers the essential purpose and return information. It could mention the requirement that the file must exist, but it's 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?
The schema has 0% description coverage for the single parameter 'uproject'. The description clarifies that the parameter is the path to a .uproject file, adding minimal but helpful context. More detail on expected format or validation would improve this.
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 reads a .uproject file and lists the specific information returned (engine version, active plugins, bridge status). It uses a specific verb ('legge') and resource, distinguishing it from sibling tools which deal with editing, presets, or 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 the tool is used to retrieve project metadata, which is clear from context. However, it does not explicitly state when to use it over alternatives or when not to use it. Given the lack of similar siblings, it's still fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It details that variables matching UPROPERTies of the new parent are absorbed, others are renamed with '_0', and mentions an optional cleanup parameter. However, it does not mention potential destructive side effects like broken references or the need for compilation.
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 paragraphs and a bullet for arguments, but it is slightly verbose. Each sentence adds value, explaining the purpose, behavior, and parameters. Could be tightened, but still effective.
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 3 parameters, the description covers the core behavior and parameter details. However, it lacks information about return value (if any), error conditions (e.g., missing blueprint), and post-reparenting steps like compilation. For a mutation tool, more completeness would be beneficial.
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 explains blueprint_path with an example path format, new_parent with both name and path examples, and describes remove_unused_variables as cleaning orphaned variables. This adds meaning beyond the bare schema 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 reassigns the parent of a Blueprint, typically to a C++ class. It specifies the verb 'riassegna' and the resource 'parent di un Blueprint', distinguishing it from sibling tools like ue_create_blueprint or ue_compile_blueprint by explaining when this reparenting is needed.
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: to give executable logic to a Blueprint because graphs are not writable from Python, and suggests creating the C++ parent with ue_cpp_class_create. It does not explicitly state when not to use it, 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.
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.
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.
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.
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.
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.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description contributes some behavioral context: it explains that instancing avoids recompilation and describes parameter types. However, it lacks details on error behavior, preconditions (e.g., parent existence), 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 concise and well-structured: a one-line summary, a benefit sentence, and a bulleted list of arguments. Every sentence is purposeful and adds value.
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 essential aspects: purpose, benefit, and parameter details. However, it does not describe return values or error conditions, which would be helpful for a creation tool. Overall, it is fairly complete for its 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 coverage is 0%, so the description must compensate. It explains all parameters: package_path (destination folder), name (example), parent_path (example path), and parameters (map with type examples: scalar, color, bool, texture). This adds significant meaning 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 creates a Material Instance from a parent material. It distinguishes from sibling tools like ue_create_material by explaining that instancing avoids recompilation, making it 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for cheap variants without recompiling) and provides context. However, it does not explicitly state when not to use it or name alternatives, though sibling context is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the two-phase closing strategy (clean close via save + bridge, fallback to process termination) and defines the effect of each parameter. However, it does not specify what happens if the editor is not open, the outcome on failure (e.g., error messages), or the state of unsaved changes when force=True and save_all=False.
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 and front-loaded with the purpose ('Chiude l'editor'), followed by a clear behavioral summary and parameter explanations. Every sentence serves a purpose with 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 the tool's simplicity (two boolean parameters, no output schema, no annotations), the description covers core functionality well. However, it lacks details on preconditions (e.g., editor must be open), error handling, and what happens on success (e.g., empty return). Still, for a closure tool, the provided information is largely 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?
The input schema provides only parameter names and defaults with 0% schema description coverage, but the tool description fully explains both parameters: save_all saves level and assets before closing, and force skips the clean attempt. This adds significant meaning beyond the schema, enabling 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 closes the editor ('Chiude l'editor') and describes the specific behavior of attempting a clean close then fallback to force termination. This distinguishes it from sibling tools like ue_save_all (only save) and ue_editor_open (open), 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this tool is for closing the editor, but it does not explicitly state when to use it versus alternatives (e.g., use ue_save_all if only saving needed). No guidance is provided on prerequisites or situations where the tool might fail, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the search locations (UE_MCP_ENGINE_DIRS, Epic Games Launcher list, Windows registry), giving good transparency about what the tool checks. No side effects or destructive actions are 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 with three sentences, each providing essential information: purpose, search locations, and usage hint. No redundant or vague statements.
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 usage and search locations, it lacks details about the output format. Since there is no output schema, the agent does not know what the returned list contains (e.g., paths, versions). This gap reduces 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 tool has no parameters, so the schema provides full coverage. The description does not need to add param details. Baseline for 0 params is 4, and the description explains the tool's behavior adequately.
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: listing Unreal Engine installations found on the machine. It specifies the search sources (environment variable, Epic Games Launcher, Windows registry) and distinguishes itself from sibling tools by focusing on engine discovery rather than project or editor operations.
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 to call this tool first when there is no project yet, providing clear usage context. It does not exclude other scenarios but implies a typical workflow order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main behavior: listing assets recursively with optional class filtering. No annotations are provided, but the description does not reveal potential issues like what happens if the path is invalid or if there are many assets. However, the output schema exists to clarify 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 concise (one sentence plus bullet-like args). It is front-loaded with the main purpose, and every sentence adds value.
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 main functionality and parameters. With an output schema present, it does not need to detail return values. However, it lacks mention of error handling or edge cases, which 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 description adds meaning beyond the schema by explaining each parameter: path as an Unreal folder, recursive includes subfolders, and class_filter is a partial class name filter. This is crucial since the schema only provides 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 'Lists assets under a Content Browser path' using a specific verb and resource. It distinguishes itself from sibling tools like 'ue_list_actors' which list actors in a level.
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 versus alternatives. While the parameter descriptions help understand usage, there is no mention of when to prefer this over similar tools like 'ue_import_assets' or 'ue_list_actors'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys this is a read-only operation ('legge') and specifies filtering options. It does not mention potential side effects (e.g., log clearing) but the read nature is clear. Some extra context on permissions or log retention would improve 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 concise, with the purpose stated in the first sentence and parameter details following. It is well-structured but could be slightly more compact. Overall, it efficiently communicates 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 the tool is simple and the purpose is clear, the description omits the return format (e.g., list of lines). No output schema exists, so the description should state what the tool returns. This gap reduces 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?
Schema coverage is 0%, so the description fully compensates by defining both parameters: 'lines' (number of lines to return, default 80) and 'only_errors' (filter for Error/Warning only, default false). This adds critical 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 it reads the Unreal Engine log tail and is the way to diagnose errors after an operation without exceptions. It identifies the specific resource (log tail) and purpose, and distinguishes from sibling tools which focus on other Unreal operations.
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 this tool when an operation didn't throw exceptions but something went wrong. It provides clear context for use, though it does not mention when to avoid using it or alternative tools, but no siblings serve the same function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It explains that the tool returns immediate status unless wait_seconds > 0, in which case it blocks and reports progress. It also notes the default project selection. This is thorough but could mention whether the tool is read-only.
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 brief overview followed by a structured parameter list. It is front-loaded and every sentence contributes value. Slight verbosity in Italian does not detract significantly.
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 (checking status with optional waiting) and lack of output schema, the description adequately covers return types (progress, errors, log tail) and parameter behavior. It could be enhanced by explicitly stating the format of the returned data.
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?
Since schema description coverage is 0%, the description fully explains all three parameters: tail_lines (log line count), uproject (project reference, default to last started), and wait_seconds (waiting behavior). It adds meaningful context about defaults and usage 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 checks the status of a compilation started with ue_build_start, returning progress, errors, and log tail. It distinguishes from sibling tools like ue_build_start (which initiates) and ue_build_unblock (which resolves issues).
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 indicates it should be used after ue_build_start and provides advice on using wait_seconds to avoid polling. However, it does not explicitly mention when not to use it or contrast with other status tools, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains the tool moves the camera to focus on an actor at a specified distance, with defaults for both parameters. Potential side effects (like whether it modifies the actor) are not discussed, but the behavior is simple and non-destructive by nature.
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?
Description is short (three sentences plus parameter list), front-loaded with purpose, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple focus tool with no annotations or output schema, description covers purpose, usage context, and parameters. It could mention return value (likely none), 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 coverage is 0%, so description must add value. It explains both parameters: 'label' is the actor to focus (defaults to current selection) and 'distance' is camera distance in cm (default 500). This adds meaning beyond the plain 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?
Description clearly states the tool focuses the camera on an actor, comparing it to the F key in the editor. It also distinguishes itself from sibling ue_screenshot by explaining how they complement each other.
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 clear context by linking to ue_screenshot, implying use before taking screenshots. However, it does not explicitly mention when not to use or list alternatives beyond that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it reports the current phase, errors, and final output path. It explains that wait_seconds > 0 causes the tool to wait up to that limit, returning the current phase instead of immediate results. This is good transparency for a status tool, though it doesn't mention rate limits or what happens if no packaging job exists.
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 opening sentence, a list of what is reported, and an Args section. It is not overly verbose, but could be slightly more structured (e.g., bullet points). Overall, it is effectively sized.
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 parameters, no output schema), the description covers the return information (phase, errors, path) and the wait behavior. It does not detail error handling or the output format in depth, but for a status tool it is reasonably 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 schema has 0% description coverage, but the description compensates by explaining each parameter: tail_lines (how many final log lines to return), uproject (which project, defaults to last started), and wait_seconds (if >0, waits for completion). This adds significant meaning beyond the schema's type and default 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 'Stato del packaging avviato con ue_package_start' (status of packaging started with ue_package_start) and lists the reported information: current phase (Cook, Stage, Package, Archive), errors, and path of the executable at completion. This distinguishes it from siblings like ue_package_start (starts packaging) and ue_build_status (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 usage after starting packaging via ue_package_start and explains parameters like wait_seconds for polling behavior. However, it lacks explicit guidance on when to use this tool versus alternatives such as ue_build_status or when not to use it, though 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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that the image is returned to the agent, saved to a specific path, and that default resolution is modest due to base64 overhead. Also explains the return_image parameter behavior.
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, rationale, location info, resolution guidance, and parameter descriptions. It is about 5 sentences plus the Args list, which is efficient 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?
No output schema exists, but the description covers the main return value: the image or path. It doesn't specify exact format (e.g., base64 in response), but the parameters cover the behavior. For a screenshot tool, this is reasonably 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% (no description in schema), but the description's Args section explains each parameter: filename (optional, auto-generated with timestamp), width/height (resolution), and return_image (if false, only path). This adds essential meaning beyond 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 captures the editor viewport and returns the image to the agent. It explains the importance ('Senza questo l'agente costruisce alla cieca') and distinguishes it as the only way to verify the scene visually. No sibling tool has the same 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?
The description provides guidance on file location, resolution trade-offs (base64 overhead), and parameter usage ('Alzala quando serve leggere un dettaglio'). It does not explicitly list when not to use 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.
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.
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 it writes to config files and notes that some settings require editor restart. This provides transparency about side effects. It does not specify whether it overwrites or appends, but that is minor given the tool's simplicity.
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 includes the essential information: purpose and parameter examples. It could benefit from a more structured format (e.g., bulleted list) but is not overly verbose. Every 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?
Given no output schema and 4 parameters, the description adequately covers the tool's behavior. It explains input parameters and notes the potential need for editor restart. For a simple write-to-file tool, 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%, so the description must explain parameters. It provides concrete examples for section ('/Script/EngineSettings.GameMapsSettings'), key ('GlobalDefaultGameMode'), value (full blueprint path), and config (enum: Game, Engine, Input). 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 states 'Scrive un'impostazione nei file Config/Default<config>.ini del progetto' (writes a setting to project config files). It clearly identifies the verb (write/set), resource (project config ini files), and distinguishes from sibling tools like ue_set_class_defaults (which sets Blueprint class defaults) and ue_set_replication (replication settings).
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 lists parameters with examples but does not explicitly state when to use this tool over alternatives. However, the purpose is clear enough to infer usage: use when setting project-level ini settings. Future improvements could add guidance on when not to use it (e.g., for runtime changes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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 key behaviors: search by command line, termination optional via dry_run, and lock file location. While it could explicitly state 'destructive' for the non-dry-run mode, the term 'terminates' implies this. The explanation of why command-line search is necessary adds useful 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 front-loaded with purpose, then usage scenario, then technical reason, then parameter details. It is efficient but slightly long; however, 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.
Completeness4/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 and no output schema, the description covers the trigger condition, the locking mechanism, parameter semantics, and the dry_run safeguard. It does not specify return format, but the context is sufficient for an agent to decide when and how to invoke it.
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 well. It explains dry_run (default true, only lists), and that engine_version/engine_root determine which lock file to check. This adds context beyond the schema's title and type, helping the agent use parameters correctly.
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 'finds and terminates' and the resource 'processes holding the build lock'. It distinguishes from siblings like ue_build_status by specifying the exact scenario (when status reports 'blocked'), making the tool's purpose unique and actionable.
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 explicitly tells when to use this tool: when ue_build_status reports 'blocked'. It explains why typical approaches fail (scans command line, not image name) and advises using dry_run first to avoid killing unrelated processes. This provides clear usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: files are created/overwritten (with force), generated code includes replication properties and BlueprintCallable functions, and for Blueprint-only projects it sets up the C++ module. It does not mention required auth or cleanup.
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 purpose explanation, a clear workflow, and a bulleted list of parameters. It is slightly verbose but every sentence adds value. Front-loads the main 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's complexity (8 parameters, no output schema, no annotations), the description is fully complete. It explains the overall workflow, each parameter in detail, and edge cases like Blueprint-only projects. No significant 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 coverage is 0%, so the description provides essential meaning for all parameters. It explains class_name naming convention, parent_class examples, properties structure with replication effects, functions with specifiers, and force overwrite behavior. This goes well beyond schema 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 it generates a compilable C++ class in a project module, specifying the verb 'genera' and the resource 'classe C++ compilabile'. It distinguishes from sibling Blueprint tools by explaining it overcomes the limitation that Blueprint graphs are not writable from Python.
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 complete workflow and explains when to use the tool (to move logic to C++ for Blueprint inheritance). It implicitly excludes alternatives like ue_create_blueprint but does not explicitly name them or state 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.
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.
Behavior4/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 discloses that replace_existing overwrites assets with the same name, and that files must be absolute paths. It also mentions the processing pipeline for specific formats. However, it does not specify the return value or error behavior, though an output schema exists.
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 and well-structured: two paragraphs, the first stating purpose and special cases, the second listing parameters with explanations. Every sentence adds value, with no redundant or missing information. It is efficiently 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 (multiple file types, skeletal import option, overwrite behavior) and the absence of annotations, the description covers essential use cases and parameter roles. It omits details on error handling but, per guidelines, the output schema (which exists) can cover return values. The description is sufficient for correct agent 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%, but the description's Args section clearly explains each parameter's meaning and context: files require absolute paths, destination is an Unreal path, replace_existing controls overwriting, and import_as_skeletal is for .fbx skeletal imports. This far exceeds what the schema provides, fully 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 starts with a clear statement of the tool's purpose: importing 3D and audio files into Unreal's Content Browser. It lists specific file extensions (.glb, .gltf, .fbx, .wav) and distinguishes between file types, making the resource and action very clear. This effectively differentiates it from sibling tools like ue_import_audio.
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 on when to use certain parameters (e.g., using import_as_skeletal=True for .fbx files with skeletons). It also notes that .glb/.gltf go through Interchange framework. However, it does not explicitly contrast this tool with siblings like ue_import_audio, which could cause confusion for audio-only imports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior such as automatic loading of asset paths and JSON formatting for vectors and colors. It explains scope (actor or component) and parameter usage. However, it does not mention undo behavior or error handling, which is acceptable for a property setter.
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 (~100 words) and well-structured, with a clear main sentence followed by supporting details and an Args list. Every sentence is informative and necessary.
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 property-setting tool with no output schema, the description covers the core functionality, input format, and scope. It lacks error behavior or edge-case handling, but is largely complete for typical use.
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 compensates fully by explaining each parameter (label, component, properties) with examples, including the component's default behavior and the structure of property 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 it sets properties on an actor or its component, with specific examples like mesh, light intensity, trigger radius. It distinguishes itself from sibling tools like ue_set_class_defaults and 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 explicitly notes it covers everything except Class Defaults of a Blueprint, guiding the agent to use this for instance-level properties. It mentions JSON format for values but doesn't provide explicit when-not-to-use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It describes the tool as a connection check returning status data, implying read-only and non-destructive behavior. It could be more explicit about expected behavior on failure, but overall it's transparent about what the tool does.
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, no wasted words. The action verb ('Verifica') is first, and every sentence adds critical information (what it checks, what it returns, when to use it).
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 parameters and no output schema, the description is complete. It explains the purpose, the returned fields, and provides a usage directive. No further detail is needed 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?
With zero parameters and 100% schema coverage, the baseline is 4. The description does not need to explain parameters but adds value by listing the returned fields, which compensates for the lack of an output 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 checks the Unreal editor connection and returns specific status info (engine version, open project, current level, actor count, transport). This distinguishes it from sibling tools, which are more specialized actions.
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 'Da usare per prima' (use first), providing a clear usage guideline to run this before other tools. It does not list alternatives or when not to use, but the instruction is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: refusal on reference and side effects of forced deletion (broken references). It does not cover other aspects like undo or trash behavior, but for a deletion tool this is substantial.
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-loaded with the main purpose, and includes necessary details in a structured way (separate Args section). 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 2 simple parameters and no output schema, the description covers purpose, usage context, parameter details, and behavioral caveats. It is complete for an agent to decide when to invoke and how to set parameters.
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 explains both parameters: path (with example format and folder support) and force (overrides reference check). This is critical for correct 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 it deletes an asset or folder from the Content Browser, with a specific use case (fixing a wrong import). It distinguishes from sibling tools like ue_delete_actor by specifying 'asset o una cartella', 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 explains default behavior (refuses deletion if referenced) and the consequence of forcing (broken references), implicitly guiding when not to use it. However, it does not explicitly name alternative tools for other deletion needs, so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains the default wait is short due to client timeout, the risk of timeout despite editor starting, and the behavior of skip_module_check causing a modal. Adds significant context beyond bare annotations (none provided).
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?
Well-structured with main action first, then an important note about waiting, then parameter documentation. Slightly verbose but every sentence adds value.
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?
Covers waiting behavior, parameters, and suggests polling. Missing explicit mention of return value format, but the context of opening and waiting is complete enough given tool 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?
With 0% schema description coverage, the description fully compensates by explaining each of the 6 parameters, including practical advice for wait_seconds and consequences of skip_module_check.
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 opens a project in the editor and waits for the bridge. This distinguishes it from siblings like ue_editor_status 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on waiting behavior, suggests polling with ue_editor_status if bridge isn't ready, and warns against setting wait_seconds too high. Lacks explicit comparison to other opening alternatives but still useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 operation is long (tens of minutes first run), runs in background, and requires the editor to be closed. It does not cover all aspects (e.g., overwrite behavior, error handling), but the key behavioral traits are communicated effectively.
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 main purpose, followed by important usage notes (duration, background, prerequisite) and a clear sequence. The argument list is succinct but covers all parameters. No superfluous sentences; every part 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 (8 parameters, no output schema), the description provides all necessary context: full parameter documentation, usage order, background execution, and prerequisite closure of editor. The agent can correctly invoke the tool and understand its 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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, defaults, and examples (e.g., configuration values, maps format, default output_dir). It adds significant meaning beyond the schema's mere type/title 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 clearly states the tool creates a playable game package via a multi-step process (cook build stage pak) and produces a standalone executable. It uses specific verbs and resources, and distinguishes from siblings like ue_package_status and ue_build_start by mentioning the sequence and background 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 explicitly provides the correct usage context: after closing the editor and before checking status. It mentions the operation is long and runs in background. While it does not explicitly state when not to use or compare to alternatives, the given sequence and constraints are clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the build runs in background, requires editor closed, and force is only for stuck builds. However, it does not explicitly mention what happens if a build is already running without force (implied it won't start) or potential side effects like blocking.
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?
Well-structured with a summary line, context block, and Args section. While detailed, the Args section repeats parameter names. Occasional redundancy, but overall efficient and 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?
With 6 parameters, 1 required, no output schema, and a sibling for status, the description covers the complete workflow: prerequisites, parameter usage, and follow-up actions. It even suggests using ue_build_status to poll for completion.
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 description must compensate. It explains each parameter: uproject (path), engine_version (force version), target (default <Project>Editor), configuration (Development/DebugGame/Shipping), engine_root (when not registered), and force (only when stuck). This adds 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 it starts compilation of the C++ module in the background. It uses a specific verb ('Avvia la compilazione') and resource ('modulo C++ del progetto'). It distinguishes from siblings like ue_build_status and ue_live_compile by specifying the workflow.
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 when-not: 'L'editor deve essere chiuso' and explains the typical sequence (ue_editor_close -> ue_build_start -> ue_build_status -> ue_editor_open). It also warns about Live Coding limitations and when to use the force parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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 key behavioral trait (only works on function body changes) and explains the parameter behavior. However, it omits details like what happens on compilation failure or if the editor is not running, which would enhance 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 concise (approximately 6 lines), front-loaded with the core benefit and limitation, and includes a structured Args section. 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?
For a single-parameter tool with no output schema, the description covers main behavior, limitations, and parameter semantics. It could mention the return value more explicitly, but it is sufficient for effective use.
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 explain parameters. It clearly defines max_wait_seconds: how long to wait before returning 'in corso' while compilation continues, adding meaningful semantics 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 recompiles C++ without closing the editor via Live Coding. It specifies the scope (function body changes only) and distinguishes it from ue_build_start, 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?
The description explicitly states when to use the tool (for fast iteration on function body changes) and when not to (for structural changes requiring ue_build_start with editor closed), providing clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses batch spawning, single undo transaction, and explains input structure with example. Does not contradict any annotations. Minor lack of detail on 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line purpose, one line usage guidance, then Args section. Front-loaded key info. 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?
Covers all necessary aspects for a batch spawn tool: single undo transaction, input structure, and when to use. Lacks explicit success/return value description, but typical for such tools.
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 has no descriptions (0% coverage). Description explains each field in the actors array (class_ref, location, rotation, scale, label) with types and example. Adds crucial 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 the verb 'spawn' and resource 'actors' in batch, using Italian. It explicitly distinguishes from the sibling 'ue_spawn_actor' by highlighting batch operation and single undo transaction.
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: use this tool over 'ue_spawn_actor' when spawning many actors (decine di elementi) to avoid multiple HTTP round-trips. Clearly defines when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![unreal-engine-mcp MCP server](https://glama.ai/mcp/servers/FFZackFair92/unreal-engine-mcp/badges/card.svg)](https://glama.ai/mcp/servers/FFZackFair92/unreal-engine-mcp)

Score Badge

Copy to your README.md:

[![unreal-engine-mcp MCP server](https://glama.ai/mcp/servers/FFZackFair92/unreal-engine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/FFZackFair92/unreal-engine-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FFZackFair92/unreal-engine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server