unreal-ai-connection

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.9.1-ue5.6
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap among Python execution tools (execute_unreal_python, exec_python_persistent, apply_python_to_selection, run_python_file) and bulk operations that could confuse an agent. Descriptions help differentiate, but the sheer number of tools (105) increases ambiguity risk.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern (e.g., inspect_*, list_*, set_*, create_*, delete_*). The few exceptions like fix_up_redirectors and convert_hdri_to_cubemap still use underscores and predictable verbs, maintaining a coherent naming scheme.
Tool Count3/5
With 105 tools, the server covers an extensive range of UE editor functionality, but this number feels high for the stated purpose. Each tool appears justified, but the count borders on overwhelming and may indicate scope creep beyond a focused domain.
Completeness4/5
The tool set is remarkably comprehensive, covering asset CRUD, actor manipulation, blueprint compilation, Python execution, animation, audio, material, and more. Minor gaps exist (e.g., no direct tool for creating Blueprints or materials), but Python execution can fill many gaps, making the surface quite complete.
Average 4.1/5 across 96 of 105 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on May 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states all fields are optional and default to 0, which is already in the schema, and mentions a single round-trip. However, it does not explain if the operation is destructive, requires permissions, or has side effects on the editor state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence is a clear purpose statement. The second sentence adds parameter defaults but includes implementation details that may not be useful for selection. Overall 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?
The tool sets the camera transform, and there is a sibling get_camera_transform. The description does not mention this relationship or any context about viewport states. No output schema exists, but for a setter this is acceptable. Missing some completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats that missing fields default to 0, which adds no new meaning beyond the schema. It does not explain the coordinate system or rotation units further.
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 sets the level-editor viewport camera transform. It does not explicitly differentiate from the sibling tool get_camera_transform, but the verb 'set' makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description mentions it's a synthetic bridge-side handler, which is an implementation detail that does not help an agent decide when to use this tool versus alternatives. There is no mention of 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?
The description indicates the tool is read-only ('Read'), but with no annotations provided, it fails to disclose details such as return format, permissions, or what exactly 'widget hierarchy' entails. It adds basic behavioral context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence that is concise and front-loaded with the action. However, it sacrifices necessary detail, especially about the parameter, which could be included without much expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema or annotations, the description does not provide enough context. It omits parameter semantics and return value expectations, leaving significant gaps for an agent to use the tool correctly.
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 0% description coverage and the single parameter 'path' is not explained at all in the description. The agent is left to guess whether it requires a file path, asset path, or other identifier, making the tool difficult to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the widget hierarchy' which is a specific verb and resource, and it specifies the types of blueprints it operates on (UWidgetBlueprint or UEditorUtilityWidgetBlueprint), distinguishing it from sibling tools like inspect_widget_blueprint.
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 reading widget hierarchy of specific blueprints, but it does not provide explicit guidance on when not to use it or mention alternative tools like edit_widget_tree or other inspect tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects and implications. It only states the basic action without explaining what 'wires to the live actor' entails, required permissions, or failure cases. 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 a single sentence that front-loads the core action. It is concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has low complexity (2 required params, no nested objects), the description omits contextual details like return behavior or error conditions. Adequate but not comprehensive for an action that modifies assets.
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 100%, so the parameter descriptions already provide meaning. The tool description adds no extra semantic value beyond what's in the schema, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('add'), the resource ('level actor as a possessable binding to a Level Sequence'), and what it accomplishes ('creates the binding GUID and wires it to the live actor'). This distinguishes it from sibling tools like spawn_actor or add_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or exclusions. For a tool that modifies sequences, explicit context about preconditions (e.g., sequence must exist, actor must be in level) is missing.
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 discloses selection and viewport framing but omits side effects (e.g., changing selection state), prerequisites, or error handling for non-existent actors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with the action. 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 tool with one parameter and no output schema, the description covers the basic action but lacks completeness regarding error states (e.g., actor not found) and behavioral nuances.
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%, but the description adds that the 'name' parameter accepts a label or unique name, which provides useful clarification. However, no format or examples are 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 'select' and 'frame the editor viewport' on an actor, distinguishing it from sibling tools like 'bulk_focus_actors' (bulk operation) and 'delete_actor' (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'find_actors_by_class' or 'get_selected_actors'. The context is implied but not explicitly stated.
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 convey behavior fully. It states 'Read structure,' implying read-only, but does not explicitly declare no side effects or discuss error conditions (e.g., invalid path, unloaded asset). Behavior is partially transparent but lacks completeness.
Agents need to know what a tool does to the world before 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 efficiently communicates the tool's action and output components. No redundant words, and the verb 'Read' is first.
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 tool, the description covers the essential purpose and output. However, it omits context like expected error handling, whether the asset must be loaded, or if the output is hierarchical – information that would be helpful for an agent unfamiliar with the domain.
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 single parameter 'path' is fully documented in the schema with a clear description. The tool's description adds no extra parameter semantics beyond listing output fields, which is not required given high 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 reads the structure of a Level Sequence asset and lists specific components (tracks, sections, bindings, frame rate, playback range). It distinguishes from generic inspect_asset and other sequence tools, though a more explicit differentiation from sibling inspect_* tools would strengthen 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?
No guidance on when to use this tool versus alternatives like inspect_asset or other sequence-focused tools. The description does not mention prerequisites, limitations, or typical use cases, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states creation and parent setting but omits critical details: whether overwriting existing assets is allowed, error conditions, required permissions, or any side effects. This is insufficient for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core action without unnecessary words. It is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being concise, the description lacks completeness for a creation tool. It does not explain default properties, naming conflict handling, or post-creation steps. Given no output schema or annotations, more context is expected.
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 100% coverage with descriptions for each parameter. The description adds no extra semantic information beyond what is already in the schema, so the baseline score of 3 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 the verb 'Create' and the specific resource 'UMaterialInstanceConstant asset', along with the action of setting its parent. This distinguishes it from other tools on the server, none of which create material instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the basic purpose but offers no guidance on when to use this tool versus alternatives (e.g., set_mi_parameter for modifying an instance). No when-not-to-use or alternative suggestions are included.
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. Description does not mention side effects (e.g., closing current level, unsaved work) or required privileges, leaving potential risks unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with example, no redundancy. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description is too sparse. Lacks behavioral context and error conditions for a potentially destructive operation.
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?
One parameter with type string; description adds an example path format. Schema has 0% coverage, so example adds some value but no constraints or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb (Load), resource (UE level), and parameter (package path) with an example. Distinguishes from siblings like list_levels.
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 when-to-use or alternatives, but context implies loading a level. Lacks guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states 'Create' implying a write operation, but does not mention side effects like asset overwriting, permissions, or what happens on name conflicts. The behavioral detail is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no extra words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters fully described in schema and no output schema, the description provides adequate context for a creation tool but lacks details on success feedback or performance. It is minimally 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 100%, so baseline is 3. The description adds slight value by mentioning 'empty MovieScene' and mapping 'display frame rate' and 'playback end-frame' to parameters, but does not significantly enhance 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 creates a new Level Sequence asset, initializing an empty MovieScene with specific parameters. This distinguishes it from sibling tools like inspect_sequence or sequencer_add_transform_keyframe.
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 a new sequence, but lacks explicit guidance on when to use this tool vs alternatives, or exclusions such as overwriting behavior or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It adds only that multi-line scripts are allowed, but omits critical information such as side effects, error handling, execution context, return values, or potential risks of running arbitrary code.
Agents need to know what a tool does to the world before 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, front-loading the verb and resource with no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core purpose and an important support detail (multi-line). However, it does not address return values, error states, or clarify behavior relative to sibling tools like exec_python_persistent.
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 already describes the 'code' parameter as 'Python source to execute', but the description adds the valuable detail that multi-line scripts are allowed. With 100% schema coverage, this extra information justifies a score above baseline.
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 that the tool executes arbitrary unreal.* Python code in the editor's embedded interpreter, and labels it as a 'universal escape hatch'. However, it does not explicitly distinguish this tool from similar siblings like exec_python_persistent or run_python_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a fallback via the phrase 'universal escape hatch', but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'canonical UE asset import pipeline' but does not disclose side effects such as file overwrite behavior (handled by replace_existing, not described), disk writing, or error handling. For a mutation tool without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that conveys the core functionality without extraneous words. Every part is meaningful and 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 is adequate for basic understanding, but with 6 parameters and no output schema or annotations, it lacks details on parameter interactions (e.g., automated, save), success/failure return values, and advanced import scenarios. It covers the essentials but misses some behavioral context.
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 100%, so the baseline is 3. The description adds value by listing supported formats (not in schema), but does not elaborate on individual parameters like 'automated' or 'save' defaults beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('Import an image file'), the input formats (PNG/JPG/EXR/TGA/BMP/HDR), the asset type (UTexture2D), and the use of 'canonical UE asset import pipeline', clearly distinguishing it from siblings like 'configure_texture' or 'convert_hdri_to_cubemap'.
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 basic usage (when to import a texture), but lacks explicit guidance on when not to use this tool versus alternatives like 'configure_texture' for post-import settings or 'marketplace_import' for marketplace assets. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states 'Mutate' implying changes, lists ops, and mentions the compile parameter note from schema. However, it does not disclose potential side effects, required permissions, or failure modes, so transparency 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 extremely concise at two sentences, with the first sentence immediately stating the purpose and operations. Every sentence earns its place without any fluff.
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 (9 parameters, 3 operations, no output schema), the description lacks crucial context such as what the result of each operation is, error scenarios, or how changes persist. The compile note is only in the schema. Therefore, completeness is poor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 89%, so the schema already documents most parameters well. The tool description adds the operation enum list but little else beyond what the schema provides. Baseline 3 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 mutates a widget tree, lists the three operations, and references a specific use case (UE 5.7 EUW WidgetTree population). This effectively distinguishes it from sibling tools like inspect_widget_tree and other non-editing 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 provides the operations but does not explicitly state when to use this tool versus alternatives. It offers a brief note on the compile parameter regarding batching, but lacks broader usage 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 provided, so the description carries full burden. It mentions triggering a command and output path but does not disclose side effects, permissions, or whether it is read-only. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First explains the action, second provides output path and parameter detail. 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 tool with one optional parameter and no output schema, the description covers the essential: action, output location, and parameter range. Could benefit from clarifying the difference from regular screenshot but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds value by stating the multiplier is optional with range 1-8. This clarifies usage beyond the schema which only shows 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?
Clearly states it triggers UE's HighResShot, specifies output path (Saved/Screenshots/<Platform>Editor/), and describes the parameter multiplier range. Differentiates from sibling screenshot tools by name and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_viewport_screenshot or screenshot_actor. The description implies high resolution but does not state conditions 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 carries the full burden. It mentions execution on the game thread in the editor world context, which is helpful. However, it does not disclose potential destructive side effects, permission requirements, or that commands may alter the editor state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly efficient, and front-loaded with the core action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential complexity and lack of output schema, the description is adequate but incomplete. It covers the basic function and execution context but omits safety warnings and details about return value format.
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 100%, so the description adds minimal extra meaning. It supplements with command examples but does not explain parameter formats beyond the schema. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 runs a UE console command, provides concrete examples ('stat fps', 'r.ScreenPercentage 50'), and notes the optional output capture. This distinguishes it from siblings like 'set_console_variable' and 'execute_unreal_python', which are more 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 does not explicitly guide when to use this tool over alternatives. Context from sibling names suggests differentiation, but no direct 'when to use' or 'when not to use' advice 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 behavioral traits are disclosed beyond the basic action. For a read-only operation like a screenshot, it is likely safe, but this is not stated. No annotations are provided to rely on.
Agents need to know what a tool does to the world before 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 communicates the essential information without any wasted words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully specifies the tool's action and output format. It mentions the active editor viewport and base64 encoding, which is sufficient.
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 (empty properties), so schema coverage is 100%. The description does not need to add parameter info. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures the active editor viewport as a PNG and returns it base64-encoded. It distinguishes from similar tools like screenshot_actor (captures specific actor) and take_high_res_screenshot.
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 screenshot_actor or take_high_res_screenshot. The agent must infer from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It correctly indicates a read-only query operation and mentions the default limit and max limit. However, it does not discuss error handling, performance, or pagination beyond the limit parameter. For a query tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before 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 concisely convey purpose, filters, and return format. No filler words or redundant information. Every sentence is essential 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 no output schema, the description mentions return fields (name, package_path, class, tags) which is sufficient. It also includes version notes for tag parameters. Missing details like whether results are sorted or paginated, but overall complete for a query tool.
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?
Input schema covers all 6 parameters with 100% description coverage. The description adds value by summarizing the filter categories and mentioning the return fields. This is helpful context but not necessary beyond the schema. Score is baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the asset registry by class and optional filters (path, name, tags). It returns structured records with specific fields. This distinguishes it from sibling tools like find_actors_by_class (focuses on actors) and inspect_asset (single asset inspection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to find assets by class and filters, but lacks explicit guidance on when to use this vs alternatives like find_actors_by_class or find_unused_assets. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It correctly states it returns data for all actors (no mention of destructive behavior) but does not disclose potential performance impact of returning many actors or that it reads from the active editor world. Adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load main purpose and optional filter. No redundant words. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional param and no output schema, the description is sufficient. It covers scope, return fields, and filter. Could be enhanced with guidance on when to use this vs siblings, but overall 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?
Schema coverage is 100% with one parameter described. The description adds 'Optional' but does not add meaning beyond the schema's 'Substring filter on actor label'. Baseline 3 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 returns name/class/transform for every actor in the active editor world, with an optional name filter. This distinguishes it from siblings like 'find_actors_by_class' (returns references by class) and 'get_selected_actors' (only selected).
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 listing all actors with optional name filter but does not explicitly mention when to use this tool over alternatives like 'find_actors_by_class' for class-based search or 'get_selected_actors' for working with selections. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states it reads data, but does not cover edge cases (e.g., invalid path, missing asset), performance, or safety implications. It lacks behavioral depth beyond the basic read 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 a single, well-structured sentence of 22 words. It is front-loaded with the key verb and resource, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description enumerates the returned data (class, tags, dependencies, file size) which is helpful. However, it omits error handling, format details, and behavior for non-existent assets. Still, for a simple read tool, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter with a clear description including examples. The tool description adds no new parameter information; the schema already provides adequate semantics, so baseline score of 3 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 specifies the action ('Read everything'), the resource ('a single asset'), and explicitly lists the returned data (class, tags, dependencies, file size). This clearly distinguishes it from sibling tools like 'bulk_inspect_assets' or asset-type-specific inspectors.
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 states it is for a single asset, allowing inference of when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., for detailed type-specific info use other inspectors).
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?
Read operation is clear, but with no annotations, description carries full burden. It doesn't disclose error handling (e.g., invalid path), permissions, or if operation is safe for concurrent use. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys precise scope with no redundancy. Perfectly concise for the information provided.
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, description lists all return categories, which is helpful. However, it lacks detail on the format or structure of each item (e.g., variables list, compile status enum). Slightly incomplete for a tool with one parameter.
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 covers 100% of parameters with descriptions. Description adds context about what the tool returns but doesn't elaborate on parameter format or constraints beyond schema. Baseline 3 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?
Description uses specific verb 'Read' and lists concrete resources: parent class, declared variables, function/event graph names, compile status. Clearly distinguishes from sibling inspect tools (e.g., inspect_asset, inspect_anim_blueprint) by detailing exactly what it returns.
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?
Description implies use when needing Blueprint internals, but no explicit guidance on when to prefer this over similar tools like inspect_asset or audit_blueprint_compile_status. No exclusion criteria or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the synthetic handler and error conditions but does not explicitly state that the tool is read-only 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but somewhat verbose with technical terms like 'stringified Text values' and 'dir() permissive enumeration' that may not be necessary for an AI agent. It could be 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?
Given the tool has only one parameter and no output schema, the description enumerates all expected return values and error conditions, making it largely complete for an inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context beyond the input schema by providing an example path and noting that the path must be non-empty. Since schema coverage is 100%, the description enhances 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 the tool inspects a UMaterialFunction by package path and lists the specific returned fields. This differentiates it from sibling tools like inspect_material or inspect_material_instance which inspect different asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions error handling (ok=False envelopes) but does not explicitly state when to use this tool versus alternative inspect tools. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavioral traits: it reads structural properties (stateless), handles LazyOnDemand caveat, emits conditional fields for editor-only data, and mentions C++ handler with no Build.cs deps. This provides good transparency beyond the basic read 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 a single dense paragraph listing many properties. While front-loaded with the purpose, it lacks bullet points or sections for better readability. It is adequate but could be more concise and 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?
Despite no output schema, the description covers all key aspects: properties returned, conditional/editor-only fields, and the LazyOnDemand handling. It is mostly complete, though it could mention error scenarios for invalid paths.
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 100% coverage on the single parameter 'path' with a clear description. The tool description does not add further meaning to the parameter beyond what the schema provides, maintaining the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read structural properties of a USoundWave asset', using a specific verb and resource. It explicitly lists the properties and distinguishes from siblings (e.g., inspect_audio_bus, inspect_sound_cue) by focusing on USoundWave-specific attributes.
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 provide explicit guidance on when to use this tool vs alternatives. It implies usage for inspecting sound wave details but lacks when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Read structural properties' implying read-only, but does not disclose error handling, edge cases, or exact return format. Adequate but could be more explicit.
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 concise at a few sentences, listing many relevant properties without redundancy. Could be slightly tighter, but effectively communicates the tool's scope.
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?
With no output schema, the description lists properties read but does not explicitly state the return format (likely JSON). It provides sufficient detail for a read tool, but missing output structure information.
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 100% with a single well-described parameter. The description adds context about the asset type and properties read, but adds little beyond the schema description. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 structural properties of UTexture assets, lists many specific properties including UTexture2D-specific ones, and distinguishes itself by pairing with configure_texture and import_texture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly pairs with configure_texture (mutates) and import_texture (creates), giving context on when to use this read-only tool vs alternatives. However, it doesn't exhaustively differentiate from other inspect_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains value shapes but does not disclose side effects (e.g., persistent save, permissions, reversibility). The mutation behavior is implied but not elaborated.
Agents need to know what a tool does to the world before 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 redundant information, directly states purpose and value mapping. Very efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the tool's straightforward nature, the description covers the essential usage. However, it could mention that the change takes effect immediately or requires saving.
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 100%, and the description mostly repeats the schema's information about value shapes. It adds little new meaning beyond what is already in the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it overrides a parameter on a UMaterialInstanceConstant, specifying the three parameter types and value shapes. Distinguishes from sibling tools by focusing on mutation rather than inspection or creation.
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 when-to-use or when-not-to-use guidance. The context of sibling tools implies it is for overriding parameters, but the description lacks prerequisites (e.g., material instance must already exist) 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?
Given no annotations, the description should disclose behavioral traits. It mentions runtime attachment, optional socketing and transforms, but omits side effects (e.g., does it overwrite? fail conditions?), permission needs, or return behavior. 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?
Single sentence, 25 words, front-loaded with the core purpose. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, a nested object, and no output schema or annotations, the description covers the main action and optional features but lacks details on defaults (e.g., auto-naming), failure modes, and behavior of attach_to and socket parameters. Adequate but incomplete for a mutation tool.
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 100%, so the description adds minimal new meaning beyond the schema. The phrase 'optionally socketed and transformed relative to a parent component' corresponds to socket and relative_transform, but no deeper semantics are provided. Baseline 3 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 the action (attach), the resource (component to actor), the context (runtime, optionally socketed and transformed), and is distinct from all sibling tools, which focus on inspection, deletion, or bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding components at runtime with optional socketing and transforms, but does not explicitly state when not to use it or suggest alternatives. However, the narrow purpose and lack of similar sibling tools make the guidance 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?
With no annotations, the description carries the full burden. It states the tool performs a prefix-search and returns specific data (names, types, flags), but does not disclose whether the operation is read-only, its performance implications, or any side effects. The implementation detail about C++ handler adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences covering purpose and pairing context. The third sentence about the language-shim experiment (PR #46) is extraneous for tool invocation and could be omitted for conciseness.
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?
Without an output schema, the description adequately explains the return values (names, types, read-only flags). It also provides workflow context by pairing with related tools. However, it lacks mention of error handling or performance limits beyond the schema's 'limit' parameter.
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?
Input schema has 100% description coverage for both parameters (prefix, limit). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 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 performs a prefix-search on the IConsoleManager registry and returns CVar names, types, and read-only flags. It distinguishes itself from sibling tools like get_console_variable and set_console_variable by focusing on discovery via prefix matching.
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 pairs this tool with get_console_variable and set_console_variable for discovery workflows, indicating when it should be used. However, it does not mention when not to use it or contrast with other sibling tools like bulk_set_console_variables.
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 fully carries behavioral disclosure. It explains the tool is a synthetic bridge handler, enumerates error categories (logical errors with ok=False, transport errors as JSON-RPC errors), and describes the return structure. This provides clear expectations 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 concise (3 sentences) and front-loaded with the main purpose. The second sentence about synthetic handler is internal detail that may be unnecessary, but overall it is efficient without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and the tool's complexity, the description covers the purpose, returned data fields, error handling, and internal composition. It is sufficiently complete for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with a well-described 'path' parameter. The description adds no extra semantic detail beyond what the schema already provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a USoundSubmix by package path, listing specific return fields (leaf class name, parent, children, etc.). It distinguishes from many sibling inspect tools by targeting a specific asset type.
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 guide when to use this tool over alternatives. It explains internal composition and error handling, but lacks direct usage context like 'use this when you need to examine a sound submix asset's properties' or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states persisting to disk (destructive write), but does not disclose potential side effects like overwriting files, permission requirements, or what happens if assets are already saved. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded: first sentence states purpose, second provides analogy and context, third lists parameters. No unnecessary 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?
No output schema, and description does not mention return value or success/failure indicators. It also does not clarify if all dirty assets or only those matching the boolean parameters are saved, nor what happens if no dirty assets exist.
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 100% and both parameters have descriptions. The description only notes they default to true, which is already in the schema. No additional meaning beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it persists in-memory modified assets to disk, uses the analogy 'Same as editor Save All', and explains the context of closing the gap after mutation tools. The verb 'Persist' and resource 'in-memory-modified asset + map' are specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says this tool should be used after edit-side tools that mutate UObjects but leave them dirty, providing a clear usage context. However, it does not mention when NOT to use it or compare to any alternative save tools among siblings, which are absent.
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 injected boilerplate and the output-capture limitation (ExecuteFile mode does not return stdout), which are key behavioral details. However, it does not cover error handling, required permissions, or side effects, leaving some gaps in 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?
Two sentences, no wasted words. The first sentence states the core purpose and available variables, the second provides critical caveat and workaround. Front-loaded with essential information, achieving high conciseness.
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 (wrapper with injected boilerplate), the description adequately covers the purpose, injected variables, and output limitation. No output schema exists, but the caveat points to a workaround (`unreal.log marker + get_log_lines`). Missing some behavioral details (errors, permissions), but overall complete for the tool's scope.
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 100% with one parameter `code`, so baseline is 3. The description adds significant value by explaining that the injected boilerplate makes `selection` and `selected_assets` available directly, which the schema alone does not convey. This enhances the agent's understanding of how to use the parameter effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 runs user Python with the editor's current selection pre-bound, naming the variables `selection` and `selected_assets`. It distinguishes itself from the sibling `execute_unreal_python` by explicitly calling itself a convenience wrapper that injects lookup boilerplate, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the selection context is needed ('convenience wrapper'), but does not explicitly state when to use this vs. alternatives like `execute_unreal_python`. It mentions the same output-capture caveat, linking to a sibling tool, but lacks explicit when-to-use or when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool performs an explicit recompile and that it should be used when no further mutation is needed. However, it does not disclose whether the recompile is synchronous, what happens on failure, or any logging/error behavior. The behavioral description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first identifies the tool's function with technical precision, second provides usage guidance and a sibling reference. No wasted words, information is front-loaded and easily scannable.
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, no annotations, and only two parameters, the description covers the essential context: what the tool does, when to use it, and a related tool. It could mention return behavior or error handling for completeness, but current coverage is good for a simple recompile tool.
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 100% with clear descriptions for both parameters (path and skip_save). The description does not add additional semantic meaning beyond what the schema provides. It mentions pairing with edit_widget_tree's compile flag, which is contextual but not parameter-specific. Baseline 3 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?
Explicitly states 'Blueprint recompile' as the core action, with a specific technical reference (FKismetEditorUtilities::CompileBlueprint). Clearly distinguishes from sibling tools like bulk_compile_blueprints or audit_blueprint_compile_status by focusing on a single, explicit 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?
Provides explicit usage context: use when a Blueprint has been mutated externally via execute_unreal_python and needs recompilation without further mutation. Also mentions pairing with edit_widget_tree's compile flag, offering a related alternative. Does not explicitly state when not to use, but the guidance is clear and actionable.
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 explains the two pathways, their outputs, and that success is based on exit code. Lacks details on system impact, permissions, 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 well-structured and front-loaded with the main purpose. It is slightly lengthy but each sentence adds value, covering both pathways and key details.
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 8 parameters and no output schema, the description covers the two modes adequately but lacks details on failure modes, error messages, or how to interpret the BuildPlugin output (no .pak generated).
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 100%, but the description adds useful context beyond schema, such as how mod_name disambiguates .pak files and that output_dir is required for success verification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool compiles a UE mod plugin to a .pak file via two specific methods (BuildMod or BuildPlugin), headless. It distinguishes itself from siblings like compile_blueprint and compile_mod_pak_direct by detailing the two pathways and their outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use BuildMod (game Dev Kits) vs BuildPlugin (vanilla UE5), including fallback for installed-build mode. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that changes are persisted, triggers UE's PreEditChange/PostEditChange flow, and rebuilds the GPU resource. This goes beyond the basic mutation fact, highlighting resource-intensive side effects. Since no annotations are provided, these behavioral details are essential and well-covered.
Agents need to know what a tool does to the world before 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 redundancy. The first sentence defines purpose and scope, the second adds behavioral context. Every word is necessary; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and 6 parameters, the description covers purpose, behaviors, and side effects adequately. It does not mention return value (likely success/failure), but that is minor for a mutation tool. Overall complete given the complexity.
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?
Input schema has 100% description coverage, so the baseline is 3. The description does not add significant meaning beyond the schema, merely confirming that the listed properties are adjustable. No additional parameter constraints or formatting details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it adjusts SRGB, CompressionSettings, LODGroup, and Filter on an existing UTexture asset, which matches the input schema properties. The verb 'Adjust' and resource 'existing UTexture asset' precisely describe the action, distinguishing it from creation (import_texture) or inspection (inspect_texture) 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?
Implies usage for modifying existing textures (not creating or reading), but does not explicitly state when to use versus alternatives like import_texture or inspect_texture. No mention of prerequisites, when not to use, or specific context beyond asset existence.
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 permanence, refusal when referenced, and force-delete undo implications. This is substantial, though it could mention permissions or logging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, then condition and warning. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity and no output schema, the description covers key aspects: action, conditional refusal, and permanence warning. Minor ambiguity about undoability for non-force deletions, but overall 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 100% with descriptions for both parameters. The description adds context about refusal and force, but the schema already defines 'force' as 'delete even if referenced'. The additional value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 deletes an asset, specifying the verb 'delete' and resource 'asset'. It also adds nuance about referenced assets, which distinguishes it from sibling bulk_delete_assets and delete_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single asset deletion but does not explicitly contrast with bulk or other sibling tools. It provides context on force usage but no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with no side effects. While annotations are absent, the tool's function is inherently safe and non-destructive, so transparency is high.
Agents need to know what a tool does to the world before 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 lists exactly what the tool returns, with no unnecessary words. It is highly concise 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?
For a simple summary tool with no parameters and no output schema, the description is mostly complete. However, it could mention that the output is a summary or specify data types, but overall it suffices.
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 schema coverage is 100%. The description does not need to add parameter information. A baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 retrieves project name, engine version, enabled plugins, and asset counts. This is specific and distinguishes it from sibling tools like inspect_project_setting (which likely provides detailed settings) and get_engine_version (which only returns engine version).
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. Given many sibling inspection tools, it would be helpful to indicate that this is for a quick overview and that more detailed inspection tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the read-only nature implicitly ('Read structural properties'), mentions a null guard for compiled data, and notes no new dependencies. It is transparent about the tool's behavior, though could state 'read-only' explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the tool's purpose and key behaviors. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what properties are returned. It covers the compiled data guard and dependency info. It could mention error handling or return format, but for a one-parameter read-only tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is fully described in the schema (UE asset path notation). The description adds little beyond that, only referencing the path in the context of the C++ handler. At 100% schema coverage, a score of 3 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 'Read structural properties of a UAnimBlueprint asset' and enumerates specific properties like parent class, target skeleton, etc. It distinguishes itself from sibling tools like inspect_blueprint and inspect_anim_montage which handle other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting anim blueprint structural data but does not provide explicit when-to-use or when-not-to-use guidance versus alternatives. It does mention a guard for uncompiled blueprints, which is helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It details implementation (C++ handler, no new deps, null-guards) and specific behavior (EFieldIterationFlags::None to skip super fields). This fully discloses 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It is moderately concise; each sentence adds value. Could be slightly shorter but appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description comprehensively explains return values (row count, sorted row names, per-property details, flags, etc.) and edge cases (null RowStruct guard). It is fully complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema's path parameter description; it only provides an example path. No additional semantics for the parameter are 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 it reads structural properties of a UDataTable, listing specific fields (RowStruct, row count, sorted row names, per-property info, flags, etc.). It is a specific verb+resource set, though it does not explicitly differentiate from sibling inspect tools, the target resource (UDataTable) 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 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 (e.g., other inspect tools for different asset types). It lacks explicit context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It clearly states the tool lists parameter names, implying a read-only operation with no side effects. The behavior is transparent and accurate.
Agents need to know what a tool does to the world before 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, front-loaded sentence with no redundant information. Every word adds value, and it is 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?
For a simple tool with one parameter and no output schema, the description is largely complete. It states the output (list of parameter names), but could further clarify the format (e.g., array of strings) for full completeness.
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 100% coverage for the single parameter 'path' with a description. The tool description does not add additional meaning beyond the schema, so a baseline of 3 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 uses a specific verb ('List') and resource ('parameter names') and explicitly mentions the types (scalar, vector, texture, static-switch). It clearly distinguishes from sibling inspect tools that cover other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool lists parameters from UMaterial or UMaterialInstance, but it does not provide guidance on when to use this tool versus alternatives like inspect_material_instance. No exclusions or context are given.
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 'Atomic snapshot under the registry's lock so the result is internally consistent' and describes return shape. With no annotations, this adds meaningful behavioral context, though it could mention that it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey purpose, filters, behavioral guarantee, and return shape. 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?
No output schema, but description explains return counts and task records. Covers key aspects for a list tool, though the return shape depends on poll_task's documentation.
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?
Input schema provides full parameter descriptions (100% coverage). Description only reiterates 'optional status / type filters and a limit' without adding new 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 'Enumerate all tasks in the FUCMCPTaskRegistry' with optional filters and limit. This distinguishes it from sibling tools like poll_task (single task retrieval) and cancel_task (mutation).
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 listing tasks but does not explicitly state when to use this vs poll_task or other siblings. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds valuable context: 'UE auto-creates a redirector at the source path.' This discloses a side effect and clarifies tool behavior beyond the input 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 two sentences, each serving a clear purpose: first states action and constraint, second discloses side effect. No redundant or 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?
The description covers the core action and a key side effect, but lacks information about return values or error handling. Given no output schema, the agent might need to know what the tool returns (e.g., success, new path).
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 100%, so the baseline is 3. The description does not add new parameter-specific meaning beyond what is already in the schema ('Source asset path.' and 'Destination folder under /Game/ or /Engine/.').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Move'), the resource ('an asset'), and specifies that the leaf name remains unchanged, which distinguishes it from tools like 'rename_asset' and 'bulk_move_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 implies usage for moving a single asset to a different folder, but does not explicitly state when to use this tool versus alternatives like 'bulk_move_assets' or 'rename_asset'. No when-not or exclusion 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?
With no annotations provided, the description discloses a key behavioral trait: 'UE auto-creates a redirector at the old name.' This informs the agent about side effects beyond the rename action, though it omits other potential behaviors like error conditions or required saves.
Agents need to know what a tool does to the world before 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, direct and front-loaded with the action. Every word adds value, and there is no redundancy 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?
For a simple 2-parameter tool with good schema coverage, the description covers the purpose and a key behavioral note (redirector). It lacks mention of return value or error cases, but given the tool's simplicity, it is nearly 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 100% with clear parameter descriptions. The description adds minimal extra meaning—'leaf name' reinforces the path scope, but this is already implicit from the schema's 'path' and 'new_name' constraints. The baseline of 3 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 the action ('rename') and the specific resource ('asset's leaf name; folder unchanged'), which distinguishes it from sibling tools like 'move_asset' (which changes folder) and 'bulk_rename_assets' (batch operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for leaf-name changes without folder relocation, but does not explicitly state when to use this tool versus alternatives (e.g., bulk_rename_assets for multiple assets) 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the composite nature and return value (base64 PNG, actor identity, world location). Could mention that viewport focus is changed as a side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence gives purpose and method, second adds synthetic nature and return details. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite tool with one parameter and no output schema, the description covers purpose, method, and return value. Lacks error handling info, but overall adequate.
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?
Only one parameter 'name' with schema description 'Actor label or unique name to focus on.' Schema coverage is 100%, so baseline is 3. Description adds no extra 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?
Description clearly states it frames the viewport on an actor and captures a PNG screenshot, using specific verb+resource. It distinguishes from sibling tools like focus_actor and get_viewport_screenshot by being a composite.
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?
States it is synthetic and composes focus_actor + get_viewport_screenshot, implying it is a convenience tool. However, lacks explicit guidance on when to use this vs calling the individual tools or bulk variants.
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 carries full burden for behavioral disclosure. It mentions write operations but lacks details on error conditions (e.g., ambiguous name), idempotency, or permissions. The schema hints at an error for ambiguous labels, but the description does not highlight this.
Agents need to know what a tool does to the world before 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 that front-load the core action and add the crucial distinction of relative mode. Every sentence is necessary and 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?
For a tool with 5 parameters and no output schema, the description covers the main purpose and modes. It lacks details on error handling and what happens if all optional parameters are omitted, but overall is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds clarity by emphasizing 'name (label or FName)' and 'absolute and relative modes', providing context beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-action ('Move / rotate / scale') and the resource ('an existing actor by name'). It distinguishes the tool from siblings like 'set_actor_property' by specifically targeting transform properties.
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 both absolute and relative modes are supported, giving clear context on how to use the tool. However, it does not provide guidance on when not to use it or alternatives, such as using 'set_actor_property' for non-transform changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the creation action and mentions 'PropertyCoercion' for properties, but lacks details on error states, required permissions, or side effects like overwriting labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first covers purpose and optional parameters, the second gives class path examples. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters with full schema descriptions and no output schema, the description is reasonably complete. It could mention the return value (e.g., spawned actor reference), but the core functionality is well 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?
Schema coverage is 100%, so all parameters are described. The description adds value by providing class path format examples and explaining that properties are applied via PropertyCoercion, which goes 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 'Create an actor in the current editor world at a location with optional rotation, label, and initial properties.' It specifies the action (create) and resource (actor), and distinguishes from sibling tools like delete_actor or find_actors_by_class by focusing on spawning new 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?
The description implicitly indicates this is for spawning new actors, but does not explicitly state when not to use it or mention alternatives like set_actor_transform for modifying existing actors. Usage context is partially 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?
Without annotations, the description carries full burden. It honestly discloses the destructive nature (deletion), partial success handling, and the synthetic bridge-side nature. It does not detail the exact result structure, but the return of per-path results and aggregate counts is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with essential purpose, then behavioral detail. Every sentence serves a clear purpose without redundancy. Very concise and 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?
No output schema is provided, and the description only vaguely mentions 'per-path results plus aggregate counts' without specifying the structure. Given the tool's complexity (batch operation with potential partial failures), a more detailed result format would improve completeness. However, the behavioral aspects are adequately 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?
Input schema covers both parameters with 100% description coverage. The description adds value by explaining the continue_on_error flag in context of partial success ('partial success is normal'), which goes beyond the schema's description. It also reiterates path normalization rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes multiple assets via a bridge handler, distinguishing it from single delete_asset and other bulk operations. Specific verb 'Delete', resource 'multiple assets', and mechanism 'composing the delete_asset C++ handler bridge-side' make the purpose unmistakable.
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 explains the default behavior (continue on error) and how to change it via continue_on_error=false, providing some usage context. However, it lacks guidance on when to use this tool versus other bulk operations (e.g., bulk_move_assets) or when deletion might be inappropriate (e.g., assets referenced elsewhere).
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 synthetic nature composing two other tools and returns a specific format, but does not mention safety, permissions, or side effects (though read-only is implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first clearly states purpose, second adds implementation detail. No wasted words.
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 zero-parameter, no-output-schema tool, the description fully covers purpose, return format, and implementation context. 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?
Input schema has zero parameters with 100% coverage, so description needs no parameter explanation. Baseline 4 for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Read' and the resource 'level-editor viewport camera transform', distinguishing it from siblings like 'set_camera_transform'.
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 reading camera transform but does not explicitly state when to use this versus alternatives like taking screenshots or setting transforms. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description clearly identifies the tool as read-only ('Read structural properties') and lists returned data (bounds, skeleton, etc.). It does not elaborate on error scenarios or side effects, but for a read operation, the safety profile is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It front-loads the purpose and uses clear bullet-point-style listing of properties. 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 has only one parameter and no output schema, the description fully covers what the tool returns (per-LOD counts, bounds, skeleton, etc.). It provides enough context for an agent to select and invoke it correctly.
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 100% (single 'path' parameter with description). The tool description adds an example path, which is helpful but not essential. The schema itself sufficiently defines the parameter, so the description adds marginal 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?
The description starts with 'Read structural properties of a USkeletalMesh asset', clearly stating the verb and resource. It lists specific properties and distinguishes from sibling 'inspect_static_mesh' with a note on cross-handler consistency, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading skeletal mesh properties but lacks explicit guidance on when to use vs. alternatives. It mentions mirroring 'inspect_static_mesh' for consistency, which hints at use alongside that tool, but no when-not or exclusion criteria 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?
With no annotations, the description carries full burden. It describes the tool as reading structural properties, implying read-only. It mentions 'C++ handler; no new Build.cs deps', offering insight into implementation safety. It does not disclose error conditions or performance but is sufficiently transparent.
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, dense sentence that front-loads the purpose and lists specifics. It is efficient but slightly long due to enumeration. Could be broken into shorter sentences, but overall 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?
Given the complexity of widget blueprint properties and no output schema, the description lists many specific properties (animations, delegate bindings, etc.) making it fairly complete. It lacks mention of return format or pagination but covers essential aspects.
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 100% with one parameter 'path' described as 'UE asset path...'. The description adds context about asset type but does not add significant meaning beyond the schema. Baseline score applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'reads UWidgetBlueprint-specific structural properties' and lists specific items like parent class, compile status, etc. It distinguishes from siblings 'inspect_blueprint' and 'inspect_widget_tree' by noting what each handles.
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 states it 'complements inspect_blueprint and inspect_widget_tree' and suggests cross-linking via shared asset path, providing clear context for when to use this tool. However, no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses synchronous rendering, force behavior, and headless operation. It lacks details on side effects like file overwriting, permissions, or error handling. No annotations are present, so the description carries the full burden.
Agents need to know what a tool does to the world before 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. Key information is front-loaded: verb, resource, output format, and special capability (headless).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, but the description does not mention what is returned (e.g., success/failure, file path). It covers the main behavioral aspects but lacks return-value information, which is important for an agent to handle the tool's response.
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 100% with parameter descriptions. The description adds context by explaining that width/height/camera_label trigger off-screen capture and that fov overrides the current FOV. This goes beyond the schema's individual 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 renders the level-editor viewport or an off-screen SceneCapture2D to a PNG file. It distinguishes itself from sibling tools like 'get_viewport_screenshot' by noting it works headless/backgrounded where deferred screenshots fail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (headless/backgrounded) and when off-screen capture is triggered (width/height/camera_label). However, it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses its read-only nature and that it composes two operations bridge-side. This adds valuable context beyond the schema about its scope and side-effect-free behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states the core action, the second adds critical usage guidance. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the status buckets and hints at the output structure via the compile_failures_only parameter. It is sufficient for a simple enumeration tool, though it could explicitly mention the output format.
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 100% with clear descriptions for both parameters. The description reinforces the path_under parameter but adds no new meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Enumerate') and resource ('Blueprints under a content path') with clear output state buckets. It distinguishes itself from siblings by noting it composes find_assets + inspect_blueprint and is a read-only audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is read-only and no recompile is triggered, and suggests pairing with bulk_compile_blueprints for fixing. This gives clear guidance on when and how to use it, though it doesn't list alternative tools for other scenarios.
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 return structure ('per-path success/failure plus aggregate counts') and error handling behavior ('continue_on_error' stops at first failure). It does not cover potential side effects, but compilation is generally non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description's mention of return shape and error handling is helpful. It covers key behavioral aspects, though it omits edge cases like path validation or skip-if-up-to-date. Overall complete for the tool's simplicity.
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 100%, so baseline is 3. The description summarizes the parameter shape ('paths list + continue_on_error') but does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Recompile multiple Blueprints in one MCP call,' specifying the verb and resource. It distinguishes itself from the single-compile sibling 'compile_blueprint' and aligns with the bulk_*_assets family.
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 notes it is 'Useful after batch-mutating BPs via execute_unreal_python or other tooling,' providing context. Although it does not explicitly name alternatives, mentioning the bulk_*_assets family and composing compile_blueprint implies when to use this tool over single 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?
Discloses that partial failures are isolated per result, and returns per-path data plus aggregate counts. Without annotations, this is valuable behavioral context. Could further mention that it is read-only, but the inspection nature implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with front-loaded purpose, output summary, and an example use case. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description adequately covers purpose, output shape, error behavior, and a typical use case. It could briefly mention the return format structure, but it remains functionally 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?
Input schema has 100% coverage with descriptions for both parameters. The description adds context about 'partial failures isolated per result' relating to continue_on_error, and 'per-path inspection data' relating to paths, but does not significantly augment the schema's explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 inspects multiple assets in one call, distinguishing it from the singular inspect_asset sibling. It also mentions the bulk_*_assets family, reinforcing its role as a batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case (pipeline audits for textures lacking power-of-two sources), implying batch scenarios. However, it does not explicitly state when not to use it (e.g., for single asset inspection), leaving a small gap.
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 details the capture-pre-values, apply, and rollback-on-failure process, including the explicit rollback failure list. Missing permission or side-effect details, but adequate.
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 action, three sentences each adding value. Slightly verbose but not excessive; clear structure.
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 bulk operation with rollback (2 params, no output schema), description covers behavior well but omits return value structure. The mention of rollback failure list implies output, but agency lacks full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds 'Max 50 entries' limit for assignments and 'Default true' for rollback_on_error, plus explains rollback behavior, going beyond 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 sets multiple console variables in one call with atomic rollback, distinguishing it from sibling tools like set_console_variable (single) and get_console_variable (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this over single-setters by emphasizing bulk operation and rollback pattern. It mirrors editor behavior, giving context, but lacks explicit 'when not to use' or 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?
No annotations are provided, so the description carries the full burden. It clearly explains that children are detached (not destroyed) and that the force flag overrides the safety check. However, it does not mention error handling for nonexistent actors or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first establishes purpose and parameter, second clarifies children behavior, third explains force flag. Every sentence adds value with no redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers core behavior (children handling, force flag) and mentions a specific error ('has_children'). It could be more complete by describing the return value or behavior when the actor name is invalid, but it is largely sufficient for a straightforward deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description adds value by explaining the force flag's purpose ('overrides the children-attached safety check') and clarifying that 'name' can be a label or FName. This enriches the schema's minimal 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 specific action ('remove an actor'), the resource ('actor in the editor world'), and the method ('by name (label or FName)'). It distinguishes itself from sibling tools like 'delete_asset' by targeting actors specifically.
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 like 'delete_asset'. While the context implies use for actor deletion, it provides no direct comparison or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: source preservation, destination non-existence requirement, and absence of redirector. This is strong but could mention error handling or 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?
Three concise sentences, each adding distinct value: purpose, key constraints, and behavioral nuance. No redundant or 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?
Given two required parameters and no output schema, the description covers essential behavioral aspects. It could mention return value or async nature, but overall sufficient for usage.
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?
Parameter descriptions in the input schema already provide meaning (source vs. destination paths). The description adds overall context but no per-parameter details beyond the schema, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 copies an asset, preserves the source, requires a non-existent destination, and creates no redirector. This distinguishes it from siblings like move_asset, rename_asset, and delete_asset.
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 (when a copy is needed, destination new) but does not explicitly list when not to use or mention alternative tools. The differentiation from move_asset (source preserved) and rename_asset (no redirector) is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any behavioral aspects such as read-only nature, side effects, or permissions. Since it's a read operation, transparency is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous 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 zero parameters and no output schema, the description sufficiently explains the return value and its use case. However, it lacks information about potential errors or assumptions.
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, but the description adds value by explaining the output structure and the minor_dotted convenience field, which goes 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 returns a structured engine version snapshot with fields like major, minor, patch, changelist, and branch, differentiating it from get_project_summary which returns a single string.
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 advises using this tool when the LLM needs to branch on engine version without parsing a single string, naming the alternative get_project_summary.
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 full burden. It indicates a read operation ('dump') and lists the data returned, but does not explicitly state that the tool is read-only or discuss any prerequisites or side effects. This leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first efficiently details the output, and the second emphasizes its importance. No wasteful or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description adequately covers what is returned and its relevance. It could be slightly improved by explicitly stating it is a read-only operation, but overall it is sufficient.
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 schema coverage is 100% automatically. The description adds no parameter information because none are needed. Per guidelines, baseline is 4 for 0 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 that the tool dumps legacy UInputSettings (action_mappings and axis_mappings with specific fields) and a migration flag. This clearly distinguishes it from sibling inspect tools, which focus on other asset types or aspects.
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 claims this is '#1 context needed before touching gameplay code,' strongly implying when to use it. However, it does not explicitly state when not to use it or compare to alternatives, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden. It discloses read-only behavior, dependency on Niagara runtime, and lazy-loading considerations. However, it does not describe return format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise and front-loaded with the tool's purpose, then implementation details. 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?
The description covers key aspects: what is read, dependencies, and initialization requirements. However, it lacks details on the exact return structure or potential errors, which would improve completeness given no output schema.
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 100% coverage and the description does not add extra meaning beyond the schema (just provides an example path). Baseline 3 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 the tool reads structural properties of a UNiagaraSystem asset and lists specific components (emitter list, user-exposed parameters, system-level settings). It distinguishes from generic inspect tools like inspect_asset.
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 such as requiring the Niagara runtime module and EnsureFullyLoaded(), but does not explicitly contrast with sibling inspect tools or state when to use this over 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?
No annotations provided, so description carries full burden. Describes bulk vs single mode behavior but lacks details on error handling, side effects, or auth needs. Assumed read-only but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence states main purpose and output format. Second explains modes. Third provides context. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, modes, and motivation. Lacks output JSON structure details and error behavior, but schema provides parameter guidance. Adequate for a simple inspection 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 100%, baseline 3. Description adds semantics by explaining that omitting 'property' triggers bulk mode and including it returns single property value. Clarifies that settings_class is a full class path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reflects UDeveloperSettings subclasses and dumps editable UPROPERTY values as JSON. Specifies two modes (bulk/single) and distinguishes from sibling inspect tools by targeting project settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions it closes the gap where LLM had no access to per-system Project Settings, indicating when to use. Does not mention when not to use or alternative 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 full burden. It explains the compact JSON structure with collapsed feature groups when master gates are off, and notes that it is a C++ handler with no new dependencies. However, it does not explicitly state that the tool is read-only with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and front-loaded with the purpose. While relatively long, each sentence provides useful information. Minor redundancy could be trimmed, but overall it earns its length.
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 a single parameter, no output schema, and no annotations, the description fully explains the tool's behavior, including output compression and technical context (C++ handler). It is complete for an inspect tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has 100% schema coverage, but the description adds value by explaining expected asset paths (e.g., /Game/Audio/Atten_Default) and the asset type (USoundAttenuation), enhancing the agent's 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 defines the tool as reading structural properties of a USoundAttenuation asset, listing all covered features (algorithm, shape, spatialization, etc.). It explicitly states it completes the audio introspection trio with siblings inspect_sound_cue and inspect_sound_wave, distinguishing it from those 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 inspecting sound attenuation assets but does not explicitly state when to use this tool versus alternatives. It mentions the 'audio introspection trio' but provides no direct guidance on when to choose this over other inspect tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It details error handling (ok=False envelopes vs JSON-RPC errors), the synthetic bridge implementation, and naming conventions. This is comprehensive for a read-only inspection 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 a single paragraph, but well-structured: start with purpose and returns, then implementation details, naming, and errors. It is slightly dense but every sentence adds value. Could benefit from bullet points for readability.
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 simple input schema (1 param, no enums, no output schema), the description is very complete. It explains the return structure, error modes, and implementation pattern, leaving no gaps for an agent to interpret behavior.
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 sole parameter 'path' is fully described in the input schema (100% coverage). The description adds value by explaining what the path leads to (the USoundClass and its properties) but does not add new constraints or format details 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 inspects a USoundClass by package path and lists all returned fields (leaf class name, parent, children, FSoundClassProperties). It is distinct from other inspect tools which target different asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide guidance on when to use it versus other inspect tools (e.g., inspect_asset, inspect_sound_wave). No when-not-to or alternatives are mentioned, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read behavior ('Read structural properties') and includes a specific null-skip behavior. However, it does not explicitly state that the operation is read-only or mention any side effects, though it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences plus a brief technical note) and front-loaded with the purpose. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides a good list of output properties, including the full graph. It lacks explicit format details but is sufficient for an agent to understand what the tool returns.
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 100% with a clear description for the path parameter. The tool description reinforces the asset type (USoundCue) but does not add significant extra meaning beyond the schema. Baseline 3 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?
Description explicitly states 'Read structural properties of a USoundCue asset' and lists specific properties, providing a clear verb and resource. It distinguishes from sibling inspect tools by naming the asset type.
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?
By specifying the asset type USoundCue, the description implies when to use this tool vs other inspect tools (e.g., inspect_sound_attenuation). It does not explicitly mention when not to use or alternatives, but the context of many inspect tools makes this differentiation 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?
The description states it is a read operation ('Read structural properties') and mentions 'C++ handler -- benefits from native struct access,' hinting at performance. However, with no annotations provided, it lacks details on side effects, idempotency, or auth requirements. A 3 is appropriate as it adds some value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste: first sentence states purpose and outputs, second gives relational context, third adds implementation and experiment note. It is front-loaded and efficiently delivers key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description adequately covers inputs, outputs (via listing), and context (pairings, C++ implementation). It lacks error handling or permissions info, but for a read-only tool it is reasonably complete. A 4 reflects this slight gap.
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 fully covers the required 'path' parameter, and the description adds meaning by listing the returned properties (LOD count, vertex/triangle counts, etc.), which goes beyond the schema. This compensates for the lack of an output schema, scoring a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads structural properties of a UStaticMesh asset and lists specific outputs (LOD count, vertex/triangle counts, bounding box, material slots). It distinguishes from siblings by naming pairing tools (inspect_asset, inspect_material), implying this is for mesh-specific structural data.
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 pairs with inspect_asset and inspect_material, indicating when to use this tool versus those alternatives. It provides clear context for selection, though it does not list all alternatives or state explicit 'do not use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains listing with optional filters but does not mention whether the operation is read-only, performance characteristics, or limits. As a listing tool, it is likely safe, but more explicit detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Front-loaded with purpose and then details. Highly 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?
Given the simplicity of the tool (2 optional parameters, no output schema), the description covers purpose, parameters, and clarifies a common use case. It could mention the return format, but otherwise is sufficient.
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 100% coverage with descriptions for both parameters. The description adds value by stating default values (path_under defaults to '/Game/') and constraints (must start with /Game/ or /Engine/), and that name_contains uses case-insensitive substring matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 enumerates all UWorld assets (levels) in the project, with optional filters. It distinguishes from sibling load_level_by_path by explaining it removes the need to know the package path beforehand.
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 this tool is for discovering levels when you don't know the path, contrasting with load_level_by_path. However, it does not explicitly state when not to use it or mention other 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 full burden for behavioral disclosure. It implies a read-only operation with no side effects, which is accurate. However, it does not mention performance or other traits, but for a simple list, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides sufficient information about what is returned. It could be improved by specifying the format of the output, but it is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. The description does not need to add parameter information. According to the baseline for 0 parameters, a 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 what the tool does: it returns the names of every registered MCP method on the UE server. The verb 'return' and resource 'names of MCP methods' are specific and unambiguous, and it distinguishes itself from sibling tools that perform individual 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 does not explicitly state when to use this tool versus alternatives. It implies usage for discovering available tools, but lacks any guidance on when not to use it or how it compares to other 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?
Without annotations, the description discloses key behaviors: each rename leaves a redirector, it is a synthetic bridge-side handler, and it returns per-entry results with aggregate counts. It could also mention error handling behavior (continue_on_error) which is only in 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 four sentences long, providing essential details without unnecessary fluff. It could be slightly more structured, but it remains concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, behavior (redirector), result shape, and schema distinction. It is complete enough given no output schema, though it does not detail error partiality which is handled by the schema's continue_on_error parameter.
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?
Although the input schema has 100% coverage with descriptions, the description adds value by interpreting what the renames parameter does (per-entry leaf name) and the redirector side effect, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames multiple assets in one call, specifies it uses a list of {path, new_name} objects, and distinguishes from sibling tools by noting the schema differs from bulk_delete_assets and bulk_move_assets.
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 each rename leaves a redirector per UE standards and that results mirror the bulk_*_assets convention, providing context. However, it does not explicitly state when to use this tool versus other rename or bulk 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 full burden. It reveals that the tool composes inspect_asset bridge-side on both paths and excludes the path field from comparison. This is sufficient disclosure for a read-only diff operation, though it omits details about permissions or side effects, which are minimal for a comparison 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 three sentences, each earning its place: first sentence states the core function, second gives use cases, third notes an important exclusion (path field). No redundant or vague language. Information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose, usage, and parameter semantics, it lacks detail on the output format. The tool returns 'fields that differ' but does not describe structure (e.g., key-value pairs, nested vs flat). Given no output schema, this gap could leave the agent unsure how to consume the result. However, for a diff of inspect_asset outputs, the return format is implied by the input schema's field structure, so it is marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (path_a, path_b, fields). The description adds value beyond the schema by explaining that the path field is excluded from comparison and providing guidance on using the fields parameter to scope the diff to a specific subset. This clarifies behavior not captured in 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 performs a symmetric diff between two assets by comparing their inspect_asset outputs. It uses specific verb+resource ('diff' + 'assets') and distinguishes itself from siblings like inspect_asset by explaining it composes two inspect_asset calls and returns only differing fields.
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 use cases: checking what changed between versions of a blueprint or cross-checking duplicated assets. It implies when to use (for symmetric diff) and excludes path field, but does not explicitly state when not to use or list alternatives, though the sibling set includes inspect_asset which could be an alternative for single asset inspection.
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 fully bears the burden. It explains the tool bypasses RunUAT, runs in seconds, produces a .pak for direct deployment, and requires pre-cooked files. It also labels itself as 'SYNTHETIC bridge-side handler'. While it lacks details on failure modes, it still provides substantial 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 concise (about 6 sentences), front-loaded with the core purpose and differentiator. Every sentence adds valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks explicit information about the tool's return value or output format. It says 'produces a .pak' but doesn't specify what the tool returns (e.g., success message, path). Given the tool has no output schema, this omission leaves a gap.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra meaning beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Compile a UE5 mod into a .pak by invoking UnrealPak.exe directly'. It also distinguishes it from sibling tool compile_mod_pak, specifying when to use each. This provides excellent clarity.
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 advises when to use this tool: 'Use when the Dev Kit's RunUAT BuildMod is broken' due to a specific bug. It also contrasts with compile_mod_pak. This offers precise usage 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?
With no annotations provided, the description carries full burden. It details the persistent state mechanism (FPythonCommandEx, Public scope), output-capture caveat (stdout not captured, use unreal.log + get_log_lines), and pairing with reset_python_state. This is thorough 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 a single paragraph that covers key points, but includes minor extraneous context (e.g., 'Tier 2 PR #45') and could be slightly more streamlined. However, it is front-loaded with the most critical information (state persistence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values. It does not explicitly state what the tool returns, but it covers the output-capture caveat, pairing, and persistent globals. Given the simplicity (single code parameter), it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already defines the parameter. The description adds minimal extra context ('persistent globals dict'), but does not enhance parameter understanding beyond stating the execution environment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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's purpose: executing Python code with state persistence across calls. It explicitly contrasts with sibling execute_unreal_python, which does not persist state, making the distinction unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions pairing with reset_python_state to reset state, implying when to use that alternative. However, it does not provide explicit when-not-to-use guidelines or potential side effects of persistent state, such as unintended variable collisions.
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 explains the matching logic (case-insensitive, path stripping) and notes it composes get_actors_in_level. It implies a read-only operation, though not explicitly stated. The behavioral details are adequate for a non-destructive filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding essential information. The purpose is front-loaded, and there is no redundancy or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameters are well-covered, the description omits the return type or format of the results. As a filter tool with no output schema, this is a notable gap. The behavior is simple, but completeness suffers from missing output description.
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 100%, providing a baseline of 3. The description adds value by clarifying that class_name accepts short names or paths, explaining case-insensitivity and path-stripping behavior, which surpasses the schema's 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 filters actors by class, distinguishes it from get_actors_in_level by specifying it composes that tool and matches class names, and provides concrete use cases like 'find every light'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with get_actors_in_level, advising against using it to dump all actors. It gives specific scenarios (finding lights/spawn points). However, it doesn't mention other filtering 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 provided, so description carries burden. Discloses read nature implicitly but does not explicitly state no side effects or if data is cleared. Could be improved by stating it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no extraneous information. Every sentence contributes meaning.
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 read tool with 3 parameters and no output schema, description covers operation, filters, limits, and defaults fully. No 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 100% with parameter descriptions, so baseline is 3. Description adds value by explicitly stating defaults (100), max (1000), and the 'at or above' severity logic, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read' and resource 'UE Output Log entries from the in-process ring buffer', making the purpose explicit and unique 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?
Describes supported filters (category, verbosity) and default/max count, giving clear context for when to use. No explicit alternatives or exclusions needed as no other log tools exist.
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 burden. It clearly indicates a read-only operation ('Read structural properties') and provides implementation detail ('C++ handler; no new Build.cs deps'). It does not specify error behavior or permissions, but for a read 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 three sentences, front-loaded with the purpose. Each sentence adds unique value: list of properties, implementation note, and sibling context. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read inspector with one parameter. The description enumerates all key properties returned (skeleton, length, frame rate, blend envelope, sections, tracks, notifies) and situates it among siblings. No output schema is needed; the description covers what the agent needs to know.
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 100% with a clear description for the single parameter 'path'. The description adds no further semantic detail beyond what the schema provides, so a baseline score of 3 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 uses a specific verb 'Read' and identifies the resource as 'structural properties of a UAnimMontage asset'. It lists concrete properties (target skeleton, play length, etc.) and explicitly distinguishes it from siblings by naming the 'animation introspection trio' with inspect_anim_blueprint and inspect_skeletal_mesh.
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 by stating it 'completes the animation introspection trio', giving context for when to use this tool versus other inspection tools. However, it lacks explicit guidance on when not to use it or any prerequisites (e.g., asset must exist).
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?
Discloses synthetic bridge handler implementation, error handling specifics (logical vs transport errors), and return envelope format. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, implementation, and error handling. No redundant information, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema), the description fully explains behavior, output fields, and error conditions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single 'path' parameter. Description adds no additional meaning beyond what schema provides, so baseline of 3 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?
Description clearly states the action ('Inspect'), the resource ('UAudioBus'), and what is returned (leaf class name, path, channels, UPROPERTYs). The name and content distinguish it from sibling inspect_* 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?
No explicit guidance on when to use this tool versus alternatives. Context is implied by specialization, but no exclusionary or comparative statements.
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 behavioral disclosure. It explicitly says 'read structural properties', indicating a read-only operation. It notes that LandscapeGuid mutates on PIE/instancing while OriginalLandscapeGuid is stable, adding useful behavior detail. No side effects or contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, packing significant detail without unnecessary words. It is front-loaded with the main purpose. While the second sentence is somewhat long, it remains clear and efficient. Minor structural improvement (e.g., bullet points) could enhance readability, but it is still 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 no output schema, the description lists the returned properties (component dimensions, total component count, etc.), giving the agent a clear idea of what to expect. It also addresses lookup nuances. Among many sibling Inspect* tools, it clearly distinguishes itself. Slight omission of output format (JSON vs text) but overall 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 100% with descriptions for both parameters. The description adds value beyond the schema by explaining that the 'guid' parameter accepts either LandscapeGuid or OriginalLandscapeGuid, and clarifies the fallback behavior when both are omitted. This provides richer 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 it reads structural properties of an ALandscape, listing specific properties (component dimensions, total component count, landscape material, bounds, two GUIDs) and explaining lookup methods. It distinguishes itself from sibling Inspect* handlers by noting landscapes have no .uasset, making the purpose very specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool (by actor label or GUID, with fallback to the only landscape). It implies when to use it (for landscape structural properties) and contrasts with sibling Inspect* tools. However, it lacks explicit guidance on when not to use it or prerequisites (e.g., landscape existence), but the context is clear enough for an agent.
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 clearly states 'Read' indicating no side effects, and specifies the returned data (parent + overridden parameters). Missing details on performance or requirements, but the read-only intent is clear.
Agents need to know what a tool does to the world before 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, front-loaded sentence that efficiently communicates the tool's purpose with no wasted words.
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 read tool with one parameter and no output schema, the description completely covers what the tool does and what it returns, meeting all informational needs.
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 100% for the single 'path' parameter. The description adds meaning by specifying it's for a UMaterialInstanceConstant and what values are read, going beyond the schema's generic 'asset path' 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 reads a UMaterialInstanceConstant's parent and overridden parameter values (scalar/vector/texture). It specifies the exact resource and what it retrieves, distinguishing it from sibling inspect tools like inspect_material or inspect_material_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read operation but does not explicitly state when to use this tool versus alternatives like inspect_material or inspect_skeletal_mesh. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full transparency burden. It explains the synthetic handler composition, acceptable input types, error handling (ok=False envelopes), and the scope of enumeration. It lacks explicit mention of read-only nature, but overall is informative.
Agents need to know what a tool does to the world before 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 (7 sentences) and well-structured. Each sentence serves a purpose: returns, synthetic nature, input constraints, limitations, coverage, and error behavior. No wasted words.
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 a single parameter, no output schema, and no annotations, the description covers the tool's behavior, inputs, outputs, limitations, and error cases completely. It is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) and a clear description for the 'path' parameter. The tool description adds no new parameter-specific details, but the context of what the tool does with the parameter is reinforced. Baseline 3 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 the tool inspects MetaSound assets by package path, returns leaf class name, path, and UPROPERTies. It distinguishes between MetaSoundSource and MetaSoundPatch, and explicitly mentions what is not covered (graph structure). Purpose is highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets expectations by clarifying that graph structure is not reflected, requiring a dedicated traversal pass. It does not explicitly compare to sibling tools like inspect_asset, but the context is clear enough for an agent to decide between this and more generic inspectors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and thoroughly explains synthetic bridge-side handler, HTTPS fetch, no auth, no API key, and CC0 asset licensing details, ensuring behavioral transparency.
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 verbose with extensive licensing details, which though valuable, could be condensed. It is well-structured but slightly wordy.
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?
Covers most aspects but lacks detail on the output structure ('normalised list') and how results integrate with marketplace_import. Adequate given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining search behavior (matches name/tags/categories), default behavior for empty query, and defaults for source, asset_type, and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 free CC0 asset marketplaces (Polyhaven, AmbientCG) for textures/HDRIs/models and returns a normalized list, distinguishing it from sibling marketplace_import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (searching CC0 assets), notes licensing distinctions, and suggests pairing with marketplace_import. Missing explicit exclusions but covers key usage scenarios.
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: non-blocking, returns registry snapshot, never waits, lists possible statuses, and explains result/error population. Lacks clarification on invalid task_id handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. 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 simplicity (one param, no output schema), the description covers purpose, behavior, statuses, and result/error conditions completely. No gaps identified.
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 100%, so baseline is 3. The description adds 'Task id returned by start_*_task' which is already in the schema description, providing no new 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 uses a specific verb 'read' and resource 'current state of a task started via any start_*_task handler', clearly distinguishing it from siblings like list_tasks and cancel_task. It also highlights the non-blocking nature.
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 states when to use: to read the state of a task. It notes non-blocking behavior, implying it's safe to call. It does not explicitly mention when not to use or suggest alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: non-historical event capture, no TTL, and return type. It omits potential side effects but is otherwise transparent for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences. The first immediately states the core purpose, the second adds behavioral nuance, and the third covers TTL. No redundant information.
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?
Despite no output schema, it specifies the return type (FGuid string) and explains cursor behavior, TTL, and relationship with siblings. This is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a clear description of event_filter (substring-match, OR-combined). The description does not add further detail, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a server-side cursor and filter on the event bus, returning a subscription_id. It distinguishes itself from siblings like poll_subscription and unsubscribe by naming them explicitly.
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 that the cursor starts at the current next_seq, so only future events are captured, and that subscriptions have no TTL (need manual unsubscribe). This provides clear context for when to use and how to manage lifecycle, though it doesn't explicitly list 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 the transparency burden. It explains the composition (screenshot_actor -> focus_actor + get_viewport_screenshot) and describes the delay_ms behavior (sleeps between actors). It misses potential side effects like viewport changes, but the given details are adequate for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core function, and the second provides context and comparison. It is well-structured and 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 no output schema, the description does not mention what the tool returns (e.g., file paths or success status). While it describes the process, the lack of output information leaves the agent uncertain about the result. This is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: for 'names', it adds a 50-entry cap and comparison to bulk_focus_actors; for 'delay_ms', it specifies default, max, and the behavioral note about sleeping between actors (not after last). This exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 frames and screenshots each actor in a sequence, explicitly distinguishing it from the sibling bulk_focus_actors by noting it always captures a PNG. It also explains the composition of screenshot_actor, providing a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for thumbnail pipelines needing deterministic centered shots. It compares to bulk_focus_actors, offering some guidance. However, it does not explicitly state when to avoid this tool or suggest alternatives beyond the sibling comparison.
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 that it composes set_actor_property, mirrors bulk_*_assets shape, each assignment has own triple, and continue_on_error defaults true. Explains per-assignment failure behavior. Lacks details on atomicity or response structure, but adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, well-structured: starts with purpose, then relates to siblings, clarifies what it is NOT, and gives usage context. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, usage, parameter constraints, and error behavior. Could mention success/failure response format, but overall sufficiently complete for a bulk tool with 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 coverage is 100%, so baseline is 3. Description adds significant value: clarifies max 200 entries, each actor/property non-empty, and explains continue_on_error behavior. Adds constraints and context beyond 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 uses a specific verb-resource combination ('apply many UPROPERTY mutations') and clearly distinguishes itself from set_actor_property and the bulk_*_assets family by explaining the composite nature and per-assignment structure.
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?
States clear usage context: 'useful after batch-spawning to push initial-state mutations without N round-trips.' Explicitly clarifies it is NOT 'set the same property on N actors' but individual sets. Could mention when to use alternatives, but provides good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool updates consumers and deletes stubs, indicating destructive behavior. However, it does not mention reversibility, partial failures, or safety of re-running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero fluff. First sentence states action, second specifies context, third relates to editor. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single parameter, the description adequately explains the tool's purpose, usage, and parameter rationale. Missing details like error handling or idempotency, but sufficient for a simple 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 description coverage is 100%, but the description adds context: 'Required to avoid accidentally rewriting an entire project.' This provides safety rationale beyond the schema's parameter 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's action: cascade-update consumers of UObjectRedirector assets and delete stubs. It distinguishes itself from siblings like bulk_fix_redirectors by specifying it operates under a folder. The verb 'fix_up' and resource 'redirectors' 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 explicitly states when to use: after move_asset/rename_asset workflows. It also mirrors editor functionality. However, it does not provide explicit when-not-to-use or alternative 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?
Discloses BFS traversal, depth bound (default 3, max 8), composition of inspect_asset recursively, and direction behavior. Lacks details on cycle handling or performance, but provides sufficient 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?
Two concise sentences front-load the core action and add directional guidance without unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description mentions returning 'every node and edge' but not the format. However, context is adequate for a graph traversal tool with well-explained inputs.
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 100%, so baseline is 3. Description adds value by explaining the BFS algorithm context and the practical use of each direction, which goes beyond 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?
Clearly states it walks the asset reference graph BFS from a root, returning nodes and edges up to a depth bound. Distinguishes direction=up and direction=down with specific use cases, differentiating from sibling tools like inspect_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use each direction: direction=up for impact-of-change analysis before deletion/renaming, direction=down for dependency audits before packaging. Does not explicitly state when not to use, but context is clear.
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?
The description extensively covers behavior: shallow reflection, non-recursive stringification of nested types, error modes (logical vs transport), and synthetic composition of other tools. With no annotations, this fully informs 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 detailed and informative, but slightly verbose with implementation details (PR #92, marker pattern). However, it is well-structured with clear sections for purpose, behavior, and error handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields (class, parent class, path, property list) and error handling. It covers enough context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a clear description of the 'path' parameter. The tool description adds context about its use for UDataAsset and the shallow reflection process, enhancing 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 the tool performs a shallow reflection on a UDataAsset, returning specific fields. It distinguishes from sibling tools like inspect_asset or inspect_data_table by specifying the target type and shallow nature.
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 UDataAsset inspection but lacks explicit guidance on when to choose this tool over alternatives like inspect_asset or other specialized inspectors. No when-not-to-use or alternative recommendations.
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 fully covers behavior: it's a C++ handler with no new dependencies, and it null-skips TObjectPtr entries (lesson from PR #55->#57). This is explicit and helpful.
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 dense but well-structured, listing specific items. It could be slightly more concise, but it effectively communicates the tool's capabilities without being overly verbose.
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 simple input (one path parameter) and no output schema, the description thoroughly explains what the tool returns (structural properties, subsets, profiles) and how it relates to a sibling tool. It is fully 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?
There is only one parameter 'path' with 100% schema coverage. The description adds no extra meaning beyond what the schema provides, so a baseline score of 3 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 reads structural properties of a UPhysicsAsset, listing specific components like body setups, constraint setups, and profiles. It differentiates from the sibling 'inspect_skeletal_mesh' by noting they pair via a shared preview skeletal mesh path.
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 mentions pairing with 'inspect_skeletal_mesh', implying when to use it (for physics assets). However, it does not explicitly state when not to use it or provide alternatives beyond that pairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It reveals that the per-subscription cursor advances atomically, ensuring no duplicate events are returned on successful polls. It also states that the filter is immutable after registration. This is good, but it could mention error handling or what happens if subscription_id is invalid.
Agents need to know what a tool does to the world before 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 sentences, all essential. The first sentence states the core action, the second explains the cursor behavior, and the third clarifies constraints. No unnecessary words, and the most important information comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, constraints, and behavioral guarantees. It doesn't describe the return format (e.g., array of events), but given that there is no output schema and the parameters are simple, the description is largely complete. A slight addition about return structure would make it a 5.
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 already describes both parameters with 100% coverage. The description adds value by explaining why two expected parameters (since_seq, event_filter) are absent, clarifying server-side management. This contextual insight goes beyond what the schema provides, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 drains events for a server-side subscription, using specific verb and resource. It distinguishes itself from sibling tools like poll_events by clarifying that cursor and filter are server-managed, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to not use this tool: it explains that there is no since_seq parameter (cursor is server-side) and no event_filter parameter (filter is set at registration). This tells the agent to re-register for a different filter. However, it doesn't compare directly to other polling tools, which would elevate to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It offers extensive behavioral details: the types supported, dotted-path syntax for nested properties, the polymorphic nature of the value parameter, and a version limitation (FInstancedStruct deferred). This far exceeds typical descriptions.
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 relative to the amount of information conveyed. It front-loads the main action and then lists supported types and limitations. While slightly long, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains input semantics and supported types. It mentions common UE structs but doesn't enumerate them all, and the sibling list provides context (e.g., bulk_set_actor_property). This is sufficient for a developer familiar with Unreal Engine.
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 covers all three parameters with descriptions (100% coverage). The description adds significant meaning beyond the schema: it explains dotted-path syntax for the property parameter, the polymorphic coercion logic for value, and the rationale for the value schema design. This provides crucial context 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 explicitly states the tool mutates a UPROPERTY on an actor, lists supported types (primitives, structs, enums, TSoftObjectPtr, etc.), and mentions dotted-path syntax for nested properties. This clearly distinguishes it from siblings like bulk_set_actor_property or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like bulk_set_actor_property. It notes a limitation (FInstancedStruct deferred to v0.4.x) but does not state use cases or exclusions. Usage is implied through the tool's purpose.
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 explains that the source is preserved and a new copy is created, and that it returns per-entry results plus aggregate counts. This covers key behavioral traits, though details like error handling or side effects are not fully expanded.
Agents need to know what a tool does to the world before 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 paragraph that efficiently communicates the core function, key differences, return format, and implementation detail. 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 output schema, the description explains return format, key behavioral differences from related operations, path constraints, and error handling. It is sufficiently comprehensive for an agent to understand the tool's behavior and 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?
Input schema has 100% coverage, but the description adds value by explaining that dest_path is a full destination path (not a leaf name) and adding constraints about non-empty strings, no NUL byte, and no '..' segment. This enriches 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 'Duplicate multiple assets in one call' and distinguishes from siblings like bulk_rename_assets by explaining the difference in path handling. It also notes that it's a synthetic bridge-side handler, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts with rename/move by noting that duplicate does not leave a redirector and explains the dest_path vs new_name difference. However, it does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear but could be more directive.
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 fully carries the burden. It discloses that each move leaves a redirector at the source (UE standard), returns per-path results plus aggregate counts, and defaults to continuing after individual failures with option to stop on first failure. This provides sufficient 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 concise (4 sentences), front-loaded with core purpose, and each sentence adds unique value. No redundant or filler content.
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?
Despite lacking annotations and an output schema, the description covers all necessary behavioral details: redirector semantics, error handling strategies, return structure, and relationship to sibling tools. This is comprehensive for a multi-asset move 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?
All parameters have schema descriptions (100% coverage). The description adds value by explaining path rules (same as bulk_delete_assets), that dest_folder applies uniformly, and the detailed behavior of continue_on_error. It also notes the shape similarity to a sibling tool, aiding interoperability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Move' and resource 'multiple assets', specifies the single destination folder, and distinguishes itself from the sibling 'move_asset' tool. It also notes it mirrors 'bulk_delete_assets' shape, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (bulk move to one folder) versus alternatives (for per-asset destinations, call move_asset directly). It also mentions the default behavior of continuing on error and how to change it. However, it does not explicitly state prerequisites or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description details return behavior: returns first `limit` unused assets and a `truncated` flag, and explains scan halting logic. Missing explicit read-only statement but clearly non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, composition+use case, return behavior. 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?
Covers main behavior and output structure (unused assets + truncated flag) despite no output schema. Could clarify exact output format but acceptable given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). Description adds significant value: default '/Game', recursive hint for path_under; default 100, max 10000, and scan halting behavior for limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 enumerates assets and reports those with zero referencers, distinguishing it from siblings like find_assets and inspect_asset via composition hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Useful for content cleanup audits before shipping.' Does not detail when not to use, but context implies alternatives for simple listing or inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It states the exact output (name/label/class/transform of every selected actor). While it doesn't discuss edge cases like empty selection, the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core functionality, zero wasted words. Efficient and clear.
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 zero parameters and no output schema, the description fully covers the tool's inputs, outputs, and the intended usage pattern as a companion to another tool. No gaps identified.
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 schema coverage is 100%. Description adds nothing beyond the empty schema, but baseline for 0 parameters is 4 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 returns selected actors' properties (name/label/class/transform). It distinguishes from siblings like 'get_actors_in_level' by specifying selection context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as a companion to 'apply_python_to_selection', guiding the agent to use it before acting on selections. Does not list exclusions or alternatives but provides clear context.
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 the full burden. It states the tool reads structural properties (non-destructive), mentions it's a C++ handler with no new dependencies, and details the exact information returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It provides essential details in a well-structured manner with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the single parameter and no output schema. It explains the return values thoroughly, covering curve class, channel count, time/value ranges, and per-channel info.
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 100% for the single parameter 'path', with description 'UE asset path of a UCurveBase'. The tool description does not add additional meaning beyond the schema, so baseline 3 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 explicitly states the tool reads structural properties of a UCurveBase asset, listing specific properties (curve class, channel count, ranges, etc.) and explaining channel layouts for subclasses. It clearly distinguishes from sibling inspect tools by focusing on curve assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading curve asset properties without specifying when to use versus alternatives. However, the context of sibling inspect tools (e.g., inspect_anim_blueprint) makes it clear this is for UCurveBase assets.
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 extensively discloses download paths, extraction logic, naming conventions, licensing, multi-map behavior, resolution handling, and format fallbacks. Also notes error messages for invalid resolutions. Highly transparent about system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose and includes excessive implementation details (e.g., exact API paths for each source) that may not be necessary for agent selection. While well-structured with front-loaded purpose, it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sources, asset types, multi-map), the description covers most scenarios: explains source-specific workflows, licensing, multi-map naming, and notes model import is not yet supported. Lacks mention of error handling beyond resolution, but overall complete enough for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value beyond schema: explains multi_map naming convention, resolution fallback, format defaults, dest_path default, and back-compat rationale. Enhances understanding of each parameter effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool downloads CC0 assets from Polyhaven/AmbientCG and imports them as UTexture2D. Specifies supported types (texture, hdri) and notes model is not yet implemented, distinguishing it from siblings like marketplace_search and import_texture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use the tool (importing marketplace assets), mentions licensing restrictions (Polyhaven API non-commercial/academic), and explains multi-map behavior. Lacks explicit when-not-to-use, but implications are clear from limitations (model not implemented).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description details the actions: start with mode options, stop tears down, query returns booleans. This sufficiently discloses behavior 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 three sentences, front-loaded with the purpose, then provides details. 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 the low complexity (2 parameters, no output schema), the description covers all necessary information: actions, modes, and return values for query.
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 100% with descriptions for both parameters. The description adds value by explaining the effects of each action and the mode options, enhancing 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 'Start / stop / query Play-In-Editor sessions,' specifying the verb and resource. It distinguishes itself from siblings as the only tool managing PIE sessions.
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 use: it 'closes the loop' after editing gameplay, allowing the LLM to scaffold changes, trigger PIE, observe, and stop. It does not explicitly state when not to use it, but gives clear usage context.
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: the 1000-entry ring buffer size, cursor-based consumption (since_seq inclusive), cap on returned events (max_count up to 1000), and the 'dropped' flag to indicate buffer overflow. This is comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with efficient use of words. It front-loads the core action ('drain editor events') and then adds necessary technical details. Minor structural improvements could be made (e.g., separating usage steps), but it is well within acceptable conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the response contract (slice of events with cursor, 'dropped' flag). It also explains the error condition (buffer overflow). It could be more explicit about the event structure, but the context signals indicate moderate complexity, and the description provides sufficient guidance.
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?
Input schema covers 100% of parameters, so baseline is 3. The description adds value by explaining the purpose of each parameter: since_seq's default (-1) and inclusive cursor behavior, max_count's default (100) and hard max (1000), and event_filter's substring matching with OR combination. This exceeds basic schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a 'Tier 2 entrypoint' for draining editor events, names specific event types (actor_spawned, actor_deleted, asset_added), and describes the polling mechanism. It distinguishes itself from sibling polling tools like poll_subscription and poll_task by focusing on event-driven polling with a ring buffer cursor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: first call with since_seq=-1 to obtain next_seq, then poll with that value. Documents the 'dropped' flag for overflow detection. However, it does not compare or contrast with sibling polling tools (poll_subscription, poll_task), which would aid in selecting the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses synthetic handler, internal wiring, optional triples skip channels, rotation order, interpolation with alias, auto-extend. Lacks error handling 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?
Efficient, front-loaded with core action, each sentence adds unique value. No fluff, appropriate length.
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 8 params, no output schema, description covers prerequisites, optional parameters, rotation convention, interpolation options, and auto-extend. References related tools, making it complete for agent 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 100%, baseline 3. Description adds value by explaining rotation order (pitch/yaw/roll), interpolation alias, and time_seconds conversion, beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add a single keyframe on a Level Sequence's 3D Transform Track for a previously-bound actor'. It differentiates from siblings like bind_actor_to_sequence and create_sequence by specifying the context of keyframe authoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: it closes the keyframe-authoring half of a prior note and lists prerequisites (sequence_path, binding_id). However, it does not explicitly state when not to use this tool or suggest 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?
Describes composition of fix_up_redirectors per folder and explains parameter behaviors (recursive echoed, continue_on_error control), adding value beyond 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?
Two sentences: one for purpose, one for usage guidance. 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 no output schema, description sufficiently covers behavior and use cases; missing return value info but acceptable for 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?
Adds meaning beyond schema by explaining recursive's purpose for intent capture and continue_on_error's stopping behavior; schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states tool resolves UObjectRedirector stubs across multiple folders, distinguishing from sibling fix_up_redirectors which operates on a single folder.
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 advises to use as follow-up to bulk_move_assets/bulk_rename_assets, implying alternative fix_up_redirectors for single folders.
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 composition of focus_actor and get_viewport_screenshot, details the settle delay behavior (sleeps between calls, not after last), and explains the screenshot_each option. Some minor gaps like error handling, but sufficient given 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?
Two sentences, front-loaded with action, no wasted words. Perfectly 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?
Comprehensive for a bulk tool with simple parameters. Mentions output (screenshots array) but doesn't specify format when no screenshots. Minor gap, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds meaningful context: max 100 entries for names, default/max for delay_ms, default false for screenshot_each, and clarifies delay timing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it frames the viewport on each actor in a sequence, optionally capturing screenshots. Distinguishes itself from sibling tools like screenshot_actor by avoiding polling loops.
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 provides a use case ('show me each enemy / spawn / light in turn' walkthroughs) and explains why it's better than using screenshot_actor individually.
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 behavior: spawning temporary actors, capture pipeline, cleanup of temp assets. It details the entire process, ensuring the agent understands side effects and safety.
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 purpose, pipeline steps, and cleanup. It is detailed but not overly verbose. Slight improvement could be made by front-loading the most critical info, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output (static UTextureCube) and covers all inputs, process, and cleanup. It is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable defaults (e.g., dest_path defaults to source folder, dest_name to source basename plus _Cube), explains cube_size range, and lists compression options. This goes 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 explicitly states the tool converts a longlat-projection HDRI to a UTextureCube for use with SkyLight's SpecifiedCubemap slot. It distinguishes itself from siblings like import_texture and configure_texture by focusing on a specific conversion pipeline.
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 purpose clearly indicates use for SkyLight cubemap setup. It mentions being a 'SYNTHETIC bridge-side handler' but lacks explicit when-not-to-use guidance or alternative tools. The context is clear but could be stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains BFS traversal, depth bound, direction options, de-duplication, and that it composes inspect_asset recursively. Lacks explicit mention of side effects or performance, but for a read operation it is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first states main purpose and composition, second distinguishes from sibling, third mentions de-duplication. Every sentence adds unique information, 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 complexity (graph walking, bidirectional), description covers traversal algorithm, parameters, and de-duplication. However, no output schema exists and description does not explain return format (e.g., list of nodes/edges with direction labels). A slight gap.
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 100%, baseline 3. Description adds value beyond schema: explains depth range rationale (1-8, bidirectional sweep can produce vast subgraph past depth 4) and clarifies include_referencers default false and that edges record direction. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it walks the asset dependency graph BFS from a root, defaulting to dependencies downward, and optionally includes referencers upward. It distinguishes from sibling 'get_reference_chain' by noting defaults and bidirectional sweep capability.
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 contrasts with 'get_reference_chain' in terms of direction default and enabling a single bidirectional pass versus two separate calls. Also mentions de-duplication across directions, guiding when to use this tool over 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 fully bears the burden. It discloses that 'ExecuteFile mode does not return stdout/eval-result' and suggests a workaround. This is transparent about a key behavioral limitation, though it could mention error handling or file existence checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second provides usage distinction, third warns about output capture. No wasted words; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and the provided caveat, the description covers core behavior and a critical usage note. It could be more complete by discussing error scenarios or file not found, but it is adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage on the single parameter 'path', already providing a good description. The tool description adds context about relative path resolution against the editor's CWD, which adds 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 'Execute a .py file from disk via the editor's embedded Python.' It specifies the verb, resource, and mechanism, and distinguishes from the sibling tool 'execute_unreal_python' by noting it avoids escaping pain for non-trivial scripts.
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 positions this tool as a complement to 'execute_unreal_python' and provides a caveat about output capture, guiding the agent to use 'unreal.log marker + get_log_lines' for results. 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?
With no annotations, the description fully covers cooperative cancellation, flag polling, status transition to 'cancelled', and Unreal Engine's lack of forced termination. Also notes idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each with distinct purpose: action, mechanism, limitations, and idempotency. No wasted words, front-loaded with core function.
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 simple single-parameter tool with no output schema, description covers all necessary behavioral aspects, edge cases, and limitations thoroughly.
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 100% for task_id, and description adds no extra information beyond the schema's description. Baseline 3 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?
Clearly states it cancels a running task cooperatively. The verb 'cancel' and resource 'task' are explicit, and it distinguishes itself from sibling tools like list_tasks or poll_task by describing cancellation behavior.
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 (to cancel running tasks), when not to (workers that don't poll ignore cancellation), and idempotency for unknown/terminal tasks. No alternative tool mentioned, but context is sufficient.
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 behavior: what gets cleared (all user-defined names, including explicit imports), what is preserved (names starting with '_'), and the effect on the editor state. It also explains the relationship with exec_python_persistent.
Agents need to know what a tool does to the world before 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 front-loaded with the core action, followed by specific exceptions (preserved names, cleared imports). Every sentence adds value with no 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 the tool's simplicity (no parameters, no output schema), the description is completely adequate. It covers purpose, behavior, exceptions, and usage context without missing any essential information.
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 100% schema coverage. The description needs no parameter information, and it adds meaningful context about the operation's scope, meeting the baseline for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 exact action: clearing user-defined names from UE Python's public globals dict. It specifies the verb 'clear' and the resource 'globals dict', and distinguishes from siblings like exec_python_persistent by explaining it pairs with that tool to wipe state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'to wipe accumulated state and start fresh without restarting the editor' and pairs it with exec_python_persistent. It implies when to use but lacks explicit 'when not to use' or alternatives beyond the pairing context.
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, but description fully discloses polymorphic value, priority level, override behavior, pre-rejection of read-only CVars, and post-verification. Highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each packed with information. No fluff, front-loaded with action.
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?
No output schema, but description covers mutation, priority, error handling, and verification. Complete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining polymorphic nature, coercion, and parsing behavior beyond schema type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'mutate' with specific resource 'UE Console Variable by name'. Description distinguishes from sibling tools like 'execute_console_command' and 'find_console_variables'.
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?
Implicitly states usage for mutating console variables with priority and override semantics. No explicit when-not-to-use or alternatives, but context is adequate.
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 the description bears full burden. It discloses that the wait runs in bridge, game thread keeps running, same response shape as poll_events with a 'timed_out' field, default timeout, hard cap, and clamping behavior for over-cap requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first front-loads the core purpose, the second adds implementation detail, the third describes response and constraints. No wasted words.
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 five parameters, no output schema, and no annotations, the description is comprehensive: covers purpose, behavior, parameter trade-offs, response shape, and constraints. No obvious gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds semantic value beyond schema by explaining the trade-off for poll_interval_ms (latency vs. round trips) and reiterates clamping behavior, providing moderate additional guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Bridge-side composition of poll_events' that polls until events arrive or timeout, specifying the resource (events) and distinguishing it from poll_events by explaining the wrapper behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (to wait for events) and contrasts with poll_events, but does not explicitly state when not to use or list alternative tools. The context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the return data (four representations, type, readonly flag, last-setter) and implies non-destructive read. Could explicitly state side-effect-free, but sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with verb and resource. Ideal conciseness.
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 single-parameter read tool with no output schema, the description fully explains purpose, returns, and sibling differentiation. Nothing missing.
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?
Input schema has 100% coverage with one parameter described. Description adds value by specifying exact CVar name requirement, case-sensitivity, and giving concrete examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads a UE Console Variable by name and returns multiple representations. Explicitly distinguishes from execute_console_command by stating it reads CVar state directly without invoking the console exec engine.
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?
Directly contrasts with sibling tool execute_console_command, telling the agent when to use this read-only direct access versus the potentially destructive exec path.
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: asynchronous, returns immediately with a task_id, can be polled or cancelled via explicit tool names, and has a 1-hour maximum duration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage, then extra constraints. Every sentence adds value with no 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 a single parameter, no output schema, and no annotations, the description provides complete context: what the tool does, how to use the result, and a critical constraint (max duration). No 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 already covers the parameter with 100% description, but the description adds context by stating the range as '1 to 3600000 ms / 1 hour' and labeling it required, reinforcing 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 a background task that sleeps for a duration and returns immediately. It also differentiates from sibling tools like poll_task and cancel_task, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool (for sleep-and-continue workflows and testing threading/cancellation) and when not (use poll_task or cancel_task for follow-up). Also provides a hard cap on duration_ms.
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 fully covers behavior: idempotent, returns ok=true with was_present=false for unknown IDs. This discloses the tool's safety and error model, exceeding typical descriptions.
Agents need to know what a tool does to the world before 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. Front-loaded with the main action, then immediately provides the critical idempotency detail. Perfectly concise.
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, one-parameter tool with no output schema, the description covers purpose, usage context, behavioral guarantees, and parameter origin. No gaps remain for the agent to infer.
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 subscription_id has 100% schema coverage with description 'Subscription id returned by register_subscription.' The description adds the origin context, reinforcing the schema's meaning. A score of 4 reflects this added 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?
Clearly states the tool removes a subscription, using a specific verb ('Remove') and resource ('subscription created via register_subscription'). Differentiates from sibling tools like register_subscription by being its inverse operation.
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 describes when to use (during shutdown for blanket unsubscribe) and the idempotent behavior for unknown IDs. Provides clear guidance that callers can rely on ok=true and was_present=false without error handling.
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-ai-connection MCP server](https://glama.ai/mcp/servers/NAJEMWEHBE/unreal-ai-connection/badges/card.svg)](https://glama.ai/mcp/servers/NAJEMWEHBE/unreal-ai-connection)

Score Badge

Copy to your README.md:

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

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/NAJEMWEHBE/unreal-ai-connection'

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