unreal-mcp

by sam-david

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Many tools are clearly distinct, but there are clusters that could cause misselection: run_stat_command overlaps with execute_console_command, build_cook_run and package_project both package the project, and reset_niagara_system vs reinit_niagara_system are similar. Descriptions help clarify, but the volume of tools increases ambiguity.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but there are notable deviations: sc_ prefix for source control (sc_status vs source control), run_* vs execute_* for similar actions, and inconsistent granularity like build_target vs build_cook_run vs package_project. Still readable, but not a clean consistent scheme.
Tool Count1/5
127 tools is extremely excessive for any MCP server, even for a complex engine like Unreal. This volume overwhelms agents and makes tool selection costly. A more focused set of 30-40 tools would likely cover the same workflows.
Completeness4/5
The toolset covers an impressive breadth of Unreal workflows: asset management, actor manipulation, blueprints, materials, animation, Niagara, build automation, testing, source control, profiling, and world partition. Minor gaps exist (e.g., explicit level save/manage), but overall the surface is remarkably complete for its scope.
Average 3.4/5 across 127 of 127 tools scored. Lowest: 2.4/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/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 merely states 'Compile a Blueprint' without revealing side effects, whether it saves/overwrites, what happens on compilation errors, or any required setup. This is too vague to inform an agent about potential impacts or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is efficiently minimal, though perhaps overly terse. It earns its place but leaves significant information unsaid, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a compilation tool with no output schema, no annotations, and only one self-explanatory parameter, the description is insufficient. It does not mention expected outcomes, compilation errors, or whether the compiled asset is saved/updated, leaving the agent without critical context for such an operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully covers the single parameter 'blueprint_path' with a clear description ('Blueprint asset path'). The tool description adds no additional semantic detail about the parameter, but since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compile') and resource ('Blueprint'), making the basic action clear. However, it lacks detail on what compiling entails and does not differentiate from related sibling tools like create_blueprint or get_blueprint_info beyond the verb itself. It is a minimal, generic statement rather than a fully clarifying one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as build_target, create_blueprint, or recompile_material. No prerequisites, expected usage context, or exclusions are provided. The description is purely a one-line action statement with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavioral traits. 'Rename or move' implies mutation but provides no details about side effects, such as whether references are updated, whether paths must be within the same directory, or whether the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient, but it is under-specified. It does not mention path handling, behavior on failure, or relationship to siblings. It is not as empty as a pure tautology, but it scores lower than a well-structured description that includes tradeoffs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description must compensate. It does not explain what happens to the asset's references, whether both paths must exist, or the meaning of failure. The presence of many asset-related sibling tools increases the need for contextual differentiation, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('Current asset path' and 'New asset path'), so the schema already conveys the meaning. The description adds no additional semantic value beyond what the schema provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource: 'Rename or move an asset.' This is clear but does not differentiate from sibling tools like duplicate_asset or delete_asset. It lacks any scoping details (e.g., what counts as a move vs. rename) that would help an agent choose this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or compare with sibling tools like duplicate_asset or delete_asset. The agent is left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Build a plugin standalone' gives no information about side effects, environment requirements, output generation, or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no unnecessary words, but the phrasing 'Build a plugin standalone' is awkward and underspecified. It is concise but not well-structured or sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build tool with three parameters, no output schema, and no annotations, the description leaves significant gaps: it doesn't explain what 'standalone' means, the role of 'platform', or what the build output is. Sibling build tools add confusion without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for all three parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Build' with 'plugin' as the resource, which is specific and distinguishes from sibling tools like build_target or package_project. However, 'standalone' is ambiguous—it could mean building the plugin in standalone mode or building a standalone plugin—so it's not perfectly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as build_target, build_cook_run, or package_project. No prerequisites, exclusions, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Create a new Blueprint class' without mentioning side effects (e.g., asset creation on disk, automatic compilation, or whether existing assets are overwritten), leaving the tool's behavioral footprint completely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a simple creation tool, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description is insufficient. It does not explain what a Blueprint class is, what the tool returns, or any prerequisites or side effects. Sibling creation tools like create_anim_blueprint appear similar, making additional context 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?
The input schema provides descriptions for all 3 parameters (name, path, parent_class) with 100% coverage, so the baseline is 3. The description adds no parameter-specific semantics, relying entirely on the schema for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and names the resource ('Blueprint class'), clearly stating the tool's action. It is distinguishable from sibling creation tools like create_anim_blueprint or create_material by explicitly naming 'Blueprint class,' though it does not elaborate on what a Blueprint class entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The description simply states the action without mentioning exclusions, prerequisites, or related tools such as compile_blueprint or spawn_blueprint_actor, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'Trigger the Data Validation framework' without describing what happens during validation, whether it is read-only or mutating, what output/return value to expect, or any side effects. This is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though it could benefit from an additional sentence to differentiate from siblings, which would improve usability without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of the closely named sibling 'validate_assets' and the absence of an output schema, the description is incomplete. It does not clarify what the Data Validation framework returns, how results are reported, or when this tool is preferred over similar validation/audit tools. The one-line description leaves the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter description 'Content directory to validate', so the baseline is 3. The tool description adds no extra meaning beyond the schema; it merely rephrases 'on assets' without providing context about the directory parameter's format, scope, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Trigger the Data Validation framework') and the resource ('assets'). However, it does not differentiate from the sibling tool 'validate_assets', which likely performs a similar validation role, so it lacks explicit distinction.
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 'validate_assets' or 'run_map_check'. There are no use-case examples, exclusions, or conditions, leaving the agent without basis for selecting this tool over its 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, the description carries the full burden of disclosure. It simply states 'Run all automation tests' without describing side effects, potential duration, failure modes, or whether it modifies project state. This is a broad operation that should warn about resource usage or that it runs everything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise in a useful way. It wastes the opportunity to convey important context, similar to the 'Process' example, where brevity is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations, output schema, or parameter details, the description should compensate by explaining what 'all' means, whether results are returned, and if it is safe to run. The existence of sibling tools (e.g., run_automation_test, run_automation_tests_by_category, get_test_results) makes the lack of context particularly problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Run' and identifies the resource as 'all automation tests,' which clearly distinguishes it from siblings like run_automation_test (single) and run_automation_tests_by_category (categorized). The word 'all' conveys broad scope, though it could be more explicit about whether it covers every test in the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as run_automation_test or run_automation_tests_by_category. There is no mention of prerequisites, filtering, or exclusions, leaving the agent to infer usage from the names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the search criteria. It fails to disclose return format, matching behavior, case sensitivity, or the meaning of 'tag' given the schema lacks a tag parameter. This leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for a simple search operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficient. It does not explain what the search returns, whether it returns full asset info or just names, or how tags relate to the provided parameters. More context is needed for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds no meaningful parameter detail and actually introduces confusion by mentioning 'tag' search without a corresponding schema parameter, potentially misleading the agent about query capabilities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for assets') and the criteria ('by name, class, or tag'), which distinguishes it from sibling list_assets and get_asset_info. However, 'tag' is not supported by the input schema (only query and class_filter exist), introducing slight ambiguity about the intended scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusion guidance is given. The description implies searching is the use case, but it does not differentiate when to use search_assets versus list_assets, get_asset_info, or other asset-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone carries the burden of behavioral disclosure. It only restates the action already implied by the tool name and offers no insight into side effects, persistence of changes, error handling, permissions, or return values. This is insufficient for an agent to understand the full impact of invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient, but its extreme brevity leaves out important details. Still, as a one-liner, it is well structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's reliance on parameters (including nested default objects) and the absence of an output schema, the description is far too sparse. It does not explain how spawning behaves when the blueprint path is invalid, how location and rotation defaults work, or what happens after spawning. The description is not complete enough for reliable invocation in non-trivial scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no mention of any of the four input parameters. Although the schema provides descriptions for 'label' and 'blueprint_path', the nested 'location' and 'rotation' objects lack explanations, and the description does nothing to clarify their meaning or defaults. With only 50% schema description coverage, the description fails to add semantics for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a concrete action ('spawn') and a specific resource ('an instance of a Blueprint class') with a location context ('in the level'). It distinguishes itself from the sibling 'spawn_actor' by explicitly limiting to Blueprint classes, making it unambiguous which tool to use for this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no comparison to alternatives, no preconditions, and no advice on when to choose this tool over 'spawn_actor' or other actor-related tools. It simply states what the tool does without explaining the situations in which it is the best choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says the modifier is 'applied,' with no mention of whether this mutates the asset persistently, requires saving, is reversible, or produces any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no wasted words. It is appropriately front-loaded and easy to parse, though it is terse and could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation operation with no output schema and no annotations, yet the description only provides the basic action. Missing are details about persistence, return values, error conditions, or any required preparation, leaving the description incomplete for an agent to use it reliably.
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 complete descriptions for both parameters (AnimSequence asset path, animation modifier class name), so the description adds no extra parameter semantics. Baseline 3 is appropriate because the schema covers 100% of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply') and the object ('an animation modifier to an animation sequence'), distinguishing it from sibling tools that create or get animation assets. It does not mention the specific modifier_class parameter, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description only states the action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. 'Clean' implies destructive action, but the description does not state whether files are deleted, whether the operation is reversible, or if special permissions are required. This lack of detail is a significant gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that clearly communicates the core action. It is appropriately sized for a simple tool with minimal parameters, containing no fluff or repetition.
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?
Although the tool is simple, the description lacks essential context such as when to run it in a build pipeline, what specific artifacts are removed, and possible side effects. With no annotations or output schema, the description is too sparse to fully guide an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'platform' is already described in the input schema with 100% coverage. The description adds no additional meaning to the parameter, so the baseline of 3 is appropriate; it neither enhances nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Clean') and a specific target ('build artifacts'), with a scope ('for the project'). It effectively communicates the tool's basic function, though it doesn't explicitly differentiate from sibling build-related tools like 'build_target'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or typical scenarios. It is entirely absent of usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral details. It only says 'create', without mentioning side effects such as whether the function is saved immediately, if existing ones are overwritten, or any permissions needed. The word 'reusable' adds minimal context but is inherent to the asset type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise and front-loaded. It is efficient, though it could arguably provide more substance without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, full schema coverage) and no output schema, the description adequately states the core purpose. However, the absence of annotations and behavioral context means the agent must infer what 'create' entails, such as saving behavior or overwrite policies, which could be ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both 'name' and 'path'. The description does not add any additional meaning beyond the schema, but the baseline is 3 because the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' and identifies the resource as a 'reusable material function', which clearly differentiates it from siblings like create_material or create_material_expression by the asset type. However, it doesn't explicitly contrast with these alternatives, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other creation tools. The description simply states the action without any context, prerequisites, or exclusions, leaving the agent to infer usage from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the core action without disclosing side effects (e.g., writing to disk, overwriting), required permissions, supported formats, or return behavior. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is concise, though the brevity comes at the cost of missing important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and sparse annotations, the description fails to provide essential context such as supported file formats, how the output path is interpreted, or how this tool compares to 'export_sequence_fbx'. The two parameters are well-documented, but the overall tool behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'asset_path' and 'output_path'. The description adds no additional meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export an asset to an external file format' clearly identifies the action (export) and resource (asset), and distinguishes from import/save operations. However, it does not differentiate from the more specific sibling 'export_sequence_fbx', so it misses the opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of how the output format is determined. The description only states the basic operation, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'detailed metadata' but discloses no behavior beyond that. Since no annotations are provided, the description carries the full burden, and it fails to mention that this is a read-only operation, what specific metadata fields are returned, or how the tool behaves when the asset path is invalid. This leaves the agent guessing about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of fluff. It earns high marks for conciseness, though the phrase 'detailed metadata' is vague and could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description must compensate by explaining what 'detailed metadata' entails and what the return format is. It does neither. For a simple getter with one parameter, this is a significant gap: the agent cannot reliably know what information will be available after calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter fully, including a clear description and example. The description adds no additional meaning beyond the schema, but per the rubric, high schema coverage (100%) yields a baseline of 3. There is no extra semantic value provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and target ('detailed metadata for an asset'), which is specific enough to distinguish it from sibling tools like list_assets. However, it doesn't explicitly contrast with similar asset-query tools such as search_assets or get_asset_references, so it falls short of 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 on when to use this tool versus alternatives. The description only states what the tool does, with no mention of use cases, prerequisites, or exclusions. Sibling tools like search_assets and get_asset_references occupy overlapping space, but no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'reinitialize' without explaining what reinitialization entails—whether it resets particle states, requires an existing Niagara component, or has irreversible effects. The agent cannot anticipate impact or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It's easy to parse and front-loads the core purpose. However, it is under-specified, sacrificing depth for brevity, which is a slight negative against an otherwise efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description should provide more context about when to use it, what reinitialization does, and how it relates to similar tools. The current text is insufficient to guide an agent reliably, especially given the existence of reset_niagara_system as a sibling.
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 documents actor_name as 'Actor with Niagara component', and the description's 'on an actor' simply restates that. Schema coverage is 100%, so the description adds no extra meaning about the parameter's format or constraints, though it does reinforce the actor's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reinitialize) and the resource (Niagara system) with a target actor. It is specific enough to distinguish from set_niagara_* tools, but it does not differentiate from the sibling tool 'reset_niagara_system', which could be synonymous or have a different meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like reset_niagara_system. It does not mention prerequisites, side effects, or exclusion conditions. The implicit usage ('when you need to reinitialize a system') is tautological and not 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?
With no annotations, the description carries the full burden of explaining behavior, but it only says 'Reset a Niagara system'. It does not disclose what resetting entails (e.g., stopping/restarting simulation, resetting to initial state, clearing effects) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the action and target. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and no output schema, the description lacks critical context. It fails to explain the tool's behavior in detail or how it differs from the closely named sibling 'reinit_niagara_system', leaving the description incomplete for an agent deciding when and how to use 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 input schema provides 100% coverage with the description 'Actor with Niagara component' for the single 'actor_name' parameter. The tool description adds only the phrase 'on an actor', which adds minimal semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset'), the object ('Niagara system'), and the target ('on an actor'). However, it does not differentiate from the sibling tool 'reinit_niagara_system', which likely performs a similar operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'reinit_niagara_system' or when a reset is appropriate. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the action and does not disclose potential side effects, whether execution is synchronous, what happens on error, or any implications of running arbitrary editor code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It is easy to parse and directly states the core function.
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?
Although the tool has only one parameter, it executes an arbitrary blueprint and the description offers no explanation of expected behavior, return values, or how it differs from related tools. With no annotations or output schema, the description needs to provide more context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter blueprint_path is already fully described in the schema ('Editor Utility Blueprint asset path'), and schema description coverage is 100%. The description adds no additional parameter meaning, which is acceptable under the baseline-3 rule for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and the target resource ('an Editor Utility Blueprint's Run event'), making the tool's function unambiguous. However, it does not explicitly differentiate this from the sibling tool run_editor_utility_widget, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as run_editor_utility_widget or other execution tools. There is no context about prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Force save' implies a mutation, but it doesn't explain side effects, permission requirements, or what 'force' actually does (e.g., overriding dirty flags or lock status). This is a significant gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key verb and resource, and contains zero unnecessary words. It is appropriately concise for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks critical context. There is no output schema and no annotations, and the description does not mention return values, success/failure behavior, or what 'force' entails. An agent could not fully assess the tool's impact or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single parameter asset_path, so the baseline is 3. The tool description adds no extra meaning beyond the schema, and neither explains the path format or whether it is project-relative or absolute.
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 'Force save a specific asset' clearly states the action (force save) and the resource (a specific asset). It implicitly distinguishes from sibling tools like save_all or resave_packages, but it does not explicitly name alternatives or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like 'use when an asset needs to be saved even if unchanged' or how it differs from save_all or resave_packages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. 'Query' implies a read-only operation, but no details about return format, error behavior, or requirements (e.g., files must be in source control) are disclosed. The description adds little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, directly front-loaded with the core action and resource. There is no unnecessary wording, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the schema covers the parameter, there is no output schema and no annotation context. The description does not explain what kind of status values will be returned, what happens for non-existent files, or any other behavioral expectations, leaving a significant information gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'paths' parameter, including a description of allowed path formats. The tool description itself adds no additional parameter semantics, but the schema fully compensates.
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 'Query source control status of file(s)' uses a specific verb and resource, clearly identifying what the tool does. It distinguishes itself from sibling tools like sc_checkout or sc_checkin, which perform actions rather than queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the name and sibling list imply it is for checking status before source control operations, the description does not explicitly state any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that LOD settings are configured but does not explain whether this overwrites existing settings, requires specific permissions, or produces any output. The mutation behavior is implicit but unelaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant filler. However, it is somewhat under-specified: 'LOD settings' is vague and does not enumerate what settings are involved, making the conciseness less useful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the presence of a closely related sibling tool (generate_lods), the description is not complete enough. It lacks usage guidance, behavioral details, and any indication of expected results, making it difficult for an agent to select this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters have clear descriptions ('Number of LODs to generate', 'Skeletal mesh asset path'). The tool description adds little beyond the schema, but the schema already fully covers parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Configure'), a resource ('skeletal mesh'), and a subject ('LOD settings'). It clearly states the tool's domain, though it does not distinguish itself from sibling tools like generate_lods, which might also deal with LODs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as generate_lods or reimport_skeletal_mesh. No context, prerequisites, or exclusions are mentioned, leaving the selection entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose whether the spawned actor becomes selected, what happens on invalid actor_class, or whether the level must be mutable; the single sentence 'Spawn a new actor in the current level' is the extent of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording, but it is somewhat under-specified for the tool's complexity; still, it earns its place as a clear purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters including nested objects and no output schema, the description lacks context about coordinate systems, defaults, and return behavior; it also fails to differentiate from sibling spawn tools, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not describe any parameters; the schema provides descriptions only for actor_class and scale, leaving label, location, and rotation with only type/default information. The description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'spawn' with resource 'actor' and scope 'current level', clearly conveying a creation operation distinct from siblings like list_actors or set_actor_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as spawn_blueprint_actor or spawn_niagara_*; it does not state prerequisites like having a level loaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Run data validation,' which is nearly identical to the tool's name. It does not disclose whether the operation is read-only, whether it modifies assets, what output it returns, or how errors are reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence ('Run data validation on assets in a directory.') that is concise, front-loaded, and free of unnecessary words. It communicates the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too sparse. It doesn't explain what validation entails, what results are produced, or how this tool relates to the sibling 'validate_data.' This is inadequate for an agent to select the correct tool among many similar asset and validation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'directory' with a full description ('Content directory to validate'), achieving 100% schema coverage. The tool description merely references 'a directory,' adding little beyond what the schema already states. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' and identifies the resource as 'data validation on assets' with a scope of 'in a directory.' It clearly states what the tool does, though it does not explicitly distinguish it from the sibling tool 'validate_data' or other asset-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'validate_data' or 'content_audit.' No prerequisites, contexts, or exclusions are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Generate collision') without revealing side effects (e.g., overwriting existing collision, modifying the asset permanently, or requiring a saved asset). This lack of transparency could lead an agent to invoke it without understanding its impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words, but it is under-specified. It lacks structure and doesn't provide any context such as default behavior or prerequisites. While concise, it sacrifices useful information, so it doesn't fully earn its place as a standalone guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (generating collision) with no annotations or output schema. The description fails to explain key context like whether existing collision is replaced, what the 'auto' type does, or whether the mesh must be saved. For a tool that modifies assets, this is incomplete and could lead to misuse.
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 100% of parameters with descriptions, so the baseline is 3. The tool description doesn't add parameter-level detail, but it doesn't need to since the schema already explains 'type' and 'mesh_path'. However, it doesn't clarify how different 'type' values (e.g., 'auto') affect behavior, so no additional value is provided 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 'Generate collision for a static mesh' uses a specific verb ('Generate') and identifies the exact resource ('collision' for a 'static mesh'). It clearly distinguishes from sibling tools like generate_lods or generate_lightmap_uvs, which target different mesh attributes. The purpose is unambiguous and concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as generate_lods or validate_assets. It does not mention prerequisites, exclusions, or typical scenarios. The only implicit usage is derived from the name, which is insufficient for an AI to decide between similar mesh-processing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only states the action without mentioning side effects like asset modification, whether compilation is triggered, or whether changes are reversible. For a mutation tool, this lack of transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately concise for a tool with only two parameters, though it sacrifices details that could improve usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description fails to provide critical context for a mutation tool, such as preconditions, side effects, or post-conditions. This makes the tool risky to invoke without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for both parameters ('Function name' and 'Blueprint asset path'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a custom function to a Blueprint' clearly states the action (add) and the resource (custom function to a Blueprint). It effectively distinguishes this tool from siblings like add_blueprint_component and add_blueprint_variable, which add other element types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage is only implied by the tool name and bare description, which is insufficient for an agent to decide between this and similar 'add' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. It fails to mention side effects such as whether the Blueprint asset is modified on disk, whether compilation is triggered, or what happens if the variable already exists. Since no annotations are provided, the description carries the full burden, and this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and well-structured, though it is quite terse and could provide a bit more detail without becoming verbose. This is efficient but border-line under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too brief to be complete. It does not explain side effects, prerequisites, or the significance of the default_value parameter. For a mutation tool that modifies a Blueprint asset, more context is needed for an agent to use 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?
The input schema has 100% description coverage for all 4 parameters, so the schema already explains variable_name, variable_type, blueprint_path, and default_value. The tool description adds no additional parameter semantics. According to the rubric, high schema coverage yields a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a variable to a Blueprint.' It uses a specific verb ('Add') and a specific resource (a variable), which distinguishes it from sibling tools like add_blueprint_component and add_blueprint_function. The purpose is unambiguous even though minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contrast with sibling tools (e.g., add_blueprint_function). The only implied usage is the obvious action, but there is no explicit context or alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only says 'compiles the project's C++ code' without explaining potential side effects like overwriting build outputs, build duration, dependencies, or failure modes. This is a significant gap for a build/mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but contains redundancy: 'Build a C++ target using UnrealBuildTool' and 'Compiles the project's C++ code' essentially restate the same idea. It could be condensed to one sentence without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-trivial build tool with four parameters and no output schema or annotations, the description is under-specified. It omits important context such as build output, typical execution time, or how it differs from sibling tools like build_cook_run, making it insufficient for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all four parameters (clean, target, platform, configuration) with 100% coverage. The description adds no extra parameter-level context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'build' and the resource 'C++ target' using UnrealBuildTool, specifically differentiating it from sibling tools like build_cook_run which also cook/run. It precisely conveys 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as build_cook_run or clean_project. There is no mention of typical use cases, prerequisites, or scenarios where another build-related tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It only states the export action and gives no information about side effects, file overwrite behavior, path expectations, or failure modes. This is a significant gap for an export operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the schema covers both parameters, the description lacks behavioral transparency and usage context. It is adequate for a straightforward export but leaves open questions about overwrites, prerequisites, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description itself adds no additional parameter context, but the schema already provides clear definitions for output_path and sequence_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact operation ('Export'), the resource ('a level sequence'), and the target format ('FBX'). This clearly distinguishes it from siblings like export_asset (generic asset export) and render_sequence (rendering rather than file export).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool over alternatives, or mention any prerequisites or exclusions. An agent gets no context on selecting this tool vs export_asset or render_sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only transparency source. It mentions the data returned but does not disclose potential side effects, error handling, or prerequisites like requiring a valid asset path. This is a significant gap for a getter 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?
One sentence, efficient and front-loaded, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is adequate but not complete. It lists the main output components (length, frames, bone data) but lacks details on return structure or error cases, especially 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 fully describes the only parameter (sequence_path) with 100% coverage. The description adds no new parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get info about an animation sequence' and specifies the info fields (length, frames, bone data), distinguishing it from generic get_sequence_info by the 'animation' qualifier. It is specific and resource-focused, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_sequence_info or get_asset_info. The description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the purpose but does not describe what the history contains, whether it includes both undo and redo, whether it is session-limited, or any side effects. No meaningful behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For this simple tool with one optional parameter and no output schema, the description is minimally adequate but does not explain return value structure, ordering, or any limitations. It leaves gaps about what the agent should expect, though the basic purpose is clear.
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% for the single 'count' parameter, which already explains it as 'Number of recent transactions to return'. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets undo/redo transaction history, using a specific verb and resource. It distinguishes from siblings like 'undo' and 'redo' which perform the actions, though 'transaction history' is somewhat ambiguous about the exact contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when this is appropriate, what conditions warrant retrieving history, or how it relates to undo/redo actions. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as execution time, side effects, return behavior, or prerequisites. It only states the action without any additional context, so the agent has no information about what happens when tests are run.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise, although it lacks depth; structure is clean and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should indicate what the tool returns or whether it is asynchronous. It only says 'Run automation tests' without mentioning outcomes, results, or other behavior, making it incomplete for an execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the 'category' parameter with examples and a clear meaning. Schema description coverage is 100%, so the baseline is 3. The description adds no extra semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Run' and the target 'automation tests' with a specific filter 'matching a category pattern'. This differentiates it from sibling tools like run_all_automation_tests and run_automation_test by indicating a category-based selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus run_automation_test or run_all_automation_tests. It does not mention alternatives or exclusions, leaving the selection entirely up to the agent.
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 fails to mention that reverting is likely destructive (discarding local changes), whether it requires prior checkout, or if it reverts to a specific revision. This omission is significant for a source control mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is somewhat under-specified, missing critical detail about behavior, so it doesn't fully earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially destructive tool with no annotations and no output schema, the description is incomplete. It lacks context about side effects, return values, or prerequisites, which is crucial for safe invocation despite the simple parameter 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 fully documents the 'paths' parameter with description 'File paths to revert', achieving 100% coverage. The tool description adds no new meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Revert file(s) in source control.' The verb 'revert' and resource 'file(s) in source control' are specific, distinguishing it from sibling tools like sc_checkout, sc_checkin, and sc_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention typical use cases, prerequisites, or conditions under which sc_revert is preferable over sc_checkout or sc_diff.
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 states the operation is a setter (implying mutation) but does not disclose possible failure modes, whether the property must already exist, how type coercion works, or whether the change is persistent or session-only. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is immediately scannable and contains no filler or redundant content. It efficiently states the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple generic setter, but the description omits observable behavior such as expected return value, error handling on invalid property names, or interaction with the Remote Control API's restrictions. Given the absence of annotations and output schema, a bit more context would make this a more complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters, including a clear example for actor_path and a minimal 'Value to set' for property_value. The description adds no additional parameter-level meaning, so the schema carries the burden. Baseline 3 is appropriate because schema coverage is 100%, but property_value's semantics are thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('property on an actor'), and specifies the API context ('Remote Control API'). It is sufficiently distinct from siblings like set_actor_transform and set_actor_tags because it targets an arbitrary named property, though it could more explicitly convey "arbitrary" or "generic."
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as set_actor_transform, set_actor_tags, or the Niagara-specific property setters. The description does not mention any prerequisites (e.g., actor must exist, property must be accessible) or when a more specialized setter would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a mutation (setting tags) but does not state whether tags are replaced or appended, whether empty array clears tags, or if there are any side effects. This lack of detail is a gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and every word is informative, achieving maximum clarity in minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is minimally adequate. It covers the core action but lacks important behavioral context like overwrite semantics and whether tags are validated against known tags, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters ('name' and 'tags'), so the description adds no additional semantic value. The description does not clarify tag format, uniqueness, or relationship between name and tags beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set tags on an actor.' clearly states the action (set) and resource (tags on an actor), making it distinct from many siblings. However, it does not explicitly distinguish from the similarly named set_actor_property, which could also be used for tag-like properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like set_actor_property or set_actor_transform. It does not mention prerequisites (e.g., actor must exist) or whether to use it for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies mutation but does not disclose whether updates are partial or absolute, what coordinate space is used, units for rotation, error behavior, or return value. The 'and/or' hint is the only behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with ten words, front-loaded and without filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three nested object parameters, no annotations, no output schema, and minimal description, the tool is under-specified. The description does not clarify partial updates, required actor checks, or rotation format, making it insufficient for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'name' has a description). The description lists the three transform properties but adds no semantic meaning beyond their names—e.g., units, coordinate system, or that each property is independently optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 sets the location, rotation, and/or scale of an actor, specifying both the verb and the resource. It distinguishes from generic sibling tools like set_actor_property by naming the specific transform components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as set_actor_property or spawn_actor. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Configure' without explaining side effects, whether it overwrites existing streaming sources, prerequisites, or reversibility. This is vague for a mutation tool and leaves the agent without critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no unnecessary words, but could arguably include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only two parameters, the description is too minimal. It does not explain what a streaming source component is, how the radius interacts with the actor, or any side effects. An agent lacks sufficient information to predict the tool's impact, making this incomplete for safe 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 description coverage is 100%, with clear descriptions for both `actor_name` and `radius`. The tool description adds no additional parameter meaning, but the schema already handles this, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Configure') and the specific resource ('streaming source component on an actor') with context ('for World Partition'). This distinguishes it from sibling tools like set_actor_property or set_data_layer_state, though it could be more explicit about what 'configure' entails.
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 phrase 'for World Partition' implies the tool is intended for World Partition workflows, giving some usage context. However, it does not explicitly state when to use this tool over alternatives (e.g., set_actor_property) or any exclusions, leaving the guidance largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely states the action 'Bind an actor to a level sequence' without mentioning side effects (e.g., whether existing bindings are overridden), required permissions, or return values. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains no redundant or irrelevant information. It is highly concise and well-structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should explain side effects, prerequisites, or return behavior. It provides none of this, leaving the tool contextually incomplete for an agent that needs to understand the full impact of invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (actor_name and sequence_path). The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Bind' and the resource 'actor to a level sequence', distinguishing it from sibling tools like add_track or create_level_sequence. The phrase 'for animation' adds context but doesn't obscure the primary action. It is specific and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_track or set_playback_range. No exclusions, prerequisites, or contextual hints are provided. The description only states the action, leaving the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., modification of the blueprint asset), persistence, or error conditions. 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 sentence with no filler, front-loading the action and target. Maximum conciseness without sacrificing clarity.
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 3 parameters, no output schema, and no annotations. The description is too brief to cover prerequisites, behavior on failure, or relation to the blueprint asset (e.g., whether it saves or requires an open blueprint). It only communicates the core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information beyond what the schema's property descriptions provide, but no deduction is needed since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Add a component') on a specific resource ('a Blueprint'), which clearly distinguishes from sibling tools like add_blueprint_variable and add_blueprint_function. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The tool name and description imply its use, but there is no explicit context or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning side effects such as whether it replaces the existing material, persists changes, requires specific permissions, or affects the slot index behavior. This lack of behavioral context leaves the agent without safety or consequence information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Apply a material to an actor's mesh component.' It is front-loaded with the action and target, contains zero wasted words, and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description is minimal and does not explain what applying a material entails in terms of persistence, replacement behavior, or any prerequisites. For a straightforward tool, more context is still needed to fully understand the operation's effects and expectations.
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 100% coverage with descriptions for all three parameters ('actor_name', 'slot_index', 'material_path'). The description adds no extra parameter information beyond what the schema already offers, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('apply') and resource ('material to an actor's mesh component'), making the tool's purpose clear. It distinguishes itself from generic set_actor_property by naming the specific operation, though it does not explicitly compare itself to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need to apply a material to an actor's mesh component. However, there is no explicit guidance on when not to use it or mention of alternatives (e.g., set_actor_property). The description does not provide exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. Executing a script can have arbitrary side effects, but the description does not mention potential modifications, required permissions, or whether changes are reversible. The only added context is 'CI/CD automation,' which is vague and does not address the actual 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, concise sentence that is front-loaded with the action and resource. Every word contributes to meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool that executes an external script. It lacks context about what happens after execution, what a 'target' is, how failures are handled, or any safety/usage caveats. With no output schema or annotations, the one-line description is insufficient for an agent to use this tool confidently in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for target, script_path, and additional_args. The description adds no additional semantic value for parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute a BuildGraph XML script for CI/CD automation.' The verb 'Execute' and resource 'BuildGraph XML script' are specific, and the CI/CD context distinguishes it from sibling build/execution tools like build_target or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or contrast with siblings such as build_target, run_gauntlet, or execute_console_command. The description simply states what it does, leaving usage decisions to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does not disclose that this likely modifies a material asset, requires compatible pins, or that connections are directional. The behavior beyond the literal action is entirely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. It immediately communicates the core action and target, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema or annotations, the description is too minimal. It does not explain the direction of wiring, default pin behavior, or side effects on the material asset. The agent would need to infer or explore to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond restating that two nodes are involved; it does not clarify the roles of from/to expressions or input/output pins. The schema already handles parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'wire' and names the resource 'material expression nodes,' clearly distinguishing it from sibling tools like connect_graph_nodes (which likely targets blueprint graphs) and connect_material_property (which connects material properties). The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the operation without any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It only says 'Connect' without mentioning that this modifies the material asset, may require saving, or whether it overwrites existing connections. This is a mutation tool with zero behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that directly states the purpose with useful property examples. No wasted words, perfectly sized.
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 modifies a material asset, but there is no output schema and no annotations. The description doesn't explain return values, side effects, or preconditions. Given the mutation nature, it should at least note the need to save or that existing connections are replaced. Not complete for safe 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 descriptions for all four parameters, so the baseline is 3. The description adds nothing beyond the schema; it only lists example properties that already appear in the enum. No additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (connect), the entities (an expression and a material output property), and gives concrete examples (BaseColor, Normal, etc.). This distinguishes it from sibling tools like connect_material_expressions, which likely connects expressions to each other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The description gives no context about prerequisites (e.g., material must be loaded) or when to prefer this over connect_material_expressions. Usage is only implied by the property list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only mentions running a commandlet and does not state whether the operation is read-only, returns a report, changes assets, or has performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is succinct and front-loaded with the core action. The mention of the ContentAudit commandlet is brief and adds specific technical context without unnecessary bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose but omits return behavior or output format, and there is no output schema or annotations to compensate. Given the tool's simplicity (no params), it is minimally adequate but leaves gaps about expected results.
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 an empty input schema, so schema coverage is 100% (vacuously). Per guidelines, a baseline of 4 applies; no parameter details are needed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs a content audit to identify costly or problematic assets, and mentions the ContentAudit commandlet. It distinguishes from sibling tools like validate_assets (which validates) and consolidate_assets (which consolidates), though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply describes the action without recommending usage contexts or excluding other asset-review tools, leaving the agent to infer suitability.
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 disclosing behavior. It only states the action itself, without detailing side effects, whether original actors are unchanged, what happens with references, or any required permissions. It does not contradict anything (since there are no annotations), but it adds minimal behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before 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 of five words. Every word contributes to the core purpose. It is highly concise and structured optimally for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation (duplication) with no annotations or output schema, yet the description only covers 'what' and 'by name'. It does not explain the offset's role relative to the original actors, whether the operation returns new actor identifiers, or any behavioral expectations (e.g., whether originals remain untouched). For a mutation tool with no output schema, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'names' is described as 'Actor names or labels to duplicate' and 'offset' as 'Offset for duplicated actors'. The description's phrase 'by name' reinforces the names parameter but adds no additional meaning beyond what the schema already provides. Since the schema fully documents both parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplicate') and resource ('actors') with a clear qualifier ('by name'). It distinguishes the tool from the sibling tool 'duplicate_asset' by specifying actors as the target. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, it does not state that to duplicate assets, one should use duplicate_asset. The only implied usage is that you need to know the actor names, but no explicit context or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention what happens if the destination path already exists, whether references are updated, or any failure modes. The description only states the basic action without side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded with the core action and resource, making it easy to scan. It could be more detailed, but that is a completeness issue, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely sparse for a tool with no output schema and no annotations. It does not clarify key details such as whether destination_path must include a new asset name, how collisions are handled, or whether the operation is recursive. This leaves the agent with unanswered questions for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (source_path and destination_path) are already documented in the schema. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Duplicate' with a clear resource ('an asset') and outcome ('to a new path'). It clearly distinguishes from sibling operations like rename_asset or delete_asset, which have different intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as rename_asset, import_asset, or duplicate_actors. There are no exclusions, prerequisites, or example scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Generate LODs' without disclosing whether existing LODs are overwritten, whether the mesh must be saved, or other side effects. This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant information. It is well-structured and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations or output schema, the description is too minimal. It doesn't explain the LOD generation process, requirements, or effects, leaving the agent without enough context for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for both parameters (lod_count and mesh_path). The description adds no additional parameter semantics beyond what the schema already includes, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates LODs for static meshes, using a specific verb and resource. It distinguishes from sibling tools like set_skeletal_mesh_lod, which targets skeletal meshes.
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. It doesn't mention prerequisites, differences from similar tools, or that it only applies to static meshes while set_skeletal_mesh_lod should be used for skeletal meshes.
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, but it only states the action without explaining return values, side effects, prerequisites, or how results are reported. This is minimal and leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and clearly states the core functionality.
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 minimal annotations, so the description needs to explain invocation and result behavior, which it does not do. While the single parameter is fully documented, the description is too sparse to be considered complete for an agent; it lacks context about what happens after running a test or how it relates to other tools like get_test_results.
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% for the single parameter, and the description's 'by name' aligns with the schema's 'Test name or pattern to run.' However, the description does not add meaningful new semantics beyond the schema, 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 runs a specific automation test by name, using a specific verb ('Run') and resource ('automation test'). It distinguishes from siblings like run_all_automation_tests and run_automation_tests_by_category by emphasizing 'specific' and 'by name.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like run_all_automation_tests or run_automation_tests_by_category. The description implies use when you know the test name, but does not explicitly state this or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states only the basic action ('check out') but does not explain side effects such as file locking, writable state changes, or the impact on local files. This is a significant transparency gap for a state-modifying operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous content. It is appropriately sized for a simple tool, front-loading the key action and resource without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema), the description is minimal but lacks crucial context about the source control workflow, such as locking behavior, prerequisites, or what 'check out' means in terms of local file state. The absence of annotations further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the parameter 'paths' already has a description "File paths to check out". The tool description adds no additional parameter semantics, format examples, or constraints beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check out') and resource ('file(s)') while distinguishing from sibling tools like sc_checkin, sc_revert, and sc_diff. It clearly identifies the operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sc_checkin or sc_revert. The description lacks any context for the appropriate workflow or scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the action but does not mention whether changes are persistent, require an asset save, or what happens if the parameter does not exist. No return behavior is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover return behavior and side effects. It does not, leaving the agent uncertain about success/failure signals. It is minimal for a simple setter but lacks contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all parameters, including the RGBA value object with ranges and defaults. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates a specific action (set) on a specific resource (vector parameter of a material instance). It distinguishes itself from sibling tools like set_material_instance_scalar and set_material_instance_texture by specifying 'vector'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative material setters or other vector setters. It does not state prerequisites such as the material instance being loaded or saved after modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it sets a float parameter, but fails to mention side effects (e.g., persistence), error conditions (e.g., missing component), or any impact on the simulation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point, with no redundant or irrelevant information. For the simplicity of the tool, this length is appropriate and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's simplicity, the schema, and the lack of annotations, the description still falls short. It omits critical context such as the need for the actor to have a Niagara component, potential parameter creation vs. setting existing ones, and how this relates to similar Niagara tools. The description alone is insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with basic descriptions for all three parameters, but the tool description adds no extra meaning beyond the schema. It does not clarify allowed value ranges, exact naming conventions for parameter_name, or how actor_name is resolved. Since schema descriptions are generic, the tool description provides minimal added semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set), the resource (float parameter), and the context (Niagara component). This distinguishes it from sibling tools like set_niagara_vector or set_niagara_bool, which target different parameter types. The verb+resource+scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as set_niagara_vector, set_niagara_color, or reset_niagara_system. There are no prerequisites, usage scenarios, or exclusions mentioned, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without detailing side effects, persistence, scope (e.g., whether it modifies the asset or just the viewport display), or any constraints. The word 'display' introduces ambiguity about whether this alters the underlying sequence asset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It states the essential purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with full schema coverage, but the description lacks crucial context such as when the change takes effect, whether a save is required, what errors could occur, or how 'display frame rate' differs from related sequence properties. For a mutation tool with no annotations or output schema, this is insufficient.
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 complete descriptions for both parameters (fps as 'Frames per second' and sequence_path as 'LevelSequence asset path'), so the schema already covers the semantics. The description adds no additional meaning or relationships beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'display frame rate of a sequence,' making the tool's purpose unambiguous. It also differentiates from sibling tools like set_playback_range, which target a different sequence property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool vs alternatives, no prerequisites, and no mention of circumstances that would favor this over other sequence-oriented setter tools. It offers no exclusionary or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects, performance impact, whether a background process is started, how to stop it, or what happens to existing captures. The meaning of 'capture' is vague and lacks operational 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 a single, front-loaded sentence with no redundant words. It conveys the essential action and purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, but the description omits critical context: how to stop the capture, whether it returns any data, and what side effects (e.g., file creation, performance overhead) occur. The existence of sibling stop_csv_profiling makes the lack of lifecycle guidance a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter (filename) with a description, so the baseline is 3. The tool description itself adds no extra parameter information, but the schema sufficiently documents the optional filename.
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 a specific action: 'Start CSV profiling capture' with a purpose ('for performance regression analysis'). It uses a specific verb and resource, distinguishing it from general start_trace, though it doesn't explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for performance regression analysis' provides context on when to use the tool, but there is no explicit guidance on when not to use it or mention of alternatives like stop_csv_profiling or start_trace. The usage is implied rather than clearly scoped.
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 mentions capturing the viewport and returning the file path, but omits details such as where the file is saved, whether it overwrites existing files, and any prerequisites (e.g., an active viewport). This is insufficient for a tool that creates a file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence states the core action, the second states the return value. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the schema covers the parameter, the description lacks critical contextual details such as where the screenshot is saved, error conditions (e.g., no active viewport), and file naming behavior beyond the schema default. Without annotations, the description should provide more context to ensure 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?
The single parameter (filename) is fully described in the schema with 100% coverage, including its default value. The description adds no further meaning about how the parameter behaves (e.g., whether it accepts a full path), so it provides no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture a screenshot') and specifies the target ('active editor viewport'), uniquely distinguishing this tool from siblings. It also mentions the return value (file path), which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., render_sequence) or any conditions. It only states what it does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'add' without mentioning side effects, validation behavior, whether existing tracks are replaced, or any required permissions. For a mutation tool, this is 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?
The description is a single sentence with no filler or redundancy. It is front-loaded with the verb and resource, making it extremely concise while still conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a complex sequence-editing suite, but the description omits context like whether the sequence and binding must already exist, or what happens if a track is added twice. However, the schema's binding_id description hints that bindings come from add_actor_binding or get_sequence_info, providing some context. The description is minimally adequate but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions and an enum for track_type, so the schema itself is sufficient. The description adds no additional semantics beyond the schema, which fits the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (add), the object (track), and the context (actor binding in a sequence). It is unambiguous and naturally distinguishes itself from sibling tools like add_actor_binding or set_playback_range by naming the exact operation and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as needing to create a sequence first or add an actor binding. It simply states the operation without any contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does not disclose whether the operation is destructive, whether it overwrites existing assets, or what failures occur. Only the action is stated, with no side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundancy. It is front-loaded with the verb and object, effectively communicating the core function despite omissions in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and no output schema, the description states the core purpose but lacks behavioral context, prerequisites, and alternative usage. It is minimally viable for a simple creation tool but leaves gaps for an agent needing to understand mutation and side effects.
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 descriptions for all three parameters (100% coverage), so the baseline applies. The description adds a semantic link by mentioning 'from an animation sequence', which maps to the sequence_path parameter, but does not add format or default details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Create' and clearly identifies the output resource 'animation montage' with its source 'animation sequence'. This distinguishes it from sibling tools like create_anim_blueprint and create_level_sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description merely states the action, leaving the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but it only states the core action. It does not mention what happens if a material with the same name exists, whether a default path is used, or any side effects of asset creation.
Agents need to know what a tool does to the world before 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 with no redundancy or filler. It efficiently communicates the tool's purpose without unnecessary detail.
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 only two parameters and a clear schema, and the description states the basic purpose. However, it lacks usage guidance and behavioral details that would make it fully self-sufficient, especially given the absence of annotations and 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 provides 100% coverage of the two parameters (name and path), including descriptions and defaults. The description adds no parameter-specific guidance, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the resource type as 'material asset', which clearly distinguishes it from sibling tools like create_material_function and create_material_instance. It is concise and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_material_instance or apply_material. There is no mention of prerequisites, exclusions, or context in which this tool is preferred.
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, but it only states the core action. It does not mention prerequisites (e.g., parent material must exist), overwrite behavior, or what side effects occur, making it insufficient for understanding the tool's full 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 single-sentence description is concise and front-loaded with the verb and object. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of annotations/output schema, the description is minimal but functional because the schema fully documents parameters. However, it lacks usage context and sibling differentiation, making it slightly below average for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described (name, path, parent_path). The description adds no additional parameter semantics beyond saying 'from a parent material,' which mirrors the parent_path description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a material instance from a parent material' clearly identifies the action (create), the resource (material instance), and the source (parent material). This distinguishes it from sibling tools like create_material or create_material_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_material or apply_material. The description only states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. While 'Delete' implies a destructive operation, it does not disclose whether the deletion is reversible, what happens to references, or any side effects. This leaves 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?
A single, tightly worded sentence communicates the core action, target, and selection criteria with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and parameter. However, the lack of usage guidance and behavioral transparency for a destructive action makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the parameter description already states 'Actor name or label to delete'. The tool description reinforces this but does not add new meaning beyond the schema, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an actor from the current level by name or label' uses a specific verb with a clear resource (actor) and scope (current level). It distinguishes itself from sibling tools like delete_asset and duplicate_actors by targeting actors specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as delete_asset for assets or select_actors for selection. The description lacks explicit context, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It simply states the action without clarifying whether the static mesh is modified or saved, whether the operation is reversible, or what context is required.
Agents need to know what a tool does to the world before 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 conveys the core purpose with no filler or redundancy. It is appropriately concise for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally coherent, but it lacks behavioral context and usage guidance. The schema covers the parameter well, yet the description does not fully explain the operation's effect or output, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and clearly describes mesh_path as the 'Static mesh asset path', so the description adds little beyond what the schema already provides. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Generate') and a clear resource ('lightmap UVs for a static mesh'), making the tool's purpose unmistakable. It also distinguishes itself from sibling tools like generate_lods and generate_collision by targeting UV generation specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what the tool does, with no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the graph is direct or transitive, whether it includes both hard and soft references, or what the response structure looks like. The term 'graph' is vague without further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and subject, with no unnecessary words or filler. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description needs to convey more about the graph semantics (depth, format, inclusivity). A two-parameter tool still requires explanation of what 'dependency and referencer graph' entails to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning. asset_path is minimally described in the schema, and direction is only self-evident through its enum values. With 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with a specific verb ('Get') and resource ('dependency and referencer graph for an asset'). It distinguishes itself from siblings like get_asset_info and search_assets by focusing on graph relationships.
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 intended usage is implied—when you need to know an asset's dependencies or referencers—but no explicit alternatives or when-not-to-use guidance is given. It does not contrast with similar content-auditing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It only states the action and does not disclose return format, read-only behavior, error conditions, or any side effects. The agent is left without clear behavioral expectations beyond a basic listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and resource. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, the description is minimally viable but incomplete. It does not describe the return value structure or any operational details, which would be expected for a tool with no annotations or 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 single parameter material_path is already described in the schema ('Material asset path') with 100% coverage. The description adds no further semantic detail, but schema coverage is high, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the action ('List all expression nodes in a material') with a clear verb and resource scope. It differentiates from sibling tools like create_material_expression or delete_material_expression by focusing solely on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_graph_nodes or when not to use it. Prerequisites like a valid material asset are not mentioned, leaving the usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'reimport... from its source file' but does not mention side effects like overwriting the existing asset, dependence on source file availability, or potential data loss. For a mutation operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence that states the action and target. It is front-loaded with the key information and contains no filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a one-parameter tool, the description is structurally adequate but lacks essential behavioral context such as overwrite behavior, prerequisites, or failure modes. With no output schema and no annotations, the description only partially completes the picture.
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 fully documents the only parameter 'mesh_path' with the description 'Skeletal mesh asset path'. The tool description adds no further semantic detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reimport' and resource 'skeletal mesh', clearly indicating an update of an existing asset from its source file. It is distinguishable from sibling tools like import_asset, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as import_asset. The usage is implied by the verb 'reimport', but there are no stated conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Run' without disclosing side effects, prerequisites, or whether execution may modify the project. This is especially risky for a tool that executes arbitrary widget code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that is front-loaded with the verb and resource. No extraneous words or repetition; highly efficient given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with complete schema coverage, the description provides the core action and parameter. However, it lacks any warning about potential side effects or execution context, which would be expected for a run-type tool with no annotations or 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 schema already describes 'widget_path' as 'Editor Utility Widget asset path' with 100% coverage. The description's 'by asset path' wording reinforces but adds no further semantic detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run'), the specific resource type ('Editor Utility Widget'), and the method ('by asset path'). This distinguishes it from the sibling tool 'run_editor_utility_blueprint', which targets a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The closely related sibling 'run_editor_utility_blueprint' is not mentioned, leaving the agent to infer use cases from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'full game instance' but fails to convey important traits such as side effects, duration, blocking behavior, or how results are returned. This is a significant gap for a test-launching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and no wasted words. It is concise and easy to scan, though it could have included more critical details without becoming bloated.
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 launches a full game instance, which is a complex operation, but the description lacks essential context such as prerequisites, output/result retrieval, or how it relates to get_test_results. With no output schema, the description should explain what happens after launch, which it does not.
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 each parameter is documented in the schema. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Launch') and resource ('Gauntlet test session via UAT'), making it clear this tool runs Gauntlet tests in a full game instance. This distinguishes it from sibling automation test tools like run_automation_test and run_map_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of running via UAT and in a full game instance implies the use case, but there is no explicit guidance on when to choose this over alternatives like run_automation_test or run_automation_tests_by_category. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the primary read action and does not disclose output format, path requirements, error behavior, or whether the diff covers working changes versus committed changes. This is a minimal statement with no added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one fully documented parameter, this is minimally viable. However, there is no output schema and no description of the return value or edge cases, leaving some ambiguity about what exactly the tool produces and under what conditions it is valid.
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 100% of the single parameter ('path' with description 'File path to diff'), so the description does not need to add much. The phrase 'modified file' adds slight contextual meaning to the parameter, but no format, absolute/relative path, or other semantic details are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('the diff for a modified file'), and the domain ('in source control'). It distinguishes this from sibling source-control tools like sc_status, sc_checkout, and sc_revert, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusion cases such as checking status first or behavior for unmodified files. Usage context is only implied by the phrase 'for a modified file.'
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 does not explain what happens to the previous selection (replaced or appended), how invalid names are handled, or whether any confirmation or return value is expected. This leaves the agent guessing about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for the simplicity of the tool, and every word contributes to stating the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description covers the core action but omits edge-case behavior (e.g., effect on current selection, handling of unknown actor names). For a simple tool this may be acceptable, but a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'names' parameter with a description 'Actor names or labels to select', giving 100% coverage. The tool description adds no additional detail beyond that, so the parameter semantics are fully handled by the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the editor's actor selection' uses a specific verb ('set') and a clear resource ('actor selection'), distinctly differentiating it from sibling tools like list_actors, spawn_actor, and delete_actor. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives, nor any mention of prerequisites or context. While it is the only selection-related tool among the siblings, the description does not explicitly state 'use this to select actors' or provide any situational cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects, whether the change is persistent, or what happens if the data layer doesn't exist. The only behavioral information is the state transition itself, which is already clear from the schema enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with direct language, front-loaded action, and no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two fully described parameters, the description is minimally adequate. However, it lacks context about when to use this tool (e.g., in relation to list_data_layers or get_loaded_cells), what the return behavior is, or any prerequisites, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the baseline is 3. The description restates the enum values already present in the schema without adding any new semantics or details about layer_name 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?
Description uses a specific verb 'Set' with a clear resource 'data layer' and enumerates the valid states (Loaded, Activated, Unloaded). This clearly distinguishes it from sibling tools like list_data_layers and get_loaded_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion cases. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects (e.g., overwriting existing values), error behaviors, or requirements (e.g., the actor must have a Niagara component). No mention of success/failure outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy or unnecessary details. It is appropriately concise for the tool's simplicity and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the schema covers all parameters, the description lacks information about error handling, return values, and usage context. Given no annotations and no output schema, the description is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions for all three parameters. The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Set') and identifies the resource ('a bool parameter on a Niagara component'), clearly distinguishing it from sibling tools like set_niagara_float and set_niagara_vector. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or when a different setter would be appropriate. Usage is only implied by the tool's name and minimal description.
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 description must carry behavioral detail. It only states the action without disclosing that tracing records data until stopped, may affect performance, or requires a connection. No mention of stop_trace.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words; it clearly communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity and complete parameter schema, but lacks behavioral context such as session lifecycle, return value, or prerequisites. Adequate for invocation but incomplete for an agent to assess side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema fully describes the channels parameter with default values and allowed options, so the schema covers semantics. The description's 'with selected channels' adds no additional 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 verb 'Start' with resource 'Unreal Insights trace session', specifying channels configuration. It distinguishes from siblings like stop_trace and start_csv_profiling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; it doesn't mention profiling use cases, prerequisites, or exclusions. Peers like start_csv_profiling exist but no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'calls a function' but gives no indication of potential side effects, required permissions, return values, or irreversible actions. This is a significant gap for a tool that invokes arbitrary exposed functions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no redundant words or filler, making it efficiently scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that calls arbitrary functions with no output schema and no annotations, the description is too minimal. It does not explain what kind of functions can be called, what the 'parameters' object should contain, what the response looks like, or any safety considerations. This level of under-specification is inadequate for a potentially powerful and arbitrary action.
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. Each parameter (preset_name, function_name, parameters) has a basic schema description, and the description adds a slight semantic link by mentioning 'Remote Control Preset', but it doesn't elaborate on the 'parameters' object structure or the relationship beyond what the schema already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Call a function') and the resource ('a function exposed via a Remote Control Preset'). It distinguishes this from sibling tools like get_preset_property/set_preset_property by focusing on invocation rather than property access. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'Remote Control Preset' and the context of sibling preset-related tools, suggesting it is for executing exposed functions rather than reading/writing properties. However, it provides no explicit when-to-use/when-not-to-use guidance or named alternatives, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the plugin requirement but does not state whether the operation is destructive, whether it checks pin compatibility, what the result of a successful or failed connection looks like, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a necessary caveat about the plugin requirement. There is no fluff or redundant information, making it efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of graph wiring (5 params, no output schema, no annotations), the description is too brief. It does not explain what a node ID is, how to obtain it (sibling tools like list_graph_nodes could help), what happens after wiring, or any expected return value. The plugin requirement is the only contextual detail, leaving the agent under-equipped.
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 basic descriptions for all five parameters. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. However, the parameters like source_pin and target_pin are only described as 'pin name', without further context on how to format them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Wire two node pins together in a Blueprint graph.' This uses a specific verb ('wire') and resource ('node pins in a Blueprint graph'), distinguishing it from sibling tools like add_graph_node or remove_graph_node which operate on nodes themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the action, but it does not explicitly mention when to use this tool versus alternatives like connect_material_expressions. The only additional guidance is the requirement for the optional C++ plugin, which is a prerequisite rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states what info is retrieved but does not disclose that the operation is read-only, whether any errors are possible, or what happens if the blueprint_path is invalid. Even though 'Get' implies a query, the description lacks explicit behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and lists the included info categories. No redundant or filler content exists.
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?
There is no output schema, so the description must convey return value expectations. It lists five key categories (class, variables, functions, components, graphs), which gives a reasonable sense of the response content. However, it does not specify the format or nesting, which keeps it just short of 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 fully documents the only parameter, blueprint_path, with its description 'Blueprint asset path'. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('Blueprint info'), and enumerates the specific categories of information included (class, variables, functions, components, graphs). This distinguishes it from sibling tools like get_asset_info or get_actor_properties, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention contexts such as inspecting a Blueprint before editing, nor does it exclude cases like non-Blueprint assets. The agent must infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Query' implies a read-only operation, but there is no explicit statement about side effects, return format, or whether it requires any specific editor state. The description is too terse to inform the agent of expected behavior beyond the innermost surface.
Agents need to know what a tool does to the world before 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, direct sentence with no filler, redundancy, or extraneous details. It is appropriately sized for a simple query tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is the only source of contextual information. It explains what the tool does but omits key details such as what the query returns, how results are presented, whether any side effects exist, or how it interacts with the world partition system. This is insufficient for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the rubric, a zero-parameter tool gets a baseline of 4 because the description need not compensate for parameter documentation. The single sentence adds no parameter-specific information, but that is acceptable here as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query currently loaded world partition cells' uses a specific verb ('Query') and a precise resource ('currently loaded world partition cells'). It clearly distinguishes this tool from siblings like list_actors or spawn_actor, none of which target world partition cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mentions of preconditions, or exclusions. There is no context about typical scenarios, and it does not reference any sibling tool or alternative approach. It is a bare statement without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not state side effects, return format, whether sublevel actors are included, or any other behavioral traits. More transparency is needed for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It front-loads the primary action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks essential context for an agent: it does not mention the return format (e.g., actor paths, names), any caveats about what 'all actors' includes, or the existence of name_filter. Without an output schema or annotations, these gaps remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (name_filter and class_filter), giving 100% coverage. The description adds little semantic value beyond mentioning class filtering, and it omits the name_filter parameter, but the schema itself compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' with a clear resource 'actors in the current level' and an optional filter. This clearly distinguishes it from sibling tools like spawn_actor, delete_actor, or get_actor_properties, and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating it lists actors in the current level, but it provides no explicit guidance on when to prefer it over alternatives or any exclusions. It does not mention when to use it vs. tools like select_actors or get_actor_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It mentions it runs multiple sub-steps, which is useful, but does not disclose potential side effects (e.g., overwriting existing output), prerequisites, duration, or failure modes. For a complex build/package operation, 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 two sentences, front-loaded with the primary action, and every word earns its place. It efficiently communicates the composite nature of the tool without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that orchestrates a multi-stage build and packaging pipeline, the description is minimal. It lacks information about output artifacts, completion criteria, or how it relates to sibling build/cook tools. The absence of annotations and output schema increases the need for more context, which is not provided.
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% (all three parameters have descriptions), so the baseline of 3 applies. The description does not add any parameter-level detail beyond what the schema already provides, such as valid platform values or the effect of 'compressed' on output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Package') and resource ('the project') with a clear goal ('for distribution'), and distinguishes itself from sibling tools by listing the full pipeline: 'Runs build + cook + stage + package.' This clearly communicates it as the all-in-one packaging operation vs. partial steps like build_target or cook_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for distribution and indicates it runs the full build/cook/stage/package pipeline, but it does not explicitly state when to use this over sibling tools (e.g., 'use this instead of running build_target then cook_content'). No exclusions or alternative guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the operation, but fails to mention whether it produces results, modifies the level, or has side effects. A single sentence does not convey enough behavioral detail for an agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and scope. It is front-loaded with the key verb and resource, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description leaves major gaps: it does not explain what 'Map Check' entails, what kind of results or errors to expect, or how the outcome is delivered. For an AI agent, this is insufficient to fully understand the tool's behavior and integration.
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 schema is empty, so the description need not elaborate on parameter meanings. The 0-param baseline of 4 applies, and the description does not contradict or miss anything relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run') on a specific resource ('Map Check validation') with clear scope ('the current level'). This distinguishes it from sibling validation tools like validate_assets or validate_data, which target other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states what it does without contextualizing typical usage scenarios or comparing to validation tools for assets/data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Execute' and gives examples, without revealing whether the command is read-only, returns output, toggles state, or has side effects. This lack of behavioral context is a significant gap for a tool that may modify viewport state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It includes the essential action and examples with no redundant or filler content, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, which are notable gaps given the existence of a similar sibling tool. The description does not fully self-contain the needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the parameter with examples ('fps', 'unit'), but the tool description presents examples as 'stat fps' which could be misinterpreted as the full command string rather than the parameter value alone. This inconsistency introduces ambiguity instead of enhancing clarity, even though schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Execute a stat console command' with concrete examples (stat fps, stat unit, stat memory), making it specific and distinguishable from generic console execution tools. The verb+resource pattern is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the 'stat' focus but does not explicitly state when to use this tool versus the sibling 'execute_console_command' or any other alternative. There is no explicit exclusion or comparative guidance, so usage is only implied rather than clearly directed.
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 side effects and requirements. It simply states the action without mentioning that the operation is permanent, whether it can be undone, or if any permissions are required. This is a significant gap for a mutation tool that changes source control state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is directly informative without any filler. Every word contributes to stating the tool's purpose, making it an excellent example of conciseness for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no annotations and no output schema. It fails to mention what happens on success (e.g., a status or revision number), whether the action is reversible, or any prerequisites like having checked-out files. Given the simplicity of the tool and the lack of structured metadata, the description should provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters ('File paths to check in' and 'Check-in description / commit message'), achieving 100% coverage. The description adds no additional meaning beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('check in') and resource ('file(s) to source control'), which is concise and unambiguous. It naturally distinguishes this tool from siblings like sc_checkout, sc_revert, and sc_diff, so there is no confusion about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to commit files to source control, but it provides no explicit guidance on when to choose this over alternatives, nor does it mention prerequisites like files needing to be marked for add or already under version control. There is no direct comparison to sibling tools, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does not disclose behavioral traits such as auto-destruction behavior, whether the spawned system returns a handle, or whether it persists in the world. The auto_destroy parameter is mentioned only in the schema, not in the description, leaving side effects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It front-loads the action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, nested objects, no annotations, and no output schema, the description is too sparse to fully inform an agent about return values, persistence, or parameter expectations. It relies heavily on the schema, which is incomplete (rotation lacks description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (location, system_path, auto_destroy have descriptions; rotation does not). The description adds no additional parameter semantics beyond the schema, and it does not compensate for the missing rotation documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Spawn' with a clear resource 'Niagara particle system' and scope 'at a world location'. This clearly distinguishes it from sibling tools like spawn_niagara_attached and set_niagara_*.
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 phrase 'at a world location' implies this is for world-space placement, but there is no explicit guidance on when to use this vs alternatives such as spawn_niagara_attached or when not to use it. It provides implied context without exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'create' without disclosing behavioral traits like whether the tool overwrites existing assets, requires specific permissions, or returns a path. For a mutation tool, this is 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?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding (verb, resource, target). It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimal but adequate for selection. However, it lacks context about preconditions (e.g., skeleton_path must point to a valid skeleton asset) and post-conditions (e.g., asset saved to content directory). No output schema exists, so return values are not required, but behavioral context is sparse.
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% – all three parameters have descriptions. The tool description adds no additional parameter meaning beyond 'target skeleton' and 'Animation Blueprint', which is already inherent in the purpose. Baseline 3 is appropriate when the schema fully documents 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 ('Create') and resource ('Animation Blueprint') with a clear target ('a target skeleton'), distinguishing it from sibling tools like create_blueprint and create_anim_montage. It fully states the tool's purpose in one sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating animation blueprints, but provides no explicit 'when to use' or alternatives. It does not mention prerequisites like skeleton asset existence or when one should prefer this over create_blueprint. Guidance is implied by the resource type itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action (create) without mentioning side effects like overwriting existing assets, permission requirements, or return values, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, clearly stating the action and purpose. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters, and the schema covers them fully. However, the description omits behavioral details such as what happens if the asset already exists or what the function returns. Given its simplicity, a score of 3 is fitting.
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 fully documents both parameters with descriptions, giving 100% coverage. The description does not add parameter-specific semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' with the resource 'LevelSequence asset' and adds context 'for cinematics,' clearly distinguishing it from sibling tools like create_blueprint or create_anim_blueprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a LevelSequence asset is needed for cinematics, but does not explicitly compare with alternatives or state when not to use it. There is no exclusion guidance, only an implied use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose side effects, whether a material must already exist, behavior on invalid paths, or any error conditions. For a mutating operation, 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?
A single, clear sentence that front-loads the action and resource, followed by useful examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple node-adding tool, the description is minimally sufficient, but it lacks context about how this fits into a broader workflow (e.g., adding a node is separate from connecting it). No output schema or annotation support increases the burden, but the operation itself is straightforward.
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 descriptions for all parameters (100% coverage), so the baseline is 3. The description adds value by giving concrete examples of valid expression_class values, but does not elaborate on x/y placement 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 uses a specific verb ('Add') and resource ('expression node to a material's graph'), with concrete examples (TextureSample, Multiply, Constant3Vector). This clearly distinguishes it from sibling tools like create_material or connect_material_expressions.
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 purpose implies usage (add a node to a material graph), but no explicit guidance is given about when to use this tool versus alternatives like add_graph_node or connect_material_expressions. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states a read-only listing action, but does not mention what happens if the actor is not found, whether the list includes nested components, or any side effects. For a simple get operation, it adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It gets straight to the point, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema or annotations, the description gives the core purpose but omits return format (e.g., names, types), error behavior, and any filtering options. It is minimally viable but leaves gaps about what the returned list contains.
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 for the single parameter 'name' is 100% (description: 'Actor name or label'), so the schema fully documents it. The tool description adds no extra meaning to the parameter, but since the schema already covers it, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all components on an actor' clearly states the specific action (list) and the resource (components) with the target (actor). It effectively distinguishes itself from sibling tools like get_actor_properties (properties vs components) and list_actors (all actors vs components of one actor).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need to see components belonging to an actor. However, it provides no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites. It doesn't mention whether the actor must exist or how it relates to tools like get_actor_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely restates the action without disclosing return format, error behavior, or side effects. For a getter, this is minimal but lacks useful context like what happens if the property doesn't exist.
Agents need to know what a tool does to the world before 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, succinct sentence that immediately states the action and resource. No redundant words or filler, making it exceptionally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema, but the description does not elaborate on the return value or usage nuances. Given the lack of annotations, a bit more context (e.g., that the value is returned directly) would improve completeness, though the current level is adequate for a basic getter.
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% for both parameters (preset_name and property_name), so the schema already documents them. The description adds no additional parameter context, hitting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a property value from a Remote Control Preset. It uses a specific verb ('Get') and resource, and differentiates from siblings like set_preset_property and call_preset_function by focusing on reading a value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading exposed properties from a preset, but does not explicitly state when to use it over alternatives like set_preset_property or call_preset_function. No exclusions or alternative-naming is provided, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Get' implies read-only, but the description does not state potential errors, permission requirements, side effects, or return format. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and scope in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is adequate but not complete. It lacks return value details, error behavior, and any usage context, though the parenthetical gives a hint about the output structure. With no output schema or annotations, more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'sequence_path' clearly described as 'LevelSequence asset path'. The description adds context about the return structure (bindings, tracks, sections) which helps understand the parameter, but it does not add details beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full structure of a level sequence, specifying the components (bindings, tracks, sections). This distinguishes it from sibling tools like get_anim_sequence_info (for anim sequences) and create_level_sequence (for creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to inspect a level sequence's structure, but does not provide explicit when-to-use guidance, alternatives, or prerequisites. It is not misleading, but the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain whether the import overwrites existing assets, what side effects might occur, or what the return value indicates. It only states the basic operation without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any filler or unnecessary detail. Every word contributes to the meaning.
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 relatively simple with two well-documented parameters, but the description omits any information about return values, potential errors, or behavioral nuances. Given the lack of annotations and output schema, the description could do more to fully inform the agent, yet the basic purpose is clear.
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 100% coverage with clear descriptions for both parameters (source_file and destination_path). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Import'), the resource ('external file'), and the target context ('into the project'). It also gives concrete examples of supported formats (FBX, PNG, WAV) and is easily distinguished from sibling tools like export_asset or delete_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an external file needs to be brought into the project, but it does not provide explicit guidance on when not to use it or mention alternative tools. There are no exclusions or conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'list assets,' providing no insight into return format, side effects (if any), or behavior beyond the obvious. It does not describe what the response looks like or any nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, and contains no filler. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description should at least hint at the return format. It doesn't mention what the list contains (e.g., asset paths, names), nor does it note the recursive default. It is minimally adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-defined. The description adds minimal value by mentioning the optional class filter, but it doesn't elaborate on directory or recursive behavior beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assets in a content directory with an optional class filter. This distinguishes it from related tools like search_assets (which searches) and get_asset_info (which gets details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a straightforward listing operation but provides no explicit guidance on when to choose this over alternatives like search_assets. It does not state when not to use it or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' implies a safe read-only operation, but it does not disclose what is returned (e.g., names vs. full paths), whether it includes disabled tests, or if any project state is required. The behavioral disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word is meaningful and directly explains the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but minimal. It does not mention the return format or how it fits with sibling tools, so an agent may need to infer what 'available' means or how filtering works. The description is sufficient for basic use but lacks context for borderline cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the sole parameter 'filter' is described as 'Filter tests by name substring'. The description itself does not mention the parameter, so it adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to list available automation tests in the project. The verb 'list' is specific, and it distinguishes the tool from sibling tools like 'run_automation_test' and 'run_all_automation_tests', which are about execution rather than enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list contains many related automation-test tools (e.g., run_automation_tests_by_category, get_test_results), but the description does not mention when to prefer this one or how it differs from them.
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. The verb 'List' implies a read-only operation, and the scope ('all nodes in a Blueprint's event graph') adds context, but the description does not explicitly state non-mutating behavior, error handling, output format, or ordering. This is acceptable for a simple list but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence of eight words, directly stating the tool's function. It is front-loaded, contains no redundant information, and is appropriately sized for a straightforward listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose but omits information about the return value (e.g., what node data is included) and any prerequisites like requiring a valid Blueprint path. This could hinder an agent that needs to chain this with graph manipulation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter blueprint_path is already fully described in the schema as 'Blueprint asset path' (100% coverage). The tool description adds no extra meaning about the parameter beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all nodes in a Blueprint's event graph. The verb 'List' and the resource 'nodes in a Blueprint's event graph' are specific and differentiate it from graph mutation tools like add_graph_node or remove_graph_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_blueprint_info or add_graph_node. It does not mention use cases, prerequisites, or exclusions, leaving the agent to infer its role solely from the name and one-sentence description.
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 transparency. While it states the operation (queue a job), it does not disclose effects such as whether rendering starts immediately, what happens to existing jobs, or any prerequisites. Minimal behavioral detail is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the key action and resource, making it easy to parse and understand quickly.
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 relatively simple with two parameters and no output schema. However, given the absence of annotations, the description leaves some ambiguity about expected return values or potential side effects. It is minimally complete for the narrow scope but lacks richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (sequence_path and output_directory), covering 100% of the schema. The description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Queue' and a specific resource 'a Movie Render Queue job for a sequence', clearly distinguishing it from sibling tools such as take_screenshot or export_sequence_fbx. It is concise and unambiguous 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rendering a sequence via Movie Render Queue, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Given the sibling tools, there is no comparison or guidance, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'resave' and names the commandlet. It does not disclose that this overwrites package files, may be a heavy operation, or that it affects all assets, which is important for a bulk mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and scope, and includes the commandlet detail without any filler. Deserves full marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, and the description is adequate for basic understanding. However, as a bulk mutation operation it would benefit from a warning about destructive side effects or a note about expected runtime, so completeness is only partially addressed.
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 does not mention the optional 'directory' parameter, but the input schema fully documents it with 'Limit to a specific content directory', so schema coverage is 100% and no additional description is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Bulk resave'), a clear scope ('all packages in the project'), and the underlying commandlet ('ResavePackages'), making it easily distinguishable from sibling save/asset utilities.
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 phrase 'all packages in the project' implies a project-wide resave workflow, but the description gives no explicit when-to-use context, exclusions, or alternatives such as save_all or save_asset.
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 burden of behavioral disclosure, but it only states the basic action. It does not explain scope (all loaded assets vs. entire project), potential side effects, reversibility, or permission requirements, which is especially important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It includes a useful clarification ('dirty' = modified) without waste, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimally viable but leaves ambiguity about the exact scope of 'all' and any consequences or return values. It provides enough to operate, but lacks richer context that could be expected without annotations.
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 the description need not explain parameter details. The baseline of 4 applies; the description correctly avoids inventing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the specific resource ('all dirty (modified) assets'), which distinguishes it from siblings like save_asset (singular) and resave_packages (packages). The parenthetical clarifying 'dirty' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as save_asset or resave_packages. There is no mention of contexts, exclusions, or prerequisites, leaving the agent to infer usage on its own.
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 states only the action, without mentioning side effects (e.g., changes to source control status), prerequisites (e.g., file must exist), or potential failures. This is a significant omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, efficiently conveying the tool's purpose with no redundant information. It is exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and a simple action, the description is minimally adequate. However, it lacks important contextual details such as error behavior, idempotency, or what happens after marking files for add. No output schema exists, so the description could have provided more clarity on expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter description 'File paths to mark for add', which mirrors the tool description. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark'), the object ('new file(s)'), and the domain ('in source control'). It distinguishes itself from sibling source control tools like sc_status, sc_checkout, sc_checkin, sc_revert, and sc_diff by focusing on adding new files.
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 phrase 'new file(s)' implies this tool is for untracked files, subtly indicating when to use it. However, it does not explicitly mention alternatives or when not to use it, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the action and provides no information about side effects, persistence, or prerequisites (e.g., whether the material instance must be loaded or whether the parameter must already exist). It adds no transparency beyond the schema description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the operation and is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, but with no annotations or output schema, the description should provide more context (e.g., whether it modifies the asset, persists, or requires a loaded material instance). The schema covers parameters, but the description alone is thin for guiding an agent safely, so it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description ('Material instance asset path', 'Scalar parameter name', 'Parameter value'). The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a scalar parameter on a material instance.' It uses a specific verb ('set') and a specific resource ('material instance') with a specific parameter type ('scalar'), which distinguishes it from sibling tools like set_material_instance_vector and set_material_instance_texture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to set a scalar parameter), but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Sibling tool names provide implicit context, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Set a vector parameter' without mentioning side effects, permissions, required component existence, or error behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is front-loaded with the core action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and complete parameter schema, the description is adequate but lacks usage context and behavioral details. Without annotations, an agent would not know about side effects or prerequisites, leaving clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described (actor_name, parameter_name, value). The description does not add additional semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set a vector parameter' and the target resource 'a Niagara component'. It distinguishes itself from sibling tools like set_niagara_float, set_niagara_color, and set_niagara_bool by specifically mentioning 'vector'.
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 vector parameters on Niagara components based on the type, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. However, it only states the basic action without mentioning side effects (e.g., persistence, runtime impact), failure behavior, or required permissions. The phrase 'exposed via a Remote Control Preset' hints at context but does not reveal behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, efficiently communicating the core operation. It is front-loaded and appropriately sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter setter with no output schema and no annotations, the description is adequate but thin. It does not mention success/failure semantics or prerequisites beyond the property being 'exposed', which leaves some gaps for an agent deciding whether to invoke 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 input schema provides 100% coverage with descriptions for all three parameters (value, preset_name, property_name). The description adds no additional parameter semantics beyond restating 'property value', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('property value exposed via a Remote Control Preset'), clearly distinguishing it from sibling tools like get_preset_property and call_preset_function. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'set' in contrast to the sibling 'get' and 'call' tools, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action and does not mention side effects, requirements (e.g., actor must be valid), return behavior, or cleanup semantics. For a spawn operation, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste, perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and no output schema, the description is minimally viable. However, it lacks behavioral transparency about return values or error handling, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described (actor_name, system_path). The description adds no additional parameter meaning, so the 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 'Spawn a Niagara system attached to an actor' clearly states a specific verb (spawn), resource (Niagara system), and attachment target (actor), distinguishing it from the sibling spawn_niagara_at_location which spawns at a location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (attaching to an actor) but does not explicitly mention alternatives or exclusions. It could be strengthened by noting that spawn_niagara_at_location is the choice when no actor attachment is desired, but currently it lacks such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (stop and save) but does not reveal side effects, what happens to captured data, whether a running session is required, or any error cases. This is minimal disclosure for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It conveys the primary action and the secondary save behavior without redundancy, earning a perfect conciseness score.
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 zero-param tool with no output schema or annotations, the description covers the basic action but misses contextual details such as requiring an active profiling session, what 'save results' means in terms of file location or format, and any return value. The pairing with start_csv_profiling is only evident through the sibling list, not the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0-param tools is 4. The description adds no parameter-specific information, but none is needed since there are no parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 stops CSV profiling capture and saves results, using a specific verb and resource. It distinguishes from the sibling tool 'start_csv_profiling' by explicitly mentioning the stopping and saving behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used after start_csv_profiling or describe any preconditions, making the usage context entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It only says 'Remove an expression node' without disclosing side effects like breaking connections, irreversibility, or whether the material needs recompilation. This is a simple restatement of the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. No wasted words or unnecessary detail.
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 delete tool with two well-documented parameters and no output schema, the description is adequate. It identifies the specific domain (material graph) and the operation, which is sufficient for an AI agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'material_path' and 'expression_name' having clear descriptions. The tool description adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove an expression node from a material graph' uses a specific verb ('Remove') and explicitly identifies the resource ('expression node from a material graph'). This clearly distinguishes it from sibling tools like 'delete_asset' and 'remove_graph_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as 'remove_graph_node' or 'delete_asset'. Usage is implied through the material graph context, but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions running the 'FixUpRedirects commandlet', but does not disclose whether the operation is destructive, requires any project state, or has side effects. 'Clean up' suggests modification, but no specifics are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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. Every word earns its place, with no filler or redundancy. It is appropriately sized for a tool with no parameters and no complexities.
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 low complexity (no parameters, no output schema), the description is mostly complete: it states the action, scope ('in the project'), and even names the underlying commandlet. However, it could add a note about safety or reversibility, especially since it is a cleanup operation. Still, the minimal context is adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The schema is empty and fully covered. The baseline for zero-parameter tools is 4, and the description appropriately contains no parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Clean up asset redirectors in the project'. It uses a specific verb ('clean up') and a clear resource ('asset redirectors'), and additionally mentions the underlying commandlet ('FixUpRedirects'). This distinguishes it from other asset-related tools like delete_asset or rename_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or when-not-to-use scenarios. Usage is only implied by the tool's name and description, but there is no explicit contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the output (structured errors, warnings, progress), which adds value, but it does not disclose side effects (likely none), edge-case behavior (e.g., malformed input), or the exact structure of the returned data. The phrase 'last build output' is slightly ambiguous given that the tool takes a build_log parameter, not a reference to a stored log.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and expected output without extraneous words. It is efficiently front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides a reasonably complete picture: it tells what it parses and what it returns. It is slightly incomplete in not detailing the output structure or handling of incomplete logs, but given the tool's simplicity, this is acceptable.
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 describes the parameter as 'Raw build log output to parse for errors and warnings.' The description does not add additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('parse') and resource ('last build output'), and the result ('structured errors, warnings, and progress') makes the tool's function unambiguous. It is distinct from sibling tools like build_target or get_test_results, which handle building or test results rather than parsing build logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus other build-related tools. It does not mention prerequisites (e.g., running a build first) or exclusions (e.g., when to use raw log viewers). The intended usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals a meaningful dependency: 'Requires the optional C++ plugin for full node type support. Falls back to Python for basic operations.' This explains potential degradation in functionality. However, it does not disclose side effects, return values, or failure modes, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and immediately states the core action with a noun phrase. Every word contributes: the first sentence defines the purpose, the second provides essential caveats. 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 tool mutates a Blueprint graph and has no output schema or annotations. The description does not mention what the tool returns, whether the blueprint must be loaded/compiled, or what happens if the event graph is missing. While the plugin caveat and schema cover some aspects, important operational details are absent for a mutation tool of moderate 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?
Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-related value beyond noting that node type support may be limited without the plugin, which relates to the node_type parameter. It does not clarify coordinate ranges, property formats, or blueprint path expectations beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add a node to a Blueprint's event graph.' This clearly distinguishes it from sibling tools like add_blueprint_component and add_blueprint_variable, which target different Blueprint elements. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about the optional C++ plugin requirement and Python fallback, which implies when the tool may be limited. However, it does not explicitly state when to use this tool over alternatives like connect_graph_nodes, nor does it mention exclusions such as Blueprint types or unsupported node categories. Usage guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior of replacing references from source assets to a target asset, which adds value. However, with no annotations provided, it does not mention whether source assets are deleted, if the operation is reversible, or any other side effects, leaving a transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose and behavior without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters, but the description does not cover important contextual aspects such as return values, source asset fate, or potential side effects. Given no output schema and no annotations, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both target_path and source_paths. The description itself adds no additional parameter detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Consolidate') and resource ('duplicate assets'), and distinguishes it from siblings like delete_asset, rename_asset, and duplicate_asset by explaining the reference replacement behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied (consolidating duplicate assets), but there is no explicit guidance on when to use this tool versus alternatives such as delete_asset or rename_asset, nor any mention of prerequisites or workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must convey behavioral traits. It only says 'Run a console command' and gives examples, but it does not mention potential side effects, prerequisites (e.g., an active editor session), permissions, or how output/errors are returned. This is a significant gap for an arbitrary command execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by helpful examples. It is free of any filler or redundant content, making it an excellent model of conciseness.
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?
Although the tool has only one parameter and no output schema, the description does not explain what happens after execution (e.g., whether output is returned, logged, or displayed). Given the potentially broad impact of executing arbitrary console commands, the absence of any note on results or behavior leaves it incomplete for safe/effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes the 'command' parameter as 'Console command to execute', while the description adds concrete format examples like 'stat unit' and 'r.SetRes 1920x1080'. This helps the agent understand what a valid command string looks like, going slightly beyond the schema's bare definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Run') and the resource ('a console command in the Unreal Editor'), with concrete examples ('stat fps', 'r.SetRes 1920x1080'). This distinguishes it from sibling tools like run_stat_command (specific) and execute_python (different interpreter).
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 imply when to use the tool but provide no explicit guidance on when not to use it or which alternative to prefer. It does not mention dedicated tools like run_stat_command for stat commands or execute_python for Python scripts, so usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that regeneration overwrites existing project files, potential loss of customizations, or prerequisites like an existing .uproject. Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and object, zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Reasonable for a simple 0-param tool, but lacks side-effect disclosure (overwrites files) and any context about IDEs coverage or prerequisites. Adequate but thin.
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?
Tool has 0 parameters, so baseline 4 applies. No parameter info needed; description adds no extraneous details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Regenerate' + resource 'IDE project files' with named IDEs (Visual Studio, Xcode, Rider), clearly distinguishing it from build or packaging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when you need to regenerate IDE project files. No explicit when/when-not or alternatives provided, but the purpose is clear enough to infer.
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 behavioral disclosure. It states what details are included (exposed properties and functions) and the verb 'Get' implies a read-only operation, but it does not explicitly mention side effects, error behavior, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the purpose efficiently without any unnecessary words. It is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema or annotations, the description provides adequate basic context but lacks details on return structure or failure cases. It is sufficient for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter 'preset_name' with 100% coverage ('Preset name'). The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with resource 'Remote Control Preset' and clarifies exactly what is returned ('exposed properties and functions'). This distinguishes it from siblings like get_preset_property (which fetches a single property) and list_presets (which enumerates presets).
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 tool's usage is implied from the verb 'Get details' – use it when you need a preset's properties and functions. However, there is no explicit guidance on when to prefer this over alternatives like get_preset_property or call_preset_function, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that the tool lists all presets, but does not mention that it is read-only, what the return format is, whether there is any pagination or ordering, or any potential side effects. This minimal disclosure falls short of the transparency expected without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the tool's purpose without any wasted words. It is perfectly concise and well-structured for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, no parameters, and no output schema, the description is mostly sufficient. However, it does not specify what the response contains (e.g., names, paths, or other details of the presets), which could leave an agent uncertain about the return format. This is a clear gap but not severe for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so a baseline of 4 applies. The description adds relevant scope ('all' and 'in the project') which clarifies the fixed behavior, but no additional parameter semantics are 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 uses a specific verb 'List' with a clear resource 'Remote Control Presets' and scope 'in the project'. It clearly distinguishes from siblings like get_preset_info by focusing on enumeration of all presets rather than individual preset details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: to get all presets, use this tool. However, there is no explicit guidance on when to prefer it over alternatives like get_preset_info, or any exclusions or prerequisites. The context is straightforward, so a 3 for implied usage seems appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action and trigger, without mentioning side effects, potential errors, prerequisites, or the outcome of the recompile. This is minimal disclosure for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It efficiently conveys the tool's purpose and trigger without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core purpose and usage context. However, it lacks behavioral details such as error handling, async behavior, or postconditions, which would be valuable given no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (material_path) with 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (recompile), the resource (material), and the trigger condition (after making changes to its graph). This distinguishes it from sibling tools like compile_blueprint and material graph editing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by specifying 'after making changes to its graph', indicating when the tool is appropriate. It does not explicitly name alternatives or exclusions, but the context is sufficient for basic differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states the action without mentioning side effects, persistence, mutation, required permissions, or return behavior. For a write operation, the lack of any disclosure beyond the verb 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 sentence, front-loaded with the action, and contains zero wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with fully documented params, the description conveys the essential purpose. However, the lack of behavioral transparency (side effects, success return, asset save behavior) leaves gaps for an agent trying to predict outcomes. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The tool description adds no additional context about parameter formats, constraints, or relationships, so it neither compensates for gaps nor adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a specific resource ('texture parameter') and object ('material instance'). It clearly distinguishes from sibling tools like set_material_instance_scalar and set_material_instance_vector, which set different parameter types.
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 context is clear: use this tool when you need to set a texture parameter on a material instance. It doesn't explicitly contrast with alternatives, but the specificity of 'texture parameter' implicitly guides selection among sibling setter tools. No exclusions or when-not-to-use are stated, but the purpose itself provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It only states the action ('Set') without disclosing side effects, error conditions, return values, or whether the parameter must pre-exist. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded and contains no unnecessary words. It earns its place without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly describes all inputs, and the tool is a simple setter, but there is no output schema or annotations. The description does not cover return values, failure modes, or behavior when the parameter is missing, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and a nested value object for RGBA color (0-1). The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set'), the resource ('a linear color parameter'), and the target ('on a Niagara component'), making it specific and distinct from sibling tools like set_niagara_float, set_niagara_vector, and set_niagara_bool.
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 the tool: for setting color parameters on Niagara components. It does not explicitly exclude or mention alternatives, but the context is clear given the sibling tool names. No exclusions are needed beyond the obvious parameter type distinction.
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 simply says 'Set', which implies mutation, but does not mention prerequisites, side effects, reversibility, or return values. This is a significant gap for an operation that modifies a sequence asset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no filler. Every word contributes to the meaning, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with well-described parameters in the schema, but the description lacks behavioral context (e.g., return value, side effects) and explicit usage guidance. It is adequate but leaves room for improvement in a complete tool specification.
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 no additional parameter semantics beyond what the schema already provides, such as 'Start frame' and 'End frame'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Set') and resource ('playback start and end frames of a sequence'), which distinguishes it from sibling tools like set_sequence_framerate or get_sequence_info. It precisely conveys the tool's function without 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?
The description provides clear context that this tool is for setting the playback range of a sequence, which implicitly tells when to use it. However, it does not explicitly mention alternatives or when not to use it, so it misses the top 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 provided, the description carries the full burden of behavioral disclosure. It states that it sets the camera location and/or rotation, which is the core behavior, but it does not mention coordinate conventions, units, defaults when both fields are omitted, or any side effects on the editor state. For a simple setter, 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 a single, clear sentence that front-loads the action and target. It contains no filler or redundant information, and every word contributes meaning.
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 a moderately detailed schema and no output schema. The description explains the essential purpose but leaves gaps such as coordinate system, rotation order, and behavior when no parameters are provided. It is minimally complete but not fully self-contained.
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% ('Camera location' and 'Camera rotation'), so the schema already documents the parameters. The description adds no additional semantics beyond what the schema provides, such as units or coordinate system, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and identifies the resource as 'editor viewport camera location and/or rotation', clearly distinguishing from the sibling 'get_viewport_camera' which reads the camera state. It precisely communicates the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to adjust the camera position or orientation) but provides no explicit guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. It relies on the name and verb to imply context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states high-level function and does not describe side effects, prerequisites, or whether the operation is safe (e.g., whether it overwrites existing cooked content or requires prior build steps). The lack of such detail leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose and immediately clarifying scope with '(no C++ build)'. No redundant information is present.
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 three fully documented parameters and no output schema, the description adequately covers the tool's core purpose and differentiator from sibling build tools. It could be enhanced by mentioning typical use cases or outcomes, but overall provides sufficient context for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The tool description does not add any extra meaning about parameters like 'maps', 'iterate', or 'platform', relying entirely on the schema. Thus, no additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Cook content only') and resource ('assets'), and differentiates from build operations with '(no C++ build)'. It also specifies the outcome 'Converts assets to platform-specific format', making 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 phrase 'Cook content only (no C++ build)' provides clear exclusion context—this tool is for cooking assets without building C++, implying use when only content cooking is needed. However, it does not explicitly name alternative tools like build_target or build_cook_run, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. The verb 'Get' implies a read operation, but the description does not disclose behavior for edge cases (e.g., actor not found), return format, or whether the operation has side effects. For a simple getter, this is adequate but lacks explicit behavioral detail compared to more transparent descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the tool's purpose. It is appropriately sized for a simple getter operation, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, complete schema coverage, and no output schema or annotations. The description fully covers the purpose and input, making it self-contained for an agent. It could arguably mention return format, but given the simplicity and lack of output schema, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the parameter 'name' has a description 'Actor name or label'). The description of the tool itself adds no additional parameter semantics beyond this, so the baseline score of 3 per the rubric applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all properties of an actor by name.' It uses a specific verb ('Get') and resource ('actor properties'), and distinguishes itself from sibling tools like get_actor_components and set_actor_property by focusing on properties rather than components or writes.
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: it is for retrieving actor properties when needed. However, it provides no explicit guidance on when to prefer this tool over alternatives (e.g., get_actor_components) or when not to use it. The context of 'Get' suggests read-only retrieval, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It only states the action (list all data layers) without additional context about return format, side effects, or state changes. For a read operation, this is minimal but not harmful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately explains what it does for invocation purposes. It could mention what output the user should expect (e.g., names or references), but it is not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty. The baseline for 0 parameters is 4, and the description correctly implies no additional input 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 uses a specific verb ('List') and resource ('data layers') with a clear scope ('current World Partition level'). It clearly distinguishes from sibling tools like set_data_layer_state and get_loaded_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading all data layers in the current level, but it does not explicitly state when to use this over alternatives or mention exclusions. It gives context (current World Partition level) but no direct comparison to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool redos the last undone editor action, offering minimal behavioral context. It does not disclose what happens when there is nothing to redo, potential side effects, or reversibility, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is perfectly sized for a zero-parameter tool and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial no-argument tool, the description is adequately complete. It states the action and target, and given the sibling tools (undo, get_undo_history), the user can understand when to use it. However, it does not cover edge cases such as empty redo history, but this is minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The schema has no properties and the description is not required to explain parameter semantics, making this 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 states a specific action: 'Redo' the 'last undone editor action,' which clearly identifies the operation and its target. This distinguishes it from the sibling 'undo' tool by explicitly referencing previously undone actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when there is an undone action to redo, but it does not explicitly discuss alternatives or exclusions. The presence of the sibling 'undo' tool provides indirect context, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds the prerequisite that the optional C++ plugin is required, which is useful. However, it does not disclose consequences like potential disconnection of edges, irreversibility, or error behavior, which would be relevant for a removal 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 concise sentences, front-loaded with the main purpose and followed by an essential requirement. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage and no output schema, the description adequately states the core action and a critical prerequisite (plugin). It might benefit from noting return behavior or failure modes, but given the simplicity, it 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?
Schema coverage is 100% with both parameters described ('Node ID to remove' and 'Blueprint asset path'). The description itself adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('node from a Blueprint graph'), clearly distinguishing it from sibling tools like add_graph_node, connect_graph_nodes, and list_graph_nodes. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage (when you need to remove a node), but there is no explicit when-to-use vs alternatives or any exclusions. The plugin requirement is a prerequisite, not a usage guideline. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, prerequisites (e.g., whether there is an undo history), or reversibility. The statement is essentially a restatement of the tool's name and provides minimal additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and contains no unnecessary words or filler. Every word contributes to the meaning.
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 low complexity (no parameters, no output schema), the description is largely complete. It could optionally mention the relationship with 'redo' or the availability of undo history, but it is sufficient for basic understanding and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Undo') and resource ('last editor action'). It distinguishes itself from sibling tools like 'redo' and 'get_undo_history' by specifying the exact scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reverting the most recent editor operation but provides no explicit guidance on when to use it versus alternatives like 'redo' or 'get_undo_history'. No exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only says 'Get the results,' which implies a read operation but does not explicitly state that it is read-only, what happens if no test run has occurred, or what format the results take. This is a minimal disclosure with 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 a single sentence with no redundant words. It is front-loaded and efficiently adds the qualifier 'last automation test run,' which provides specificity beyond the tool name without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is adequate for selecting the tool but lacks detail about the return value structure, potential errors (e.g., 'no run has occurred'), or whether results include pass/fail, timings, or logs. It does not fully explain the output, which is not covered by an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema fully documents the inputs. Per the rubric, 0 parameters automatically earns a baseline of 4. The description adds no additional parameter information because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 names a precise resource in 'results of the last automation test run.' This clearly distinguishes it from sibling tools like run_automation_test and run_all_automation_tests, which execute tests rather than retrieve 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 context implies the tool is used after an automation test run to fetch its results, and it is naturally distinct from the run-* siblings. However, it lacks explicit guidance on when to use this tool versus alternatives, such as mentioning that it only returns the most recent run or that other tools might provide more detailed queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It only states the action without disclosing side effects, prerequisites (e.g., connection requirements), or failure behavior if no trace is active. This is a minimal disclosure for a mutating 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?
A single, precise sentence that states the action and target. No fluff or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter stop operation, the description covers the core function. However, it omits potential behavioral context such as whether trace data is saved, whether it requires an active connection, or error handling. This makes it minimally viable but not fully 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 accepts zero parameters, and schema coverage is effectively 100% (empty schema). The baseline for no parameters is 4, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('active Unreal Insights trace session'), clearly distinguishing it from the sibling 'start_trace'. 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?
Implies usage context via 'active' trace session, indicating it should be used only when a trace is running. Does not explicitly mention alternatives or when not to use it, but the contrast with start_trace is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key safety behavior of checking references before deletion, but does not explain what happens when references exist (e.g., error unless force) nor mention other consequences like irreversibility or permission requirements. This is better than nothing but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. It is front-loaded with the primary action and immediately provides a critical behavioral note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description covers the core purpose and a critical behavioral aspect. The schema documents all parameters, and since there is no output schema, return values are not necessary to explain. It could mention potential error conditions or confirmation prompts, but given the simplicity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully described in the schema. The tool description adds value by explaining the rationale for the force parameter: it relates to the reference check. This connects the parameter to the real-world behavior, going beyond the schema's literal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('an asset'). It distinguishes itself from sibling tools like delete_actor (which targets actors) and provides a specific behavioral detail ('Checks for references first') that adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an asset needs to be deleted, but it does not explicitly state when to use this tool versus alternatives like rename_asset or delete_actor. The reference-check behavior hints at a prerequisite but no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool runs arbitrary code with access to the full unreal module, which implicitly signals it can perform broad operations. However, it does not elaborate on potential side effects, dangers, or what happens after execution (e.g., return values, errors), and there are no annotations to fill this 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 two short sentences, front-loaded with the core verb and resource, and includes only essential details. There is no wasted wording or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description is largely complete: it states what the tool does and the environment context. It does not explain return values or error behavior, but given the simplicity and the explicit mention of arbitrary code execution, it covers the primary needs for an agent to use it 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 coverage is 100% with the 'code' parameter described as 'Python code to execute in the editor'. The description adds meaningful context by noting access to the full 'unreal' module, which informs what the code can reference, going beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary Python code in the Unreal Editor's Python environment, using a specific verb and resource. It distinguishes itself from siblings like execute_console_command by specifying Python, and the addition of 'full unreal module' clarifies its scope of access.
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 the general-purpose tool for running Python in the editor, but it does not explicitly state when to prefer it over alternatives or provide exclusions. There is no mention of alternative tools or use cases, leaving the agent to infer its role from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the read-only nature via 'Get', but does not add context about coordinate systems, units, or edge cases such as when no viewport is open. For a simple getter, 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 efficiently conveys the action and object. No redundant words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description adequately states what is returned (location and rotation). However, it lacks details on the return format (e.g., vectors, rotators) or coordinate space, which is a minor gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The schema is trivially complete, and no additional parameter documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Get the current editor viewport camera location and rotation' with a specific verb and resource. It distinguishes from the sibling set_viewport_camera by clarifying it retrieves, not sets, the camera state.
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 implied usage is to read current camera data, but there is no explicit guidance on when to use it, when not to, or alternatives like set_viewport_camera. The description provides contextual clarity but lacks exclusions or explicit recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It conveys the read-only nature and output concept (list with enabled status), but gives no details on return format, error conditions, or preconditions. For a zero-parameter list tool, this is minimally sufficient.
Agents need to know what a tool does to the world before 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 with no filler. It front-loads the action and scope, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is nearly complete. It could be slightly more explicit about what the output looks like, but it covers the essential purpose adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the baseline for zero-parameter tools is 4. The description doesn't need to elaborate on parameter semantics since the schema is empty and coverage is effectively complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('List'), a resource ('installed plugins'), and an added detail ('their enabled status'). It naturally distinguishes itself from sibling tools like enable_plugin and disable_plugin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided, but the purpose is straightforward enough that usage is implied. The description doesn't mislead, but it also doesn't offer any guidance beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly lists the pipeline stages (build, cook, stage, package, deploy/run), conveying the tool's mutating and multi-step nature. It does not mention potential long execution times, prerequisites, or artifact outputs, but the stage listing is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the tool's purpose and pipeline stages. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema, no annotations), the description only provides a broad overview and lacks guidance on parameter combinations, prerequisites, or expected outcomes. It is minimally viable but leaves gaps for an agent deciding how to configure the pipeline.
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 documents all 12 parameters with descriptions, so schema coverage is 100%. The description adds a high-level pipeline overview but does not explain parameter semantics beyond what the schema already provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a full BuildCookRun pipeline with specific verbs: build, cook, stage, package, and optionally deploy/run. It also labels itself 'the primary command for packaging a project,' which distinguishes it from sibling tools like build_target, cook_content, and package_project.
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 identifies the tool as the primary command for packaging a project, indicating when to use it. However, it does not explicitly mention alternative sibling tools for partial operations (e.g., build_target, cook_content) or state when not to use this tool, so it stops short of full exclusionary 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 full burden of disclosing behavior. It identifies the file being modified (.uproject) and the post-action requirement (editor restart), which are critical for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two short sentences with no redundant information. The action and consequence are front-loaded, making it 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 single-parameter tool with no output schema, the description provides all essential context: what it does, where it acts, and what the user must do after. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (plugin_name) with a clear description. The tool description does not add additional parameter-specific context, so the baseline score of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable a plugin') and the target resource ('.uproject file'). This specific verb+resource combination distinguishes it from sibling tools like enable_plugin and list_plugins.
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 notes a practical consequence (requires editor restart) but does not explicitly discuss when to use this tool versus alternatives like enable_plugin. The intended use is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It adds relevant context about CDO defaults and dot paths for components, but it does not mention persistence, compile requirements, or whether this is a destructive operation. For a mutation tool, this is a gap but not a contradiction.
Agents need to know what a tool does to the world before 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 resource. Every word serves a purpose: the first sentence defines what the tool does, and the second provides a crucial usage hint. No redundant or vague wording.
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, combined with the rich schema (100% parameter coverage), is adequate for a simple setter. However, without annotations or an output schema, the description does not address potential side effects (e.g., whether the property change requires asset save or blueprint recompilation) or error handling. It is minimally complete but leaves some behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters with 100% coverage. The description adds valuable semantic nuance beyond the schema by explaining the 'ComponentName.PropertyName' dot path format for property_name, which clarifies how to address component sub-properties. This extra meaning justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' with a precise resource: 'default property value on a Blueprint's CDO'. It clearly distinguishes from instance-level setters like set_actor_property by specifying CDO (Class Default Object). The dot-path example for component properties further clarifies the tool's specific scope.
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 that this tool operates on Blueprint defaults, implying it should be used instead of instance-level setters. It does not explicitly name alternatives or exclusions, but the mention of CDO and the dot-path convention offers situational guidance for component properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the operation modifies the .uproject file and requires an editor restart to take effect, which is a key side-effect. It does not mention potential errors or permission requirements, but for a simple config-enabling tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the verb and resource. It contains no redundancy or extra fluff, earning its place entirely.
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 one-parameter tool with no output schema, the description adequately covers the purpose and the critical restart requirement. It is complete enough for an agent to invoke the tool correctly, though it omits minor details like error handling or whether the plugin must be installed first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the sole parameter 'plugin_name', with its own description. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Enable' and clearly identifies the resource as 'a plugin in the .uproject file'. This distinguishes it from sibling tools like disable_plugin and list_plugins, making the tool's 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 implies the tool is used when you want to activate a plugin, and the note about requiring an editor restart provides practical usage context. It does not explicitly name alternatives, but the purpose is clear enough that an agent can infer when to use it in the plugin management workflow.
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. The verb 'Check' clearly indicates a read-only operation, and the description lists exactly what will be inspected (transport types). It doesn't specify return format or behavior when nothing is connected, but for a status-check tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or irrelevant text. It efficiently conveys the tool's exact scope.
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 low complexity (zero parameters, no output schema), the description provides sufficient context to understand its function. It could benefit from describing the response shape, but the core behavior is clear enough for the simple use case.
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 the baseline is 4. The description adds no parameter information, which is appropriate because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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's purpose: checking which Unreal Engine transports are connected, and it explicitly lists the transport types (Remote Control, Python, Plugin Bridge). This is a specific verb+resource combination that distinguishes it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever you need to know the connection status of Unreal Engine transports. No alternatives are mentioned because no sibling tool performs this specific function, and the verb 'Check' implies a query-only usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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