Server Quality Checklist

Tool Scores

• unreal_set_viewport_cameraA
  3.7/5.0
  Behavior3/5

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

  The annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false, so the safety profile is clear. The description adds genuinely useful side-effect disclosure: it doesn't persist data or affect saved project state, and it affects only the editor view. However, it fails to disclose viewport focus/selection behavior, what happens if a shot is taken while the viewport is in a different mode, or whether the operation clamps out-of-bounds rotations, which would be richer behavioral context. The downside of dropping focus to the viewport is undisclosed.

  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 action in the first sentence. The Args/Returns/Examples layout makes it skimmable and each section has a purpose, though the return JSON block is verbose and duplicates what the output schema already provides.

  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 only one parameter, the description covers the essentials: purpose, parameters, return shape, and error behavior. The inclusion of an example usage ('framing a shot before unreal_take_screenshot') adds real workflow context, but it falls short of addressing the broader execution-context race conditions that tools in a rendering pipeline like this face.

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

  Parameters3/5

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

  The description repeats the params (location, rotation) and their units and coordinate systems, which mirrors what the schema already documents. With schema description coverage at 0% in the formal sense, this repetition is somewhat helpful but not additive. It adds the clarification that the return value is the 'pose actually applied,' but the echo of both schema and return adds bulk without delivering new semantic richness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with a specific verb-resource pair: 'Move the editor's perspective viewport camera to a specific pose,' which directly names the target, scope, and action. It explicitly contrasts with CameraActor manipulation, making it clear this does not touch level cameras. The distinction from siblings like unreal_take_screenshot and unreal_spawn_actor is clearly drawn.

  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 Examples section names an 'instead' condition (when not to use it: 'you want a camera the level keeps') and names the alternative (spawn a CameraActor), which is good usage guidance. However, since the Unreal MCP API has no well-known Sandbox convention analogous to filesystem MCP, the guidance to look before you leap falls a bit flat.

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

