Unreal Engine MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes (property reading/writing, function calling, actor management, level operations, asset search). The only slight overlap is between ue_ping and ue_get_api_info, both providing connectivity/info, but their descriptions make the difference clear.
Naming Consistency5/5
All tool names follow a consistent ue_verb_noun pattern (e.g., ue_get_property, ue_spawn_actor, ue_open_level). The naming is uniform, lowercase, and snake_case, with no mixed conventions or ambiguous verbs.
Tool Count4/5
22 tools is slightly above the typical 15-tool threshold, but the breadth is justified by the wide scope of Unreal Engine automation. The count feels appropriate for editor control, object inspection, asset handling, and level management without being bloated.
Completeness4/5
Core workflows are covered: inspecting objects, reading/writing properties, calling functions, managing actors (list, select, spawn, destroy, transform), level operations (open, save, current, save all), asset search/metadata, and editor utilities (console, PIE). Minor gaps exist, such as no explicit undo/redo or asset creation, but the surface is well-rounded for typical automation.
Average 4.1/5 across 22 of 22 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses that only provided components are changed (a key behavioral trait) and implies a write operation via 'Set'. However, it lacks details like coordinate space conventions, units for rotation (though schema states degrees), or success/failure behavior, so it is 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?
Two sentences, front-loaded with the verb and resource. Zero waste, every clause adds meaningful information about flexibility and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, it would benefit from a note about return values or side effects. However, the description clarifies the core behavior well and the schema covers parameter details, making it sufficiently complete for the task.
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 the baseline is 3. The description adds value by explaining that parameters can be combined arbitrarily and omitted ones are not affected. This goes beyond the schema by clarifying the partial update semantics, which is crucial for correct usage.
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 an actor's transform (location, rotation, and/or scale). It specifies the action and scope precisely. However, it does not explicitly distinguish itself from sibling tools like ue_set_property, which could also modify actor properties, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as ue_set_property or ue_call_function. It does not mention exclusions or prerequisites, leaving the agent to infer usage from purpose 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses a maximum of 100 operations per batch and lists supported operation types, but it omits critical behavioral traits such as atomicity (does one failure abort the whole batch?), execution ordering, error handling semantics, or return value structure. For a batch execution tool, these are significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and contains zero waste. Every sentence contributes: purpose, efficiency justification, supported operations, and a hard constraint. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. While it covers batching and constraints, it fails to explain what the response looks like, whether operations are processed atomically, or what happens on partial failure. Given the moderate complexity of a batch execute tool, the description is incomplete for an agent to confidently infer behavior under error conditions.
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 schema already documents each parameter (type enum, target, objectPath, value). The description adds minimal value beyond stating the three operation types, which map directly to the enum values. With full schema coverage, a baseline of 3 is appropriate; the description neither improves nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute multiple operations in a single batch request.' It also distinguishes itself from sibling tools by emphasizing batch execution and efficiency over calling individual tools, while specifying the supported operation types (function calls, property reads, property writes).
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 usage guidance by stating 'More efficient than calling individual tools when you need to perform many operations.' This implies when to choose the batch tool, though it doesn't explicitly mention when not to use it or name alternatives. However, the context of batching is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, this description should disclose side effects, since calling arbitrary Blueprint functions can mutate world state or execute destructive operations. It only states what the function does, not possible consequences or error conditions, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and includes a helpful example list and a pointer to ue_describe_object. 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 tool that can invoke arbitrary functions, it provides a good high-level overview and schema coverage is complete. However, it lacks return value description, error handling, and side-effect warnings, which are important for a potentially destructive tool with 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 already covers all three parameters with descriptions, so the baseline is 3. The description adds no extra parameter meaning beyond noting the function must be Blueprint-callable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 the tool as invoking Blueprint-callable functions on UObject instances, with concrete examples (actor methods, engine utilities, custom Blueprint functions). This distinguishes it from sibling tools like ue_set_property and ue_execute_console_command.
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 prescribes a specific workflow: use ue_describe_object first to discover available functions. It does not explicitly mention when not to use it or name direct alternatives, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that any console command is supported, but it does not warn about potential side effects such as modifying editor state, crashes, or the need for a running editor session. For an arbitrary-command execution tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by a short list of examples. It is front-loaded with the core purpose and adds useful context without any unnecessary verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description does not mention return values or output format, and there is no output schema to compensate. It also lacks context about prerequisites like a running Unreal Engine project. The description is minimally sufficient but could be more complete for an arbitrary-command 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 schema already provides 100% coverage for the single parameter, so the baseline is 3. The description adds value by listing common command examples ('stat fps', 'show collision'), which helps the agent understand what to pass and what kinds of commands are available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (execute) and resource (console command in Unreal Engine). It also distinguishes this tool from siblings by noting it supports any command available in the editor console (~), making its scope explicit.
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 running editor console commands and lists common examples, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Since no sibling tool appears to serve the same purpose, the context is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full responsibility for behavioral disclosure. It omits any details about parameter precedence (what happens if both location and actorPath are provided), error behavior for invalid actor paths, or whether this is an editor-only operation. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes only relevant context about large levels. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the purpose but lacks details on edge cases and parameter interaction. The tool is relatively simple, but ambiguity about behaviors could mislead the 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?
Both parameters have schema descriptions (100% coverage), so the baseline is 3. The description implicitly maps 'actor' to actorPath and 'location' to location but adds no additional semantics about their relationship or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves the editor viewport to focus on a specific actor or location, using a specific verb ('move') and resource ('viewport'). It distinguishes itself from sibling tools which focus on properties, actors, or level 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?
It provides the context that the tool is useful for navigating large levels, implying when to use it. However, it does not explicitly mention when not to use it or name alternative tools, though no sibling directly overlaps.
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 for disclosing behavior. It lists actions but does not mention side effects (e.g., whether PIE mode blocks editor interaction, whether state is preserved), prerequisites, or how the mode affects the editor. The action enum itself already conveys the basic operations, so the description adds little beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions 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-loads the tool's role, lists actions, and gives a brief use case. Every sentence contributes value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete enough: it states the purpose, actions, and a use case. It lacks prerequisite or side-effect details, which are already accounted for in the transparency dimension, so the overall completeness is good but not perfect.
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 covers the single 'action' parameter fully with an enum and description. The tool description merely repeats the action names without adding any extra meaning about parameter format, defaults, or edge cases. Baseline 3 is appropriate given the 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 opens with the specific resource (Play In Editor mode) and lists the exact actions (start, stop, pause, resume), making the purpose clear. This differentiates it from sibling tools like ue_set_property or ue_spawn_actor, which handle different concerns.
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 statement 'Useful for testing gameplay changes' provides clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but since no sibling tool directly overlaps with PIE control, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates that it saves all changes, but does not mention side effects, preconditions, error behavior, or whether the operation is destructive or asynchronous. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. Every word contributes to the core meaning, making it highly concise and efficiently 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 tool with no parameters and no output schema, this description provides the essential context: it saves the current level and all changes. It does not elaborate on preconditions or return values, but given the tool's simplicity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is trivially 100% since there are no properties. The description adds no parameter information because none is needed, so the baseline 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 action ('Save') and the resource ('current level'), and implicitly distinguishes from the sibling tool 'ue_save_all' by specifying 'current' level. This is a specific verb+resource construction that fully clarifies the tool's 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 when to use this tool (when you want to save the current level) but does not explicitly contrast it with alternatives like 'ue_save_all' or mention exclusions. No guidance is provided on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It implies a read-only operation ('Get') but does not mention error handling, permissions, or side effects. The description adds some detail about return content but lacks deeper transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that cover purpose and usage without wasted words. It front-loads the core function and follows with a practical tip, making it highly 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 simple tool with one parameter and no output schema, the description is quite complete. It explains what the tool does and gives a usage hint. It could mention error behavior or the return structure, but given the 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?
The input schema already explains the single parameter (assetPath) as 'Full path to the asset', providing 100% coverage. The description does not add further parameter details, but it hints at how to obtain the path (via ue_search_assets), which is a marginal addition. 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's function with a specific verb ('Get') and resource ('detailed metadata about an asset'), listing concrete data points (class, size, references). It also distinguishes itself from sibling tools like ue_search_assets by referencing it as a prerequisite, 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 explicitly advises using ue_search_assets to find asset paths first, which is a clear usage guideline. It provides context but does not explicitly list exclusions or alternatives, so it misses a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It correctly states the tool searches the registry and returns paths, but does not explicitly mention read-only behavior, case sensitivity, or whether filters combine with AND/OR. No contradictions, but the description adds only moderate detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. It avoids fluff and clearly states what the tool does and what it returns. The only minor weakness is the vague 'etc.', but it does not detract from overall efficiency.
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 lack of output schema, the description tells the agent what it returns (asset paths) and why they are useful. Minor gaps exist around search semantics (e.g., substring vs exact match, filter combination), but these are not critical for a search tool. The description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions for query, limit, pathFilter, and classFilter. The description adds a light mapping ('by name, path, or class') to the parameters, but does not elaborate on how filters interact. Baseline 3 is appropriate since the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' and clearly identifies the resource ('project's asset registry') and search criteria ('by name, path, or class'). It also mentions the return type ('asset paths') making it clearly distinct from sibling tools like get_asset_data or describe_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Useful for finding meshes, materials, blueprints, textures, etc.') and notes that returned paths can be used with other tools, implying a search-then-use flow. It does not explicitly state alternatives or exclusions, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that read-only properties and properties with BlueprintSetters cannot be written, but it does not mention failure behavior, permissions, or side effects. The mutation nature 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?
The description is three sentences, each serving a distinct purpose: stating the action, listing constraints, and directing to alternatives. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary usage and constraints, but lacks details on return values or error conditions. With no output schema and no annotations, the agent is left without information about success/failure signals or what happens if the property is invalid. The optional 'value' parameter in the schema also introduces ambiguity that the description does not resolve.
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 adds context that property types can be seen via ue_describe_object, which indirectly helps interpret the 'value' parameter, but it does not specify types or formats directly. The value parameter's optional nature in the schema is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Write a property value on a UObject', which clearly states the action and target. It distinguishes from sibling tools by specifying the scope (public properties) and excluding properties with BlueprintSetters, which aligns with the alternative ue_call_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'For properties with setters, use ue_call_function with the setter function instead', providing a direct alternative. It also advises using ue_describe_object to inspect property types, guiding the agent on prerequisites. This is strong usage 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 provided, the description carries the burden of disclosing behavior. It clearly states this is a read-only operation (gets a list), defines the scope (current level), describes the optional filter, and specifies the return format (actor paths). It doesn't mention potential limitations like performance with large scenes, but for a simple get-all tool this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no fluff. Every sentence adds value: the first states the core functionality, the second explains the optional filter and return value usage. This is 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?
The tool is simple with one optional parameter and no output schema. The description covers the essential context: what it does, the filter option, and what it returns (actor paths) with examples of how to chain with other tools. It doesn't explain edge cases like empty levels or behavior if the level is not loaded, but given the low complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full documentation for the single parameter 'classFilter' with description 'Optional class name to filter actors', achieving 100% coverage. The tool description adds little beyond restating the same concept ('filter by class name to get only specific actor types'). Per the rubric, baseline 3 is appropriate when schema coverage is high and description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list of all actors') and the specific resource ('in the current level'). It also distinguishes itself from the sibling tool ue_get_selected_actors by emphasizing 'all actors' rather than selected actors, and mentions the optional class filter to narrow results.
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 you need an enumeration of all actors in the level, with optional class filtering. It also provides guidance on downstream usage by noting the returned actor paths can be used with ue_get_property or ue_call_function. It doesn't explicitly contrast with ue_get_selected_actors, but the name and context make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly signals a read-only operation via 'Get' and enumerates the output fields, but it does not mention edge cases such as behavior when no level is open or the structure of the response. This 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?
The description is a single, front-loaded sentence that directly states the purpose and scope without any wasted words. It is 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 zero-parameter getter with no annotations or output schema, the description sufficiently covers what the tool does and returns. It lacks specifics like error handling or the full breadth of 'world settings', but overall it is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add meaning beyond the schema. However, it does usefully specify the returned fields (name, path, world settings), which compensates for the lack of an output schema. Baseline 4 applies for zero-parameter 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 uses the specific verb 'Get' with the clearly identified resource 'currently open level' and lists the returned information (name, path, world settings). This distinguishes it from sibling tools like ue_open_level or ue_save_level, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the tool acts on the currently open level, making it obvious when to use it. It does not explicitly exclude alternatives, but the context is unmistakable for a getter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates this is a non-destructive connectivity test and that success means the API is reachable, adding meaningful context beyond the empty schema. However, it does not describe timeout or error 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 a single, front-loaded sentence that wastes no words. It states the action and expected outcome clearly and concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description explains the purpose and success condition but does not specify the exact return value or behavior when the API is unreachable. This is almost complete but could be slightly more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The description correctly refers to the only relevant aspect (connectivity to the Remote Control API). Per the scoring guide, 0 parameters yields a baseline of 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Test connectivity to Unreal Engine.' It specifies the exact success condition ('if the Remote Control API is reachable'), and this distinguishes it from sibling tools that manipulate actors, assets, or 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?
The description implies this is a health check for the Remote Control API, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The usage context is inferred, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that it returns the path to the new actor and supports both built-in and custom Blueprint classes. It does not enumerate side effects or prerequisites, but for a spawn operation, this level of detail is sufficient and goes beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences long, and front-loaded with the core action. It includes only essential details: the operation, the supported class range, and the return value. No wasted words 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?
The description covers the key aspects of the tool: what it does, where it operates, what classes it supports, and what it returns. The schema handles parameter details. It does not address edge cases (e.g., invalid class names) but is sufficiently complete for a tool of this 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?
The schema already provides 100% coverage for parameter descriptions. The description adds only marginal value by giving concrete examples of className (StaticMeshActor, PointLight) and reiterating location. It does not clarify rotation or label beyond what the schema states, 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 the tool spawns a new actor at a specified location, using a specific verb and resource. It also lists supported class types and the return value, making the purpose unambiguous and distinct from sibling tools like destroy or query actor tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use it: when you need to create an actor in the current level. It does not explicitly mention alternatives or exclusions, but the context is strong enough that an agent can infer the appropriate use case without ambiguity.
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 carry the full behavioral burden. It states the core action (saving) and its scope (all modified assets and levels), but it does not disclose potential side effects such as overwrite behavior, whether unmodified assets are ignored, or if it blocks. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the primary action front-loaded. The Ctrl+Shift+S reference is a helpful, concise addition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save-all tool with no parameters, no output schema, and no nested objects, the description completely covers the tool's purpose and behavior. The equivalence to a well-known editor shortcut provides additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is effectively 100%. The description does not need to explain parameters, and the baseline for no-parameter tools is 4. Nothing is missing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save all modified assets and levels.' This is a specific verb+resource combination that distinguishes it from siblings like ue_save_level, which focuses only on the current level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool via the Ctrl+Shift+S equivalence, which is a well-known save-all shortcut. It implicitly contrasts with ue_save_level by emphasizing 'all,' but it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Get information' clearly indicates a read-only, non-destructive operation. The description also specifies what information is returned (API routes) and the comprehensiveness ('all available'). While it omits details like return format or authentication needs, these are not critical for this simple discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource. Every word serves a purpose—it states what it does and why it's useful. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters, no output schema, and no annotations. The description fully explains the purpose and provides usage context. While it doesn't detail the exact structure of the returned route information, that is not essential for a user to understand the tool's function. The low complexity makes this description 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 tool has zero parameters, and the description adds no parameter-specific details, which is appropriate since none exist. Per the rubric, 0 params receives a baseline of 4. The description's mention of 'all available' reinforces that no filtering is possible, indirectly confirming the lack of 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 uses a specific verb ('Get') and a concrete resource ('all available Remote Control API routes'), clearly distinguishing it from sibling tools that perform operations like setting properties or spawning actors. The scope ('all available') is explicit, leaving no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Useful for understanding what endpoints are available.' This implies a discovery/exploration use case. It does not explicitly state when not to use it or name alternatives, but the purpose is straightforward and no comparable sibling exists for listing API routes.
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. The verb 'Get' and 'describe' clearly imply a read-only operation with no side effects. It also discloses what is returned (metadata, properties, functions), but doesn't explicitly state the response format or absence of side effects beyond the verb. This is strong but not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence clearly states the action and outcome, the second provides immediate usage guidance. Perfectly structured 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?
The tool is simple (one parameter, no output schema). The description covers what it does, what it returns, and when to use it in relation to sibling tools. No critical gaps 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 coverage is 100% with a clear parameter description ('Full path to the UObject to describe'). The tool description adds context about the tool's purpose but does not add meaning beyond the schema's parameter description. 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 tool gets detailed metadata about a UObject, listing what it includes (properties and Blueprint-callable functions). This distinguishes it from sibling tools like ue_get_property (which retrieves a specific property) and ue_call_function (which invokes a function).
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: 'Use this to discover what operations are available on an object before calling ue_call_function, ue_get_property, or ue_set_property.' This names specific alternatives and provides a clear workflow, which is excellent 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 the full burden. It explicitly states the action is irreversible (except via editor undo) and scopes it to the current level. It doesn't discuss side effects like reference cleanup, but the essential consequence is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the purpose, the second adds the irreversibility caveat and a useful pointer to a sibling tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destruction tool with no output schema, the description covers purpose, scope, consequence, and parameter acquisition. There are no missing essentials relevant to the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents actorPath as 'Full path to the actor to destroy.' The description goes further by explaining how to obtain actor paths ('Use ue_get_all_actors to find actor paths'), adding practical meaning beyond the schema's field 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 begins with 'Destroy (delete) an actor' — a specific verb and resource — and scopes it with 'from the current level.' It clearly distinguishes itself from sibling tools like ue_spawn_actor (creation) and ue_get_all_actors (listing).
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 workflow guidance by pointing to ue_get_all_actors for finding actor paths. It also warns about irreversibility, which signals caution. While it doesn't explicitly list alternatives, there is no direct alternative to destroying an actor, so the guidance is adequate.
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 burden. It discloses the key behavioral constraint (only public properties without BlueprintGetter) and points to the alternative for getters. The verb 'read' implies a non-mutating operation, but it does not explicitly mention return format or error behavior. This is solid transparency for a 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?
Two sentences, front-loaded with the primary action and scope. The first sentence states exactly what the tool does; the second provides essential usage boundaries. Zero 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?
Despite lacking an output schema and annotations, the description is complete for a simple read tool. It clearly defines the operation, states the eligibility rule, and directs the user to sibling tools for related tasks. The 2-parameter schema is fully covered, and no additional context is necessary.
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 both parameters described. The description adds context about what constitutes a readable property but does not elaborate on parameter syntax or types beyond the schema. Baseline 3 is appropriate when schema handles parameter 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?
Specific verb 'Read' plus resource 'property value from a UObject' clearly states the tool's function. It distinguishes from ue_call_function for getter-based properties and references ue_describe_object for property discovery.
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 tells the agent when to use this tool vs ue_call_function ('For properties with getters, use ue_call_function instead') and advises using ue_describe_object to see available properties. This is direct when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. The verb 'Get' implies a read-only operation, and it explicitly mentions that it returns actor paths that can be used with other tools, providing useful behavioral context. It does not discuss edge cases like no selection, but this is minor for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions 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 concise sentences, front-loaded with the core action. Each sentence adds value: what it does, why it's useful, and what it returns. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with zero parameters and no output schema, the description is complete. It explains the return value (actor paths) and its practical use with other tools, giving an agent sufficient information to invoke and use the result 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?
The tool has no parameters, so the description does not need to explain parameter semantics. The baseline score of 4 applies because there is no schema information to compensate for and no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the list of currently selected actors' with a specific verb and resource, and differentiates from sibling 'ue_get_all_actors' by highlighting 'currently selected'. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context ('Useful for performing operations on user-selected objects') that implies when to use the tool, and the 'currently selected' wording helps distinguish it from other actor-related tools. However, it does not explicitly name alternatives or state 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?
With no annotations, the description carries the burden of disclosing behavior. It explicitly states that by default the selection is replaced and that addToSelection=true adds to the existing selection. This is the key behavioral trait for a selection tool. It doesn't discuss return values or side effects, but none are critical for this simple 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 two sentences with no wasted words. It leads with the primary purpose, then immediately clarifies the parameter behavior. Every word earns its place, and the structure is easy to parse.
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 tool with two parameters and no output schema, the description covers everything needed: what it does, the default behavior, and how to opt into additive selection. It is self-contained and sufficient for an agent to invoke correctly without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameter descriptions for actorPaths ('Array of actor paths to select') and addToSelection ('Add to existing selection'). The description adds semantic value by explaining the default behavior (replaces) and how to modify it using addToSelection=true, deepening the meaning beyond the schema's brief labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 selects actors in the Unreal Editor, with a specific verb ('Select') and resource ('actors'). It also distinguishes the default behavior (replace current selection) from the alternative (add to selection), which sets it apart from sibling tools like ue_get_selected_actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need to select actors, with the default replacing the current selection and addToSelection=true for adding. It doesn't explicitly exclude alternative tools, but the purpose and behavior are clear enough for an agent to select this appropriately 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?
No annotations are provided, so the description carries the full burden of safety disclosure. It openly states that opening a level will close the current level, which is a significant behavioral side effect. It doesn't mention return value or save behavior, but for a single-purpose open tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, then the side effect, then the search tip. 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 the low complexity (one parameter, no output schema, no annotations), the description covers the purpose, the key side effect, and how to find valid inputs. It is sufficiently complete 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?
The schema already describes levelPath as 'Path to the level to open' with 100% coverage. The description adds meaning by hinting at how to source valid values (via ue_search_assets), which enriches the parameter semantics 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 states a specific action (open a level) on a specific resource (Unreal Editor level) and adds a critical consequence (closes current level), making it clear and distinguishable from sibling tools like ue_get_current_level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells users to use ue_search_assets with classFilter='World' to find available levels, giving an actionable alternative for the prerequisite of discovering level paths. This is concrete usage guidance beyond a simple 'when to use' statement.
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:

[![ue-mcp MCP server](https://glama.ai/mcp/servers/erhansiraci/ue-mcp/badges/card.svg)](https://glama.ai/mcp/servers/erhansiraci/ue-mcp)

Score Badge

Copy to your README.md:

[![ue-mcp MCP server](https://glama.ai/mcp/servers/erhansiraci/ue-mcp/badges/score.svg)](https://glama.ai/mcp/servers/erhansiraci/ue-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/erhansiraci/ue-mcp'

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