unreal-engine-mcp

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with detailed descriptions that make it easy to differentiate. Despite the large number, there is no overlapping functionality; tools like ue_spawn_actor and ue_spawn_many are separate for single vs batch operations.
Naming Consistency4/5
Most tools follow a consistent `ue_verb_noun` pattern, but the inclusion of `preset_` prefixed tools (e.g., preset_library_list) introduces a minor inconsistency. The naming is otherwise predictable and readable.
Tool Count2/5
With 72 tools, the server far exceeds the recommended range (3-15) and even the 'borderline' range (16-25). While Unreal Engine is complex, this many tools risks overwhelming agents and implies insufficient scoping.
Completeness4/5
The tool set covers a broad range of Unreal Engine development tasks including project creation, asset import, blueprint manipulation, material creation, packaging, rendering, and multiplayer setup. Minor gaps exist (e.g., animation, landscape editing), but the core workflows are well-supported.
Average 3.8/5 across 58 of 72 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations exist, so the description must disclose behavioral traits. It only states the search action, without mentioning safety (e.g., read-only), errors, or side effects. The agent cannot infer if this is a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the core action. However, it is too brief to provide necessary details, making it under-informative rather than efficiently scoped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and no output schema, the description should at least mention return format (list of paths) and that max_depth controls recursion depth. It lacks completeness for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema. It does not explain that 'directory' is the root path or that 'max_depth' limits recursion. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for .uproject files under a folder. The verb 'Cerca' (search) and resource '.uproject' are specific. However, it does not differentiate from sibling tools like ue_project_info or ue_project_create, which have distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ue_project_info or ue_project_create. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the plugin requirement and that the asset is empty, but does not disclose error scenarios, whether creation can overwrite existing assets, permissions needed, or if the operation is synchronous. For a creation tool, this is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose, prerequisite, and next step. It is front-loaded with the main action. However, it could be slightly improved by including parameter details, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is incomplete. It fails to clarify what the function returns, whether it's blocking, or what happens if the asset already exists. The post-creation guidance is helpful, but the overall context for an agent is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (name and package_path) with defaults and 0% schema description coverage. The description does not reference these parameters at all, providing no additional meaning about what they control or how they affect the creation. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crea un asset MetaSound Source vuoto' (Create an empty MetaSound Source asset), specifying the verb and resource. It distinguishes this from sibling create tools by naming the specific asset type, though it does not explain what a MetaSound Source is or how it differs from other audio assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear next step: 'Il grafo va poi popolato nell'editor MetaSound o via ue_exec_python.' (The graph must then be populated in the MetaSound editor or via ue_exec_python.) However, it does not specify when to use this tool versus alternatives like ue_create_sound_cue, nor does it state any preconditions beyond the plugin requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'duplicate' but does not disclose side effects (e.g., dependency copying, asset loading requirements, overwrite behavior). The context of creating a 'variant' implies modification, but details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded with the core action. However, it is too minimal for the tool's needs, missing parameter details. It earns points for being concise but loses for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required string params, no output schema), the description is incomplete. It does not explain the path semantics, whether it creates a new asset or replaces an existing one, or any prerequisites like asset must be loaded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of the two parameters ('path', 'new_path'). No information on format (absolute, relative, content browser paths) or expected values, leaving the agent with no guidance beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool duplicates an asset to create a variant for modification, using a specific verb ('duplica') and resource ('asset'). It distinguishes from sibling tools like ue_delete_asset or ue_rename_asset by focusing on duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'la via rapida' hints at a faster method but does not specify when not to use it or mention any alternative duplication methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that this is a read-only operation. While implicit, it lacks explicit disclosure of side effects, permissions, or other behavioral traits beyond the single action of listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the core action. However, it could be structured more clearly (e.g., mentioning parameters) without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters of unclear purpose and no output schema, the description is incomplete. It fails to specify the role of the parameters or the return format, which are essential for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain either of the two optional parameters ('engine_root', 'engine_version'). The description adds no value beyond what the bare schema provides, forcing the agent to infer parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool lists official templates available in the installation, with specific examples (TP_Blank, TP_ThirdPerson). It distinguishes itself from sibling tools like 'ue_engine_list' which lists installed engines, not templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives among many sibling tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states it opens an existing level, without disclosing side effects like closing the current level, handling unsaved changes, or requiring the level to exist. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of one line plus a parameter example. It is front-loaded with the action but lacks structure (no title, no sections). While concise, it is under-specified for a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should be more thorough. It omits details about return values, error handling, and behavioral nuances (e.g., does it reload the level?). The minimal information is inadequate for a tool in a complex environment like UE.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a docstring with a concrete example for the 'path' parameter ('/Game/MyGame/Levels/L_Main'), which provides meaningful guidance beyond the schema's type and title. With 0% schema coverage, this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens an existing level in the editor (verb+resource). The sibling tools include ue_new_level, which creates a new level, distinguishing the purpose. However, it does not explicitly differentiate from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like ue_new_level or ue_spawn_actor, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. It does not specify whether the transform is absolute or relative, the coordinate system, units, or what happens if the label is not found. With no annotations, the description carries the full burden but fails to disclose these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is front-loaded and efficient, but it sacrifices necessary detail. It could be slightly longer without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transform tool (4 parameters, no output schema, no annotations), the description is incomplete. It fails to specify transformation mode, coordinate system, error handling, or default behavior for omitted parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only explains the 'label' parameter (actor identified by label) but does not add meaning for location, rotation, or scale (e.g., array format, expected units). The parameter names are merely repeated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Modifica' (modify) and specifies the resources 'posizione/rotazione/scala' (position/rotation/scale) of an actor identified by label, distinguishing it from sibling tools like ue_set_actor_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; there is no mention of when to use this tool versus alternatives like ue_spawn_actor or ue_set_actor_property, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only states the operation, but fails to mention side effects, persistence, triggers for compilation, or whether it affects existing instances. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure (function statement followed by argument list). It avoids unnecessary words and uses an efficient format. However, the use of Italian may limit accessibility for English-speaking agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and detailed schema descriptions, the description is too minimal. It does not explain return values, prerequisites, or how this tool differs from similar ones like ue_set_actor_property, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for both parameters: blueprint_path as 'path of the Blueprint' and properties as a map with an example. However, it does not elaborate on path format, valid property names, or type constraints, which would be helpful given the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the Class Defaults (CDO) of a Blueprint. The verb 'set' and resource 'Class Defaults' are specific, and it is distinguishable from sibling tools like ue_set_actor_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ue_set_actor_property or ue_compile_blueprint. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Crea un Blueprint' without disclosing side effects, requirements (e.g., editor state), error conditions, or return behavior. Minimal insight into tool behavior beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (two lines) and efficiently lists arguments with examples. It is well-structured with Args section. Could potentially be more concise by combining into a single sentence, but current form is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool, the description omits important context: what happens after creation (e.g., asset appears in browser), error handling (e.g., duplicate names), and dependencies (e.g., open project). Incomplete for an AI agent to use without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description adds significant value by providing examples for package_path and name, and listing common values for parent_class. This aids understanding but lacks format constraints like required path prefix.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crea un Blueprint' clearly states the tool's function (create a blueprint). It is specific and distinguishable from siblings like ue_cpp_class_create or ue_create_material. However, it does not specify the type of blueprint (e.g., Blueprint Class) explicitly, relying on parameter examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks prerequisites, context (e.g., requires open project), or any indication of when this tool is appropriate. Sibling tools are not referenced or distinguished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions synchronization context but omits critical details like whether changes are persistent, permissions needed, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's purpose and context with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema or annotations, the description only provides a high-level purpose, lacking details on return values, parameter roles, and behavioral completeness for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the four parameters (e.g., replicates, always_relevant, replicate_movement, blueprint_path), leaving the agent without guidance on how to set replication behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool configures Blueprint replication for network synchronization, distinguishing it from sibling tools like ue_set_actor_property which address different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in network game contexts but provides no explicit guidance on when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action without disclosing potential side effects, required editor state, or safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. It is efficient but could be better structured with additional context. Still above average for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description is minimal but does not mention any contextual details like required editor state or that current settings are used. It leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, and description coverage is 100%. The description adds no param info, which is appropriate. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts Play In Editor with current settings. It is distinct from siblings like ue_stop_pie and ue_configure_pie, though no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring the editor to be open, or conditions when PIE cannot be started.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral details. It mentions resolving the link from the page but does not disclose side effects, permissions, or error scenarios. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an Args section. However, it is in Italian, which may reduce clarity for some users. It is reasonably concise but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the core functionality and slug usage. Missing details on the destination parameter and potential side effects make it slightly incomplete for a tool with no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. The slug parameter is explained with an example, adding meaning beyond the schema. However, the destination parameter is not described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and extracts a Kenney pack by resolving the link from the page. It specifies the resource (Kenney CC0 pack) and the action (download and extract), distinguishing it from sibling tools like preset_download_url which handle generic URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading Kenney packs but does not explicitly state when to use or not use this tool versus alternatives like preset_download_polyhaven. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It lacks any disclosure about authentication, rate limits, return format, or behavior on missing results. Only basic search functionality is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (two sentences) and front-loaded with the main purpose. It efficiently communicates the tool's function and key parameters, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 3 parameters, the description is incomplete. It omits return format, pagination, error handling, and any prerequisites. The tool is simple but description lacks contextual details needed for robust use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'query' with an example ('concrete') and lists allowed values for 'asset_type'. However, 'limit' parameter is not described, only its default is in schema. Description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for CC0 materials/HDRI/models on ambientCG. The verb 'cerca' (search) and resource 'ambientCG' are specific, and it distinguishes from siblings like preset_search_polyhaven and preset_download_ambientcg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies its domain (ambientCG) but does not mention when-not-to-use or alternative tools for other sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool returns a hierarchy, but does not mention if it is read-only, recursive, how the tree is structured, or any side effects. This is insufficient for a tool with no annotational safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences covering purpose and parameter guidance. No redundant information. However, it is in Italian, which may be less accessible for English-centric agents, slightly reducing effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema exists, so the description need not detail return values. However, it omits behavioral context (e.g., whether the tree includes all actors or only spawned ones, depth limit). Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'label' is described as 'se indicato, parte da quell'attore invece che dalle radici' (if provided, starts from that actor instead of roots). This adds clear meaning beyond the schema, which only defines type and default. Schema description coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Albero padre/figli degli attori del livello' (parent/child tree of level actors), which clearly indicates the tool retrieves the actor hierarchy. It distinguishes from sibling tools like ue_list_actors (flat list) and ue_spawn_actor, but lacks an explicit verb like 'get' or 'list', slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the label parameter for specifying a start actor, but provides no guidance on when to use this tool versus alternatives (e.g., ue_list_actors). No explicit when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits, but it only says 'deletes'. It does not mention what happens if the label is not found, whether children are affected, or if it is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action. However, it sacrifices important details for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description gives the basic purpose but omits error cases and return behavior. It is minimally complete but would benefit from more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'label' parameter has 0% schema description coverage, and the tool description adds no extra meaning beyond 'the indicated label', leaving format, case sensitivity, and validation unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (actor), and the scope (current level) using the specific label. It distinguishes from sibling tools like 'ue_spawn_actor' or 'ue_list_actors'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites (e.g., actor must exist), no mention of error handling or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the burden on the description. The description does not disclose behavioral traits such as overwrite behavior, permissions required, error handling, or side effects. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence in Italian. While not verbose, it is under-specified for a tool requiring parameter clarification. It lacks structure or any elaboration beyond the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema (not shown), the description should complement these. It does not mention what the tool returns (e.g., asset path, success status) or provide context beyond the import action. The description is insufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameter semantics. It does not explain what the 'files' array expects (e.g., file paths or names) or how the 'destination' path is relative. The default value is mentioned in the schema but not elaborated in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports .wav files as SoundWave assets into the Content Browser. It specifies the file type, target asset type, and destination, distinguishing it from sibling tools like ue_import_assets and ue_create_sound_cue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing audio files but does not explicitly state when to use this tool versus alternatives like ue_import_assets or when not to use it. No comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose side effects, such as whether the camera movement is temporary or persistent, or if a level must be open. The description only states the basic action without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a one-line purpose and two parameter explanations. No superfluous content; every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too brief. It does not explain the return value, prerequisites, or whether the camera applies to the current viewport or a specific one. Essential context is missing for a tool with 2 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying that location is [x, y, z] in cm and rotation is [pitch, yaw, roll] in degrees. This compensates for 0% schema description coverage, though more detail (e.g., coordinate system, relative vs absolute) could improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sposta la camera della viewport' (Move the viewport camera), which clearly indicates the verb and resource. It distinguishes from sibling tools like ue_get_camera (read-only) and ue_set_actor_transform (for actors), but does not explicitly call out differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., ue_set_actor_transform for actors). The description does not specify prerequisites or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on side effects, authentication needs, whether downloads are synchronous, or any constraints. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with the purpose in the first sentence. However, it could be improved by also briefly explaining the destination parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a workflow (downloading from vault) and no output schema, the description lacks details on expected outcomes, error cases, and how destination affects behavior. It only covers the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the app_name parameter (identifier from preset_fab_list_vault) but does not mention the destination parameter, which is optional with default null. With 0% schema coverage, the description should cover both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool downloads an asset from the Epic vault using 'legendary', with a clear verb and resource. It differentiates from sibling tools like preset_fab_list_vault.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after preset_fab_list_vault by noting that app_name comes from that tool, but it doesn't explicitly state when to use this tool versus alternatives like preset_download_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions downloading and extracting but omits critical details like network dependency, file overwrite behavior, storage location, or time expectations. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear breakdown of arguments. It avoids unnecessary words, though the formatting of arg descriptions could be more structured. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description leaves significant gaps. It does not explain the return value, side effects (e.g., file creation), or the role of the destination parameter. The tool's complexity requires more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds value by providing examples for asset_id and variant. However, it completely ignores the destination parameter, leaving its purpose unclear. The examples are helpful but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Scarica ed estrae' (download and extract) and identifies the resource as ambientCG assets, clearly distinguishing it from siblings like preset_download_url (URL-based) and preset_extract_archive (archive extraction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ambientCG assets but provides no explicit guidance on when to use this tool versus alternatives like preset_search_ambientcg or preset_download_polyhaven. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions download location and extraction, but does not address side effects like overwriting, size limits, network usage, or caching. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences with no filler. The main purpose is front-loaded, and the extraction condition is clearly stated. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers the main behavior and two parameters partially. It misses explanations for 'filename' and 'destination', and does not fully specify the behavior of the tool. Sibling tools like preset_extract_archive are related but not cross-referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the 'url' parameter (direct URL, file types) and 'extract' (default true, extracts archives). However, 'filename' and 'destination' are left unexplained, leaving gaps despite partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a file from a direct URL into the local library, listing supported file types (zip, glb, fbx, wav). It distinguishes from siblings like preset_library_list and preset_extract_archive by focusing on URL-based downloads, but does not explicitly differentiate from other preset_download_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for direct URL downloads and explains extraction behavior when extract=True. However, it lacks guidance on when not to use this tool or mention alternatives like downloading from specific sources (e.g., preset_download_polyhaven).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the action and format constraint. It fails to disclose side effects (e.g., whether the archive is deleted, overwriting behavior) or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, making it highly concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the presence of two parameters, the description is too brief. It does not explain the destination parameter, return values, or how the extraction behaves, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters 'archive' or 'destination', leaving the agent without guidance on what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extract) and the resource (zip/tar archive), and includes an explicit unsupported format (.rar), distinguishing it from sibling tools like preset_download_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the archive must already be on disk and that .rar is not supported, providing clear context for when to use the tool. However, no explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the basic action (compile and save) but lacks details about side effects, error states, or success indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the key instruction front-loaded. Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple compile-and-save operation, the description is adequate but lacks details on return values, error handling, and precise path requirements. Given no output schema, more context would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description adds no information about the blueprint_path parameter, such as format, source, or valid values. The parameter remains minimally documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles and saves a Blueprint, using a specific verb and resource. However, it does not differentiate from siblings like ue_create_blueprint or ue_save_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool after manual modifications in the editor, providing clear context. However, it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions writing to .uproject (a file modification) and the need for editor restart. It lacks details on permissions, idempotency, error conditions, or return values. The provided info is useful but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. It front-loads the main action and then adds important context and a note. Perfectly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is insufficient for a complete understanding. It does not explain parameters, potential errors, or the exact modifications to the .uproject. The bridge use case and restart note are helpful but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain parameters. However, it does not describe 'enable', 'disable', or 'uproject' at all. The description only covers the overall action, leaving parameter semantics completely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables/disables plugins by writing to the .uproject file. It specifies it's useful on existing projects, which gives context. However, it does not explicitly distinguish from siblings since no direct sibling exists for plugin management, but the action is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: enabling PythonScriptPlugin and RemoteControl for the bridge. It also advises that the editor needs restarting if already open. It does not give explicit when-not-to-use or alternatives, but the context is helpful for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions the optional link to a SoundWave. It does not disclose side effects like overwriting existing assets, or any required engine states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear paragraphs: a one-line purpose and an Args section with examples. Every sentence is informative, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a creation tool with 3 parameters and no output schema. Explains main use and parameters, but lacks description of return value, error handling, or what a Sound Cue is relative to other audio assets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description compensates with brief explanations and concrete examples for each parameter (e.g., '/Game/MyGame/Audio' for package_path). This adds value over bare schema field titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Sound Cue, optionally linked to an imported SoundWave. The sibling tools include ue_import_audio and ue_create_metasound_source, so this is distinct but not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter examples for package_path, name, and optional wave_path. It mentions the optional connection to a SoundWave, giving context on when to use wave_path. However, it lacks explicit guidance on when to use this tool vs alternatives like ue_create_metasound_source, and does not mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It mentions the detach action and keep_world behavior, but lacks details on edge cases (e.g., invalid label, actor without parent) or side effects. Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line for the purpose and two lines for parameters. No redundant information; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema), the description covers the essential purpose and parameter meanings. However, it omits common usage contexts like error handling, prerequisites (actor must have a parent), and return value (success/failure). It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add value. It does so by explaining both parameters: 'label' is the actor's label, and 'keep_world' maintains world position. This clarifies the boolean's behavior beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sgancia un attore dal suo padre' (detaches an actor from its parent), which is a specific verb and resource. It is distinct from siblings like ue_attach_actor, but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detaching actors from parents but provides no explicit guidance on when to use it versus alternatives, prerequisites, or the implication of keep_world parameter. It assumes the actor already has a parent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'status' but does not disclose whether the operation is read-only, blocking, or what the output structure is. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status tool with no parameters and no output schema, the description is somewhat vague. It does not specify what aspects of status are reported (e.g., running, idle, error) or how to interpret results. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the input schema fully covers parameter semantics. The description adds no parameter information, but none is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides status of the editor process and Remote Control bridge, using a specific verb and resource. It distinguishes from sibling tools like ue_status or build_status by specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites or exclude cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It states the tool lists files, implying a read-only operation, but does not explicitly confirm no side effects, destructive actions, or other behavioral traits. For a simple list operation, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the purpose and adding a practical usage hint. No redundant or unnecessary information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output usage, but lacks explanation of parameters and does not provide examples or edge cases. Given the low schema coverage, more detail on parameter behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two optional parameters (subfolder, extensions) with 0% description coverage. The description does not explain what these parameters do or how they affect the listing. It only mentions the default library path, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists downloaded files in the local library and specifies the default path. It also explains that the returned paths are intended for use with ue_import_assets, distinguishing it from download or other listing tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by stating that returned paths can be fed to ue_import_assets, making it clear when to use this tool (when needing to import previously downloaded assets). However, it does not explicitly state when not to use it or mention alternatives, but the context with siblings is sufficiently distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions adding and recompiling. It fails to disclose prerequisites (e.g., blueprint must be open), side effects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main action, and structured with Args. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description lacks important context such as prerequisites, return values, and potential delays due to recompilation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds valuable examples for blueprint_path and component_class (e.g., 'StaticMeshComponent'), and explains that 'name' is the component's name in the blueprint, which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a component to a Blueprint and recompiles it, using a specific verb and resource. It distinguishes from sibling tools like ue_create_blueprint or ue_add_variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding components to blueprints but does not provide explicit guidance on when to use this tool versus alternatives like ue_add_variable or ue_compile_blueprint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose behavioral traits such as required permissions, side effects (e.g., asset modification), or conditions (e.g., actor must have a mesh). Only the basic action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, combining an Italian title line with English parameter documentation. It is structured but uses two languages, which could be streamlined. Every line adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the action and parameters but omits return behavior, error conditions, and prerequisites. Given no output schema or annotations, a bit more context (e.g., 'returns nothing on success') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool's description provides clear explanations for all 4 parameters: label (actor label), material_path (path), slot (index with default 0), component (default first MeshComponent). This adds significant meaning beyond the schema's type/title-only fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assegna un materiale a un attore piazzato' (assign a material to a placed actor), specifying the verb and resource. It distinguishes from sibling tools like ue_set_actor_property or ue_create_material by being material-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a material needs to be assigned to an actor, but provides no explicit guidance on when not to use it or alternatives. No differentiation from other actor manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic listing action. It fails to mention that the tool is read-only, whether there are limits on recursion depth, or performance considerations, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences for purpose and parameter explanations. It front-loads the main action and uses a structured args list, though some details could be integrated into the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential usage but lacks details on default behavior (e.g., recursive=true), output format, and edge cases. Given the output schema exists, return values are covered, but additional context like case-sensitivity of class_filter would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter: path (example '/Game/MyGame'), recursive (include subfolders), and class_filter (partial class name filter). This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Elenca gli asset presenti sotto un path del Content Browser' (list assets under a path of the Content Browser), providing a specific verb (list) and resource (assets under a path). This clearly distinguishes it from sibling tools like ue_delete_asset or ue_import_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it implies usage for listing assets, it lacks exclusions or context that would help an agent decide between this and similar tools like ue_list_actors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says it saves, but does not explain whether it overwrites files, requires user confirmation, or triggers a dialog. The effect on unsaved changes is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, seven-word sentence in Italian. It is extremely concise with no unnecessary words, front-loading the purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is fairly complete for a save action. It could mention immediate results or feedback, but the core functionality is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% by default. The description does not need to add parameter meaning, and its simplicity is appropriate for a parameterless save operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current level and all modified assets. The verb 'save' and the resources 'level' and 'modified assets' are specific, and it distinguishes from sibling tools like ue_open_level or ue_spawn_actor which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other save-related tools (if any) or conditions like needing to save before closing. No exclusions or context for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as authentication, rate limits, or what happens with invalid inputs. It only states the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded: two lines plus an Args section. Every sentence is necessary and no extraneous information exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks details on search behavior, sorting, pagination, or error handling. However, for a simple search tool with 3 parameters, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description compensates by explaining asset_type values (hdris, textures, models), categories as filters with examples, and limit as max results. This adds meaning beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches CC0 assets on Poly Haven, distinguishing it from siblings like preset_search_ambientcg and preset_download_polyhaven.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. Usage is implied by the name and siblings, but no when-not-to or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains what parameters do but does not mention side effects, whether the editor must be open, or if settings persist. This is insufficient for a configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one introductory sentence followed by three bullet-point-like args. No unnecessary fluff, well-structured, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional parameters, no output schema), the description covers the purpose and parameters well. However, it lacks mention of side effects or how this action integrates with sibling tools like ue_start_pie.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: num_players, net_mode (with valid values), and one_process. This adds significant meaning beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures multi-client Play In Editor for local multiplayer testing. It distinguishes from sibling tools like ue_start_pie by focusing on configuration rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters but does not explicitly state when to use this tool vs alternatives (e.g., ue_start_pie). No guidance on prerequisites or when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses it executes arbitrary Python and mentions the 'result' variable, but lacks details on side effects, error handling, or security implications. It gives some transparency but not full.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the purpose stated in the first sentence. It includes a separate Args section. A bit more brevity could be achieved, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of arbitrary code execution and no output schema, the description should explain the return mechanism (result variable) and output format. It does mention 'result' but does not specify the return value type or behavior, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful context for the only parameter 'code' via an example, showing how to assign the return value. This compensates well for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes arbitrary Python code in the Unreal editor, using the verb 'esegue' and specifying the resource. This distinguishes it from sibling tools that perform other actions like saving, opening levels, or managing actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'escape hatch' implying advanced use, and lists available modules, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Some guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the main behavior (listing actors of current level with filters) but does not detail side effects, performance, or read-only nature. Adequate for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the main action and filters. Every part is essential, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no required ones) and the presence of an output schema, the description is nearly complete. It could mention the default behavior (lists all actors) but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It maps 'name' and 'class' to the parameters but does not clarify substring matching or case sensitivity. Partially helpful but lacks specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists actors of the current level with optional filters, distinguishing it from sibling tools like ue_list_assets (which lists assets) and ue_actor_hierarchy (which shows hierarchy).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives; the context implies it is for listing actors with filters, but no when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It indicates a read-only operation (reading log tail) but does not explicitly state it has no side effects, nor does it cover error conditions, permissions, or output format. This leaves important behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, then lists parameters in a clear structured format. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description lacks explicit mention of return format (e.g., string or list). However, parameters and use case are covered. Given the simplicity, it is moderately complete but could specify the output type for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully explains both parameters: 'lines' (number of final lines to return, default 80) and 'only_errors' (filter to Error/Warning only). This adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the tail of the Unreal log for debugging after non-exceptional operations. The verb 'legge' and resource 'coda del log di Unreal' are specific and distinct from sibling tools, which focus on other Unreal actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use ('after an operation that didn't throw exceptions') but does not explicitly state when not to use it or mention alternatives. Since no sibling tool reads logs, the guidance is adequate but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool modifies config files and that some changes require restart, but does not specify whether values are appended/overwritten, error handling, or persistence behavior (e.g., if the file is created if missing). This leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured, using a clear 'Args' list with examples. It avoids redundancy and is easy to scan. Minor improvement could be more compact formatting, but it's already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the parameters and adds a restart note. However, it lacks details on return values, side effects (e.g., auto-save), or error scenarios, which would make it more complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for 0% schema coverage by listing each parameter with real-world examples (e.g., '/Script/EngineSettings.GameMapsSettings') and specifying allowed values for 'config' ('Game' | 'Engine' | 'Input'). This adds significant meaning beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a setting to project config files, with a specific verb (scrive/un'impostazione) and resource (file Config/Default<config>.ini). It provides detailed parameter examples, making the purpose unambiguous and distinct from sibling tools like ue_set_actor_property, which operate on different targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note about requiring editor restart for some settings, giving a practical usage hint. However, it does not explicitly state when to use this tool versus alternatives (e.g., for runtime vs. persistent settings) or what prerequisites exist, limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the asset is downloaded to a local library and specifies parameter options, but it does not mention side effects (e.g., overwriting, errors on invalid IDs), rate limits, or any output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The Args section could be formatted as bullet points for quicker scanning, but every sentence is necessary and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers all parameters with allowed values. It lacks information on return values (e.g., success/failure) and error handling, but provides sufficient detail for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. It explains each parameter: asset_id with an example, resolution with enumerated values (1k, 2k, 4k, 8k), formats with type-specific examples (jpg for texture, gltf for models, hdr for HDRI), and destination as an alternative folder. This adds critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: 'Scarica un asset Poly Haven (CC0) nella libreria locale' (Download a Poly Haven asset into the local library). It includes a verb (download) and a resource (Poly Haven asset), clearly distinguishing it from siblings like preset_download_ambientcg or preset_download_kenney.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Poly Haven assets but does not explicitly state when to use this tool versus other download tools (e.g., for different sources) or search tools. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It transparently states that no public API exists and describes the dependency on the legendary client or manual steps from Epic Games Launcher, which is adequate for a read-only listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences that front-load the core purpose and immediately follow with critical setup information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully covers the tool's purpose and setup requirements. It is complete for a listing tool with external dependencies, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds no parameter details. However, the baseline for zero parameters is 4, and the description provides useful context about the tool's operation and prerequisites.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists purchased Unreal content from the Epic account (Fab/Marketplace). The verb 'elenca' (list) and resource are specific, and it distinguishes from sibling 'preset_fab_download' which handles downloads, though not explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the prerequisite (legendary client) and provides installation instructions, but does not explicitly state when to use this tool versus alternatives like 'preset_fab_download' or other preset tools. Usage context is implied but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool recompiles the blueprint and requires a specific engine version, but for a mutation tool with no annotations, it lacks details on side effects (e.g., saving, breaking references) and error conditions. This leaves the agent without full understanding of behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two well-structured paragraphs: one for purpose/requirement, one for parameter explanations. Every sentence adds value, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs and requirements well but lacks output schema information and error handling. For a tool with 7 parameters and no annotations, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema by explaining each parameter with examples and clarifying sub_type usage for structs/objects and class names. Given 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a member variable to a Blueprint and recompiles it, using specific action verbs and resource. It distinguishes from sibling tools like ue_create_blueprint or ue_add_component by specifying its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a requirement (UE 5.4+) and suggests checking ue_status for capabilities, providing context for when to use. However, it does not explicitly state when not to use or provide direct alternatives, though no similar sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that instancing does not recompile the shader graph, a key behavioral trait. However, it lacks details on side effects, authorization needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with purpose and benefit front-loaded, followed by parameter details. It is not verbose but could better separate general description from parameter listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should include return behavior or post-creation effects. It does not mention what the tool returns or whether the instance is automatically saved. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by listing each parameter with its purpose and value types (scalar, color, bool, texture). This adds significant meaning beyond the bare schema, though exact formats for complex types could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a material instance from a parent material and sets parameters, using specific verb and resource. It distinguishes from sibling tools like ue_create_material by emphasizing that instancing avoids shader recompilation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (for multiple variants without recompilation) but does not explicitly state when not to use or name alternative tools. However, context implies alternatives like ue_create_material for new materials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool gets camera data and provides timing advice, but does not disclose details like return format, potential blocking, or read-only nature. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences: the first states the purpose, the second provides a usage guideline. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description captures the core function and critical usage advice. It could optionally mention the return data type, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. Baseline is 3 as the description adds no parameter-specific detail, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool obtains the camera's position and orientation ("Posizione e orientamento della camera"), which is a specific verb+resource combination. It distinguishes itself from sibling tools like ue_set_camera by being a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling this tool before spawning actors ("Da chiamare prima di spawnare") and explains why actors at origin may be off-screen. It does not mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool lists components but does not explicitly state it is safe/read-only, rate limits, or any side effects. Basic information is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences conveying essential purpose and usage. No unnecessary words, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states the tool returns name and class, which is sufficient for a list tool. It does not describe ordering or filtering, but for this simple tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description adds that the `label` parameter identifies a placed actor, but does not explain format or constraints beyond that. It adds some meaning but not enough to fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists components of a placed actor with name and class, and identifies the purpose: to know what to pass as `component` to ue_set_actor_property. This verb+resource phrasing distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use it (to get component names for ue_set_actor_property) but does not provide explicit when-not-to-use or alternatives. Given the context of sibling tools, it is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions creation and opening, but does not disclose potential side effects, such as what happens if the path already exists or any authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by parameter documentation in a standard docstring format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage and no output schema, the description provides essential coverage for purpose and parameters. However, it omits behavioral details like error handling or return value indication. Adequate but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by providing an example path format and explaining that the template parameter is optional and used for duplication. This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new level and opens it, using a specific verb and resource. Among sibling tools like ue_open_level and ue_save_all, this tool is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new levels, but does not explicitly differentiate from alternatives or state when not to use it. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It specifies the main behavior (reading a .uproject file and returning engine version, plugins, bridge status) and adds context beyond the schema. However, it does not mention error handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all essential information without any fluff. It is front-loaded with the action and resource, making it efficient for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains what the tool reads and what data it returns. It is mostly complete, though it could mention the output format (e.g., JSON) and potential error cases (e.g., file not found).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify the parameter. It states the tool reads a .uproject file, implying 'uproject' is a file path. However, it lacks details about path format (absolute/relative), file extension, or existence requirements, which are needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Legge' (reads) and the resource '.uproject', and lists specific information retrieved: engine version, active plugins, and bridge readiness. This distinguishes it from sibling tools like ue_project_create or ue_project_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a .uproject file but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Context from sibling names provides some differentiation, but the description itself lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that references are updated, adding behavioral context beyond the schema. However, it does not detail error handling, consequences of invalid paths, or undo behavior. With no annotations, more transparency would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence plus a brief parameter list with examples. Every part is essential and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers purpose and parameter format. It lacks mention of return value or failure modes, but is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by providing examples for both parameters, indicating the expected format (e.g., '/Game/Imported/SM_rock'). This adds significant meaning beyond bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves or renames an asset while updating references, which is a specific verb-resource combination. It distinguishes from sibling tools like ue_delete_asset and ue_duplicate_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use when needing to move/rename with reference updates), but the description lacks explicit guidance on when not to use it or alternatives. No comparison to other asset tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains parameters and notes that the label is used by other tools for retrieval. However, it does not disclose error handling, permission requirements, or side effects of spawning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in a bullet-like Args list. It is front-loaded with the main action and each parameter is explained briefly. Slightly verbose due to examples but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters and no output schema, the description covers essential details for each parameter and explains the label's reuse. It lacks information on failure modes or coordinate systems, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides detailed semantics for all 5 parameters, including examples for class_ref and units for location and rotation. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool spawns an actor in the current level, using a strong verb and resource. It distinguishes itself from the sibling 'ue_spawn_many' by implication (single vs many).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on how to use the parameters but lacks explicit guidance on when to use this tool versus alternatives like 'ue_spawn_many'. It does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It explains the basic behavior (moving parent moves child) and the attach_rule parameter, but does not disclose what happens if the child is already attached to another parent, or any error conditions. Partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences of context and a clear Args list. Every sentence serves a purpose, and the key concept is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description is adequate but incomplete. It does not mention return values, error handling, or prerequisites like whether the actor needs to be in the level. Some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining socket ('nome del socket sul padre, se ne ha') and listing the three possible values for attach_rule. All four parameters are covered, though schema coverage is technically 0% because the description is separate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool attaches one actor to another, with the concrete example 'moving the parent moves the child'. It also distinguishes from the sibling 'ue_detach_actor' by implication and provides a use case for composing a scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (composing a scene by parenting objects) and contrasts it with leaving objects unlinked. It does not explicitly list when not to use it or mention alternative siblings like 'ue_spawn_actor', but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool moves the camera to focus on an actor, similar to the F key, and that using the selection when no label is given. However, it does not disclose potential side effects like persistence of camera position or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs followed by an Args section. It front-loads the purpose and context, and each sentence adds value. Could be slightly more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 optional parameters, no output schema), the description covers the essential aspects: what it does, how parameters work, and relationship to a sibling tool. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning for parameters. It does so effectively: label is 'actor to focus; if omitted uses current selection,' and distance is 'camera distance in cm (default 500).' This provides clear guidance beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool focuses an actor with the camera, analogous to the F key in the editor. It distinguishes from sibling ue_screenshot by explaining that without it, the screenshot captures whatever the camera was already looking at, which is rarely the newly built object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: as a complement to ue_screenshot to frame the actor before capturing. It implies that without this, the screenshot may not capture the intended actor. However, it does not explicitly state cases where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it stops the current session but does not disclose side effects (e.g., losing unsaved changes), requirements (e.g., a session must be running), or what happens if no session exists. Adequate for a simple stop command but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is front-loaded and immediately communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and performs a simple action, the description is sufficient. It fully explains what the tool does without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% coverage (empty). Per guidelines, baseline for 0 parameters is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ferma', stops) and resource ('sessione Play In Editor', Play In Editor session), clearly indicating the tool's action. It distinguishes from siblings like ue_start_pie which starts the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after starting a PIE session but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The context makes it somewhat clear, but it lacks direct usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses default rejection of deletion if referenced and the risk of broken references. However, it does not cover error handling, undoability, or permission requirements, which would be helpful for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the action, and lists parameters simply. Every sentence adds value, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the tool's primary behavior and parameters adequately. It lacks details on return values or error scenarios but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds concrete examples for path (e.g., '/Game/Imported/rock_01') and explains the force parameter's effect, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it deletes an asset or folder from the Content Browser, provides a specific use case (remedying a wrong import), and distinguishes itself from sibling tools like rename or duplicate by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says when to use (to fix an import mistake) and explains default refusal on reference detection. It does not explicitly mention alternatives or when not to use, but the risk of broken references serves as a caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the two-phase approach (clean close attempt then process termination) and the effect of each parameter. However, it does not mention what happens if save_all=False and clean close fails (still terminates), which is somewhat ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The purpose is stated first, followed by a clear explanation of the two-step process and parameter descriptions. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the essential behavior (close modes, parameter effects). It could mention return value or prerequisites (editor must be open), but these are implied. Complete enough for a close tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so effectively: save_all saves level/assets before closing, force skips clean close and terminates directly. This adds meaning beyond the schema's boolean names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes the editor, specifying a two-step process (clean close then force terminate). It distinguishes from sibling tools like ue_editor_open (open) and ue_save_all (save).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use force (if clean close fails or force=True), but does not explicitly mention when not to use this tool or suggest alternatives (e.g., use ue_save_all for saving only). The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses it runs in UnrealEditor-Cmd headless, is asynchronous (start and check status), and warns that without config, output may be missing. It could mention return value or non-destructive nature explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states purpose, then context, then Args list. It is appropriately sized for the complexity, though slightly verbose. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers purpose, behavioral context, and most parameters, it does not describe the tool's return value (e.g., success indicator, job ID). Given no output schema, this is a gap. It also omits two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description adds significant value. It explains 7 of 9 parameters (e.g., config format, resolution default, output_dir default). engine_root and engine_version are undocumented, but coverage is high and explanations are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a Level Sequence with Movie Render Queue in background. The verb 'Renderizza' and resource 'Level Sequence' are specific, and it distinguishes from sibling tools like ue_render_status by focusing on initiating renders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the tool runs in a headless process to avoid blocking the editor, and directs to ue_render_status for progress. While it doesn't explicitly list alternatives or exclusions, the context is sufficient for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that the tool actually creates and connects nodes in the material graph, not just sets parameters. However, it omits details like authentication requirements, side effects, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a brief clarification. Every sentence adds value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 parameters, no nested objects) and lack of output schema, the description covers all parameter semantics and basic behavior. It could mention the return value (e.g., created asset path), but this is not critical for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section explains every parameter in detail: package_path, name, textures (with channel list and 'auto' key), scalars, and two_sided. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a material by connecting textures to PBR channels, and contrasts it with Blueprint graphs to highlight its full scriptability. This distinctly separates it from sibling tools like ue_create_material_instance and ue_assign_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for full material graph creation (as opposed to Blueprint graphs), but it does not explicitly specify when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that spawning is grouped into a single undo transaction, which is a key behavioral trait. However, it does not mention failure handling, permissions, limits on number of actors, or what happens to the spawned actors (e.g., naming, collision). The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear purpose, followed by a rationale, then a concise parameter breakdown. Every sentence adds value; there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers input needs thoroughly. It explains the undo transaction and performance benefit. However, it does not describe the return value (e.g., success indication, spawned actor references) or maximum number of actors, leaving minor gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'actors' as an array of objects with no structure, while the description provides detailed semantics: required 'class_ref', optional 'location', 'rotation', 'scale', 'label', plus an example. This fully compensates for the 0% schema description coverage and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool spawns many actors in one call and one undo transaction, and explicitly contrasts with ue_spawn_actor which requires multiple HTTP round-trips. The verb 'spawna' and resource 'molti attori' are specific, and the sibling tool differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool when spawning 'qualche decina di elementi' (several tens of elements) due to cost savings over individual spawns. This implies a threshold for when to use this vs ue_spawn_actor, though it does not explicitly state when NOT to use it (e.g., for single actors).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the search locations and that it lists installations. It does not mention side effects, but for a read‑only listing tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first states the core purpose, the second provides search context and usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool without an output schema, the description covers its purpose, search scope, and when to call it. It does not detail the output format, but the tool is simple enough that this is not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially 100%. The description adds value by explaining the search locations (UE_MCP_ENGINE_DIRS, Epic Games Launcher, Windows registry), which is useful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Unreal Engine installations on the machine. It specifies the verb 'list' and the resource 'engine installations', distinguishing it from project-focused siblings like ue_project_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'to be called first when there is no project yet', providing clear context for when to use this tool. It does not explicitly mention alternatives, but the context is sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses idempotency, a key behavioral trait, and the example implies nested folder creation. However, it does not cover error cases or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences plus args), with no unnecessary words. The main purpose is stated first, and the example is efficiently placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the idempotency guarantee, the description covers essential use. It could mention that the path is relative to the /Game root, but the example makes that clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by providing an example path format ('/Game/MyGame/Meshes') that clarifies the expected structure beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Crea una cartella nel Content Browser' (creates a folder in the Content Browser), clearly identifying the verb, resource, and context. No sibling tool performs this function, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is straightforward: create a folder. The idempotency note and example path provide practical guidance. While no explicit 'when to use' is given, the tool's uniqueness among siblings makes it implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: long operation, background execution, editor must be closed, produces standalone executable. It does not cover failure modes or concurrency limits, but the details are sufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first paragraph covers purpose and key traits, second gives usage flow, then parameter list. It is somewhat long but every sentence adds value, and important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description covers purpose, usage flow, parameter details, and behavioral traits. It lacks return value info but references ue_package_status for monitoring, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains 7 of 8 parameters (all except engine_version) with defaults, examples, and usage notes. This adds significant meaning beyond the empty schema, e.g., maps notes on omission and slower cooking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Crea il pacchetto giocabile del gioco (cook + build + stage + pak)' and specifies it produces a standalone executable. It distinguishes from sibling tools like ue_build_start (which only builds) and ue_package_status (which monitors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it runs in background, is long, and must follow ue_editor_close and precede ue_package_status. However, it does not explicitly state when not to use it (e.g., for only building use ue_build_start), so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses JSON formats for vectors, colors, and auto-loading of asset paths. It explains the 'component' parameter's purpose. However, it does not mention potential side effects, required permissions, or whether changes are persistent. Overall, it adds significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, elaboration, and an Args section. It is slightly verbose but remains focused. Every sentence adds value. It could be slightly more concise, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers parameter details, behavior, and examples. It lacks information about return values or error handling, which would be helpful. However, it is sufficiently complete for a property-setting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters: 'label' (actor label), 'properties' (map with JSON formats), and 'component' (optional, name or class). Examples are provided for vector and color formats. This adds substantial meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting properties on an actor or its component. It distinguishes itself from 'Class Defaults' (handled by a sibling tool) and provides concrete examples (mesh, light intensity, trigger radius). The verb 'imposta' (set) and resource 'attore' (actor) are specific, and the description differentiates from sibling tools like ue_set_actor_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the scope ('everything except Class Defaults'), which implies when to use this tool vs. alternatives. It does not explicitly list exclusions or mention specific sibling tools, but the context is clear. A score of 4 reflects good implied guidance without explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that wait_seconds causes blocking and progress reporting, and that uproject defaults to the last build. This adds behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single introductory sentence followed by clearly structured parameter descriptions. Every sentence adds value, no redundancy. It is front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 optional parameters, no output schema), the description covers the purpose and key behaviors adequately. It mentions return aspects like status and log lines but does not detail error handling or prerequisites. Slightly incomplete, but sufficient for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains each parameter: tail_lines (number of final log lines), uproject (project reference, defaults to last build), wait_seconds (waits and reports progress if >0). This compensates fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks the status of a compilation started with ue_build_start, mentioning specific states like 'in corso' (in progress), errori, and coda del log. It distinguishes itself from siblings like ue_build_start and ue_build_unblock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use it (after starting a build) and gives guidance on using wait_seconds to avoid multiple reads ('meglio un'attesa sola che venti letture'). It does not explicitly mention when not to use it or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it returns current phase, errors, and final executable path, and describes wait behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short introductory sentence, then parameter explanations in a structured format. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return values (phase, errors, executable path). It could be more explicit about the return format, but it is sufficient for a status tool. Context with sibling tools is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all three parameters clearly: tail_lines (lines of log to return), uproject (project reference, defaults to last packagestart), and wait_seconds (wait limit if >0). This adds meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports status of packaging started with ue_package_start, listing phases (Cook, Stage, Package, Archive), errors, and final executable path. This distinguishes it from sibling tools like ue_build_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (checking packaging progress) and explains wait_seconds behavior (if >0 waits, else returns immediately). However, it does not explicitly state when not to use or provide alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses many behaviors: writing multiple files, enabling specific plugins, autostart server, force overwrite, default engine version handling, and blueprint-only exclusion. However, it does not mention error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-sentence purpose, a paragraph listing created files, then a bulleted list of parameters. Every sentence adds value, and it is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description covers the purpose, created files, and all parameters. It lacks details on return values and potential errors, but it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 11 parameters, adding meaning beyond the schema (e.g., valid name format, parent directory, engine lookup behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an Unreal project from specification, listing the files it writes. It distinguishes itself from sibling tools like ue_project_find, ue_project_info, etc., by being the creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new project but does not explicitly state when to use it over alternatives or when not to use it. The parameter explanations give context, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavior: success checking based on files, and wait_seconds parameter causing waiting and progress reporting. It doesn't mention permissions or side effects, but it's a read-only operation implied by 'stato'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and uses a clear bullet-like format for arguments. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters and no output schema, it explains parameters and key behavior. It doesn't specify the return format, but the concept of 'succeeded' and log lines is sufficient. Could be slightly more explicit about return values, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description provides detailed meaning for all three parameters: tail_lines (log lines), uproject (project reference, defaults to last), wait_seconds (wait and report progress). This fully compensates and adds clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks the status of a render started with ue_render_sequence, with a specific nuance about success based on files rather than exit code. This distinguishes it from sibling tools that start rendering or check other statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions the tool is for render status after ue_render_sequence, and explains the behavior of wait_seconds. However, it doesn't compare to other status tools like ue_status, but the context is clear enough for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes variable absorption/renaming and the optional cleanup of unused variables. No annotations provided, so description carries full burden. Lacks details on reversibility or post-actions like compilation, but covers main aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, well-structured with bullet points for args. Slightly verbose but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return value or post-conditions (e.g., if blueprint is saved/compiled). Input parameters are well described, but missing outcome details for a modification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema (which has 0% coverage): provides examples for blueprint_path and new_parent, explains the format, and clarifies the remove_unused_variables parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reassigns the parent of a Blueprint to a C++ class, with the purpose of giving executable logic. It distinguishes from siblings like ue_cpp_class_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (to give executable logic to a Blueprint), mentions alternatives (ue_cpp_class_create), and describes variable behavior. Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the file is saved to <Progetto>/Screenshots/MCP, that the default resolution is modest to avoid large base64 responses, and that return_image=False only returns the path. These details go beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes a rationale, storage info, resolution advice, and parameter documentation. It is slightly verbose but every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple screenshot tool with 4 parameters, the description covers all necessary aspects: what it does, why it's needed, file persistence, resolution considerations, and parameter details. No output schema exists, but the tool's return type (image or path) is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully documents all 4 parameters: filename, width, height, and return_image. It explains default behaviors (timestamp, resolution trade-offs) and the effect of return_image, adding significant meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cattura la viewport dell editor e restituisce l immagine all agente', which translates to capturing the editor viewport and returning the image. This verb+resource combination is specific and distinct from sibling tools like ue_set_camera or ue_render_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that without this tool the agent builds blindly and it is the only way to verify the scene visually, providing clear context for when to use it. It also warns about resolution trade-offs but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists the return fields but does not explicitly state that the tool is read-only or non-destructive. However, given it is a status check, it is likely safe. The description could be more explicit about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states purpose and return values, the second gives usage priority. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status check tool with no output schema, the description adequately lists all return fields. It also provides contextual guidance (use first). No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter explanations are needed. Baseline score of 4 applies as the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Unreal Editor connection and returns specific status fields (engine version, open project, current level, actor count, transport). It distinguishes itself from sibling tools by being a diagnostic/status check rather than an action tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Da usare per prima' (use it first), providing clear guidance on when to use this tool relative to siblings, implying it should be a preliminary step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It thoroughly discloses behavior: generation of C++ files, creation of module files (Build.cs, etc.) for Blueprint-only projects, overwrite behavior via 'force', replication handling for properties, and BlueprintCallable function generation. No contradictions with annotations (none exist). This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured. It begins with the primary purpose, then provides workflow context, then parameter details. Every sentence adds value, though the workflow is repeated in both prose and bullet list. Could be slightly more concise, but overall effective and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, nested objects for properties and functions, no output schema), the description covers all major aspects: each parameter, replication, BlueprintCallable, module creation, file overwriting. It does not mention error handling or return values, but these are minor gaps. The description is sufficiently complete for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains every parameter in detail: uproject path, class_name naming convention, parent_class options, module default, properties structure (with replication effects), functions structure (with BlueprintCallable default), with_tick default, and force. It goes beyond schema by providing examples and behavioral implications, fully compensating for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates compilable C++ classes in the project module. It explains the limitation of Blueprint graphs (not writable in Python) and positions this tool as the solution, distinguishing it from Blueprint creation tools. The verb 'genera' (create) and resource 'classe C++' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool (when logic cannot be expressed in Blueprint graphs) and outlines a full workflow (ue_cpp_class_create -> ue_editor_close -> ... -> ue_reparent_blueprint). It also notes that if the project is Blueprint-only, the C++ module will be created. However, it does not explicitly state when not to use it or compare to alternatives like ue_create_blueprint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool waits for bridge response, that default wait is short due to client timeout, and that if bridge not ready, the response indicates so. Mentions shader compilation and potential modal blockage due to skip_module_check. However, no annotations provided, and the description could be more explicit about side effects (e.g., editor launch) but is still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose. The following paragraph and Args list are well-organized, though slightly verbose. Every sentence adds value, but the entire text could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explicit return value details (no output schema), but the description implies the tool returns status about bridge readiness and refers to ue_editor_status for detailed polling. For a tool with 6 parameters and no output schema, it provides good contextual information, but missing exact response structure for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the Args section add significant meaning beyond the schema (which only has titles and defaults). Each parameter is explained: uproject (path), engine_version (force version), wait_seconds (with caveats), extra_args (command-line args), engine_root (engine path), skip_module_check (warning about modal). With 0% schema coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Apre un progetto nell'editor e attende che il bridge risponda' which is a specific verb+resource. It clearly distinguishes from sibling tools like ue_editor_status (polling for bridge_ready) and ue_editor_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use polling (ue_editor_status) instead of increasing wait_seconds because of client timeout. Advises against raising wait_seconds beyond client timeout, especially on first launch with shader compilation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that GLB/GLTF go through Interchange and that replace_existing controls overwriting. This gives a clear behavioral picture without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a main line, followed by technical notes, and then a clear parameter listing with examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple formats, skeletal handling), the description covers all necessary aspects: supported formats, framework usage, parameter semantics, and intent. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains each parameter in detail, including absolute paths, destination folder, and the role of import_as_skeletal for FBX. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool imports 3D/audio files into the Content Browser, listing specific formats. The verb 'import' and resource 'assets' are explicit, and it distinguishes itself from sibling tools like ue_import_audio by being more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance for when to use import_as_skeletal with FBX files and mentions the Interchange framework for GLB/GLTF. It lacks explicit 'when not to use' statements, but the sibling tools list implies specialization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: searches by command line, terminates processes, handles dotnet/cmd, checks lock file, and warns about potential false positives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-organized, but slightly verbose. Every sentence adds value, so it remains efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains behavior, output (list of processes), and logic. Could mention output format explicitly, but sufficient for agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides detailed semantics for dry_run (default true, safe), engine_version and engine_root (to locate lock file). However, format expectations are not given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (find and optionally terminate), resource (processes holding build lock), and differentiates from siblings like ue_build_status by specifying the exact use case when builds are blocked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Serve quando ue_build_status riporta blocked'), explains why alternatives like taskkill don't work, and provides dry_run recommendation for safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains that the tool does not close the editor, is fast, but limited to function bodies. It does not mention error handling or return values, but the core behavioral constraints are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with no redundant sentences. It front-loads the main purpose and uses a clear structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description provides sufficient context: when to use, limitations, and alternative tool. It is complete enough for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The Args section explains max_wait_seconds: it controls how long to wait for result before returning 'in corso' (in progress), with compilation continuing. This adds context beyond the default value in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool recompiles C++ without closing the editor (Live Coding), and distinguishes itself from full rebuilds by specifying it only works on function body changes. It explicitly names the alternative tool ue_build_start for structural changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for fast iteration on function body changes) and when not to use it (for changes that alter reflection data like UCLASS/UFUNCTION/UPROPERTY, which require ue_build_start with editor closed). This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the build runs in background, that the editor must be closed, that force is for stuck builds, and that builds queue on a mutex. This provides rich behavioral context beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, a bolded warning, a typical sequence, and a bulleted argument list. It is informative without being verbose. However, the argument descriptions could be slightly more concise (e.g., 'forza una versione del motore diversa da quella associata' is a bit wordy). Still, it is well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides comprehensive context: preconditions, sequence, parameter details, and force usage. It lacks an explicit statement about the return value (e.g., a build ID), but the sibling ue_build_status implies the agent can check progress. Slightly more detail on the immediate result of starting a build would make it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: uproject (path to .uproject), engine_version (force different engine version), target (default '<Progetto>Editor'), configuration (lists three values), engine_root (path when engine not registered), force (use only when previous build stuck). This adds meaningful semantics beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Avvia la compilazione del modulo C++ del progetto (in background).' This specifies the verb 'avvia' (starts), the resource 'compilazione del modulo C++', and the context 'in background'. It distinguishes the tool from siblings like ue_build_status (which checks status) and ue_build_unblock (which unblocks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'L'editor deve essere chiuso' and explains why (Live Coding prevents DLL writing). Provides a typical sequence: ue_editor_close -> ue_build_start -> ue_build_status -> ue_editor_open. Also clarifies when force should be used: only when previous build is stuck and processes are closed. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that console commands write to log, not return values, and the tool captures new log lines. It warns that it can execute 'quit' and passes through Python interpreter, not the remote API, giving full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-liner, behavioral explanation, usage examples, technical detail, and parameter descriptions. Each sentence adds value, and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description fully covers return behavior, execution mechanism, and potential dangers. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: 'command' with example 'stat fps', and 'wait_seconds' as wait time for log output. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes an editor console command and returns its output. It distinguishes from sibling tools like ue_exec_python and ue_read_log by explaining it captures new log lines from command execution. The verb 'execute' and resource 'console command' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples of when to use (e.g., 'stat unit', 'r.ScreenPercentage') and contrasts with the remote execution API. It does not explicitly list when not to use or compare to siblings like ue_exec_python, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/Groggy-rollcall812/unreal-engine-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Groggy-rollcall812/unreal-engine-mcp)

Score Badge

Copy to your README.md:

[![unreal-engine-mcp MCP server](https://glama.ai/mcp/servers/Groggy-rollcall812/unreal-engine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Groggy-rollcall812/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/Groggy-rollcall812/unreal-engine-mcp'

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