• unreal_list_assetsA
  4.1/5.0
  Behavior3/5

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

  The annotations (`readOnlyHint: true`, `idempotentHint: true`, `destructiveHint: false`) establish the safety profile, and the description's pagination details ('has_more', 'next_offset') and 'On failure: "Error: ..."' add useful behavioral context. However, the ReadOnly flag is carried by the annotation, so the description's incremental value is moderate—pagination behavior is helpful but not essential for safety, and the format is largely encoded in the output schema.

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

  Conciseness4/5

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

  The description is easy to scan with clear blocks: a concise opening, 'Use this to' usage, a detailed but structured output schema, and a 'Don't use when' conclusion. The code blocks break up the length, avoiding a wall of text while keeping only functional content.

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

  Completeness4/5

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

  The description covers the primary use case (finding the object path), the output schema (with pagination and error handling), and the boundary condition ('Don't use when: actors in level'), covering the essential bases. The only minor gap is a few edge cases (e.g., invalid input) that are left to the schema to hint at, but nothing critical is missing.

  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>` provides detailed descriptions, types, and defaults for all five parameters, so the semantics are already well-covered by the schema. The description's 'Params' section and examples (e.g., ': default 50') add no meaningful lift beyond the schema, giving a solid baseline of 3 with no reason to boost or penalize.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening statement 'List assets in the project's content browser, with filtering and pagination' is a precise verb+resource pairing, while 'Use this to find the object path of a asset before spawning it into a level' gives the precise context. It sharpens the focus without ambiguity, and the contrast with `unreal_spawn_actor (naming the sibling explicitly) makes the boundary clear.

  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 opening 'Use this to' explains when to apply it, and the 'Don't use when: you want actors placed in the level (use unreal_list_actors)' names the sibling and the condition that selects it. This is the gold standard for when-to-not scenarios.

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

• unreal_save_allA
  4.3/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description discloses that the operation writes to the project on disk, is harmless to repeat when nothing changed, and can be cancelled by the user resulting in saved=false. This adds meaningful behavioral context beyond what annotations alone provide.

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

  Conciseness5/5

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

  The key purpose is stated in the first sentence, followed by compact and relevant notes on behavior, arguments, return format, and usage. Every section adds value, and there is no redundant filler.

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

  Completeness5/5

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

  The description covers purpose, persistence behavior, idempotence, parameter meaning, return payload including cancellation, failure indication, and when to use/discard. There is no missing piece needed for an agent to invoke this 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 description repeats the parameter meaning already present in the schema ('save_level: Also save the open level (default True)') without adding new details such as behavior when false or edge cases. Since the schema documents the single parameter adequately, no additional compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('save') and resource ('every modified asset, and optionally the open level'), making its function unambiguous. It clearly distinguishes from sibling tools like list, import, spawn, and delete without any ambiguity.

  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?

  Explicit when-to-use and when-not-to-use guidance is provided ('Use when finishing a batch of spawns or imports...', 'Don't use when the user is still experimenting...'). It does not name a specific sibling alternative, but the contextual direction 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.

• unreal_get_statusA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: UDP multicast discovery, the fact that editors with remote execution disabled won't appear, and the structured error message. It does not contradict annotations.

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

  Conciseness4/5

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

  The description is long but well-structured: purpose, when-to-use, args, returns, examples. Every section serves a purpose; the return schema is essential because no separate output schema exists. It is thorough without being redundant.

  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 diagnostic tool with a complex output and specific behavior, the description covers everything: purpose, usage context, parameter semantics, full return structure, error format, and examples. Nothing an agent needs to call it correctly is missing.

  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 a description for wait_seconds ('How long to listen...'), and the description repeats it with the phrase 'Discovery listen window' and range. This adds minor semantic framing (discovery vs. general listen) but mostly restates schema info, so it meets 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 opens with a concrete verb and resource: 'Check whether a running Unreal Editor is reachable, and describe it.' It also differentiates itself from siblings by stating to call first when other tools fail, distinguishing connection issues from bugs. This clearly sets the tool apart from execution or asset tools.

  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: after another tool returns a connection error, or to confirm which project is open. Gives a must-not use case: when already connected and wanting to run code, with the alternative 'unreal_execute_python' named. This leaves no ambiguity about selection.

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

• unreal_execute_pythonA
  4.5/5.0
  Behavior4/5

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

  The description explicitly states the code 'can modify or delete project content' and is 'not sandboxed', which is consistent with the destructiveHint annotation. It adds valuable context by explaining the return value behavior ('returns raw console output' vs structured data) and hinting at the risk profile. While annotations already flag destructiveness, the description's blunt warning about the ability to 'modify or delete project content' is a strong, behavior-informing disclosure. It doesn't detail specific permission requirements, but for an escape-hatch tool in this context, the warning is quite potent.

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

  Conciseness5/5

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

  The description is perfectly structured and incredibly efficient, mixing a strong opening statement, a crisp warning, and a helpful 'Args:' and 'Examples:' breakdown. Every section earns its place, front-loading the purpose and crucial safety warning before diving into parameter semantics. It's a model of clarity and 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 an 'escape hatch' tool, the description provides exactly what's needed to use it correctly and safely. It clearly states the return schema (including success/result/output structure and error format), the difference between evaluate modes, and the all-important 'don't use this if a dedicated tool exists' guidance. Given its role as a fallback, the clarity on side effects and return format is complete and 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 schema description coverage is reported at 0%, meaning the description itself must carry the semantic weight. The description names the parameters ('code', 'evaluate') and gives a high-level summary of each. For instance, it contrasts 'single-expression evaluation' with 'validated input'. While it adds meaning, it's not exceptionally deep about the exact string semantics beyond what the schema's 'description' fields could hold. Since schema coverage is 0%, this is better than average but doesn't fully compensate for the lack of schema semantics, placing it at a solid 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 'Run arbitrary Python inside the running Unreal Editor' and explicitly frames it as a 'general-purpose escape hatch', which strongly distinguishes it from siblings. It reinforces this by naming the specific siblings it is not ('unreal_list_actors / unreal_list_assets') and what makes them different (structured, paginated data).

  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 ('how many static meshes are in /Game/Props?', 'calling an unreal API no other tool exposes') and, crucially, when not to use it ('Don't use when: listing actors or assets') with reasons why alternatives are superior. It also states 'Prefer a specific tool when one exists' as a general rule, which is an explicit routing directive.

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

• unreal_import_assetA
  4.6/5.0
  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 the no-dialog behavior, overwrite semantics of replace_existing, error message format, and the fact that the source file must exist on the editor machine. This is substantial context. Missing some potential side effects (e.g., what happens on failed import beyond error message), but overall solid.

  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 Args, Returns, and Examples sections, and key behavior (no dialog, overwrite) is front-loaded. It is relatively long but information-dense; the examples clarify use cases. Could be slightly tighter, but structure aids scanning.

  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?

  Covers purpose, parameters, return schema, error handling ('Error: <message>' when source missing), and usage guidance with sibling differentiation. For an import operation with no annotations provided, this description fully equips an agent to decide when to call it, what arguments to provide, and what to expect in return.

  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 four parameters (source_file, destination_path, replace_existing, save) are described with types and meaning. Adds the /Game requirement for destination_path and the default True for replace_existing and save, which the schema does not state. Return schema is also documented with counts and destination. This goes well 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 states a specific verb ('import'), resource ('file from disk into the project's content browser'), and scope ('Runs Unreal's automated import pipeline'). It also distinguishes itself from siblings by explicitly naming what it is not (use unreal_list_assets when already in project, use unreal_spawn_actor for placing).

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use and when-not-to-use guidance: 'Use when: bring this FBX into Unreal' and 'Don't use when: the asset is already in the project (use unreal_list_assets)'. It also mentions a sibling tool (unreal_spawn_actor) for a follow-up action.

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

• unreal_take_screenshotA
  4.6/5.0
  Behavior5/5

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

  The description goes beyond the sparse annotations by disclosing the asynchronous write behavior: the path is returned before the image is on disk, so the caller must wait. It also explains the return format and the meaning of its fields, which helps the agent interpret the result correctly. No annotation is contradicted.

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

  Conciseness4/5

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

  The description is well structured: a one-sentence summary, a note on asynchronous behavior, a brief Args section, a Returns block, and an Examples section. Every block earns its place, though the Args section is somewhat redundant with the schema. It is slightly longer than strictly necessary, but remains tight and scannable.

  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 covers all information needed to call the tool correctly: the purpose, a prerequisite, the three modifiable parameters with defaults and ranges, the exact asynchronous caveat, and a complete return contract including failure strings. The output schema is also described. There are no gaps that would cause an agent to mis-call it.

  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 complete descriptions for all three parameters (filename, width, height), including an example path and bounds, so the description's Arg list largely restates this. Still, the description adds the default values and range constraints in a convenient summary, but does not introduce meaning beyond what the schema offers. With full schema coverage, 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 opens with a specific verb and resource: 'Capture a high-resolution screenshot of the editor viewport to a PNG file.' This clearly identifies the action and output, and distinguishes it from sibling tools like unreal_set_viewport_camera (which frames the shot) and unreal_execute_python (a general command channel). No ambiguity remains.

  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 tool explicitly states when to use it ('producing a visual check of the level after placing actors') and when not to ('you need a final production render'), and names the alternative (unreal_execute_python). It also gives a prerequisite hint to frame the shot first with unreal_set_viewport_camera. This is model guidance for selection.

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

• unreal_set_actor_transformA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces this with 'Setting the same values twice has no additional effect'. It also discloses the None-keeping behavior ('Any field left as None keeps its current value') and the error format ('Error: <message>') including a hint to list actors. This adds meaningful operational context beyond the annotations.

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

  Conciseness5/5

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

  The description is well-structured: the core action is front-loaded, followed by a concise note on None behavior, an Args section mapping parameters, a Returns section with error handling, and clear usage examples. Every sentence serves a purpose, and the content is organized for quick scanning.

  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, parameter semantics, idempotency, None behavior, return format (referencing unreal_spawn_actor's schema), and failure handling. It does not explicitly mention prerequisites like requiring an actor to exist, but the error hint partially addresses that. Given that an output schema exists (though not shown in the input), the description is sufficiently complete for an agent to call 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 input schema already includes per-parameter descriptions with units (e.g., 'New world location [X, Y, Z] in cm'), so schema coverage is high. The description adds the None-keeping semantics and clarifies that omission leaves fields unchanged, which is not explicitly stated in the schema. It also provides a concrete example of partial modification ('raise the camera rig 200 units' -> location with new Z), reinforcing parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear, specific action ('Change the location, rotation and/or scale of an actor already in the level') and distinguishes itself from sibling tools like unreal_spawn_actor (creation) and unreal_delete_actor (removal). It explicitly notes the tool modifies an existing actor, leaving no ambiguity about its 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 provides direct usage guidance with concrete examples: 'Use when: "raise the camera rig 200 units"' and 'Don't use when: creating a new copy (use unreal_spawn_actor)'. It names the alternative tool and the condition that selects it, leaving no inference required.

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

• unreal_delete_actorA
  4.9/5.0
  Behavior5/5

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

  Adds significant context beyond annotations: it warns this is destructive, notes that recovery requires an undo which the server cannot trigger, and advises confirming the target. This covers consequences and mitigation, exceeding the basic destructiveHint.

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

  Conciseness5/5

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

  Well-structured with clear sections (warning, args, returns, examples). The critical warning is front-loaded, and every sentence serves a purpose 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?

  For a single-parameter destructive action, the description covers the action, consequences, usage rules, return format, and error handling. It is complete for an agent to call correctly without further 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?

  The description explains the 'actor' parameter as 'Label or path identifying the actor to destroy' and references using unreal_list_actors for confirmation. Though the schema already has a similar description, the tool description adds the safety context of verifying the target before destruction.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('remove') and resource ('actor from the current level'), clearly distinguishing from siblings like unreal_list_actors (listing) and unreal_spawn_actor (creation). It is not a tautology and conveys a precise action.

  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 when-to-use ('user explicitly asks to remove a placed object') and when-not-to-use ('only want to hide it, or when unsure which actor'), and directs the agent to unreal_list_actors for disambiguation. This is model guidance.

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

• unreal_list_actorsA
  4.9/5.0
  Behavior5/5

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

  Annotations already provide readOnlyHint, idempotentHint, and non-destructive safety information. The description adds important behavioral context beyond that: it operates on the currently open level, the label field is the identifier other actor tools accept, and it specifies both the success JSON schema and the 'Error: <message>' failure format.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core purpose. The Args, Returns, and Examples sections each earn their place, and there is no filler or tautology. Despite being detailed, every sentence serves a practical purpose for correct invocation.

  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 covers scope, filtering, pagination, output schema, error format, and cross-tool identifier semantics. It also includes usage examples that tie into sibling tools. Nothing needed to call this tool correctly is missing.

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

  Parameters4/5

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

  The description documents all nested parameters inside the params object, including substring match semantics, limits, defaults, and offsets. Although the JSON schema already describes these fields, the description packages them in a tool-ready way and adds the crucial note that the label field is used as an identifier by other actor 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 opens with a specific verb and resource: 'List actors placed in the currently open level, with their transforms.' This clearly distinguishes it from sibling tools such as unreal_list_assets, unreal_spawn_actor, and unreal_delete_actor, so an agent can select it confidently.

  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 Examples section explicitly states when to use the tool ('what's in this level?', finding a label for unreal_set_actor_transform) and when not to use it ('looking for unplaced content (use unreal_list_assets)'). This gives an agent direct routing guidance with a named alternative.

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

• unreal_spawn_actorA
  5/5.0
  Behavior5/5

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

  Annotations already mark this as non-read-only and non-idempotent, but the description adds explicit behavioral detail: each call creates a new actor and calling twice spawns two copies. It also documents failure return format and the specific error case for a non-existent asset_path.

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

  Conciseness5/5

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

  The description is well-organized with Args, Returns, and Examples sections. Every sentence adds value, and the most important behavioral caveat about duplicate spawning is front-loaded.

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

  Completeness5/5

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

  Covers all necessary invocation details: parameter semantics, defaults, output shape, failure behavior, source of valid inputs, and when to avoid this tool. The presence of an output schema is supportive, but the description is self-sufficient even without it.

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

  Parameters5/5

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

  Schema description coverage is reported as 0%, so the description carries the full burden. It compensates thoroughly by explaining every parameter: asset_path, location units and default, rotation units, scale multipliers, and optional label.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: placing an existing content asset into the current level as a new actor. It also distinguishes itself from siblings by specifying where asset_path comes from and by naming what it is not for.

  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 'Use when' and 'Don't use when' guidance, including the concrete alternative unreal_set_actor_transform for moving existing actors. It also tells the agent to source asset_path from unreal_list_assets, leaving little to inference.

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