Unreal-MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation4/5
Tools are generally distinct by domain, but some Niagara introspection tools (e.g., 'get_niagara_module_inputs', 'get_niagara_rapid_iteration_parameters', 'get_niagara_module_input_binding') have overlapping purposes that could confuse an agent.
Naming Consistency4/5
Most tools follow a verb_noun pattern, but a few like 'health_check' and 'performance_start_trace' use noun_verb_noun, slightly breaking consistency.
Tool Count3/5
With 286 tools, the server is very comprehensive for Unreal Editor operations, but the count is high enough to potentially overwhelm agents, and some tools could be consolidated.
Completeness5/5
The tool set covers all major Unreal subsystems (assets, materials, blueprints, Niagara, state trees, input, performance, etc.) with full CRUD and lifecycle operations, no obvious gaps.
Average 3.6/5 across 286 of 286 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on May 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Mozilla Public License 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Spawn...', giving no details on side effects, required permissions, or what happens to the spawned actor. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but critically under-specified. It sacrifices necessary detail for brevity, failing to earn its place as a sufficient explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no parameter descriptions, no annotations, and many sibling tools, the description is grossly incomplete. It does not mention output, return type, or any completion semantics, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description adds no meaning to any parameter (e.g., how 'location', 'scale', 'rotation' affect spawning). Agents have no guidance on parameter usage.
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 'Spawn a Blueprint actor instance in the level', which clearly indicates the action and resource. However, it does not differentiate from sibling tools like 'spawn_actor' or 'spawn_actor_by_class', making the purpose somewhat ambiguous.
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 vs alternatives, nor any prerequisites or context for use. The description lacks usage pointers entirely.
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 must disclose behavior, but it fails to mention whether the duplication creates a copy, modifies the original, handles dependencies, or requires permissions. It is critically under-informative 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but severely under-specified for a tool with three required parameters and no additional context. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the asset ecosystem and the presence of many sibling tools, this description is inadequate. It does not explain the asset type, the operation's effect, or the output schema, leaving the agent without critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it adds no meaning beyond parameter names. The parameters (source_path, dest_path, dest_name) are not explained in terms of format, constraints, 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 the action ('Duplicate') and the resource ('asset') with a destination ('to a new location'). It conveys the core purpose but does not distinguish from sibling tools like duplicate_data_table_row or duplicate_widget, lacking specificity on asset type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., rename_asset, duplicate_data_table_row). There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Rename' without indicating if it is destructive, whether renamed functions require recompilation, or if references are updated. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. Conciseness should not come at the cost of essential information; here it omits needed 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?
The tool has 3 required parameters and no return details in the description. Although an output schema exists, it is not provided, and the description does not explain the result or side effects. For a rename operation, more context (e.g., success indication, error conditions) would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain what each parameter means beyond their names (blueprint_name, old_function_name, new_function_name). No formats, constraints, or relationships are described.
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 'Rename a function in a Blueprint.' states the action and resource clearly, but does not differentiate from other rename tools like 'rename_asset' or 'rename_widget', nor from sibling blueprint function tools like 'create_blueprint_function' or 'delete_blueprint_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 on when to use this tool versus alternatives, no prerequisites, no examples of valid function names or scope. The description provides no usage context.
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 carry the full behavioral disclosure burden. It fails to mention whether the tool is read-only, what happens if the actor has no material slots, error handling, or output format. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the key action. However, it is too sparse and does not include useful details, making it minimally acceptable rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists but no annotations, the description should explain the nature of the returned info (e.g., list of slot names, material assignments) and any prerequisites. It completely lacks this context, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'actor_name' with no description, and the schema description coverage is 0%. The description does not add any meaning to this parameter beyond its name, so the agent has no guidance on what value to provide.
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 ('Get') and resource ('material slot info for a level actor'), which clearly indicates the tool's purpose. It distinguishes from sibling tools like 'get_blueprint_material_info' or 'get_available_materials' by focusing on a level actor's material slots. However, 'material slot info' is somewhat vague and could be more precise.
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. There are many sibling tools related to materials and actors, and without context, an agent may struggle to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral context. It does not disclose whether the operation modifies the Blueprint asset permanently, if it requires a specific editor state, or what happens on failure. The tool likely has side effects, but they are unmentioned.
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 sentence, which is efficient but overly brief. It omits essential details, sacrificing informativeness for brevity. A minimally complete description would require more structure and content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no parameter explanations, and no usage context, the description is severely incomplete. It fails to convey what materials are acceptable, how component names are resolved, or any output behavior (though output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage. The description adds no information about what 'material_path', 'material_slot', 'blueprint_name', or 'component_name' mean or how to specify them correctly. This is a critical gap for correct invocation.
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 verb 'apply' and the resource 'material to a Blueprint component', specifying the target. It distinguishes from the sibling 'apply_material_to_actor' by focusing on Blueprint components, but does not explicitly mention this 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 on when to use this tool versus alternatives like 'apply_material_to_actor' or other material-related tools. There is no indication of prerequisites, typical use cases, or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only states 'Create' implying mutation, but fails to mention side effects, permissions, or any constraints beyond the schema. The burden of transparency is not met.
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 extremely concise at one sentence, but it sacrifices necessary information. It is under-specified rather than efficiently compact, leading to poor usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a blueprint function and the presence of an output schema, the description lacks any context about prerequisites, return values, or how it fits into the Blueprint workflow. It is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (blueprint_name, function_name, return_type). The agent must infer meanings from names alone, which is insufficient for correct invocation.
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 verb 'Create' and the resource 'function in a Blueprint', providing a specific action and object. However, it does not differentiate from sibling tools like 'create_blueprint_variable' or 'add_blueprint_node', which could confuse the agent about the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'add_function_input' or 'create_blueprint_variable'. The agent lacks context for proper selection and may misuse the tool.
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 only says 'Set physics properties' but does not mention side effects (e.g., enabling simulation), required component state, or that the operation modifies an existing component. The output schema exists but is not shown, so the agent lacks behavioral clarity.
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?
While the description is a single concise sentence, it is under-specified. Given 7 parameters, omitting parameter explanations makes it insufficiently informative. The description should be longer to cover essential details, so conciseness here is a detriment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no schema descriptions, no annotations, and an output schema not shown, the description fails to provide necessary context. The tool has 7 parameters and modifies a component, yet no prerequisites, return values, or usage patterns are described. This is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The tool description does not explain any of the seven parameters (mass, linear_damping, etc.), leaving the agent without guidance on what values to provide. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set physics properties on a Blueprint component' clearly states the action (set) and target (physics properties on a Blueprint component). It distinguishes from sibling tools like 'set_static_mesh_properties' and 'set_mesh_material_color'. However, it does not list the specific properties (mass, damping, etc.), which would add more 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 on when to use this tool versus alternatives, prerequisites, or when not to use it. The description merely states the action without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, error conditions, or success/failure outcomes. The term 'compile' implies a build process, but no details about what happens during compilation or what the output is.
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 concise at just three words, but it lacks structure and does not earn its place with substantive information. It could be expanded to include key details without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and no annotations, the description is incomplete. It does not explain what the output represents, how compilation errors are handled, or any other critical context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter blueprint_name is described only by its name and type in the schema. The description adds no additional meaning, such as what name format is expected or how it relates to existing blueprints. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compile' and the resource 'a Blueprint', which accurately identifies the tool's action. It distinguishes the tool from sibling compile tools like compile_niagara_system and compile_statetree by specifying Blueprint. However, it does not elaborate on what 'compiling' entails in this context.
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 when to compile a Blueprint vs. using other blueprint-related tools or when compilation is necessary. No prerequisites or post-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 provided. The description only states it performs auto-layout, but does not disclose if it overwrites existing positions, affects connections, or requires the material to be open. For a tool that modifies graph layout, more behavioral context is needed.
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 concise. However, it lacks necessary details, making it insufficiently informative. The conciseness does not fully compensate for missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with no description, no annotations, and only a minimal description, the contextual completeness is low. It does not cover what happens to the graph, any side effects, or return value (though output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'material_path' parameter. It does not explain the format, expected value, or purpose beyond the schema definition.
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 auto-layouts all nodes using Unreal's arrangement algorithm. It specifies the action (auto-layout) and resource (nodes). However, it doesn't explicitly mention the material path scope, which is inferred from the parameter. It distinguishes from sibling material tools that focus on adding, connecting, or deleting nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like build_material_graph or manually arranging nodes. The description lacks context about prerequisites or situations where auto-layout is 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, the description must disclose behavioral traits. It states 'Save to disk' but does not explain whether this is a safe operation (overwrites existing data? creates a backup? requires specific permissions?). The lack of detail about the operation's nature (e.g., destructive, persistent) leaves the agent without critical context.
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 to the point, which is good for conciseness. However, it sacrifices necessary detail; it is underspecified rather than efficiently informative. The single sentence is front-loaded but incomplete.
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, a single required parameter, and an output schema, the description should at least hint at the output or the exact nature of the operation. It does not mention the return value or any context about what 'saving' means in this environment. The tool is simple, but the description lacks completeness.
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 only parameter 'asset_path' is a string, but the description adds no information about its expected format, meaning, or constraints. Schema description coverage is 0%, so the description carries the full burden of explaining parameter semantics, but it fails to do so.
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 identifies the action ('Save') and resource ('specific asset'), and the target ('to disk'). However, it is too vague to clearly distinguish from similar operations. Among siblings, there are tools like open_asset, duplicate_asset, delete_asset, but the description does not clarify whether this saves changes to an existing asset or exports it to an external file.
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 guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., save_all, export_asset), nor does it mention prerequisites or disclaimers about side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, whether it modifies a material instance or creates a new one, or whether it applies in the editor or runtime. The description only states 'set material color.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the purpose, with a separate line for the color format. However, it is too terse given the six parameters; it omits essential details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required) and no schema description coverage, the description is severely incomplete. It does not explain the required parameters blueprint_name and component_name, the optional material_path, material_slot, or parameter_name. The presence of an output schema does not excuse the lack of explanation of inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains the 'color' parameter format (array of 0-1 values). The other 5 parameters (blueprint_name, component_name, material_path, material_slot, parameter_name) are not explained at all, leaving the agent to infer their meaning from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets material color on a mesh component, including the color format. It's a specific verb and resource, but does not explicitly differentiate from sibling tools like apply_material_to_actor or set_material_instance_parameter.
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, no prerequisites (e.g., mesh must have material), and no mention of when to prefer other material-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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It implies a write operation ('Set'), but does not disclose whether properties are merged, overwritten, or replaced, nor any prerequisites, permissions, or side effects. The reference to another tool is insufficient without its behavior being known.
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 extremely short (two sentences) but omits critical information needed for correct usage. While brevity is valued, under-specification reduces effectiveness. Each sentence does not earn its place; the second sentence is a vague reference rather than adding substantive guidance.
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 complexity (3 required parameters, no parameter descriptions, no annotations), the description is woefully incomplete. It does not explain parameter semantics, return value behavior (despite output schema existing, but not described), or any constraints. The agent is left without enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no meaning to the parameters (properties, widget_name, widget_blueprint_path). The phrase 'Same format as set_data_asset_properties' does not clarify parameter semantics. This leaves the agent to guess the purpose of each parameter.
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 verb 'Set' and the resource 'widget properties', specifying 'multiple' to indicate bulk operation. It is not a tautology and distinguishes the tool as a widget-specific setter among many sibling set_* tools. However, it lacks specificity about the types of properties (e.g., layout, appearance) to fully differentiate from similar 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?
The description provides no guidance on when to use this tool over alternatives. It only mentions 'Same format as set_data_asset_properties', which is a format reference, not usage context. There are no explicit when-to-use, when-not-to-use, or alternative tool mentions, leaving the agent without decision support.
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 behavioral traits. It mentions that extra args are only needed for specific node types, which is helpful, but it does not explain side effects, reversibility, or whether adding a node automatically connects it. The description lacks depth 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the purpose. However, the list of node types could be more compact or formatted better to avoid information overload. It is structured but not optimally organized.
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 10 parameters, many node types, and an output schema, the description is incomplete. It fails to describe the return value, explain all parameters, or provide usage examples. The output schema exists but is not mentioned in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only partially explains parameters via the extra args note (e.g., message, variable_name, target_function). It does not explain pos_x, pos_y, event_type, function_name, target_blueprint, or other parameters. The list of node types adds context but does not compensate for the missing parameter details.
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 adds a node to a Blueprint graph and provides a comprehensive list of node types by category. It is specific about the verb (Add) and resource (Blueprint graph node). However, it does not explicitly distinguish from siblings like add_event_node, which may cause confusion.
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 such as connect_blueprint_nodes, set_blueprint_node_property, or delete_blueprint_node. It does not specify prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool 'analyze' a graph but does not disclose whether it modifies data, has side effects, requires permissions, or impacts performance. Minimal transparency beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that quickly conveys the core purpose. It is concise and front-loaded. However, it could incorporate brief parameter context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, 1 required, and no schema descriptions, the description should at least list or hint at key parameters. It also does not reference the output schema or explain what the analysis returns. The description is too sparse for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 5 parameters. It does not add meaning to the parameter names, types, or defaults. The agent gets no help in understanding what each parameter controls, such as the role of 'include_node_details' or 'trace_execution_flow'.
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 resource (blueprint graph) and action (analyze), specifying it covers nodes, connections, and execution flow. This distinguishes it from siblings like 'read_blueprint_content' which read broader content. However, 'analyze' is somewhat vague and could be more precise.
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. The description does not mention prerequisites, exclusions, or compare with siblings like 'read_blueprint_content' or 'add_blueprint_node'. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a write/mutation operation (apply and save) but does not disclose potential side effects, permissions required, or whether the action is reversible. The brief mention of mirroring an internal method adds little practical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. The second sentence adds technical reference. While every sentence earns its place, the structure could be improved by ordering information more logically.
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 incomplete parameter descriptions, the description does not provide sufficient context for a mutation tool. The existence of an output schema helps with return values, but the description still fails to cover error conditions, preconditions, or success criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It only references 'system_path' and 'module_name' in the schema, but the description itself adds no meaning, leaving the agent with no understanding of what these parameters represent or how to use them.
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 applies a scratch pad module's edit-copy and saves the asset, referencing the 'Apply & Save' button and a specific method. This distinguishes it from similar tools like 'apply_niagara_scratch_pad' by emphasizing the save action. However, the term 'edit-copy' is somewhat vague.
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 'apply_niagara_scratch_pad' (which may not save). There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
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 does not disclose whether the material replaces existing ones, any side effects, or permission needs. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words, but lacks structure like bullet points or sections. Borderline too brief given the parameter count.
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 3 parameters and an output schema, the description fails to mention return values, error conditions, or how the material is applied. Incomplete for effective 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 coverage is 0% and description adds no parameter details. 'material_path' and 'material_slot' are not explained beyond their names, leaving the agent uncertain about format or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply) and objects (material, level actor). It distinguishes from sibling 'apply_material_to_blueprint' by specifying 'level actor' as target. However, it does not elaborate on scope or context, leaving some 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 on when to use this tool versus alternatives like 'apply_material_to_blueprint' or 'set_mesh_material_color'. No prerequisites or conditions 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 full burden but only states 'name matches the given pattern' without specifying pattern syntax, case sensitivity, or matching behavior. This is insufficient for reliable agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with key info. However, its brevity sacrifices necessary details, making it 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 presence of an output schema, the description could be simpler, but it still lacks critical usage context like pattern format and differentiation from find_actors. The tool definition feels incomplete.
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 only parameter 'pattern' has no description in the input schema (0% coverage) and the tool description adds only that it's a pattern to match names, no format or constraints. This adds minimal value over the parameter name.
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 verb 'find' and resource 'actors' with a matching condition on name. However, it does not distinguish itself from the sibling tool 'find_actors', which may have different 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?
No guidance is provided on when to use this tool versus alternatives like 'find_actors'. The context is implied but not explicit, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond the operation are disclosed. The description does not mention whether the tool is read-only, what happens if the row is not found, or any required permissions. Since no annotations are provided, the description should carry this burden but fails to do so.
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 extremely concise, consisting of a single sentence. It is front-loaded and to the point, but the brevity comes at the cost of missing important details. No wasted words, but it is underspecified.
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, the simple description is insufficient for an agent to correctly invoke the tool. It does not explain the parameters or the return value, even though an output schema exists (but was not described). The description is incomplete for a tool with two parameters and no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with no descriptions, and schema description coverage is 0%. The description itself does not explain what 'data_table_path' or 'row_name' mean, nor does it clarify what constitutes a 'row name.' The description adds no semantic value beyond 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 'Get a single row from a Data Table by its row name,' which clearly expresses the verb 'Get' and the resource 'single row.' It distinguishes from the sibling tool 'get_data_table_rows' (plural) which implies multiple rows. However, it does not specify what a 'Data Table' is, but within the context of the tool suite, it is likely clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not state when to use this tool versus alternatives like 'get_data_table_rows' or 'get_data_table_schema.' The distinction is only implicit through the word 'single.'
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 states it lists assets but does not mention that the default 'recursive' parameter is true (affecting results), nor any side effects, limitations, or pagination. Minimal behavioral insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (two sentences plus Args), but the Args section is formatted as bullet-like lines that could be more integrated. The first sentence is front-loaded and clear, though the structure is adequate but not optimally concise.
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 an output schema existing, the description fails to clarify key behaviors like recursive listing, return format (e.g., asset names or full paths), or if there are limits. Given the complexity and many sibling tools, it lacks sufficient detail for an agent to confidently decide when to invoke this tool.
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?
With 0% schema description coverage, the description compensates partially by explaining 'path' and 'class_filter' with examples. However, it omits the 'recursive' parameter entirely, which is crucial for understanding scope. Only 2 of 3 parameters are described, leading to incomplete guidance.
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 verb 'List' and resource 'assets in a Content Browser directory,' with examples for path and class_filter. It distinguishes itself from sibling tools like 'find_assets' (which likely searches across multiple directories), though it doesn't explicitly mention the 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?
The description provides no guidance on when to use this tool vs alternatives, such as when to use 'find_assets' instead. It lacks context on prerequisites, typical use cases, or exclusions, leaving the agent to infer usage without 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 exist, so the description must describe behavior. It only mentions 'in-place across both asset and edit-copy graphs' but omits effects of renaming (e.g., breaking references, permission requirements, what happens if old_name 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 13 words) but sacrifices essential detail. It is front-loaded with the action, but every sentence should earn its place; here it is too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no schema descriptions, no annotations, and an output schema not shown, the description is severely incomplete. It does not explain how to identify the parameter (e.g., module_name, script_path) or the role of direction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions in schema. The description does not explain any of the 6 parameters (old_name, new_name, direction, module_name, script_path, system_path), leaving the agent to guess their 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 specifies the action ('Rename a script parameter') and the scope ('in-place across both asset and edit-copy graphs'), distinguishing it from sibling tools like add/remove/list script parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., add/remove), no prerequisites or exclusions provided. The agent must infer usage from 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 exist, so description carries full burden. Only says 'Add an event node', omitting side effects (e.g., blueprint modification, compilation requirements). Lacks detail on mutation scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with examples, no fluff. Brief but includes essential purpose and sample values. Could list more event types.
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, 0% parameter descriptions, and an output schema not described, the tool is under-documented. Missing return value info, prerequisites, and detailed behavior.
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 has 0% description coverage. Description only clarifies event_name via examples. No explanation for pos_x, pos_y (position) or blueprint_name, leaving these parameters unclear.
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?
Clearly states it adds an event node with specific examples (ReceiveBeginPlay, etc.). Distinguishes from general node addition tools like add_blueprint_node, though not explicitly.
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?
Provides no guidance on when to use this tool versus alternatives such as add_blueprint_node. No when-not or context 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 cover behavioral aspects. It only states the operation is a delete without disclosing effects, reversibility, permissions, or error conditions. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (9 words) but lacks necessary detail, making it under-informative rather than efficiently 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?
Despite having 2 simple parameters and an output schema, the description omits important context such as preconditions, side effects, and expected outcomes. It is not complete enough for an AI agent to use without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the parameters (system_path, module_name) beyond their names. The description adds no value to understanding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete), the resource (scratch pad module), and the context (Niagara System). This distinguishes it from sibling tools like delete_niagara_system or duplicate_niagara_scratch_pad_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It lists returned properties and mentions the output shape matches a serialization pattern, but does not disclose potential errors, auth needs, or side effects. It is safe for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a list of properties. It is front-loaded and concise, though the list could be condensed. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical usage context for the parameters, no error handling, and no conditional logic. For a tool with three nullable parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention any of the three parameters (module_name, script_path, system_path). Users are given no guidance on how to specify which script to target, making the tool nearly unusable without external knowledge.
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 'Read the details-panel properties of a Niagara script' and enumerates the returned properties. This distinguishes it from sibling tools like set_niagara_script_properties, though not explicitly.
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 (e.g., set_niagara_script_properties) or prerequisites. The read nature is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It does not state that the tool is read-only, nor does it explain pagination via max_results or scope (e.g., whether it lists all assets in the project or within a directory).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, and the second lists return fields. It is front-loaded and wastes no words, though it could be more precise about parameters.
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 4 parameters, no annotations, and no output schema (though return fields are listed), the description does not sufficiently cover behavior, parameter details, or usage context. It lacks completeness for an agent to use it 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?
Schema coverage is 0%, so the description must explain all parameters. It mentions filtering by 'name and path' which maps to 'filter' and 'path' parameters, but it omits 'recursive' and 'max_results' entirely, leaving their purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists UInputAction assets with optional filtering, distinguishing it from generic asset listing tools. However, it mentions 'name and path' filtering while the actual parameters are 'filter' and 'path', causing slight 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 sibling tools like list_assets or get_input_action. The description does not mention alternatives or context for 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?
No annotations are provided, so the description should disclose behavioral traits. It only states the action without mentioning consequences (e.g., irreversible removal, effects on graph validation) or requirements (e.g., pin must be dynamic).
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 single sentence is concise but at the expense of completeness. It is front-loaded with the action, but lacks structure and detail.
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 complexity (Niagara system, scratch pad graph, optional parameters) and the presence of an output schema (not shown), the description is insufficient for an agent to reliably use the tool. Parameter semantics and behavioral traits are missing.
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?
With 0% schema description coverage, the description adds no meaning to the six parameters. Critical fields like system_path, module_name, pin_name, node_id, node_class, and node_index are unexplained, leaving the agent to infer their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (remove), resource (dynamic pin), and context (from any node in a scratch pad graph). It distinguishes from sibling tools like add_niagara_node_pin and rename_niagara_node_pin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remove_niagara_custom_hlsl_pin or other removal tools. No prerequisites or context 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 present, so the description carries full burden. It only states the removal action without disclosing side effects (e.g., impact on connections, undoability, permissions). The tool has an output schema, but its details are not in the description.
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 no fluff, but it is too short to convey necessary information. It could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, zero annotations, and lack of parameter explanations, the description is insufficient. It does not clarify the relationship between module_name, script_path, and system_path, nor does it help distinguish from similar removal tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (e.g., name, direction, module_name). It fails to add meaning beyond the schema, leaving the agent uninformed about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'named input or output parameter from a Niagara script', effectively differentiating it from siblings like 'remove_niagara_user_parameter' and 'remove_niagara_custom_hlsl_pin'.
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 'remove_niagara_user_parameter' or other removal tools. The description lacks context 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 provided. The description only states the action and scope but does not disclose side effects, reversibility, or error conditions. For a destructive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus parameter list) but lacks structure and detail. It is concise but at the expense of completeness, missing critical information for correct usage.
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, 0% schema coverage, and the complexity of removing a state from a hierarchical tree, the description fails to provide necessary context about the effect on the tree, return value, or error handling. Output schema exists but is not leveraged in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description merely lists parameter names without explaining their roles or required combinations (e.g., which identifier to use to specify the state). The required parameter 'asset_path' is noted, but the tool needs additional identification of the state, which is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Remove' and the resource 'a state and all its children from the tree.' It distinguishes from sibling tools like remove_statetree_node by specifying removal of a state with all its children.
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 (e.g., remove_statetree_node for single nodes). No context on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only indicates 'rename' without discussing side effects, required permissions, or behavior on conflicts; no annotations to compensate.
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?
Single short sentence is concise but lacks necessary detail; every word earns its place but the sentence is too brief to be fully useful.
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?
Output schema exists but description doesn't mention return value or error conditions; lacks context on prerequisites like system state or naming rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions, and the description adds no meaning beyond parameter names; no elaboration on format, constraints, or relationship between 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?
Description clearly states 'Rename a scratch pad module on a Niagara System' - specific verb+resource, distinguishes from sibling rename tools for assets and parameters.
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 provided on when to use this tool vs alternatives like rename_niagara_script_parameter or rename_asset, nor any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it 'Sets' (mutation), but lacks details on success/failure behavior, required existence of actor, or effects of partial transforms.
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?
One short sentence, front-loaded. No fluff, but borderline under-specified. Still concise for the breadth covered.
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, no annotations, and an output schema not described, the description lacks completeness. Does not explain default values, error handling, or how the transform is applied.
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 coverage is 0%; the description mentions location, rotation, scale but does not explain array formats (order, units). Adds minimal value beyond the parameter names.
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?
Clearly states the tool sets an actor's location, rotation, and/or scale. The verb 'Set' and resource 'actor transform' are specific, but no differentiation from sibling tools like set_actor_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_actor_property for individual properties). The description provides no context about prerequisites or 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 does not disclose side effects, safety (e.g., whether this triggers recompilation), or reversibility. Only states the boolean action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose then listing args. It wastes no words, but could benefit from more structured parameter 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?
The description lacks context about return values (output schema exists but unused), prerequisites, or relationship to other tools. For a setter tool with 5 required params, more completeness is needed.
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 coverage is 0%, so the description must explain parameters. It provides brief role descriptions (e.g., 'Path to the Niagara System asset') but no format, constraints, or examples. For 5 params, this is minimal additional value.
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 ('Enable or disable') and the resource ('a module in an emitter's stack'). It distinguishes from sibling tools like remove_niagara_module or add_niagara_module by focusing on the enabled state.
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, such as set_niagara_module_input or remove_niagara_module. No conditions, prerequisites, or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., whether it replaces existing mesh), permissions needed, or what happens if the component is missing. The statement is minimal and lacks behavioral detail beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It is efficient but too brief, missing important details. Conciseness is good, but it sacrifices completeness.
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 tool with 3 parameters and an output schema (not shown), the description is too sparse. It does not explain return values, error cases, or the relationship between inputs. An agent would benefit from more context about what the tool accomplishes beyond the obvious.
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 does not mention any parameters. Schema coverage is 0%, and the description adds no meaning beyond the schema. The default value for 'static_mesh' is not highlighted, and the purpose of 'blueprint_name' and 'component_name' is obvious but not explained.
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 static mesh on a StaticMeshComponent in a Blueprint. It specifies the verb and resource, but the tool name 'set_static_mesh_properties' suggests multiple properties while the description only mentions the mesh itself. Still, it differentiates from sibling tools like 'add_component_to_blueprint' or 'set_blueprint_node_property' by targeting a specific component 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 on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., component must exist) or when not to use it. The description lacks context about 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?
No annotations provided; description only states the basic action. Does not disclose side effects, permanence, authorization needs, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, but slightly too brief given the parameter complexity.
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?
Lacks enough context for a delete operation: output schema exists but isn't described, parameters are unclear, and expected behavior is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and the description does not explain parameters beyond 'by name'. data_table_path is completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (delete), target (row from a Data Table), and identifier (by name). It distinguishes from sibling tools like get_data_table_row or update_data_table_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites (e.g., existence of table or row), and no when-not-to-use 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, placing full burden on the description. The description only states the basic read operation without disclosing any behavioral traits such as idempotency, safety, performance implications, or side effects. It fails to indicate that this is a read-only, non-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.
Conciseness4/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 primary action. However, it is somewhat terse and could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter documentation and no annotations, the description is incomplete. It does not clarify what a 'Data Table asset' is or how to locate the path. Although an output schema exists, this does not compensate for missing parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no description for 'data_table_path'), and the tool description adds no meaning beyond the parameter name. It does not explain what format the path should be, how to specify it, or provide examples, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Get'), resource ('all rows and their field data from a Data Table asset'), and scope ('all rows'). This distinguishes it from siblings like 'get_data_table_row' (single row) and 'get_data_table_schema' (schema only).
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. Siblings like 'get_data_table_row' exist for retrieving a single row, but the description does not mention this or any context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions 'force recompile' but doesn't disclose side effects (e.g., discarding unsaved changes), permission needs, or if it affects dependencies. Only mentions success/failure reporting.
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?
Very concise (one sentence) and front-loaded. However, it underspecifies important details, so it loses a point for not earning its place with sufficient information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having one parameter and an output schema, the description lacks details about return value format, side effects, and error conditions. Completeness is low for a tool that performs a forced operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description does not explain what material_path means (e.g., full asset path, object name) or any format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Force recompile and save a material', specifying the verb and resource. It distinguishes from sibling tools like compile_blueprint (different resource) and create_material (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., save_all, build_material_graph) or what prerequisites are needed (e.g., material must already exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states a mutation action ('add') but lacks details on side effects, requirements, or constraints (e.g., duplicate names, type restrictions).
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?
Single sentence is concise but overly brief, sacrificing completeness. It is front-loaded with purpose but lacks structure for parameter or behavior 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 annotations, 0% schema description coverage, 5 parameters, and an output schema, the description fails to provide essential context. It does not address prerequisites, parameter behavior, or what the output schema contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the tool has 5 parameters. The description provides no explanation of any parameter's meaning or usage, forcing agents to guess from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
'Add an output parameter to a Blueprint function' clearly specifies the action (add), resource (output parameter), and context (Blueprint function). It distinguishes from siblings like add_function_input or set_material_function_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in Blueprint function editing but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It only says 'Add', implying mutation, but fails to specify side effects, required permissions, or whether compilation is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a single sentence and an Arg list. The structure is clear but somewhat code-oriented, which may reduce readability 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?
Given the complexity of adding a global task to a StateTree, the description lacks crucial context such as return value, effect on existing tasks, and required compilation. Output schema exists but is not described.
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?
Description provides basic explanations for each parameter (asset path, task class, properties, instance properties) which adds meaning beyond the schema's type-only definitions. However, explanations are vague and do not clarify the structure of properties objects.
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 it adds a global task to the StateTree. However, with sibling tool 'add_statetree_task' also present, it does not differentiate between global and regular tasks, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'add_statetree_task'. No prerequisites or conditions for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions creation but does not disclose side effects, overwrite behavior, or required permissions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with purpose. It could be more structured but is not verbose. Every sentence adds some value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details on many parameters, return values, or behavioral context. For a tool with 7 parameters and 0% schema coverage, more information is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for variable_type by listing valid values (bool, int, float, string, vector, rotator), compensating for schema's lack of descriptions. However, other parameters like tooltip, category, is_public, default_value, variable_name, and blueprint_name are not explained. Schema coverage is 0%, so partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a variable in a Blueprint' and lists allowed types, making the core action and resource clear. It is distinct from siblings like add_component_to_blueprint or delete_blueprint_variable, but no explicit differentiation is provided.
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 other variable-related tools such as set_blueprint_variable_properties or create_blueprint. No context on prerequisites or typical 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?
The description does not disclose behavioral traits beyond the action itself. Since annotations are absent, the description carries the full burden but fails to mention side effects (e.g., breaking connections), irreversibility, or required permissions. It only says 'delete' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (single sentence, 10 words) and front-loaded, but it sacrifices completeness. While every word earns its place, the overall information density is low, leaving critical gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides minimal context. It does not explain what happens after deletion (e.g., connections removed, undo available) or how the 'function_name' parameter affects the operation. For a deletion tool with 3 parameters, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description only mentions 'by GUID' which corresponds to node_id, but does not explain the optional function_name parameter or its default value. The agent lacks necessary semantic context for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (node from a Blueprint graph), and the method (by GUID). It is specific and distinguishes the tool from siblings that operate on different graph types (e.g., delete_material_expression, delete_niagara_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?
No guidance is provided on when to use this tool versus alternatives, when not to use it, or any prerequisites. The description only states the action without contextual instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states that the tool retrieves metadata, implying a read operation with no side effects. However, it does not explicitly confirm read-only behavior, mention performance implications, or describe the response structure beyond listing a few fields.
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 concise and front-loaded with the verb 'Get'. It efficiently conveys the core purpose without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, has output schema), the description minimally covers the purpose and output but omits input semantics and usage context. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is critical for explaining the parameter 'asset_path'. The description does not mention the parameter at all, nor its format or expected values. It only describes the output, adding no meaning to the input parameter.
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 'Get asset metadata' and specifies the returned information: class, package, and key properties. It distinguishes the tool from siblings like 'get_asset_properties' or 'list_assets' by focusing on metadata, but does not explicitly differentiate.
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 'get_asset_properties' or 'find_assets'. There is no mention of prerequisites, limitations, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it gets editable properties, but does not clarify that it is read-only, what error scenarios exist (e.g., asset not found), or any side effects. A more comprehensive description would address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and efficient, though it lacks some detail. It earns its place without 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 existence of an output schema, the description does not need to detail return values, but it fails to cover error handling, the meaning of 'editable properties', or any usage context. The tool is simple but the description is too minimal for full agent understanding.
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 sole parameter asset_path has no description in the schema (0% coverage), and the tool description does not elaborate on its meaning (e.g., file path vs content browser path). The description adds no value beyond the parameter's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 all editable properties of an asset. It uses a specific verb and resource, distinguishing it from siblings like set_asset_property (which sets properties) and get_asset_info (which gets general info).
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_asset_info or set_asset_property. There is no mention of prerequisites, typical workflow context, 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 must convey behavioral traits. It does not disclose whether the operation is read-only, permissions required, error conditions, or any side effects. The description is too brief to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently states the purpose. However, it omits necessary details for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists, the description is adequate for a simple retrieval, but lacks usage context and parameter semantics. It is minimally complete.
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 single parameter 'data_table_path' is not described. With schema description coverage at 0%, the description adds no meaning beyond the schema's type and requirement. The agent lacks clarity on what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves column names and types from a data table's row struct. It uses a specific verb 'Get' and identifies the resource 'Data Table's row struct', distinguishing it from sibling tools like get_data_table_rows.
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 prerequisites, when it is appropriate, 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 exist, so the description bears full responsibility for behavioral disclosure. It mentions retrieving 'overridable parameters' but does not indicate whether this is a read-only operation, whether it requires specific permissions, or any side effects. The lack of behavioral context 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 concise sentence that efficiently communicates the tool's purpose. However, it could benefit from front-loading the key action and resource even more clearly. Still, it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but indicated), the description does not need to explain return values. However, for a tool with one parameter, the description should provide more context about the material path (e.g., content browser path, package format) to ensure correct usage. The current description is adequate but lacks full situational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'material_path' has no description in the schema (0% coverage), and the tool description does not add any additional meaning. It fails to specify the expected format, path requirements, or how to locate the material instance. This is insufficient for an agent to correctly provide the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'overridable parameters from a Material Instance', and lists specific parameter types (scalar, vector, texture, switch). This effectively distinguishes it from sibling tools like set_material_instance_parameter.
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 or exclusions. An explicit comparison to set_material_instance_parameter or other material tools would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the action. There is no mention of permissions, side effects, or behavior on missing paths. A read-only operation should be indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the main action. The Args section adds clarity, but could be more compact. However, it is efficient overall.
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 4 parameters and no annotations, the description is incomplete. It misses two important parameters (recursive, max_results) and does not explain the return value, though output schema exists. The description should cover all inputs to be adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (path, recursive, max_results, class_filter), but the description only covers path and class_filter, omitting recursive and max_results. With 0% schema description coverage, the description fails to compensate, leaving two critical parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'list', the resource 'data assets', and the scope 'in a content path, optionally filtered by class'. It distinguishes from sibling 'list_assets' which likely lists all asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'find_assets' or 'list_assets'. No conditions for use or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It discloses that removal is destructive and that root widget is protected, but does not detail other behaviors like irreversible deletion, effects on references, or required permissions.
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, extremely concise, with the key restriction included. No wasted words; front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context such as prerequisites, error conditions, side effects, and return behavior. With two undocumented parameters and no behavioral detail, it is insufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (widget_blueprint_path, widget_name) or their expected formats. No compensation for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Remove' and the resource 'widget and its children', and mentions a restriction (cannot remove root widget). This distinguishes it from related sibling tools like add_widget and move_widget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, no mention of prerequisites or contexts where it should be avoided. It only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'Set a property', omitting side effects, permissions, or result details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with examples, no unnecessary 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?
Covers the basic operation but lacks asset_path explanation and usage context. Output schema exists but not described.
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?
Explains property_name and property_value with examples, adding value over schema. However, asset_path is undocumented, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a property on an asset, with examples. It distinguishes from get_asset_properties, but does not explicitly differentiate from other set_* 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 on when to use this tool vs alternatives like set_actor_property. Agent must infer from the 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?
With no annotations, the description carries full burden. It lists actions but does not disclose side effects, error conditions, or whether changes are automatically saved. Agents cannot anticipate failures or understand the full impact of mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. The action list is clearly delineated. However, the second line could be more structured (e.g., tables or bullet points) to reduce ambiguity, but overall it is not overly 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's complexity (14 params, no schema descriptions, no annotations), the description is incomplete. It lacks context on prerequisites, return values (despite an output schema), and example usage. Agents need more information to correctly invoke the tool.
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 coverage is 0%, yet the description only vaguely associates parameters with actions. It does not map which params are required for each action, and key params like property_name and property_value for direct property setting are not explained. This leaves agents guessing parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a node property or performs semantic editing, listing specific actions like add_pin and set_enum_type. It distinguishes itself from sibling tools like add_blueprint_node or connect_blueprint_nodes, which handle different blueprint graph operations.
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, when to choose direct property setting versus semantic actions, or any prerequisites (e.g., blueprint must be open). This omission forces the agent to guess based on the action list.
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 adds value by noting that it accepts both snake_case and PascalCase naming, which is a helpful behavioral detail. However, with no annotations, it does not disclose error handling, side effects, or return values beyond what output schema might cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a bullet-like list of common properties. It is front-loaded with the purpose and provides additional detail without being 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 4 parameters and zero schema coverage, the description is incomplete. It fails to explain material_path and node_index, and does not specify the format or constraints of property_value. The output schema exists but is not reflected in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only provides examples for property_name, ignoring material_path, node_index, and property_value. It does not sufficiently compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a property on an existing material expression node. It distinguishes from siblings like add_material_expression and set_material_instance_parameter by specifying 'existing expression 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?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no exclusions or caveats 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?
The description provides no behavioral details beyond the basic action. No mention of side effects, validation, permissions, or what happens if the property does not exist. An output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes an argument list, but the list is informal and could be more compact. It is acceptably concise but not optimally 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?
Given four required parameters and many sibling tools, the description lacks details on value serialization, error handling, and return value. The output schema is not described, leaving users to rely on external documentation.
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 repeats parameter names and gives a few examples for the 'property' parameter, but adds little meaning beyond the schema. It does not clarify the expected format for system_path or emitter_name, and the 'value' parameter is only described as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource 'property on an emitter within a Niagara System', distinguishing it from sibling tools like set_niagara_system_property and set_niagara_renderer_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as set_niagara_system_property or set_niagara_renderer_property. Users must infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'set layout slot properties' without disclosing side effects, required permissions, whether changes are reversible, or what happens if the slot is invalid. The description adds minimal behavioral context beyond the obvious mutation.
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 redundant words. However, it could benefit from a bit more structure, such as listing the required parameters or mentioning that the output schema provides result 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?
Despite having an output schema (context signal), the description does not mention the return value or error cases. For a mutation tool with no annotations and three required parameters, the description should specify what happens on success/failure or any constraints, which it does not.
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 coverage is 0% and the description only lists example property keys (anchors, offsets, padding, alignment) without explaining the format, constraints, or how to structure the 'properties' object. For a free-form object parameter, this is insufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('layout slot properties') and lists example properties like anchors, offsets, padding, alignment, etc. This clearly distinguishes it from the sibling tool 'get_slot_properties' which reads slot 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?
No guidance on when to use this tool vs alternatives (e.g., when the parent widget is not set up or when to use 'set_widget_properties' instead). There is no mention of prerequisites, context, 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 were provided. The description fails to disclose any behavioral traits such as side effects (e.g., triggering recompile, validation, or irreversible changes). It only states 'Set a property' without elaborating on what happens when the property is set or any constraints. The parameter list adds no behavioral context beyond naming.
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 starts with a clear, succinct sentence defining the primary action. The subsequent parameter list is structured but slightly verbose with repetitive 'Args:' formatting. Overall, it is reasonably concise and front-loaded with the main 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 description lacks completeness for a complex tool with 7 parameters and required state identification. It does not explain the relationship between transition_index and the state's transitions, nor how to properly select the state. The existence of an output schema is not mentioned, leaving the agent without information on what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add brief definitions to parameters (e.g., 'Content path to the StateTree asset' for asset_path), but fails to explain complex semantics. For instance, it does not clarify that exactly one of state, state_name, or state_guid is needed to identify the state, nor what transition_index means relative to the state's Transitions array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource 'property on a transition' in a StateTree asset. It lists example properties like Trigger, Priority, TargetState, which makes the action concrete. It effectively differentiates from sibling tools such as set_statetree_state_property or set_statetree_node_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 guidance on when to use this tool versus alternatives like remove_statetree_transition or other setter tools. It does not mention prerequisites, required context (e.g., an open StateTree asset), or when not to use it. Usage is only implied by the tool name and initial 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, the description carries the burden of revealing side effects. It does not state whether linking overwrites an existing link, whether it is reversible, or if any validation is performed. The behavioral impact is unclear.
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 fairly concise but includes an 'Args:' block that adds verbosity. The structure is readable but could be more streamlined.
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 6 required parameters, no annotations, and an output schema not elaborated, the description omits critical context such as whether linking creates a binding, if the parameter must pre-exist, or what the result looks like. The agent may lack information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a helpful example for 'linked_parameter' (namespace and formatting), but other parameters like 'system_path' and 'emitter_name' lack any additional explanation beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Link') and the resource ('module input to a Niagara parameter'), specifying the scopes (user, system, emitter, particle). This distinguishes it from sibling tools like 'set_niagara_module_input' or 'add_niagara_user_parameter'.
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 when to link vs. set a module input. It does not mention prerequisites or contexts where linking is 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?
No annotations are provided, so the description must carry the full burden. It does not disclose any behavioral traits such as side effects, necessary permissions, or whether the node must belong to a valid graph. The tool likely just updates coordinates, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is slightly under-specified given the tool's complexity, balancing conciseness and 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?
Despite having an output schema, the description lacks context about graph editing requirements, such as needing an open material graph or validation steps. Sibling tools suggest a rich material system, but this tool's description is too minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter details. Parameters like 'pos_x' and 'node_index' are undefined, leaving critical ambiguity about coordinates and how to identify the node.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'material expression node', and the action context 'to a new graph position'. It uniquely identifies the tool's purpose among sibling tools like 'add_material_expression' and 'delete_material_expression'.
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 or alternatives. The description implies usage for repositioning nodes, which is clear but lacks exclusions or context about prerequisites like valid editor state.
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 only states the action and two constraints, but does not disclose side effects, permissions needed, or behavioral details beyond those constraints. It lacks information on whether the move is reversible, if original widget is preserved, or any feedback on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the action. It is efficient but could be slightly more structured to improve readability. Still, every sentence serves a 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 a move operation in a hierarchy, the description is insufficient. It lacks parameter details, usage context, and does not fully leverage the existence of an output schema. The constraints are helpful but do not provide complete guidance for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are described in the schema. The description does not compensate by explaining any of the parameters (widget_blueprint_path, widget_name, new_parent_name, index). It adds no semantic value beyond the raw 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 (move), the object (widget), and the destination (different parent panel), along with explicit constraints (cannot move root or into own descendants). This distinguishes it from sibling tools like rename, duplicate, or remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by stating constraints (no root/descendant moves), but does not explicitly mention when to use this tool versus alternatives like add_widget or reorganizing via other means. There is no direct 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'rebuild its signature', which is a behavioral trait beyond the remove action, but it does not disclose other side effects like destructive nature or permission requirements. With no annotations, this is a modest addition.
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, but it omits important details like parameter roles, making it too brief for practical use. Still, it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters with no schema descriptions and an output schema present, the description fails to explain parameter meanings or expected behavior, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation for the three required parameters (pin_name, module_name, system_path). The user is left to infer their meaning from context alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and identifies the resource as 'a pin from a Custom HLSL node', clearly distinguishing it from sibling tools like 'add_niagara_custom_hlsl_input' and 'rename_niagara_custom_hlsl_pin'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'remove_niagara_node_pin' or other pin removal tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states the action without disclosing side effects, required permissions, whether the blueprint needs to be compiled or saved, or what happens if inputs are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Efficiently conveys the core action.
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 complexity (5 params, required fields) and presence of an output schema, the description lacks details about return values, required preconditions, or integration with other blueprint tools. Incomplete for an AI agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description adds no explanation for parameters like param_type (allowed values) or is_array (effect on the parameter). The param names are somewhat self-explanatory but insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (add), the object (input parameter), and the context (Blueprint function). It distinguishes from sibling tools like add_function_output and delete_blueprint_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 on when to use this tool versus alternatives like add_function_output or compile_blueprint. No prerequisites or conditions mentioned, which is needed given the many sibling tools.
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 handle behavioral disclosure entirely. It fails to mention any important traits such as whether adding an input with an existing name overwrites or fails, any permission requirements, or the effect on the material function graph. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line purpose, followed by a well-organized parameter list. Each parameter has a brief, useful comment. Minor redundancy exists (e.g., repeating 'preview_value' in preview_value's comment), but overall 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 9 parameters, no annotations, and no output schema, the description covers parameter semantics well but omits broader context. Missing information about return behavior, error conditions, and operational context (e.g., graph changes). It's adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description provides thorough parameter explanations including types, enums, and usage hints (e.g., 'JSON array for default value'). It adds essential meaning beyond the raw schema, which only lists types and defaults.
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 verb 'Add' and resource 'input pin to a Material Function'. It is specific about the operation but does not differentiate from sibling tools like 'set_material_function_input' or 'add_material_function_output', which perform related but distinct actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that this tool creates a new input pin while 'set_material_function_input' modifies an existing one. The agent receives no context for appropriate 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, the description carries the full burden of disclosing behavioral traits. It does not mention idempotency, effects of duplicate names, or required permissions, leaving critical gaps for an agent.
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?
Extremely concise: one sentence followed by bulleted argument descriptions. No wasted words, and the key action is front-loaded. Every part adds value.
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 an output schema exists, the description does not mention return values. It also lacks information on error conditions or side effects, making it incomplete for a complete agent understanding.
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?
Despite 0% schema coverage, the description explains each parameter with examples (e.g., type lists common values). This adds meaningful context beyond the schema property names, though the asset_path format could be more precise.
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 'Add a tree-level parameter,' which specifies the action and resource. This distinguishes it from sibling tools that add other StateTree elements like states or tasks.
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 prerequisites, such as requiring the asset to be loaded, or when to use the complementary remove_statetree_parameter tool.
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 only lists parameters and their values. It does not disclose behavioral traits such as whether the operation is destructive, requires specific permissions, or has side effects. No annotations are provided to supplement this.
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 structured as an args list, which is clear but verbose. Front-loading is minimal; the purpose is stated first, but the parameter list dominates. Could be more concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters and no annotations, the description covers all parameters with brief explanations. The output schema exists, so return values are not needed. It provides sufficient context for the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by enumerating each parameter with valid values (e.g., trigger options, delay semantics). This compensates for the schema's lack of descriptions, though some parameters (e.g., delay_variance) could use more detail.
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 'Add a transition to a state,' specifying the verb and resource. However, it does not differentiate this tool from sibling tools like add_statetree_state or add_statetree_task, lacking 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 on when to use this tool versus alternatives. It does not mention prerequisites, context, or situations where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It does not mention any side effects, permission requirements, or validation behavior. The agent cannot know if the tool will silently fail, overwrite existing connections, or require a specific blueprint state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a clear purpose statement and an args list. It front-loads the action and then details parameters. However, it could be slightly more efficient by integrating the purpose more tightly with the parameter descriptions.
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 complexity (6 params, 5 required, modifies a graph), the description is incomplete. It fails to mention the return value (though an output schema exists), does not explain the behavior of 'function_name' in detail, and omits 'blueprint_name'. The agent is left with unanswered questions about how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the parameters it lists (source_node_id, source_pin_name, target_node_id, target_pin_name, function_name) with brief explanations. However, it omits the required parameter 'blueprint_name' entirely, which is critical. Since schema coverage is 0%, this omission creates a significant gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Connect two nodes in a Blueprint graph.' This is a specific verb+resource that distinguishes it from sibling tools that add, delete, or set properties of nodes. The purpose is unmistakable.
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 vs. alternatives like 'add_blueprint_node' or 'connect_material_expressions'. There are no prerequisites, no warnings about invalid connections, and no mention of whether nodes must already exist. The agent receives no help in deciding 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, and the description lacks behavioral details such as side effects, failure conditions, or whether the disconnection is reversible. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it omits the material_path parameter, making it slightly incomplete. It is otherwise concise.
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 incomplete: it fails to mention the required material_path parameter and does not describe return values despite an output schema. With no annotations, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning for node_index and input_pin but omits material_path, which is a required parameter. With 0% schema coverage, the description should compensate, but it does not cover all 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 tool's purpose: disconnecting a specific input pin on a material expression node. The verb 'Disconnect' and the resource 'input pin' are specific. It distinguishes itself from sibling tools like 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 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 prerequisites, when not to use it, or suggest other tools for related tasks.
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 notably discloses that connections are NOT copied, which is a critical behavioral detail not obvious from the name. With no annotations, this is helpful. However, it does not mention other potential side effects, permissions, or whether the material needs recompilation. Overall adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. The first sentence states the purpose, the second provides return value and a key caveat (no connections). Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essentials: duplication, offset, return value, and connection behavior. However, it does not address prerequisites (e.g., node must exist), usage context among many sibling tools, or any output schema details (though output schema exists but not provided). Adequate but not fully complete for an unfamiliar user.
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?
With 0% schema description coverage, the description must compensate. It explains that the original node is offset (implying offset_x and offset_y), but does not describe material_path or node_index explicitly. The term 'offset from original' gives context for offset parameters, but leaves the other two parameters ambiguous. More detail would improve usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it duplicates a node with same type and properties and offset. It distinguishes from other tools like add_material_expression (which adds from scratch) and move_material_expression (which moves). However, it could be more explicit about when to use this versus siblings, and the term 'node' is slightly ambiguous without context of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like add_material_expression. The description does not mention prerequisites (e.g., material must be loaded) or context (e.g., only works on material graph nodes).
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 behavioral traits beyond the basic action. With no annotations provided, the agent is left uninformed about side effects (e.g., whether the original is modified, naming conventions, or potential errors).
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, with a purpose line followed by an Args list. It is efficient, though the Args format could be slightly more structured (e.g., bullet points or clearer separation). 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?
While the description covers the basic purpose and parameters, it lacks context about prerequisites (e.g., system must be loaded), behavior (e.g., naming conflicts), and relationship to other tools. An output schema exists, so return values are assumed covered, but overall completeness is adequate but not thorough.
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?
Since the input schema has 0% description coverage, the description compensates by providing clear meanings for all three parameters: system_path, emitter_name, and new_name (optional). This adds significant value beyond the bare schema types.
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 'Duplicate an emitter within a Niagara System' and lists the key parameters. The verb 'duplicate' is specific and distinguishes from sibling tools like 'add_niagara_emitter' or 'remove_niagara_emitter', though no explicit comparison is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there prerequisites or context about the duplication process. The description only lists parameters without 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?
No annotations exist, so the description must disclose behavior. It states it 'gets information' but doesn't describe what information is returned, side effects, error conditions, or requirements like system compilation. The minimal description fails to provide transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose followed by a bulleted parameter list. Every sentence adds value, no filler, and the key action is 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?
Despite having an output schema, the description does not explain what 'detailed information' includes. It lacks prerequisites, usage context among many Niagara renderer tools, and any safety notes. For a tool returning complex data, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential context for each parameter: system_path (path to asset), emitter_name (target), renderer_index (default 0). This meaningfully supplements the raw schema types.
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 retrieves detailed renderer information from an emitter, using a specific verb-object structure. It naturally contrasts with sibling tools like set_niagara_renderer_property, but doesn't explicitly differentiate 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 on when to use this tool versus alternatives. It does not mention prerequisites, appropriate contexts, or scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it lists subclasses, with no disclosure of read-only nature, performance, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy or fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits parameter details for two of three parameters, making it incomplete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'filter' but does not explain 'panels_only' or 'include_abstract' semantics, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 available UWidget subclasses, which is a specific verb+resource. It is distinct from sibling tools, none of which directly list widget 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?
The description says to use the filter to narrow results, but provides no guidance on when to use this tool vs alternatives, nor 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 must carry the full burden. It does not disclose side effects, error cases, permissions, or what happens when conflicting properties are set. The behavior is minimally described as 'set properties' without nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines) and front-loads the purpose. Each sentence serves a purpose: stating the action and listing parameters with helpful examples. 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 is relatively simple, and the output schema exists (so return values are covered). However, the description lacks context about when to use this tool, error handling, or dependencies. Given the complexity and sibling tools, it is minimally adequate but could include more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant value by explaining asset_path as 'Path to the InputAction asset', value_type as a convenience shortcut with enumerated options (Boolean, Axis1D, etc.), and properties as a dict of property names to values with an example. This goes beyond the bare 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 clearly states 'Set properties on an Input Action' with a specific verb and resource. It lists the arguments, making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like set_input_action_property (singular) or other input action modifiers, but the distinction is implied.
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 add_input_action_trigger or create_input_action. It does not mention prerequisites, limitations, or context for invocation.
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 behavior. It mentions JSON-encoded values but does not explain side effects, required preconditions, or error handling. The tool modifies a material instance, yet no behavioral details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a clear list of args. It front-loads the purpose but could be more structured with bullet points.
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 modifies an asset, the description lacks context about preconditions, side effects, and output. Although an output schema exists, the description does not mention return values or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds meaning for param_type and value (allowed types and formats). However, it omits semantics for material_path and param_name, which remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a parameter override on a Material Instance, with a specific verb and resource. This distinguishes it from other material-related tools like set_material_properties or get_material_instance_parameters.
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 are there prerequisites or context for usage. The description only lists parameter formats.
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 fails to disclose behavioral traits like overwrite behavior, error handling, or required permissions. It merely states the action without any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a docstring format with an 'Args' block. It avoids redundancy and is front-loaded with purpose. Minor improvement could be removing the 'Args:' header for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and an output schema, the description is incomplete. It does not explain return values, error states, or the effect on the Niagara system. The tool's complexity warrants more context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining the 'value' parameter format (scalars, vectors, colors, enums, bools). However, the other five parameters lack any added semantic meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a static value on a module input parameter. The verb 'Set' and resource 'module input parameter' are specific, and the tool is well-differentiated from siblings like 'get_niagara_module_input' and 'clear_niagara_module_input'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'set_niagara_dynamic_input' or 'set_niagara_curve'. The description does not mention prerequisites, conditions, or exclusions, 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?
No annotations are provided, so the description bears the burden of behavioral disclosure. It states 'Add or update' implying mutation, and gives color format details, but does not mention side effects, overwrite behavior, persistence, permissions, or return values. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single-purpose sentence followed by parameter details in a list format. It front-loads the purpose and avoids unnecessary words. The structure is informal but effective.
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 that an output schema exists, the description need not detail return values. However, it omits prerequisites (e.g., asset existence), error conditions, and what happens on conflict. It provides adequate parameter info but lacks full context for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: 'asset_path' is 'Content path to the StateTree asset', 'name' is 'Display name for the color', and 'color' specifies acceptable formats (hex or RGBA floats). This provides clear semantic context beyond 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 clearly states 'Add or update a color in the StateTree theme,' identifying the verb (add/update) and resource (color in theme). It distinguishes from sibling tools that deal with other aspects like states or tasks, although it doesn't explicitly differentiate from other set_statetree_* 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?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or preferred use cases. The usage is only implied by the purpose.
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 behavioral traits such as whether the tool can replace actors, permissions needed, or side effects. The output format is not mentioned despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear two-line structure: the purpose sentence followed by an 'Args:' list. No redundant information, though the main sentence could be slightly more specific.
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 6 parameters and a rich set of sibling tools, the description covers the key inputs but omits return value information and implicit constraints (e.g., spawning in the current level). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful explanations for each parameter (e.g., 'location/rotation/scale: [x,y,z] arrays', 'static_mesh: Path to static mesh asset'), which compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Spawn an actor in the level' and lists key parameters, but it does not differentiate from sibling tools like spawn_actor_by_class or spawn_blueprint_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is purely functional without context on 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?
No annotations are present, so the description must fully disclose behavior. It mentions optional data but omits side effects (e.g., duplicate row_name handling), permissions, or what constitutes a successful operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes a practical example. No superfluous 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?
Despite an output schema existing, the description fails to explain required parameters adequately and lacks behavioral details needed for correct invocation. The tool has 3 params (2 required) and minimal 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 description explains the 'data' parameter with an example, but does not describe 'row_name' or 'data_table_path' beyond their names. With 0% schema coverage, this partial explanation only moderately compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new row') and distinguishes this tool from siblings like get_data_table_rows and update_data_table_row. The example of setting field values 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 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 vs alternatives, nor any conditions or prerequisites. The description lacks 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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only lists parameter descriptions and defaults, without mentioning side effects, permissions, persistence, or recompilation triggers. Essential behavioral context is missing.
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 plus a structured Args list. It is front-loaded with the purpose, and every line adds value. No unnecessary 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?
The description covers all parameters and purpose, and an output schema exists for return values. However, it lacks usage context and behavioral transparency, leaving gaps for someone unfamiliar with the tool's role among siblings.
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?
Since schema description coverage is 0%, the description compensates well by detailing each parameter: function_path gets 'Full path', output_name gets an example list, and sort_priority explains display order. This adds substantial meaning beyond the schema's type/default information.
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 'Add an output pin to a Material Function,' which is a clear verb+resource combination. It effectively communicates the tool's primary function, but does not explicitly differentiate from siblings like add_material_function_input.
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 over alternatives. With numerous sibling tools for material functions (e.g., add_material_function_input, set_material_function_output), it fails to mention the specific context or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions that the pin's name is usable inside HLSL source, but does not explain side effects, prerequisites (e.g., scratch pad module must be open or exist), error conditions, or whether the modification is immediately applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main action. The list of types is useful but slightly verbose. No unnecessary words, but could be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain the result of adding the pin, whether it requires recompilation, or how it appears in the HLSL editor. Prerequisites and error handling are missing.
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 coverage is 0%, so description must compensate. It lists types but does not explain key parameters like 'system_path' or 'module_name' beyond their names. The 'pin_type' default is mentioned but not its meaning. The description adds minimal value over 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 'Add', the resource 'typed input pin', and the context 'scratch pad module's Custom HLSL node'. It distinguishes from sibling tools like add_niagara_custom_hlsl_output, which adds an output pin.
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 lists supported types and mentions that the pin's name is usable inside HLSL source, implying usage context. However, it does not provide explicit guidance on when to use this tool vs alternatives, such as when to add an output pin or other node modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses mutation (adds pin) but fails to mention idempotency, error states (e.g., duplicate pin), or impact on existing node structure. Lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant text. Could be improved by front-loading key details like 'typed output' but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is bare given sibling diversity and lack of annotations. Does not explain output schema, prerequisites (e.g., existing scratch pad module), or relation to other custom HLSL operations. Incomplete.
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 coverage is 0%, so description must explain parameters. Only 'typed output pin' hints at pin_name and pin_type, but system_path and module_name are unexplained. Insufficient for a 4-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 typed output pin' to a 'scratch pad module's Custom HLSL node'. This distinguishes it from siblings like add_niagara_custom_hlsl_input (adds input) and add_niagara_node_pin (general pin).
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 context (adding output pin to custom HLSL node) but gives no explicit when-to-use, prerequisites, or alternatives. Slight implicit guidance from name but insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description only states the action without disclosing side effects, modifications to the asset, or requirements. The behavioral impact (e.g., modifying the scratch pad) is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the main action. The Args section adds some length but remains efficient. Every sentence contributes, though the reference to add_niagara_map_get_pin could be a minor distraction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema to cover return values, the description lacks context on prerequisites, error cases (e.g., missing MapSet node), and interaction with other Niagara tools. Not sufficient for a graph-editing tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The Args section lists parameters and gives brief descriptions, but parameter_type references another tool for details, and the descriptions are minimal. Insufficient to fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a typed input pin to the first ParameterMapSet node in a scratch pad graph, with a reference to the UI action, distinguishing it from siblings like add_niagara_map_get_pin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through the mention of mirroring the '+' click, but no explicit when-to-use, when-not-to-use, or comparison to alternatives like add_niagara_node_pin. No prerequisites or context 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 of behavioral disclosure. It only states the action without revealing side effects (e.g., whether the asset is modified in memory or saved, whether permissions are required, or if there are limitations on task types). The existence of an output schema is noted but not described, leaving behavioral expectations 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 concise: a one-line summary followed by a clean, bullet-like list of parameters. Every sentence contributes value, with no extraneous content. The structure is easily 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?
Given the tool's complexity (7 parameters, 2 required, output schema present), the description covers the basic action and parameter meanings but lacks deeper context. It does not explain how a task fits into the StateTree architecture, what constitutes a valid state, or how properties and instance_properties should be structured. The output schema exists but is not mentioned, which reduces contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists each parameter with a brief explanation (e.g., 'task_class: Task struct name (e.g. MassEnemyAttackTask)'), adding meaning beyond the bare schema. While some explanations are minimal (e.g., 'state: State index path'), they provide enough context for typical use. The examples for task_class are helpful.
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 'Add a task to a state', which clearly identifies the action (add), the resource (task), and the target (state). This distinguishes it from sibling tools like add_statetree_state or add_statetree_evaluator. However, it does not elaborate on what a task represents in the StateTree context, which could be improved for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like add_statetree_evaluator or add_statetree_condition. There is no mention of prerequisites (e.g., the state must exist), nor any exclusion criteria. Users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects or prerequisites. For example, does 'destroy' remove the actor permanently? No details on what happens to the actor after each action.
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?
Extremely concise: two sentences and parameter list. Front-loaded with the purpose. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) which may document return values, but the description lacks context on prerequisites (e.g., actor must exist) and error conditions. Given the narrow scope, it's minimally adequate but could elaborate on state assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by listing the possible action values (activate, deactivate, reset, destroy) and clarifying actor_name is a name/label. This helps the agent understand valid inputs.
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 controls a Niagara effect actor with actions like activate, deactivate, reset, destroy. It differentiates from siblings like spawn_niagara_effect or delete_niagara_system by focusing on runtime control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as when to activate vs spawn, or when to destroy vs use delete_niagara_system. The agent must infer context from actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose important behavioral traits such as permanence of deletion, undo capability, required permissions, or side effects. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is front-loaded with the verb and object, making it efficient and 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 tool's simplicity (one parameter, no annotations, but has output schema), the description is minimally adequate but lacks details on prerequisites, side effects, or return value expectations.
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 parameter 'name' has no description in the schema (0% coverage), and the description only adds a vague 'by name' without clarifying what constitutes a valid name (e.g., actor label, unique ID). More detail 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 clearly states the verb (delete), object (actor), and context (from the level by name). It is specific and distinguishes this tool from siblings like spawn_actor or set_actor_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with other actor-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?
No annotations are provided, so the description must fully disclose behavior. It mentions the 'force' parameter to skip reference checks but does not explain consequences of deletion (e.g., irreversibility, side effects on dependent assets). It lacks clarity on default behavior when force=false and does not confirm if deletion is permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence for purpose and a clear list of parameters. No unnecessary words. The structure 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?
The description is minimal but covers the basic operation. It does not mention output (though an output schema exists), preconditions (e.g., asset existence), or post-conditions. Given the tool's simplicity and presence of output schema, the description is adequate but could add more context about side effects or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds an 'Args' section explaining each parameter beyond the schema. Schema coverage is 0%, so the description compensates by describing system_path as the path to the asset and force as skipping reference checks. This provides meaningful guidance for both 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 that the tool deletes a Niagara System asset, using a specific verb and resource. It distinguishes from sibling tools like 'delete_asset' (generic) and 'remove_niagara_emitter' (sub-component). However, it is somewhat brief and could be more explicit about the asset type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'delete_asset' or other Niagara deletion tools. The description does not mention any conditions like 'use this when you want to delete a Niagara system specifically' or 'avoid if you need to delete with reference checks'.
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 only discloses the empty-name behavior but omits important traits like read-only nature, what 'detailed info' includes, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence, front-loading the purpose. However, it lacks structure (e.g., sections) and could add more detail without harming 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?
Despite having an output schema, the description is too brief to be complete. It does not explain the meaning of three parameters, nor does it provide usage context or behavioral details beyond the empty-name case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only partially explains one parameter (function_name) via the 'empty name' note. The other two parameters (blueprint_path, include_graph) are not described at all, leaving their meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 detailed info about Blueprint functions, with a specific verb and resource. It also clarifies a special behavior (empty name returns all functions), distinguishing it from sibling tools like get_blueprint_variable_details or analyze_blueprint_graph.
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 hints at usage by noting empty name returns all functions, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action is 'Get', implying a read operation, but fails to disclose side effects, permissions, or any other behavioral traits. This is insufficient for a safe selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose followed by a single parameter docstring. No wasted words; the key information is front-loaded. Ideal length for quick scanning.
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 presence of an output schema reduces the need to describe return values, the description is minimal and does not explain what 'tree-level parameters' encompasses or how it relates to other statetree concepts. Adequate for simple use but lacking in broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, so the description compensates by explaining the 'asset_path' parameter as a 'Content path to the StateTree asset'. This adds meaningful context beyond the schema's type-only definition. However, the description does not elaborate on format or validation.
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 retrieves 'tree-level parameters' and specifies the information included (name, type, value). However, it does not differentiate from sibling tools like get_statetree_info or get_statetree_states, missing an opportunity for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites or context, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool is read-only ('read') and supports all FProperty types, but does not explain behavior for missing widgets, return format, or side effects. The description is adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that quickly communicates the tool's core function. It is efficient and front-loaded, earning its place without unnecessary words. However, it could benefit from slightly 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?
Despite having an output schema, the description is too minimal given the tool's four parameters and zero schema coverage. It omits critical details like the filter parameter's usage and the meaning of include_inherited, leaving significant gaps for an agent to operate 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?
Schema description coverage is 0%, so the description must compensate. It fails to explain any of the four parameters (widget_blueprint_path, widget_name, filter, include_inherited). While widget_blueprint_path and widget_name are somewhat clear from their names, filter and include_inherited are ambiguous, and no additional meaning 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 the tool reads all property values from a widget, using the verb 'read' to indicate a read-only operation. It explicitly mentions support for all FProperty types, distinguishing it from sibling write tools like set_widget_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?
The description provides no guidance on when to use this tool versus alternatives like set_widget_properties or other widget-related tools. There is no mention of prerequisites or scenarios where this tool is preferred, leaving the agent to infer usage from 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 provided, so description carries full burden. It states 'Get' implying read-only, but does not disclose behaviors like requiring an open level, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no unnecessary words, front-loaded with the action and resource. Very concise 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?
For a simple parameterless tool with output schema, the description covers the essential purpose but lacks details on failure cases or conditions. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (0), so description adds value by specifying the returned information. Baseline for 0 params is 4, and the description is adequate.
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 retrieves current editor level info including world name, actor count, and actor list. It uses a specific verb and resource, though it does not explicitly differentiate from siblings like get_actors_in_level.
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, nor any prerequisites or context provided. Among many sibling getter tools, usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only list operation but does not explicitly state non-destructiveness, permissions, or any limitations. Basic transparency is present but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and effectively conveys the core purpose and return value. 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?
While the description covers the action and return fields, it omits essential parameter details and does not address potential edge cases or prerequisites. An output schema exists but the lack of parameter documentation reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'system_path' has 0% schema description coverage, and the description does not mention or explain it. Users are left guessing the format or meaning, making the parameter effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('List'), the resource ('scratch pad modules'), and the scope ('on a Niagara System'). It also specifies the return fields, distinguishing it from sibling tools like list_niagara_modules or create_niagara_scratch_pad_module.
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 prerequisites, context, or exclusion criteria, which is critical given the large set of sibling listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It fails to explain what 'open' entails (e.g., focuses editor, selects asset, any state changes), leaving the agent uninformed about side effects or read-only status.
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 examples, which is concise and to the point. However, it is overly brief for a tool with no annotations and low schema coverage, potentially sacrificing needed detail.
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 complexity (opening assets in an editor) and numerous siblings, the description lacks completeness: no indication of success/failure behavior, no clarification of asset path requirements, and no mention of the output schema that exists.
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 only parameter, asset_path, has no description in the schema (0% coverage). The description adds no additional meaning, such as expected format, valid extensions, or examples, beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Open an asset in the UE5 editor' with a clear verb ('open') and resource ('asset'), and lists examples (blueprint, material, data table, widget, etc.), which distinguishes it from sibling tools like find_assets or list_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when wanting to open an asset in the editor, but provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the basic action, omitting any behavioral traits such as whether the removal is reversible, affects other states, or requires a compile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear purpose sentence followed by parameter definitions. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, missing return values is acceptable, but the description lacks broader context such as constraints (e.g., cannot remove last transition) or required compilation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds brief semantics for each parameter (e.g., 'Content path to the StateTree asset'), providing useful context beyond names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Remove' and resource 'transition from a state', distinguishing it from sibling tools like add_statetree_transition.
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, prerequisites, or side effects. It only describes parameters, not the context of removal.
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 provides some behavioral insight (fixes up Blueprint variable tracking), but does not disclose other potential side effects, permissions, or error states. 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?
Single sentence with a parenthetical clarification. Front-loaded with verb and resource, no redundant words. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 required string params, output schema present), the description covers the key behavior but lacks details such as naming rules, uniqueness constraints, or what happens if the widget doesn't exist. Minimal but sufficient for a simple rename.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the purpose or constraints of any parameter (new_name, widget_name, widget_blueprint_path). The agent must infer meanings from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (rename) and the resource (widget), and adds specific context about fixing Blueprint variable tracking if bIsVariable. This distinguishes it from sibling rename tools for assets, data table rows, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other rename tools (e.g., rename_asset). The description implies use for widgets but does not provide alternatives or exclusion 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 provided, and the description lacks behavioral traits such as what happens if both key and action are omitted, or error handling. Minimal disclosure beyond basic operation.
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 front-loaded with purpose, but the Args section largely duplicates the schema, making it slightly redundant. Still concise with no waste.
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?
Even with an output schema, the description omits prerequisites (e.g., existence of IMC), ordering with sibling tools (add_key_mapping), and what the tool returns. Incomplete for safe invocation.
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 repeats the schema's parameter list with minimal additions (e.g., 'optional'). With 0% schema coverage, it fails to provide useful semantics like expected formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Change' and resource 'existing mapping in an IMC', clearly distinguishing from add_key_mapping and remove_key_mapping.
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 listing parameters but does not explicitly state when to use this tool over siblings like add_key_mapping or remove_key_mapping. No exclusion or 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?
No annotations exist, so the description carries the burden of behavioral disclosure. It explains the recompile parameter default and lists acceptable values for blend_mode and shading_model, but does not mention side effects, permissions, or what happens to other properties not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line purpose statement followed by parameter details. However, the parameter list is not formatted as a clear bullet list, slightly reducing readability. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and an output schema (not shown), the description should fully explain the tool's behavior. It only details 2 parameters and omits the effects of omitted properties. It also lacks guidance on how this compares to sibling material tools, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It covers blend_mode and shading_model with possible values and mentions recompile, but leaves 5 other parameters (two_sided, dithered_lof_transition, etc.) unexplained. This is insufficient for a tool with 8 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 'Bulk-set material-level properties in one call', specifying a verb (set) and resource (material properties), and distinguishes from sibling tools like set_material_instance_parameter by emphasizing bulk-setting at the material level.
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 prerequisites, when not to use it, or which sibling tools handle similar tasks (e.g., set_material_instance_parameter).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only details the parameter format but fails to mention behavioral traits such as whether the tool overwrites existing comments, requires specific permissions, or has side effects on the material graph.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose, the second explains the parameter format. No filler, front-loaded, and every sentence contributes.
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 presence of an output schema reduces the need to describe return values. However, the description omits explanation of 'material_path', and the tool's mutation behavior is not fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed structure for the 'comments' parameter (JSON array with fields), but 'material_path' is left unexplained. Overall, partial coverage adds some value but not 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 verb ('Add') and resource ('comment boxes to a material graph'), with the purpose of organization. It distinguishes from sibling tools, none of which handle comments.
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, nor any prerequisites or context. The description only explains what the tool does, not when it should be used.
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 says 'delete' but does not disclose side effects (e.g., irreversible, cascade deletes), permissions needed, or whether the blueprint must be saved. The lack of behavioral context limits an agent's understanding of consequences.
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 conveys the action and target. 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 delete tool with an output schema, the description is nearly complete. It could briefly mention that the tool permanently removes the function and may fail if dependencies exist, but overall it covers the essential purpose.
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 coverage is 0% (no property descriptions). The description does not explain the parameters: what 'function_name' refers to (e.g., exact name vs. display name, case sensitivity) or ensure clarity for 'blueprint_name'. No additional meaning is added 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 'Delete a function from a Blueprint' clearly states the specific verb 'Delete' and the distinct resource 'a function from a Blueprint'. It differentiates from sibling tools like 'delete_blueprint_node' (which deletes a node) and 'rename_blueprint_function' (rename, not delete).
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 vs alternatives (e.g., delete_blueprint_node, delete_blueprint_thing). There is no mention of prerequisites, such as requiring the function to exist or be unused, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description reveals the destructive nature (break connections), it lacks detail on side effects, such as whether the pin remains or if connections are permanently removed. With no annotations, the burden is higher, but the description adequately implies mutation.
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 target, containing no redundant information. Every word contributes to 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 mutation tool on a graph with 6 parameters, the description lacks context such as required graph state, error conditions (e.g., pin not found), or whether the node must be in a scratch pad. The presence of an output schema is noted but not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes 6 parameters, 3 required, but the description provides no explanation of their roles or how to specify them. Given 0% schema description coverage, the description does not help the agent understand which parameters are needed or how they constrain the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Break all connections on a specific pin of a node in a scratch pad graph' clearly states the action (break connections), target (pin of a node), and scope (scratch pad graph). It distinguishes from sibling like 'connect_niagara_pins' by explicitly focusing on disconnection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when disconnecting pins is appropriate, prerequisites (e.g., graph must be in scratch pad), or contrast with similar tools like 'disconnect_material_expression' or 'connect_niagara_pins'.
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 disclose all behavioral traits. It only states the core action, omitting details like side effects (e.g., whether the original row is modified), required permissions, or data limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous text. Front-loaded with the key 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?
Output schema exists but is not used to describe return values. Given the tool's simplicity and many sibling tools, the description is adequate for basic understanding but lacks usage and behavioral context that would aid correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should compensate. It references 'existing row' and 'new name' corresponding to source_row_name and new_row_name, but adds little beyond the parameter names themselves. Does not clarify data_table_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?
Description clearly states 'Copy an existing row under a new name', specifying verb, resource, and result. It distinguishes from related siblings like add_data_table_row (add new) and rename_data_table_row (rename existing).
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 (e.g., add_data_table_row, rename). Does not mention prerequisites, such as requiring the source row to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states 'Duplicate' with no disclosure of side effects, permissions, or whether the operation is safe. 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?
Two sentences: one purpose, one argument list. No wasted words, front-loaded with clear verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters and declares output schema exists. Lacks details on prerequisites, failure cases, and return value meaning. Adequate for a simple duplication but could be 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 0%, but description lists three parameters with brief explanations (system path, source name, optional new name with default). Provides basic semantics but no format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Duplicate an existing scratch pad module on a system' with verb, resource, and scope. It is distinct from sibling tools like rename, create, delete.
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 (e.g., create, rename, duplicate_niagara_emitter). Agent must infer from 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. It mentions a special case (empty name returns all variables) but does not clarify what 'detailed info' includes, any prerequisites (e.g., blueprint must be compiled), side effects, or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 a key behavior. While efficient, it could be slightly expanded 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?
The tool has an output schema (not shown), so return values need not be described. However, given the complexity and many sibling tools, the description lacks prerequisites, error handling, and differentiation from similar tools like get_blueprint_class_defaults. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context for variable_name (empty returns all) but provides no explanation for blueprint_path or any constraints. Incomplete parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed info') and the resource ('Blueprint variables'), and includes a specific behavior note ('empty name = all variables'). It effectively distinguishes from sibling tools like create_blueprint_variable or set_blueprint_variable_properties.
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 variable details are needed, but provides no explicit guidance on when to use this tool versus alternatives like read_blueprint_content or get_blueprint_class_defaults. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is read-only and lists returned fields. However, no error behavior is mentioned (e.g., what happens if the asset_path is invalid) and no annotations are present to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second lists returned fields. No redundancy, front-loaded with key action.
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?
Missing input parameter explanation and any usage context. Output schema exists but the description still has gaps in completeness for a simple read tool.
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 does not describe the sole parameter 'asset_path' at all, despite 0% schema coverage. The agent receives no help understanding what this parameter represents or how to format it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read all properties, triggers, and modifiers of an Input Action', specifying the verb 'Read' and the resource 'Input Action'. Also lists specific return fields, distinguishing it from sibling tools that create or modify input 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?
No explicit when-to-use or when-not-to-use guidance. Though the read nature is implied, the description does not directly advise when to use this tool over siblings like create_input_action or set_input_action_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes a read-only listing operation and details the returned data. However, it does not mention any behavioral traits like editor state prerequisites or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that cover purpose and output without any redundancy or 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?
Despite having an output schema, the description omits input parameter explanations. For a tool with two optional parameters, the lack of parameter documentation makes it incomplete for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'filter' or 'include_abstract' parameters. Users cannot know how to use these parameters effectively without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: list all UDataAsset subclasses. It specifies the exact return fields (name, class path, parent class, UPrimaryDataAsset flag, editable properties). This distinguishes it from sibling tools like list_data_assets (which lists instances) and search_parent_classes (which searches class hierarchies).
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 or provide usage context. It implies that it lists class definitions, contrasting with list_data_assets for instances, but offers no direct guidance on filter or include_abstract parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'list' without disclosing that the operation is read-only, has no side effects, or any performance considerations. This lack of behavioral context 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 concise sentences: first states the action and resource, second lists return fields. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits crucial details about parameter behavior (e.g., path defaults, filter syntax, recursive scope, max_results limit). For a tool with 0% schema description coverage, this leaves agents unprepared to use parameters 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?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'optionally filtered' but does not describe the four parameters (path, filter, recursive, max_results), their defaults, or usage. The description adds almost no value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists UInputMappingContext assets with optional filtering, and its name distinguishes it from siblings like list_input_actions (which lists actions) and get_input_mapping_context (which retrieves a single context). The verb 'List' and resource 'UInputMappingContext assets' are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies listing input mapping contexts but does not explicitly compare it to other list tools (e.g., list_assets, find_assets) or provide when-to-use vs alternatives. 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 must disclose behavioral traits. It describes the tool as listing modules, implying a read operation, but does not explicitly state that it is read-only, safe, or has no side effects. It also lacks information about authentication, rate limits, or any potential impacts, leaving the agent with incomplete understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences plus a parameter list. The first sentence clearly states the purpose. There is no unnecessary repetition or fluff. However, the parameter list could be slightly more structured (e.g., bullet points) for even faster scanning.
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 three optional parameters, the description covers the main functionality and parameter semantics. However, it does not mention the output format (even though an output schema exists, the agent would benefit from a high-level summary), nor does it address potential pagination or default ordering. This leaves some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself has no parameter descriptions. The description adds significant value by detailing the 'category' options (listing all valid values), explaining 'search' as an optional substring search, and clarifying 'max_results' as a limit on results. This exceeds the baseline and compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies the resource as 'available Niagara module scripts', clearly indicating the tool's purpose. It also notes the tool is intended 'for use with add_niagara_module', providing context. However, it does not differentiate from sibling tools like 'get_niagara_modules' or 'list_niagara_ops', so clarity is good but not excellent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to obtain modules for 'add_niagara_module', but it does not explicitly state when to use this tool versus alternatives such as 'get_niagara_modules' (which may list modules for a specific system) or 'list_niagara_ops'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden. It correctly identifies the tool as a read operation but does not disclose potential side effects, permissions, or how the data is returned. The statement is straightforward but lacks depth for a comprehensive understanding.
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 core purpose. However, it could be slightly expanded without being verbose, especially regarding parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description is minimal. While the output schema may document return values, the description does not address the scope of 'complete content' or the effect of optional includes.
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 has 6 parameters with 0% description coverage. The description fails to explain the boolean parameters (include_functions, etc.) or how they affect the output. It only lists item types, which does not compensate for missing 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 clearly states the tool reads complete Blueprint content, listing specific components (event graph, functions, variables, components). The verb 'Read' and resource 'Blueprint content' are precise, distinguishing it from sibling tools that create or modify blueprints.
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 when not to use it, such as for partial reads or modifications, nor does it reference sibling tools like 'get_blueprint_class_defaults' or 'get_asset_info'.
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. It does not disclose side effects (e.g., if removal is permanent, if saving is required) or any behavioral nuances beyond 'remove'.
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?
Extremely concise: two sentences plus a brief parameter list. No wasted words; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description suffices for basic understanding but lacks broader context (e.g., what happens if the emitter doesn't exist, if the system is saved automatically). The output schema exists, so return values are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds minimal descriptions for each parameter ('Path to the Niagara System asset', 'Name of the emitter to remove'), providing basic context beyond type-only 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 ('Remove an emitter') and the resource ('Niagara System'), distinguishing it from siblings like add_niagara_emitter or duplicate_niagara_emitter.
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, prerequisites, or alternatives. The description simply states the action without context like 'Use when you need to delete an emitter' or 'Do not use if...'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'Remove' without explaining side effects, reversibility, error handling (e.g., what if parameter doesn't exist), or whether it requires specific system 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 extremely concise with no wasted words. It uses a clear Args section structure, 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?
For a simple removal tool with no annotations and an output schema (not shown), the description covers the basic functionality but omits success/failure behavior, return value explanation, and error conditions. 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?
Schema coverage is 0% so the description must add meaning. It provides brief descriptions for both parameters (path and name) but lacks details like format, allowed characters, or case sensitivity. Adds some value but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a user parameter from a Niagara System'), which distinguishes it from sibling tools like add, set, and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when the parameter exists, or when removal is safe vs. using set to clear). No prerequisites or conditions are 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?
No annotations exist, so the description must carry the full burden. It discloses that renaming is 'in-place' and preserves row order, but does not mention side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, containing only one sentence. While efficient, it omits important details, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters and an output schema (not shown), the description is minimal. It provides the core purpose but lacks completeness for smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it does not explain the three parameters (data_table_path, old_row_name, new_row_name). No details on path format, naming rules, or casing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a row in-place (preserves row order).' clearly identifies the verb (rename), resource (row), and key behavioral traits. It distinguishes this tool from siblings like update_data_table_row or delete_data_table_row.
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 like update_data_table_row or duplicate_data_table_row. There is no mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses automatic rewriting of braced references for Custom HLSL nodes, which is a useful behavioral detail. However, it does not mention side effects, requirements (e.g., pin must be dynamic), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and the second sentence adds a key behavioral detail. No superfluous wording.
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 7 parameters, 0% schema coverage, and no annotations, the description is severely incomplete. It does not help the agent understand how to specify the target pin or node, nor does it describe return values or error conditions. The output schema may mitigate, but the description itself lacks crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides no explanation of any of the 7 parameters. It does not clarify node_id, node_class, node_index, module_name, system_path, or how old_name/new_name relate to the pin naming system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Rename' and the resource 'dynamic pin on any node in a scratch pad graph'. It distinguishes from siblings like rename_niagara_scratch_pad_module and rename_niagara_custom_hlsl_pin by specifying the scope (any node's dynamic pin).
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 renaming dynamic pins but lacks explicit guidance on when to use this tool versus alternatives (e.g., rename_niagara_custom_hlsl_pin). No 'when not to use' 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 provided, and the description does not disclose behavioral traits such as whether the operation is destructive, requires specific permissions, or has side effects. It simply says 'Set', which implies modification but lacks detail on impact or reversibility.
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 front-loaded with the purpose and then lists parameters in a docstring format. While informative, the 'Args' section is somewhat redundant with the input schema and could be more concise. The description has 5 lines of parameter details, which are mostly repetitions of schema names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 3 required) and no output schema details in the context, the description covers the basic purpose and parameter meanings. However, it lacks usage guidance and behavioral transparency, making it less complete for an agent without external knowledge.
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?
Despite 0% schema coverage, the description includes an 'Args' section that explains each parameter's purpose (e.g., 'asset_path: Content path to the StateTree asset', 'property_name: Property to set'). This adds meaning beyond the schema's name and type alone. However, the three state identifiers (state, state_name, state_guid) could be clarified further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Set a property on a state' and lists example property names (Name, Type, SelectionBehavior, etc.), distinguishing it from sibling tools like get_statetree_state or set_statetree_node_property. The verb 'Set' and resource 'state property' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (e.g., set_statetree_node_property for node-level properties). No exclusions or prerequisites mentioned. The description implies use when modifying a state property, but lacks explicit 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 description is the sole source. It only states the action without disclosing behavioral details like whether the Content Browser must be open, what happens if the asset is not found, or if it selects the asset. Very limited transparency beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no extraneous words. Every word earns its place. Optimal size for the described action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and a presumably simple action, the description is minimally viable. However, it lacks details like whether it works on all asset types, handling of subfolders, or any side effects. The presence of an output schema might compensate but is not available. Could be more complete for a navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter, but the description implies 'asset_path' is the path to the asset, adding meaning beyond the schema's bare type declaration. However, it does not specify path format (e.g., full path or relative) or validation rules. Adequate but minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Navigate' and 'show' with a clear resource 'Content Browser' and 'specific asset'. It effectively distinguishes from siblings like 'open_asset' (which likely opens for editing) and 'find_assets' (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not specify scenarios where navigating to show is preferred over opening or finding assets. Missing explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly explains the three output arrays and their definitions, which adds value. However, it does not disclose whether the tool modifies the graph, requires specific permissions, or has performance implications. For a read-only analysis tool, this is acceptable but not excellent.
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 four sentences, well-structured and front-loaded with the core purpose. It uses bullet-like formatting for the three output categories, making it easy to parse. No unnecessary words.
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 an output schema (not shown) but the input parameters are completely undocumented in the description. Given that there are three parameters with no schema descriptions, the description fails to provide adequate context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the three parameters (module_name, script_path, system_path). While these appear to be different identifiers for the graph, the description offers no guidance on their meaning or how to choose among them, leaving the agent without essential usage 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 classifies three specific node types (orphaned, dead-end, missing-inputs) in a Niagara graph. It uses specific verbs and resource names, and distinguishes itself from sibling tools like 'trace_niagara_connection' or 'get_niagara_graph_nodes' by focusing on validation of connection issues.
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 finding problematic nodes but does not explicitly state when to use this tool versus alternatives (e.g., trace_niagara_connection for specific connections). No direct comparison to sibling tools or indications of prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action (adding a component) and lists parameters, but does not disclose side effects, permissions, or what happens if the actor doesn't exist. The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear purpose sentence, then listing parameters in a bullet-style format. It is front-loaded and avoids unnecessary verbosity. However, the parameter list could be integrated into a more streamlined paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and parameters but lacks context about the environment (e.g., actor must exist, system path validity, saving requirements). An output schema exists but is not shown; the description does not mention return values, which is acceptable since an output schema is present. Overall, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by providing clear, human-readable explanations for each parameter (e.g., 'actor_name: Name/label of the target actor'). It adds semantic meaning beyond the schema's type and required flags, though it could specify formats or constraints like path type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a NiagaraComponent to an existing actor in the level.' It specifies the verb, resource, and target, which distinguishes it from sibling tools like add_niagara_emitter or add_niagara_module.
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 lacks any mention of prerequisites, conditions, or exclusions. It only describes the parameters without contextual usage 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?
With no annotations, the description fails to disclose behavioral details such as whether the binding can be overwritten, compatibility checks, reversibility, or side effects. It only states the action without depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parameter list, which is concise and front-loaded. While efficient, the parameter descriptions could be more structured (e.g., tabular format) for clarity.
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 5 required parameters and an output schema, but the description does not explain the return value or success/failure behavior. For a mutation tool, this omission makes it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for all 5 parameters with examples (e.g., 'Property path on source (e.g. "TargetLocation")'). This is valuable context beyond the schema's empty descriptions, though more detail on 'asset_path' would improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 property binding') and the resource ('connecting a source node's output to a target node's input'). It distinguishes itself from sibling tools like add_statetree_state or add_statetree_task by specifying the connection between nodes.
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, prerequisites, or conditions. The sibling tools include many similar operations, but 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?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, permissions required, or whether the operation is destructive. The description only states the basic action 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence and a parameter list. It is front-loaded with the purpose. The parameter list is structured clearly, but some redundancy exists with the schema. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic operation and parameter meanings, but given the lack of annotations and the complexity of the tool (mutation, 4 parameters), it could provide more context about the role of global evaluators, typical usage, and whether the operation saves automatically. An output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds valuable meaning to parameters, e.g., explaining 'evaluator_class' as an Evaluator struct name with an example, and clarifying that 'properties' and 'instance_properties' are JSON objects for node and instance data. This goes beyond the raw schema, though the JSON object formats could be further detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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') and the resource ('a global evaluator to the StateTree'), distinguishing it from sibling tools like add_statetree_task or add_statetree_condition.
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 context for adding an evaluator. The description lists parameters but does not help the agent decide when to invoke this tool.
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 behavior. It says 'Create' but doesn't mention if overwriting occurs on existing path, what the output is, or any side effects. Template semantics are vague ('empty' vs path).
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?
Concise with a clear purpose sentence followed by parameter descriptions in Args format. No extraneous text. 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?
Output schema exists, so return value documentation not required. However, given many sibling Niagara creation tools, the description lacks context for tool selection. Also, no mention of typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates well. asset_path explanation with example format adds meaning. template description clarifies options ('empty' or path). However, no further details on allowed templates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Niagara System asset.' with a specific verb and resource. It distinguishes from siblings like delete_niagara_system and list_niagara_systems. The example path 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs other creation tools (e.g., create_niagara_module_asset). No prerequisites or conditions mentioned. Template parameter described but no usage scenarios.
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?
Description implies a read-only operation, but with no annotations provided, it lacks details like error handling (e.g., blueprint not found) or whether any side effects occur. Adequate for a simple getter 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?
A single, concise sentence that is front-loaded with the action and resource. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and existence of an output schema, the description is minimally adequate. However, it could mention what the returned info includes (e.g., slot names, materials) to improve completeness.
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?
Only parameter 'blueprint_name' is mentioned but not elaborated. Schema coverage is 0%, so description should add meaning like format or valid values, but it does not. The parameter's purpose is inferred from the tool name, but explicit guidance is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves material slot info for Blueprint mesh components. The verb 'get' and resource 'blueprint_material_info' are specific, and it distinguishes from sibling tools like get_material_info (general) and get_actor_material_info (actor-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites, such as whether the blueprint must be loaded, or when to use other material-related 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. It discloses the read-only nature and scope (ALL, no filter) but omits details on error handling, performance implications, or prerequisites. Basic transparency is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence and an args list. It avoids redundancy and presents the core purpose first. However, a title could improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, output schema exists) and many siblings, the description covers the basic functionality but lacks error context and differentiation from sibling tools. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists and explains two optional parameters (filter, include_inherited) but fails to describe the required asset_path parameter. Since schema description coverage is 0%, the description partially compensates but leaves a critical gap for the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Read' and the resource 'data asset', specifying it reads ALL property values with no visibility filter. This effectively distinguishes it from similar sibling tools like get_asset_properties which likely operate on regular assets.
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 guidelines provided. The description does not indicate when to use this tool versus alternatives, nor does it mention preconditions or exclusions. Agent receives no guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the burden. It discloses the return data (pins and nodes) but does not mention any behavioral traits like read-only nature, permissions required, or error conditions. It provides basic transparency but misses important 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 two sentences, front-loaded with the purpose, and every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool deals with material functions, the description covers the main return types. However, it lacks details about parameter semantics, prerequisites (e.g., function existence), and error handling. An output schema exists, so return value documentation is not solely the description's responsibility, but parameter guidance is missing.
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 single parameter 'function_path' has 0% schema description coverage, and the tool description does not elaborate on its meaning, expected format, or constraints. This is a critical gap since the description should compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 verb 'Inspect' and the resource 'Material Function', and lists the exact returned components (inputs, outputs, internal nodes), distinguishing it from sibling tools like get_material_info which operates on materials.
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 get_material_graph_nodes or get_material_expression_info. The context implies it's for inspecting the overall function structure, but no exclusions or prerequisites are 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 full burden. It states the tool 'lists slots that have something connected,' implying it is a read-only query. However, it does not clarify whether it modifies anything, requires specific permissions, or how it handles disconnected slots beyond not listing them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the main action and clarifying a key constraint. Every word adds value; no filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is clear in scope but lacks details such as what constitutes an 'expression node' or 'output slot' in the context of Unreal materials. Given the availability of an output schema, the return structure is covered, but the description alone is minimally adequate for understanding the tool's function within the larger material graph toolset.
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 provides no explanation for the 'material_path' parameter, such as its expected format or how it is used (e.g., asset path, object reference). With 0% schema description coverage, the description fails to add any semantic value beyond the schema's minimal 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 uses the verb 'Query' and specifies it lists which expression node feeds each material output slot. It clearly distinguishes from sibling tools like 'trace_material_connection' by focusing specifically on output slot connections and noting it only returns connected slots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for inspecting material connections but provides no explicit guidance on when to use this tool over alternatives (e.g., trace_material_connection, get_available_material_pins) or prerequisites like whether the material must be 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?
The description does not disclose any behavioral traits beyond the action itself. It does not mention irreversibility, side effects, permissions, or return values. No annotations are provided to supplement this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Every sentence is necessary. However, it could be better structured (e.g., bullet points for args) but remains 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?
For a simple removal tool with three parameters, the description covers the basics. However, it lacks mention of return values (though an output schema exists), behavior on invalid indices, or how to obtain trigger indices. Could be more complete given no 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 Args block provides clear explanations for all three parameters, compensating for the 0% schema description coverage. Each parameter's purpose is concisely explained, e.g., 'Path to the IMC asset' for context_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 clearly states it removes a trigger from a mapping in an Input Mapping Context. The verb 'remove' and resource 'trigger' are specific, and it distinguishes from sibling tools like add_mapping_trigger or remove_mapping_modifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remove_mapping_modifier or add_mapping_trigger. The description does not mention prerequisites, context, or conditions for appropriate 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?
No annotations are provided, so the description carries full burden. It states it removes a renderer, implying a destructive action, but does not disclose side effects, permanence, return values (even though an output schema exists), or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no extraneous text. It uses a clear docstring format, front-loading the main purpose, and each sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with 3 parameters and an existing output schema, the description covers the essential inputs and action. It lacks mention of the return value, but the output schema exists. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains renderer_index in detail ('Index of the renderer to remove (from get_niagara_emitters)'). For system_path and emitter_name, it just repeats the parameter names, adding minimal 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 ('Remove a renderer from an emitter by index') and specifies the resource. It differentiates from sibling tools like add_niagara_renderer, get_niagara_renderer_info, etc., by focusing on removal.
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 or exclusions. It does not mention that the emitter must exist or that the renderer index must be valid.
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 'remove'. It does not disclose behavioral aspects such as prerequisites (asset must exist, node must exist), side effects, or reversibility. The agent lacks information about the destructive nature beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and structured parameter explanations. It is front-loaded and free of extraneous information, though it could benefit from slightly more structured formatting.
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 removal tool with two parameters, the description provides essential purpose and parameter definitions. However, it lacks context about return values (output schema exists but not described) and potential error conditions. This is sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning to both parameters: asset_path is 'Content path to the StateTree asset' and node_guid is 'GUID of the node to remove'. This effectively clarifies their roles beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and specifies the resource types: 'task, evaluator, or condition by GUID'. This distinguishes it from sibling tools like remove_statetree_state which remove different node 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?
The description does not provide guidance on when to use this tool versus alternatives. It lists what it removes, but does not explicitly state that other removal tools exist for different node types (states, transitions, etc.).
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 behavioral trait of rewriting braced references in HLSL source after rename. However, with no annotations, it lacks details on error handling, undo, or effects on connections beyond reference updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the main action and provide a specific technical detail about reference rewriting. No extraneous 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?
Given an output schema exists (but not shown) and no annotations, the description covers the core purpose but lacks parameter definitions and usage context. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not individually explain system_path, module_name, old_name, or new_name. While old_name and new_name are implied by the action, the other two parameters are left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Rename a Custom HLSL pin' and the specific resource. It includes the unique detail of updating braced references in HLSL source via whole-word replacement, distinguishing it from sibling rename 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 rename_niagara_node_pin or rename_niagara_scratch_pad_module. There is no mention of prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It warns that existing nodes may become invalid, which is a key behavioral note. However, it omits other crucial traits such as whether changes are reversible, permission requirements, or impact on compiled state trees. The warning is valuable 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?
Extremely concise: two sentences plus param descriptions. The warning is front-loaded, and every word serves a purpose. No 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 complexity of modifying a state tree schema, the description is adequate but could provide more context, such as possible schema_class values or effects on bindings/transitions. The presence of an output schema doesn't fully compensate for missing explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds needed context. It defines 'asset_path' as 'Content path to the StateTree asset' and 'schema_class' with an example ('MassStateTreeSchema'). This clarifies the parameters beyond the raw schema types.
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 'Change the schema of a StateTree' with a specific verb and resource. It warns about potential invalidation. While not highly elaborate, it effectively conveys the core function and distinguishes from siblings (e.g., set_statetree_state_property).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when not to use, or comparison to other state tree tools. The warning about invalidation implies care but does not constitute 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?
No annotations are provided, so the description must carry the full burden. It states the action but does not disclose side effects (e.g., asset modification requiring save), permissions, or failure modes. The description 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 concise: one sentence plus a clear list of parameters. Every sentence is informative, and the structure front-loads the 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 add operation with 3 parameters and no annotations, the description is adequate but lacks details about constraints (e.g., what happens if component already exists, if blueprint must be unmodified). The presence of an output schema slightly reduces the need, but more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds meaningful context for each parameter: blueprint_path with example path, component_class with example values, and component_name as optional. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'component to a Blueprint's default components'. It is specific and distinct from sibling tools like 'add_blueprint_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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'add_blueprint_node' for graph nodes). The description does not mention prerequisites or context for 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?
No annotations are provided, so the description carries full burden. It explains parameters but does not disclose side effects, whether changes are destructive, save behavior, or reversibility.
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 structured with an Args section and is efficient. The list of modifier types is slightly verbose but necessary for 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?
Given no annotations and no output schema details in the description, the description lacks behavioral context and return value information. It is incomplete for safe and 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?
Schema coverage is 0%, so description adds significant value. It clarifies asset_path as path, modifier_type with a list of valid classes, and properties with an example format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Add a modifier to an Input Action' with a clear verb and resource. It distinguishes from siblings like remove_input_action_modifier and add_input_action_trigger by specifying the action on modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implicitly suggests use for adding modifiers but does not mention alternatives 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 full burden. It describes the action and parameters but lacks behavioral details such as side effects (e.g., asset modification) or required permissions. The agent is left to infer that this modifies the emitter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence followed by parameter list. It is concise and front-loaded, though the parameter descriptions could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameters comprehensively and the presence of an output schema (not shown) reduces the need to explain return values. However, it could mention what happens after addition (e.g., if the asset is auto-saved) for fuller context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description includes a detailed Args section with examples for module_path and valid enum values for script_usage. This adds significant meaning beyond the bare schema, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a module to an emitter's script usage stack.' It uses a specific verb ('Add') and resource ('module') with context, and distinguishes from sibling tools like remove_niagara_module and reorder_niagara_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description focuses on parameters but does not mention when-not-to-use or provide context about prerequisites or preferences.
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 available, so the description carries the full burden. It explains that stages add processing passes and notes the 'per frame' execution for num_iterations. However, it does not disclose side effects (e.g., permanent modification) or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and uses a clean bullet format for parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no annotations, output schema exists), the description covers purpose and parameters adequately. It does not mention prerequisites like system/emitter existence, but the required params imply them. Overall sufficient 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?
Schema coverage is 0%, but the description provides clear explanations for all 5 parameters, including iteration_source options and default for num_iterations. This adds significant meaning beyond the raw 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 clearly states 'Add a simulation stage to an emitter' and explains what simulation stages do. While it is specific and distinguishes from many sibling Niagara tools, it does not highlight unique differentiating features versus other emitter-modifying 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, nor are there prerequisites or exclusions. The agent must infer usage from the tool's basic function without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosing side effects and preconditions. It does not mention if the asset is auto-saved, if existing assets are overwritten, or if permissions are required. The only behavioral hint is the requirement for a full content path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the action. Every sentence serves a purpose: stating the action and detailing the parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple creation tool with only two parameters and an output schema (not detailed). However, given the rich ecosystem of input-related sibling tools, it could mention that the context is created in the content browser or that duplicates are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by clarifying asset_path as a full content path with an example, and describing description as an optional localized string. The schema parameters are plain strings, so this contextual information is helpful, even though schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new UInputMappingContext asset, with a specific verb ('Create') and resource ('UInputMappingContext asset'). It distinguishes from siblings like 'add_key_mapping' or 'get_input_mapping_context' which operate on existing contexts.
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 indicate prerequisites, when to create vs. use existing contexts, or how this fits into the input system workflow.
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 is the sole source. It mentions 'asset + edit-copy' but doesn't clarify if deletion affects both or selects one, nor does it explain side effects (permanence, undo, prerequisite graph state). Minimal disclosure of behavioral traits for a 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?
Two efficient sentences: first states purpose, second gives parameter guidance. No redundancy, front-loaded, every word adds value.
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 many sibling tools (e.g., add_niagara_graph_node, get_niagara_graph_nodes), the description provides no context about when to use this tool vs. other node manipulation tools, or about prerequisites (e.g., graph must be open, asset saved). The existence of an output schema is irrelevant as description doesn't mention it. Incomplete for reliable agent 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 has 5 parameters with 0% description coverage. Description only covers node_index and node_id, ignoring module_name, script_path, and system_path. These are likely needed to specify the graph context, but the agent is left guessing how to set them. Insufficient compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (delete) and resource (node from Niagara graph), specifies it works on asset and edit-copy graphs, and distinguishes from sibling tools like add_niagara_graph_node. Provides identification methods (node_index or node_id from get_niagara_graph_nodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to provide either node_index or node_id, referencing get_niagara_graph_nodes for node_id. This gives clear usage context. Lacks explicit when-not-to-use or alternatives (e.g., remove_niagara_emitter, delete_asset), but still adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions deep-copying children and auto-renaming on conflicts, which are key behaviors beyond the tool name. However, with no annotations, it does not disclose other important details like whether the operation is destructive, required permissions, or what happens to the original widget. The presence of an output schema (not shown) might mitigate some gaps, but the description itself is 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?
Extremely concise at two sentences, with no fluff. The main action is front-loaded, and every word adds value. Ideal structure for quick comprehension.
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 4 parameters, no annotations, and an output schema (not shown), but the description omits critical details such as parameter explanations, prerequisites (e.g., widget must exist), and return value semantics. For a duplication tool with moderate complexity, this is insufficient for an agent to use correctly without additional 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?
Schema description coverage is 0% (none of the 4 parameters have descriptions in the schema). The tool description does not explain any parameters (new_name, widget_name, parent_widget_name, widget_blueprint_path), leaving their meaning and usage unclear. Given the low coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (deep-copy/duplicate), the resource (widget), and includes a key distinguishing feature (including children and auto-renaming). It differentiates from sibling tools like duplicate_asset which duplicates assets, and other widget tools that add/remove widgets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for duplicating widgets but does not explicitly guide when to use it over alternatives such as duplicate_asset or other widget manipulation tools. No explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to convey behavior. It implies a read operation with 'Get' but does not explicitly state non-destructive behavior or error conditions. The description adds some transparency by detailing return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose, a sentence for return fields, and a bullet-style list for parameters. No extraneous text, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and parameter details. However, it lacks mention of edge cases (e.g., missing emitter) or output schema specifics, though an output schema exists. Mostly complete for a read 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?
With 0% schema coverage, the description fully compensates by explaining each parameter, including examples for filter and valid values for script_usage. This adds significant meaning beyond the bare 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 clearly states it retrieves modules from an emitter's script usage stack and lists the returned fields. It distinguishes itself from sibling tools like list_niagara_modules (which likely lists all module assets) by focusing on the attached modules in a specific emitter context, though this differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for choosing it over other Niagara module 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?
Without annotations, the description does not disclose behavioral traits such as permanence, side effects, required permissions, or whether the asset is automatically saved. It only states the basic removal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-line purpose followed by parameter details. No unnecessary words; front-loaded with the 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 description covers basic purpose and parameters but lacks context on how to obtain the binding index, whether removal is immediately saved, or the return value. Given that output schema exists, it is minimally adequate but incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: 'asset_path: Content path to the StateTree asset' and 'binding_index: Index of the binding to remove'. This adds meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a property binding by index,' specifying the action ('remove'), the resource ('property binding'), and the method ('by index'). This distinguishes it from sibling tools like add_statetree_binding and get_statetree_bindings.
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 context on how to obtain the binding_index (e.g., from get_statetree_bindings). It merely states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Only states the basic action; no information on side effects, permissions, error handling, or success/failure conditions.
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 with no wasted words. Action and scope are front-loaded and clear.
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 parameterless tool with an output schema, the description covers the core action. However, lacking annotations, it would benefit from mentioning what happens when no dirty assets exist or if saving fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Description adds no parameter detail, but none is needed. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'save' and resource 'all unsaved (dirty) assets', clearly distinguishing from sibling 'save_asset' which saves a single 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 explicit guidance on when to use this tool versus alternatives like 'save_asset'. The description implies bulk operation but lacks 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, the description carries full burden for behavioral disclosure. It does not mention side effects, error conditions, return value, or prerequisites (e.g., system must be loaded). The presence of an output schema is not referenced.
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 and well-structured. The purpose is stated first, followed by a bullet-style parameter list. No unnecessary words, each sentence 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 complexity of Niagara renderers and the existence of an output schema, the description is adequate but lacks information on return values, error handling, and usage context. Parameter semantics are good, but overall completeness could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates with a clear parameter list including examples for 'property'. It clarifies each parameter's purpose, adding value beyond the schema's type 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 sets a property on an emitter's renderer, using a specific verb-resource pairing. It distinguishes from siblings like 'set_niagara_renderer_binding' or 'get_niagara_renderer_properties' by focusing on setting individual 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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'set_niagara_renderer_binding' or 'set_niagara_emitter_property'. It assumes the agent knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses what issues are reported (unconnected_outputs, unused_inputs, orphaned) and the return format (healthy flag). It does not explicitly state that the tool is read-only, but the diagnostic nature implies no side effects. The description is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, well-structured, and front-loaded with the main action. Bullet points list the reported issues clearly. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and presence of an output schema, the description adequately covers the diagnostic purpose and outcomes. It mentions the healthy flag and issue categories. However, it could be more complete by describing error cases or output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the 'function_path' parameter. It does not clarify the format or validity of the path. Since schema coverage is low, the description must compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Diagnose issues in a Material Function's internal graph.' It specifies the action (diagnose), the resource (Material Function's internal graph), and lists specific issues it detects. This distinguishes it from sibling tools like 'validate_material_graph'.
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 prerequisites or exclusions. While the context of siblings suggests it is for material functions, no comparative advice 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, the description must carry behavioral transparency. It lists valid trigger types (e.g., InputTriggerDown) and optional properties with an example, giving some insight into behavior. However, it fails to disclose side effects (e.g., overwriting existing triggers), error conditions, or what the tool does beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for the action followed by clear, well-structured argument documentation. Every sentence adds value, and the parameter list is organized and front-loaded. 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 moderate complexity and the presence of an output schema (not shown but indicated), the description covers parameter inputs adequately. However, it lacks usage guidance, behavioral details, and does not explain what the tool returns. The coverage is minimal but functional for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates excellently. It enumerates all valid trigger_type values (including obscure ones like InputTriggerChordAction), explains the properties parameter with an example, and provides context for asset_path (though no description, its purpose is clear from the context). This far exceeds the bare schema definitions.
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 explicitly states 'Add a trigger to an Input Action,' clearly identifying the verb (add) and resource (trigger to an Input Action). However, it does not distinguish this from the sibling tool 'add_mapping_trigger,' which also adds triggers but on mapping contexts. Without differentiation, an AI agent might not know which to choose.
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 'add_mapping_trigger' or 'add_input_action_modifier.' The description lacks any context about prerequisites, preferred scenarios, or what makes this tool appropriate, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects (e.g., overwriting existing mapping), error conditions, or prerequisites. Minimal behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose sentence; Args list is structured and efficient. Slightly verbose with examples but overall concise with no 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?
Covers parameter requirements and structure adequately but lacks behavioral expectations (e.g., return value, error cases). Output schema exists, so return format is covered, but completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds meaningful parameter explanations with examples for key names and structure hints for triggers/modifiers. Compensates well but could detail allowable values more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb 'Add' and resource 'key-to-action mapping to an Input Mapping Context'. Distinguishes from sibling tools like remove_key_mapping and set_key_mapping by specifying addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for adding a new mapping but does not explicitly state when to use or not use alternatives. No mention of prerequisites or comparison with sibling tools like set_key_mapping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states 'Add a modifier' without explaining side effects (e.g., whether it replaces existing modifiers, requires saving, or is idempotent). The behavioral impact is insufficiently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a single paragraph and a docstring-style parameter list. No redundant information, but the parameter list could be more compact. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema but description does not mention return value or error handling. For a mutation tool, more context on success/failure signs would improve completeness. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context for all 4 parameters: explains context_path as path to IMC asset, mapping_index as index from get_input_mapping_context, modifier_type with example, and properties as optional. Only minor vagueness on properties structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool adds a modifier to a specific mapping in an Input Mapping Context. The verb 'Add' and resource 'modifier' are specific, and it distinguishes from siblings like remove_mapping_modifier and add_mapping_trigger.
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. The description implies the context (adding to a mapping), but does not specify prerequisites, when not to use, or mention sibling tools like add_mapping_trigger.
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 describes the additive operation but does not disclose whether it is destructive, if it requires specific permissions, or the side effects (e.g., modifying the graph). The lack of behavioral context is a 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 well-structured, starting with a clear one-sentence purpose and then providing detailed context. The Args section adds necessary detail but could be slightly more concise by integrating into the main text. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and parameters adequately. However, given the complexity of the tool (4 params, 0% schema coverage, no annotations), it lacks usage guidelines and behavioral transparency. The presence of an output schema reduces the need to explain return values, but completeness is still moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter in the Args section, including examples for parameter_name and a list of types for parameter_type. It adds meaning beyond the raw 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 ('Add a typed output pin to the first ParameterMapGet node') and provides concrete context about how it mirrors the editor's '+' button and naming convention. This distinguishes it from sibling tools like add_niagara_map_set_pin or add_niagara_node_pin.
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 tool's operation and parameters, but it does not explicitly state when to use it versus alternatives (e.g., add_niagara_map_set_pin for set pins, or add_niagara_node_pin for generic pins). No when-not conditions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavioral traits: it notes that transition_index is required when target='transition' and operand combines with previous conditions. However, it lacks disclosure of side effects, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a clear one-sentence summary, then lists parameters in a structured format. Though slightly verbose due to the Args: section, it is generally well-organized 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?
Given the complexity with 10 parameters, the description adequately covers parameter usage. However, it does not address error scenarios (e.g., invalid state path) or return values, though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter's meaning, including required conditions for transition_index and the nature of properties/instance_properties as JSON objects. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a condition to a state's enter conditions or a transition's conditions, specifying the action and resource. It distinguishes from sibling tools like add_statetree_state and add_statetree_task by focusing on conditions.
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 does not provide any guidance on when to use this tool versus alternatives, such as when to add a condition versus a task. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists parameters but does not disclose behavioral traits such as side effects (e.g., auto-compilation), error conditions, or requirements (e.g., blueprint must be open). The examples for widget_class provide some context but are insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-sentence summary followed by a bullet-like list of parameters. It is concise but could be more structured (e.g., using a table). Each sentence adds value 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?
Given the complexity (7 parameters, no annotations, output schema exists), the description is partially complete. It explains most parameters but misses 'widget_blueprint_path' and does not address error scenarios. The presence of an output schema reduces the need to describe return values, but overall some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains most parameters with examples and meaning (e.g., 'parent_widget_name: Name of the parent panel', 'index: Insert position among siblings'). However, 'widget_blueprint_path' is not explained, and some parameter format details are missing, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Add a new widget to a Widget Blueprint's Designer tree.' It specifies the resource (Widget Blueprint) and the context (Designer tree), distinguishing it from sibling tools like remove_widget or move_widget.
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 prerequisites, when not to use it, or how it fits among the many sibling widget manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It mentions 'commit...edit-copy to the original script' indicating mutation, and references the mirrored function. However, it lacks details on parameter effects, return values, failure conditions, or whether it is destructive. The prerequisite is noted, but overall depth is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core action. It is concise but includes technical jargon ('FNiagaraScratchPadScriptViewModel::ApplyChanges') that may be opaque. The structure is efficient, but could be slightly more accessible.
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 the Niagara scratch pad workflow and 0% schema coverage, the description is incomplete. It does not explain what a scratch pad module is, what 'edit-copy' means, or what happens after committing (e.g., overwrite, success/failure signals). The output schema is not shown, so the return value is unclear. More context is needed for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 required parameters with no descriptions, and schema description coverage is 0%. The description does not explain what 'module_name' or 'system_path' refer to, leaving the agent to infer from names alone. This fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: committing a scratch pad module's edit-copy to the original script, with an explicit UI analogy (Apply button) and reference to the underlying function. It distinguishes from siblings like 'apply_and_save_niagara_scratch_pad' by not mentioning saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Requires the Niagara System to be open in the editor so the view model exists.' This tells the agent when the tool can be used. However, it does not explicitly state when to avoid using it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that compilation returns errors/warnings, but does not disclose whether compilation modifies the asset, requires specific permissions, or has side effects. Minimal behavioral insight beyond the operation itself.
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) and front-loaded with the core purpose. Every word contributes value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple one-parameter tool with an output schema, the description covers the essential: what it does and what input is needed. Minor gap: it does not clarify whether compilation has side effects or if errors are returned immediately, but output schema likely handles return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that asset_path is a 'Content path to the StateTree asset', which adds meaning beyond the parameter name alone. However, it does not specify format or constraints (e.g., relative vs absolute 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 clearly states the verb 'compile' and the resource 'StateTree', which distinguishes it from sibling tools that perform other operations (e.g., get, add, remove) on StateTrees. It also differs from compile tools for other asset types like compile_blueprint or compile_niagara_system.
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 prerequisites, expected state of the StateTree, or when compilation is necessary. No exclusions or context hints are 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?
No annotations are provided, so the description carries full burden. It explains parameters and special values (e.g., to_node='material'), but does not disclose side effects, permissions, error conditions, or whether connections are idempotent.
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 structured as a docstring with a clear introductory sentence and an 'Args' section. It is concise and informative, though the missing material_path description slightly diminishes its 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 description covers most parameters but omits the required 'material_path'. With an output schema existing, return values need not be explained, but the description lacks behavioral context and does not fully compensate for absent annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to from_node, to_node, to_pin, and from_pin by explaining their roles and possible values, which is valuable given 0% schema description coverage. However, it fails to describe the required 'material_path' parameter, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Connect two expression nodes using their indices.' It specifies the action (connect) and resource (expression nodes), and distinguishes from sibling tools like disconnect_material_expression and connect_blueprint_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites, exclusions, or context for when this tool is 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?
No annotations provided, so description carries full burden. It explains parameters but omits critical behaviors: overwrite behavior if asset exists, required permissions, error handling, or side effects. A creation tool needs to disclose these.
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?
Well-structured with parameter breakdown and example, but slightly verbose. Every sentence adds value, though the examples could be shortened. No wasted words, but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, description fails to explain return value or behavior when asset exists. For a creation tool, this is a gap. Also lacks context on idempotency or validation, making it incomplete for complex usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds comprehensive definitions: explains class_name format (short/full path), asset_path requirement, and initial_properties capabilities (primitives, structs, arrays, etc.). This significantly enhances schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new data asset of any UDataAsset subclass', specifying verb (create), resource (data asset), and scope (any subclass). This distinguishes it from sibling tools like create_blueprint or create_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives (e.g., add_data_table_row or create_blueprint). The description implies usage via parameter explanations but lacks when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose all behavioral traits. It mentions that the `unreal` module is pre-imported and how to return data (set `result`), but it does not describe error handling, side effects, execution environment constraints, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the main purpose in the first sentence and behavioral notes in the second. Every sentence contributes value, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a Python executor with an output schema (per context signals), the description provides sufficient information for core usage. It lacks details on environment persistence or timeouts, but for a simple execution tool it is largely 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?
Although the schema has 0% description coverage for the `code` parameter, the description adds crucial context: it explains how to use the parameter to return structured data (set `result` variable) and that `unreal` module is available. This significantly enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute arbitrary Python code inside the running Unreal Editor.' This is a specific verb (execute) and resource (Python code in Unreal Editor), and it distinguishes itself from sibling tools which are all targeted operations (e.g., save, get assets).
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 vs. alternatives (e.g., for automation vs. direct manipulation via other tools). It does not mention prerequisites, when not to use it, or how it compares to sibling tools that achieve similar effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is read-only ('Read') and discloses that the return type is polymorphic based on the parent widget. However, it omits details about required permissions, error cases (e.g., widget without a slot), or side effects. No annotations exist, so the description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the action and key nuance about type dependency. It wastes no words and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has an output schema (not shown), the description provides enough context for basic understanding of slot property retrieval. However, it lacks details on parameter semantics and fails to address potential complexities like handling different parent types or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (filter, widget_name, widget_blueprint_path) with 0% description coverage. The description does not explain any parameter, leaving the agent to infer their purpose. 'filter' is especially ambiguous without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads layout slot properties and specifies that the slot type depends on the parent widget (e.g., CanvasPanelSlot, HorizontalBoxSlot). This distinguishes it from sibling tools like 'get_widget_properties' which read widget-level properties.
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 retrieving slot-specific layout properties but does not explicitly state when to use this tool versus alternatives like 'get_widget_properties' or 'set_slot_properties'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states it's a read ('get') but does not mention permissions, error conditions (e.g., invalid asset_path), or whether the operation is safe. The description is minimally 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 concise (two sentences plus args list), front-loads the purpose, and every sentence provides value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description defines inputs and purpose, it lacks usage context such as typical scenarios or how the returned data is structured. The existence of an output schema partially compensates, but the description alone is not fully informative for a tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to both parameters beyond the schema: 'asset_path: Content path to the StateTree asset' and 'filter: Optional substring filter on evaluator class name'. With 0% schema coverage, this fully compensates and clarifies parameter purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'all global evaluators' from a StateTree asset, specifying the verb (get) and the resource (global evaluators). It distinguishes itself from sibling tools like add_statetree_evaluator (adds) and get_statetree_global_tasks (different entity 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?
The description provides no guidance on when to use this tool versus alternatives, such as get_statetree_states or get_statetree_global_tasks. It lacks explicit context for selection, e.g., 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?
With no annotations present, the description must fully convey behavioral traits. It only briefly describes parameters and states it retrieves tasks and their properties. There is no mention of side effects, permissions, rate limits, or response behavior, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by a clear parameter list. Every sentence is useful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. However, it lacks context about the scope (e.g., all tasks from the asset) or any limitations. Still, it is sufficient for a straightforward retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters: asset_path as 'Content path to the StateTree asset' and filter as 'Optional substring filter on task class name'. This adds meaning beyond the bare schema, though examples or format hints would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all global tasks with their properties,' which is a specific verb+resource combination. It distinguishes well from sibling tools like 'add_statetree_global_task' and 'get_statetree_states'.
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 scenarios where another 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.
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. While 'Remove' implies mutation, it does not describe side effects, error conditions (e.g., out-of-bounds index), permission requirements, or return value. The only behavioral hint is to check indices via get_input_action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the core action first and a helpful tip second. No redundant words, and the structure is optimal for quick parsing.
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 two-parameter removal tool, the description covers the basic operation and provides a usage hint. However, without behavioral details (error handling, side effects) and no output schema, it leaves gaps for a fully informed agent decision.
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 coverage is 0%, so parameter descriptions are absent. The description only clarifies that 'index' refers to the modifier index, but does not explain 'asset_path' (likely the input action asset). This adds minimal value beyond the raw 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 ('Remove') and the target resource ('modifier from an Input Action by index'), making the tool's purpose unambiguous. It distinguishes from sibling tools like add_input_action_modifier and remove_input_action_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct pointer to use get_input_action to see current modifier indices, which helps the agent know how to prepare input. However, it does not explicitly state when to prefer this tool over alternatives or any 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?
Annotations are absent; description carries full burden. It only states the removal action without disclosing side effects, reversibility, permissions, or impact on the IMC asset. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with one sentence and a clear parameter list. No unnecessary words. Could benefit from a more structured format, but effective for its length.
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 (remove modifier by index), description explains parameters adequately. However, it lacks context about what a modifier is, prerequisites, or effects. Output schema exists but is not shown, so return values are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The Args section adds meaning to each parameter (e.g., 'Path to the IMC asset', 'Index of the mapping'). While not highly detailed, it provides essential context beyond raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Remove a modifier from a mapping in an Input Mapping Context'. It distinguishes from sibling tools like 'remove_mapping_trigger' and 'add_mapping_modifier' by specifying the element being removed (modifier) and the context (mapping in IMC).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The purpose implies usage for removing modifiers, but no when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that UE5 automatically fixes references, which is a key behavioral trait. However, it doesn't disclose whether the operation is destructive (e.g., old path removed) or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It front-loads the action and includes only essential information without unnecessary 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?
For a simple rename/move tool with two params and an output schema (not detailed), the description covers the basic purpose and a behavioral note. However, it lacks details on whether the operation copies or truly moves, or what the output schema returns.
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 coverage is 0%, and the description only implies the purpose of source_path and dest_path without specifying path formats (e.g., relative vs absolute). It adds minimal meaning beyond the param names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rename or move) and resource (asset) with a specific verb. It distinguishes from sibling tools like rename_data_table_row by being generic for assets. The note about UE5 auto-fixing references adds context.
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 vs alternatives like duplicate_asset or delete_asset. The note about auto-fix references implies safe usage, but no when-not-to-use conditions 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 exist, so the description carries full burden. It only states the operation without disclosing side effects (e.g., impact on emitter renderers, undo behavior, or effect on gameplay).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences of purpose plus a clean Args list. Every element is necessary and no redundancy. Front-loaded with the action verb 'Move'.
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?
An output schema exists (as per context signals) but is not shown; the description does not mention return values. However, for a simple reorder operation, the provided info is largely sufficient. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes an Args section explaining each parameter: system_path, emitter_name, and new_index (with note '0-based'). This adds meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'move' and the resource 'emitter to a new position in the system's emitter list', distinguishing it from sibling tools like reorder_niagara_module or remove_niagara_emitter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., reorder vs. remove/duplicate) is provided. Missing context such as prerequisites 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.
Behavior3/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 reveals that the tool returns matches with location information (state, evaluator list, transition, etc.), which is helpful. However, it does not mention search behavior details like case sensitivity, substring matching (though class_filter hints at this), or potential performance implications. The read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, two example lines, one sentence for return info, and a structured parameter list. It is well-organized and front-loaded with the core purpose. The parameter descriptions are separate but clear. Minor improvement would be to combine the two example lines into a single sentence for tighter structure.
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 moderate complexity (3 parameters, search functionality) and the presence of an output schema, the description is sufficiently complete. It explains all parameters, describes return values with location context, and provides example queries. Missing details like sorting or result limits are minor, as the output schema likely covers structure. The description enables 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 input schema has 0% description coverage, but the description compensates by explaining each parameter: asset_path (content path), class_filter (substring filter with examples), and category (filter options like 'task', 'evaluator', etc.). This adds significant semantic meaning beyond the schema's type information. The inclusion of valid category strings is particularly useful.
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 purpose: searching for nodes across the entire StateTree by class name or category. The verb 'Search' and resource 'nodes' are specific, and the example questions illustrate common use cases. However, it does not explicitly distinguish itself from sibling tools like get_statetree_node or get_statetree_states, leaving some ambiguity about when to use 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context through example questions ('Is MassEnemyAttackTask used?' or 'Which states have conditions?'), suggesting scenarios where searching is appropriate. However, it lacks explicit guidance on when not to use this tool or which alternative tools (e.g., get_statetree_node for a known node ID) would be better suited. No prerequisites or limitations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the curve types and the key JSON format, but lacks details on side effects (e.g., overwriting or appending curves), error handling, or required permissions. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence purpose followed by a list of args. Every sentence is necessary, and there is no redundancy. It is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 required parameters and no annotations, the description covers the core functionality well, including curve type and key format. An output schema exists (not shown) which likely documents return values. Minor omission: no mention of whether the input must already exist or if the tool validates keys.
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 0% description coverage, but the description lists all 7 parameters and provides format examples for 'keys' and 'curve_type.' For other parameters (e.g., 'system_path'), only names are given, which are self-explanatory but add minimal value. Baseline for low coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a curve on a module input parameter,' specifying the verb and resource. This distinguishes it from sibling tools like 'set_niagara_module_input' or 'set_niagara_user_parameter,' which handle different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites, limitations, or exclusions. Without such context, the agent may misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'batch-set' and lists supported properties, but does not state whether the operation is destructive, requires specific permissions, triggers compilation, or auto-saves. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose line and an 'Args' section using bullet points. It is informative without being overly verbose, though a slight reduction in technical detail could improve 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?
Given the complexity of 4 parameters, nested objects, and no annotations, the description covers the core functionality and parameter semantics fairly well. However, it lacks information about return values (despite an output schema being present) and side effects like auto-saving or compilation, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description adds significant meaning: it defines the 'properties' parameter as a dict with explicit supported keys and types, and clarifies the resolution logic for the script target via system_path+module_name or script_path. This greatly aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch-set details-panel properties on a Niagara script' with specific verbs and resources. It is distinct from sibling tools like 'get_niagara_script_properties' and 'set_niagara_system_property'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to target the script via system_path+module_name or script_path, but does not explicitly state when to use this tool versus alternatives, nor provides exclusions or prerequisites. Some guidance is implied but not formalized.
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 cover behavioral traits. It only states basic spawning behavior and auto-activation, but omits error handling, permission needs, performance impact, or whether it's blocking/async.
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 well-structured docstring with a brief introduction and a bullet list of parameters. Every sentence adds value, no redundancy, and it's appropriately sized for the tool's complexity.
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 presence of an output schema and no annotations, the description covers the tool's purpose and all parameters adequately. However, it lacks behavioral context such as error scenarios or system requirements, which is needed for a spawning operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by clearly explaining each parameter, including format (e.g., coordinates as strings) and defaults. It adds meaningful information beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool spawns a Niagara System as an actor, using specific verbs and resource. It distinguishes from sibling tools like 'spawn_actor' or 'control_niagara_effect' by specifying the exact type of effect and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'spawn_actor' or 'control_niagara_effect'. No prerequisites, exclusions, or context for usage 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 captures a PNG and returns file path, width, and height. It does not mention side effects (e.g., file overwriting), performance implications, or error conditions. With no annotations provided, the description partially fulfills the transparency burden but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each serving a purpose: statement of action, mode explanation, return value list, and guidance on viewing the image. It is front-loaded and free of irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema visibility, the description covers the core functionality and return values. However, it lacks details on file path behavior (default location, naming), error handling, and environment assumptions. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It adequately describes the 'mode' parameter with examples, but the 'file_path' parameter is not explained at all. This leaves a key parameter undocumented, reducing the tool's usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 uses the verb 'Capture' and specifies the resource 'editor to a PNG'. It distinguishes between two modes ('viewport' and 'window') with specific explanations, making the tool's purpose unambiguous. No sibling tools directly compete, so purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on choosing between modes ('viewport' vs 'window') and suggests using the Read tool after capture. However, it does not discuss broader usage context, prerequisites, or when to avoid using this tool. No alternatives are mentioned, which is acceptable given the unique functionality.
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 details the BFS algorithm, direction options, max depth, and optional pin filter. However, it lacks information on performance implications, what happens if the starting node doesn't exist, and whether the operation is read-only. Since no annotations are provided, the description carries full burden, but it is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence defining the core operation, followed by a bullet-style list of parameters. It is front-loaded with essential information. Slightly verbose in the parameter examples, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, graph traversal) and the existence of an output schema, the description covers the key aspects: direction, depth, pin filtering, and node identification. It does not specify prerequisites (e.g., open Niagara system) but is sufficient for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the purpose of key parameters (direction, max_depth, pin_name) and the dual identifier system (system_path+module_name OR script_path). The pin_name filter is clearly described. Some parameters like node_index and node_class are listed but not elaborated, keeping it concise.
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?
Clearly states it performs a breadth-first trace of connections from a starting node, explaining upstream/downstream directions. However, it does not explicitly differentiate from the sibling tool trace_material_connection, which serves a similar purpose for material graphs.
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?
Describes the purpose (upstream/downstream analysis) and parameters, but does not provide explicit guidance on when to use this tool over alternatives, nor does it mention when not to use it. The usage context is implied but not directly 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 provided, but description only mentions creation and setting properties. Does not disclose behavior on existing asset paths, permissions needed, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with bullet-style listing of parameters. No extraneous information. Every sentence provides value.
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?
Missing return value description despite having an output schema. Does not explain what the tool returns (e.g., asset reference). Also lacks context on how this fits with other input action tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains all three parameters: asset_path (with example path), value_type (with allowed enum values), and properties (optional dict). Adds significant meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new UInputAction asset' with specific verb and resource. It distinguishes from sibling tools like set_input_action_properties or list_input_actions by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the creation context is implicit. Missing exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns every visible pin, whether it's connected, expected type, and feeder node, and also reports substrate_enabled and has_front_material_connected status. It does not mention destructive behavior or authorization, but for a read-only query, 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 concise and well-structured in three paragraphs: purpose, usage, and extra context. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are already covered. The description explains what is returned and why it is useful, including dynamic behavior (pins change based on material settings). It is quite complete for a single-parameter query tool, though it could mention error handling for invalid material paths.
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 only parameter 'material_path' is given no description in the input schema (0% coverage). The tool description does not add any semantics about the parameter, such as format or path expectations, which is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries available material output pins for a specific material, with specific verb+resource. It explains what is returned (visible pins, connection status, type, feeder node) and distinguishes from sibling tools like get_material_graph_nodes by focusing on output pins for connection purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this to discover valid to_pin values for connect_material_expressions with to_node="material".' It also mentions that available pins change based on blend mode, shading model, and Substrate, providing clear context. However, it does not explicitly mention when not to use it or alternatives, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it's a read operation returning mapping details. No side effects or limitations disclosed, which is acceptable for a simple read but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No unnecessary words; every sentence adds 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?
Output schema exists, so return value documentation is covered. Missing parameter documentation is a gap, but overall sufficient for a read operation on a single-parameter tool.
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 only parameter 'asset_path' has 0% schema description coverage and the description does not explain its meaning or format. The tool name and context hint it's a file path, but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'Read' and resource 'key mappings from an Input Mapping Context'. It distinguishes from sibling tools like list_input_mapping_contexts (which lists contexts) and add_key_mapping (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage context is implied (reading existing mappings) but no alternatives or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It discloses that the tool recompiles by default and returns error messages with node indices. However, it does not mention potential side effects (e.g., modifying the material), performance impact, or error handling if the material is not found. More detail on the recompile behavior and what happens with cached errors would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences that are front-loaded. Every sentence adds value: the first states the purpose, the second describes the return value, and the third explains the default behavior. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description is fairly complete. It covers the purpose, return value, and key behavior (recompile by default). It is missing details about what happens when no errors exist or when the material path is invalid, but the output schema likely provides structure for return values. It is adequate for a focused utility tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to parameters. It only indirectly addresses the 'recompile' parameter by stating 'Recompiles first by default,' but does not explain the 'material_path' parameter at all. The description adds minimal value beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets shader compilation errors for a material. It specifies the resource ('shader compilation errors for a material') and the verb ('Get'), making the purpose unambiguous. It distinguishes itself from siblings like 'recompile_material' and 'get_material_info' by focusing on retrieving errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that recompilation happens by default to get fresh errors, which implies usage context. However, it does not explicitly state when to use this tool versus alternatives like 'recompile_material' or 'get_material_info', nor does it mention when to set 'recompile' to false. No exclusion criteria or specific prerequisites are 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, the description carries the full burden. It discloses that the tool returns editable UPROPERTY lists via reflection or HLSL schema for CustomHlsl, and input/output parameters for script assets. However, it does not mention side effects, permissions, or error behavior, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence, followed by two focused paragraphs for each mode. Every sentence adds value, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two modes and the presence of an output schema, the description covers the essential aspects: what each mode returns, examples, and a comparison to a similar tool. It does not cover error cases or limitations, but is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds significant meaning to both parameters: it explains 'type' as node short name or full class name with examples, and 'script_path' as an optional asset path that switches the output. This compensates for the lack of per-parameter schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves pin/property schema for Niagara node types or script assets, specifying two distinct modes. It distinguishes itself from similar tools like get_expression_type_info by mentioning the comparison, but does not explicitly differentiate from siblings like get_niagara_node_info or describe_niagara_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (node class vs script path) but lacks explicit guidance on alternatives or when not to use this tool. It implies usage contexts through examples but does not provide clear exclusions or comparisons to 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?
No annotations provided, so description carries burden. It describes the tool as a read operation and outlines return format, but lacks details on permissions, restrictions, or behavior in edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences: first states purpose, second describes output structure. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description adequately covers return structure. However, input parameter format is under-defined, and edge cases are not mentioned.
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?
Input schema has only one parameter 'widget_blueprint_path' with 0% schema description coverage. Description does not explain the expected format or valid values for the path, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads the complete widget hierarchy from a Widget Blueprint's Designer, using specific verb 'Read' and resource 'widget hierarchy', distinguishing it from sibling tools like get_widget_properties or list_widget_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the hierarchy but does not explicitly state when to use this tool over alternatives, nor does it provide when-not-to-use or mention alternate tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses overwrite behavior and default, but does not mention side effects (e.g., creating intermediate folders) or output 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 concise and front-loaded with the main action. It uses a bullet-like list for parameters, making it easy to scan. No redundant sentences.
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 presence of an output schema, the description does not need to explain return values. It covers essential information for using the tool, though it could mention the output type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds significant value by explaining each parameter with examples, default values, and file paths, making the tool usable.
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 imports external files into the Content Browser, with specific example types. It distinguishes from the sibling batch import tool by being singular, but does not explicitly mention import_assets_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing a single file and provides parameter details, but lacks explicit guidance on when not to use it or alternatives like import_assets_batch for batch imports.
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 given, so the description must cover behavioral traits. It describes a read-only list operation but does not disclose any side effects or requirements. This is adequate for a simple list 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 (two sentences) and front-loaded with the main purpose. It is concise and clear, though a bit more structure could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately explains the tool's function. It does not need to elaborate on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds full meaning for the single optional 'filter' parameter. It clearly explains that the filter is a substring filter on the data interface name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb 'List' and the resource 'Niagara Data Interfaces', with examples like Grid2D, Grid3D, AudioSpectrum. This distinguishes it from sibling tools such as list_niagara_systems and list_niagara_modules.
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 does not indicate when to use this tool versus alternatives. No guidance on context or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses that outputs come from UNiagaraNodeOutput and inputs from filtered variable metadata, which is sufficient for a read-only list tool. It does not cover permissions or error cases, but the provided details are solid.
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 four sentences, each purposeful and well-structured. It front-loads the main purpose, provides technical detail, and ends with concrete use cases. No wasted words.
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 three parameters and an output schema, the description should explain how to use the parameters and clarify what the output contains. It does neither, leaving significant gaps for an AI agent to correctly invoke the tool.
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?
Despite 0% schema description coverage and three parameters, the description contains no information about module_name, script_path, or system_path. Users have no guidance on how to specify which script to query, which is a critical omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'List input + output parameters of a Niagara script', which is a specific verb-resource combination. It distinguishes itself from sibling tools like list_niagara_available_parameters by focusing on a script's own parameters, and provides technical details about data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful for discovering what an Add Parameter dropdown would show or for diff-auditing a graph before/after mutation', giving clear usage context. It lacks explicit exclusion of alternatives, but the context is strong enough for most 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?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention whether the tool is read-only, requires the asset to exist, or what happens on invalid input. The return format is not described despite the existence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three lines, front-loads the purpose, and provides a clear parameter list with no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and no annotations, the description should describe return values. It does not mention what the tool returns (expected to be a list of type names). Parameter coverage is good, but output semantics are missing, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining each parameter's role: asset_path determines schema, category must be one of three specific strings, and filter is an optional substring filter. This adds meaning beyond raw types, though details like filter case sensitivity are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'task/evaluator/condition types' for the StateTree schema, using a specific verb and resource. It distinguishes from siblings like 'list_statetree_enum_values' (which lists enum values) and 'search_statetree_nodes' (which searches for nodes).
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 context through the 'category' parameter (task/evaluator/condition), but does not explicitly state when to use this tool versus alternatives like 'list_statetree_enum_values' or 'search_statetree_nodes'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the mutation (adding a trigger) but does not mention side effects, permission requirements, error conditions (e.g., invalid mapping_index), or reversibility. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus a list of args. No redundant information, and the purpose is front-loaded. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete given the existence of an output schema and the tool's straightforward nature. It explains all parameters clearly, but could mention error scenarios or dependencies (e.g., the IMC must already exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter with context and an example (e.g., trigger_type: 'InputTriggerPressed'). Although schema coverage is 0%, the description compensates well, though the 'properties' parameter remains somewhat vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 trigger to a specific mapping in an Input Mapping Context.' This distinguishes it from sibling tools like remove_mapping_trigger and add_key_mapping, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing required parameters but provides no explicit guidance on when to use this tool over alternatives (e.g., add_key_mapping). No context about prerequisites or scenarios 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 bears full responsibility for behavioral disclosure. It describes parameters but lacks details on side effects, prerequisites (e.g., existing system/emitters), error conditions, or return values. Critical for a mutation tool with 7 parameters and an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief: a single sentence for purpose and a bullet list for arguments. It is front-loaded with the main action and avoids unnecessary words. Every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters adequately, but given the complexity (7 params, mutation, output schema), it lacks prerequisites, return value explanation, and error handling. Some behavioral context is missing, making it less complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully explain parameters. It does so thoroughly, listing all 7 parameters with context (e.g., event name examples, execution mode meanings, default values). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add', the resource 'event handler', and the target 'emitter', with the purpose of responding to events from a source emitter. This distinguishes it from sibling tools like add_niagara_emitter or add_niagara_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding event handlers to emitters but does not explicitly state when to use this tool versus alternatives (e.g., modifying handlers via other tools) or when not to use it. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses naming conventions (input names become 'Module.<name>') and the direction default, but does not cover side effects, permissions, or constraints on parameter names/types beyond the type registry reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs and a bullet list for arguments. It is concise with no redundant information, and the action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality but omits explanations for three optional parameters. With an output schema present, return values are not needed, but the missing parameter docs reduce completeness for a tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It explains 'name', 'type', and 'direction' but does not mention 'module_name', 'script_path', or 'system_path', which are optional but crucial for context. The description is incomplete for half the 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 tool name and description clearly state that it adds an input or output parameter to a Niagara script. It specifies the action (adds an input/output parameter) and the resource (Niagara script), and distinguishes from sibling tools like 'remove_niagara_script_parameter' and 'rename_niagara_script_parameter'.
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 context on when to use 'output' for dynamic inputs and references 'list_niagara_parameter_types' for valid types. However, it does not explicitly state when not to use this tool or provide alternatives, such as when to use 'add_niagara_user_parameter' or 'set_niagara_module_input'.
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 only lists parameters and their defaults but does not describe side effects, required permissions, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief introductory sentence followed by a clear parameter list. It could be slightly more concise, but the parameter details are efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (8 parameters, 2 required) and the presence of an output schema, the description provides sufficient parameter documentation. Missing guidance on expected output or error scenarios, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds substantial value by listing all parameter options (e.g., state_type values, selection_behavior enum) and clarifying that parent params can be omitted for root states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Add a state to the tree' and distinguishes from sibling tools like add_statetree_task or add_statetree_evaluator by focusing specifically on state addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage guideline: 'Omit parent params for a root-level state.' However, it does not mention when to use this tool versus alternatives like add_statetree_task or add_statetree_evaluator.
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?
Mentions validation and clean type mismatch rejection, adding behavioral context. No annotations exist, but description doesn't cover side effects, permissions, or limitations beyond validation.
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?
Three sentences, front-loaded with key action. Each sentence adds value, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a tool with many siblings, but lacks explanation of system_path and module_name, and does not describe output. Under-specified for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains how to identify pins via (class|index|id) trio, which maps to parameters. Adds significant meaning for those fields, but leaves system_path and module_name unexplained, with 0% 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?
Clearly states the action (wire pins), context (scratch pad graph), and identification method (class|index|id trio). Distinguishes from sibling tools like connect_material_expressions by specifying 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?
Provides identification guidance but no explicit when-to-use vs alternatives or prerequisites. Implies usage through context but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full weight. It discloses that deletion triggers automatic recompilation and save, and that indices shift. This is helpful context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and then side effects. No unnecessary words 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 has an output schema (not shown), so return values need not be described. The description covers the main behavioral effects, but lacks error handling info and prerequisites (e.g., material must be valid).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It mentions 'by index' but does not clarify the format or range of node_index nor explain material_path. This leaves parameter semantics vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a single expression node by index, and mentions it belongs to material graphs. The purpose is specific and distinct from sibling deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests re-querying after deletion due to index shifts, providing a clear usage hint. However, it does not specify when to use this tool over alternatives 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 must bear the full burden. It fails to disclose behavioral traits such as whether the tool is read-only, performance implications, or any safety considerations. The description only covers basic functionality without 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 two sentences with no filler. The first sentence states the core purpose, and the second explains the parameter options. It is efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as per context signals), the description does not need to explain return values. It provides enough context for a straightforward reference-finding tool, though it lacks prerequisites or error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'direction' parameter by explaining the three options: 'dependents' (who uses this), 'dependencies' (what this uses), 'both'. This goes beyond the schema, which only defines type and default. The 'asset_path' is implicitly described as 'the given asset'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Find assets that reference or are referenced by the given asset,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like 'find_assets' (general search) and 'list_assets' (listing all assets) by focusing on reference 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 description explains the 'direction' parameter options but does not explicitly state when to use this tool over alternatives like 'find_assets' or 'get_asset_info'. It implies usage for dependency analysis but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the return output but does not disclose side effects, permissions, or whether the operation is read-only. However, as a 'get' operation, it is implicitly non-destructive, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear main sentence followed by a bullet list of parameters. Each sentence adds value, though the parameter list could be slightly shorter if schema descriptions were used. Still, it is concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward nature (read operation, 4 params, no nested objects), the description covers the essential aspects. It lists return fields and includes filter usage. Minor omissions like error handling are acceptable given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides thorough parameter documentation: system_path and emitter_name paths, scope valid values ('particle', 'emitter', 'system', 'all'), and filter examples like 'Color' or 'Velocity'. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get attributes defined on an emitter at a given scope.' It specifies the return fields (name, type, scope, source) and distinguishes from sibling tools like list_niagara_emitters or get_niagara_system_info by focusing on emitter attributes.
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 mentions filtering but does not explain when to use filters or contrast with other Niagara attribute tools. There is no 'when not to use' or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions only the data returned and the filter option. It does not disclose whether the operation is read-only, what permissions are needed, how pagination works, or any side effects. This is insufficient for an agent to understand the tool's behavior beyond its immediate function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus an Args section. It front-loads the core purpose, lists returned fields, and then explains parameters. No extraneous information or repetition. Every sentence contributes 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 output schema exists, the description appropriately lists returned fields and parameters. However, it lacks mention of potential limitations (e.g., maximum number of emitters returned) or error conditions. For a simple list tool, this is nearly complete; minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters: 'system_path' is explained as 'Path to the Niagara System asset', and 'filter' is described with examples like 'Spark', 'Flame', 'Trail'. Since the schema has zero description coverage, this supplement is valuable and clarifies how to use the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get emitters in a Niagara System.' It specifies what data is returned (name, unique_name, index, etc.) and distinguishes itself from sibling tools like 'get_niagara_system_info' and 'get_niagara_emitter_attributes' by focusing on emitter listing and metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance ('Use filter to get specific emitters by name substring'), but it does not explicitly state when to use this tool versus alternatives like 'get_niagara_system_info' or 'list_niagara_systems'. No exclusion criteria or contextual hints are given, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get' which implies a read-only operation, but does not explicitly confirm no side effects, auth requirements, or return behavior. The output schema may cover return details, but the description lacks 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 extremely concise: a single action line followed by two parameter descriptions. Every sentence is necessary and there is no wasted text. The information is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It correctly identifies the tool's scope (event handlers on a specific emitter) and provides parameter info. Minor missing context: what constitutes an 'event handler' or that the system must exist, but overall complete for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds descriptions for both parameters: 'system_path: Path to the Niagara System asset' and 'emitter_name: Name of the target emitter.' This adds meaningful context beyond the schema's type-only definitions. However, no format constraints or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get all event handlers configured on an emitter.' It uses a specific verb and resource, and the tool name matches. It distinguishes itself from sibling tools like 'add_niagara_event_handler' by being a read operation, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or context. While the sibling 'add_niagara_event_handler' implies this is for reading, explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool returns parameter names, types, current values, and module ownership. It does not explicitly state it is read-only, but the name 'get' implies that. No mention of side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear structure: a brief purpose statement followed by bulleted parameter descriptions. It is front-loaded and easy to parse, though could be slightly more streamlined.
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 presence of an output schema (not shown), the description adequately explains input parameters and return values. It is sufficiently complete for an agent to understand the tool's function, though it lacks warnings about sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section describes each parameter in detail, including system_path, emitter_name, script_usage, and filter. It provides examples for filter (e.g., 'Color', 'SpawnRate'), adding significant meaning beyond the schema which only has names and types. Schema description coverage is 0%, but the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves rapid iteration parameters (actual configurable values on modules) and lists examples like spawn rate, gravity, colors, etc. This distinguishes it from sibling getter tools that retrieve system info or emitters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_niagara_module_inputs or set_niagara_rapid_iteration_parameter. The description does not mention prerequisites or context for usage.
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 implies a read-only operation ('List') but does not disclose any additional behavioral traits. Since no annotations exist, the description carries the burden, but it fails to mention possible side effects or performance implications. It is adequate for a simple list 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 extremely concise: one sentence for the purpose followed by bullet points for parameters. Every part is necessary, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It covers what the tool does and the parameters. However, it could mention whether the listing is recursive or scoped to a directory, though the 'path' parameter implies directory scoping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining each parameter's purpose (e.g., 'Content Browser directory to search in'). This adds meaningful context beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Niagara System assets'), clearly indicating the tool's function. It differentiates from sibling tools like 'list_assets' and 'find_assets' by focusing on Niagara System assets alone.
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. With many sibling tools for listing and searching assets, explicit context or comparisons would help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output but does not disclose any behavioral traits such as side effects, authentication needs, or rate limits. For a read-only listing tool, 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 two sentences that are front-loaded with the core purpose, followed by what it returns. No unnecessary words or fluff, making it highly 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?
While an output schema exists, the description fails to explain the filter parameter, which is a significant gap given the low schema coverage. For a simple listing tool, this is minimally complete but could be improved.
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 only parameter 'filter' is not mentioned in the description, despite having 0% schema description coverage. The description should explain its purpose (e.g., how to filter results) since the schema only provides a default empty string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 available UInputTrigger subclasses with their editable properties, which is a specific verb-resource pair. It also mentions the return fields (name, display_name, parent class, editable property names/types), distinguishing it from sibling tools like list_modifier_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 description explicitly says 'Useful for discovering valid trigger_type values', which provides clear context for when to use this tool. While no alternatives or exclusion criteria are given, the sibling tools (e.g., list_modifier_types) are different enough that the usage is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it removes a trigger by index, but does not mention error handling (e.g., if index is out of bounds), whether the operation is reversible, 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 two sentences, front-loaded with the action and resource, followed by a helpful usage tip. Every sentence is valuable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema and two parameters, the description provides the essential information. It lacks mention of prerequisites (e.g., the input action must exist) or behavior when the trigger doesn't exist, but is sufficient for a basic 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 coverage is 0%, so description must add meaning. It explains 'index' is used to identify which trigger to remove and recommends get_input_action to find indices. However, it does not explicitly describe the 'asset_path' parameter or provide full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 identifies the resource 'trigger from an Input Action' and the method 'by index'. It also mentions using get_input_action to see indices, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using get_input_action first to see current trigger indices, providing clear context for when to use this tool. However, it does not state when not to use it or alternative 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 provided, the description carries the full burden of behavioral disclosure. It mentions that only one trait is removed without affecting others, which is helpful. However, it does not disclose behavior when the trait does not exist, what happens if both identifiers are provided (though implied not to), or any permission requirements or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two sentences upfront stating the purpose and key constraint, followed by a brief args list in a standard format. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with no output schema described, but the context indicates an output schema exists. The description does not mention return values or behavior on failure (e.g., trait not found). Given the tool's simplicity and the presence of an output schema, this is a minor gap but the description could still be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by explaining that trait_index and trait_class are alternative identifiers and providing an example for trait_class. This is especially valuable given the schema itself has no descriptions (0% coverage). The description covers all three parameters adequately.
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 ('Remove a single trait') and the target resource ('Mass Entity Config'). It specifies that it does not affect other traits, adding precision. While it distinguishes from siblings like 'add_mass_config_trait' implicitly, it does not explicitly contrast with 'set_mass_config_trait_property' or 'get_mass_config_traits'.
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 guidelines on how to identify the trait ('by EITHER trait_index OR trait_class (not both required)') and includes an example for trait_class. It does not, however, give guidance on when to use this tool versus alternatives or handle cases where both identifiers 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 carries full burden. It states the action is removal (destructive), but lacks details on reversibility, side effects, or prerequisites. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence and an args list. It is front-loaded but could be slightly more structured (e.g., bullet points). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with 4 required params, the description covers all inputs. It does not mention output or side effects, but an output schema exists (not shown). Adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all four parameters: system_path, emitter_name, module_name, and script_usage with explicit allowed values, adding meaning beyond the raw 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 verb 'Remove' and the resource 'a module from an emitter's script usage stack'. It distinguishes from sibling tools like add_niagara_module or reorder_niagara_module.
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 lists the script_usage parameter with allowed values, providing context for when to use the tool. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It only says 'Move a module' without disclosing side effects (e.g., index shift, validation, error handling). Not transparent about what happens if new_index is out of bounds.
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?
Concise one-sentence purpose followed by a structured parameter list. No wasted words, front-loaded with action, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 5 parameters are explained. Output schema exists so return values are covered separately. Missing preconditions or behavioral caveats, but adequate for a straightforward reorder tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section explaining each parameter (system_path, emitter_name, module_name, script_usage, new_index) with brief context, adding value beyond the schema's type-only definitions. However, it lacks details on constraints (e.g., valid index range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move a module') and the target resource ('within its script usage stack'), using specific verb and resource. It distinguishes from sibling tools like remove_niagara_module or add_niagara_module by focusing on reordering.
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 context (reordering modules) but does not explicitly state when to use this tool vs alternatives, such as add/remove. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description must disclose behavioral traits. However, as a search tool, behavior is straightforward and safe. The description adds limited behavioral context beyond what the name implies, but doesn't mention side effects or permissions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using bullet-like lines for each parameter. It front-loads the main action and contains no unnecessary details. Every sentence is useful.
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 an output schema, so the description is not required to explain return values. It covers all parameters and the search operation sufficiently. Minimal gaps remain, such as not clarifying that results are filtered by path, but the path parameter handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter's purpose, default value, and usage examples (e.g., filter examples). This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for Material Functions by name, using a specific verb and resource. It effectively distinguishes from sibling tools like 'search_niagara_functions' and 'find_assets' by targeting a specific asset type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'find_assets'. There is no mention of prerequisites or exclusions. The description merely explains what the tool does without contextual usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Modify' but fails to mention side effects (e.g., auto-compilation, persistence, error handling) or prerequisites beyond the parameters. The return value is not described despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a one-line summary followed by a structured parameter list. Every sentence adds value with no redundancy or fluff. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description explains each parameter well but lacks context about return values, error conditions, or behavioral implications (e.g., does it require the function to be saved first?). It is adequate but incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so excellently by providing clear, meaningful comments for each parameter (e.g., 'Full path to existing material function', 'New pin name'), adding significant value over the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify an existing FunctionOutput node's properties', using a specific verb and resource. It effectively distinguishes itself from sibling tools like add_material_function_output (which creates) and set_material_function_input (which modifies inputs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter context (e.g., node_index from get_material_function_info) but does not explicitly state when to use this tool versus alternatives or exclude cases. No 'when-not-to-use' or alternative tool names are mentioned, leaving the agent to infer usage from 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 full burden. It states that the tool sets playback range but does not disclose side effects (e.g., persistence, permissions, or what happens if parameters are out of bounds). The behavioral impact is insufficiently explained 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 concise with a clear front-loaded purpose statement, followed by practical usage hints and a structured parameter list. No redundant sentences, making it efficient for an AI 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?
Despite having an output schema, the description lacks essential context such as whether changes are permanent or temporary, whether the asset must be open, and error handling for invalid inputs. This gap reduces completeness for a setter 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?
Input schema has 0% coverage, but the description includes an 'Args' section with brief explanations, examples (e.g., '5.0 for 5 second preview'), and defaults. This adds significant value beyond the schema, though 'system_path' could be more precise about the asset path format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Set the timeline playback range in the Niagara editor.' It distinguishes from the sibling tool 'get_niagara_playback_range' and provides practical examples of when to adjust the range (e.g., short-lived effects, looping effects).
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 concrete usage advice: extend range for effects dying quickly, use longer range for looping effects. However, it lacks explicit exclusions or comparisons to alternative tools beyond the implicit getter/setter distinction.
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 bears the full burden. It explains the parameters and gives examples but does not disclose side effects (e.g., whether it overwrites existing bindings), failure conditions, or required permissions. This is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, an explanatory sentence, and a parameter list. It is somewhat lengthy but clear. Minor repetition (e.g., 'Bind' in both summary and explanation) but not excessive.
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 presence of an output schema (not shown but stated), the description doesn't need to explain return values. It covers all parameters adequately, explains the binding concept, and provides examples. It could mention error cases or prerequisites but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides detailed parameter explanations with examples (e.g., binding_name: 'ColorBinding', attribute: 'Particles.Color'). This fully compensates for the missing schema descriptions and adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set an attribute binding on an emitter's renderer' and explains it binds a renderer input to a particle/emitter attribute. This distinguishes it from sibling tools like set_niagara_renderer_property (sets property directly) and add_niagara_renderer (adds a renderer).
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 doesn't mention prerequisites, such as the emitter needing to have a renderer, or when a binding slot is available. The sibling tools list is large but no explicit comparison 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?
No annotations are provided, so the description must disclose behavioral traits. It states that only fields in 'data' are modified and gives an example. However, it does not mention what happens if the row does not exist, whether the update is idempotent, or any permission requirements. The partial update behavior is clear, but other details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences: first sentence states purpose, second explains partial update behavior, third gives an example for the data parameter. It is front-loaded and every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, partial update behavior, and an existing output schema (not shown), the description covers the core behavior and an example for data. It does not explain return values (but output schema handles that). It could mention that the row must exist or error handling, but for a relatively simple tool, it is adequately 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 0%, so the description must compensate. It explains that the 'data' parameter is a JSON string of fields to update and provides an example. However, it does not describe 'row_name' or 'data_table_path', leaving their formats ambiguous (e.g., does row_name refer to the first column value?). The partial explanation for 'data' is helpful but incomplete for all 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 'Update specific fields on an existing row (partial update)', which is a specific verb + resource. It distinguishes from sibling tools like add_data_table_row, delete_data_table_row, etc., by focusing on partial updates to existing rows.
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 modifying specific fields while preserving others, but does not explicitly state when to use or when not to use this tool versus alternatives like set_data_table_row (if it existed) or other update tools. No exclusions or alternative tool names 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 provided, so description carries full burden. It describes the main action but lacks details on side effects (e.g., whether it modifies the system in-place, permissions needed, error scenarios, or what 'add' entails beyond the parameter choice).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with 4 sentences; first sentence states purpose, second explains key choice, then Args list. No redundant words, front-loaded with key 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?
Output schema exists, so return values are covered. Description covers purpose, parameters, and the main choice. However, given the complexity of Niagara systems, could be more explicit about what 'add' means (e.g., does it load asset, compile, immediate effect?). Still mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by listing and explaining each parameter (system_path, emitter_path, emitter_name, template) and clarifying that emitter_path and template are alternatives. Adds meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Add) and resource (emitter to Niagara System). It distinguishes from siblings like remove_niagara_emitter and duplicate_niagara_emitter, and explains two methods (emitter_path or template).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage by stating the two alternatives (emitter_path vs template) but does not explicitly say when to use one over the other or when not to use this tool. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the parameters but does not mention side effects (e.g., whether adding a renderer overwrites an existing one, requires specific permissions, or is reversible). The behavior is somewhat predictable from the name, but deeper transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It begins with a clear purpose sentence, followed by a bulleted list of parameters with succinct explanations. Every sentence adds value; no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but indicated), the description covers parameter semantics adequately. However, it omits potential error conditions and prerequisites. For a set of tools with many siblings, a bit more context (e.g., 'the emitter must already exist') would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% parameter description coverage. It explains each parameter's role, lists valid renderer_type values, and clarifies optional vs required fields. This enables correct parameter selection and reduces ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a renderer to an emitter.' It specifies the resource (emitter in a Niagara system) and the verb (add). Among sibling tools like remove_niagara_renderer and get_niagara_renderer_info, this tool's purpose is distinct 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, nor does it mention prerequisites or restrictions. While the action is straightforward, adding context such as 'requires an existing emitter' or 'use after add_niagara_emitter' would help ensure correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the creation behavior and template duplication, but does not specify what happens if the asset_path already exists (overwrite/error), whether permissions are needed, or if the asset is automatically saved after creation. These are important gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main action sentence, a behavioral note, and a clear args list. It is not overly verbose; each sentence adds value. Minor improvement would be tightening the template duplication sentence, but overall it is appropriately sized for the tool's complexity.
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 that an output schema exists (context signal), the description does not need to detail return values. It covers the creation purpose, template behavior, and parameters adequately. However, it lacks information about error conditions and prerequisites like valid content paths, which would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It explains asset_path with a concrete example, enumerates the three module_type options, and clarifies that description is optional. This adds meaning beyond the schema which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a standalone Niagara script asset (module/dynamic input/function). It distinguishes from sibling creation tools like create_niagara_system (creates a system) and create_niagara_scratch_pad_module (scratch pad). The verb 'create' and resource 'Niagara script asset' are 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 provides example usage (asset_path format, module_type options) but does not explicitly state when to use this tool versus alternatives like create_niagara_scratch_pad_module. No 'when not to use' guidance is given. The behavioral note about duplicating the editor's template hints at ideal use cases but is not a clear guideline.
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 disclosure. It describes the creation action but omits details like error handling on duplicate paths, permission requirements, or schema validation 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 extremely concise, using only two sentences and a bullet list. Every part adds value without redundancy or extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return value details are not required. However, the description lacks information about prerequisites, file overwrite behavior, or error conditions – which would improve completeness for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description provides the only meaningful documentation. It adds definitions and examples for both parameters, making them actionable beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new StateTree asset', specifying the verb and resource. It distinguishes from siblings like add_statetree_state (which modifies existing) and other asset creation tools by targeting StateTree specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples for parameters but does not explicitly state when to use this tool versus alternatives (e.g., modifying an existing StateTree). Usage context is implied but not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and does well: it reveals the underlying FProperty introspector, the recursive handling of Unreal property kinds, and specifics for enums, structs, and data interfaces. It could mention side effects or performance, but a read-only schema lookup likely has none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose first, then details. The list of property kinds is lengthy but relevant. It is concise enough, though could be slightly trimmed without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and an output schema exists. The description adds extra context on recursive property handling and type-specific return details, making it complete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a bare 'type' string property with no description, but the description's Args section fully compensates by detailing acceptable values: built-in names, registered types, UEnum/UScriptStruct paths, and UNiagaraDataInterface subclass names. This adds critical 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 clearly states the tool returns the full schema of any Niagara type, listing supported categories (primitive, enum, struct, data interface). It is specific about what it does, but does not explicitly distinguish from sibling tools like get_niagara_data_interface_schema or get_niagara_system_info.
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 a list of supported input types, implying when to use this tool, but it lacks explicit guidance on when not to use it or comparison with alternatives. There is no mention of prerequisites or contextual conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the scanning scope (six specific scripts), node type being searched, and the return fields. This provides good behavioral transparency for a read operation, though it could mention if there are side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a summary line followed by details. It efficiently conveys the core functionality in a few sentences, though it could be improved by including parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the scanning scope and return structure well, but lacks parameter documentation. Given the presence of an output schema, return values need not be explained. It could mention error handling or performance, but overall is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the two required parameters (module_name and system_path) despite 0% schema description coverage. While 'named scratch pad' implies module_name is the scratch pad name, system_path is not described. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'reverse lookup' to find where a scratch pad script is referenced in the stack, distinguishing it from sibling tools like list_niagara_scratch_pad_modules or apply_niagara_scratch_pad. It provides a specific verb ('find') and resource ('scratch pad script references'), and gives an example use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear use case ('Use this to answer "what uses GetDataInterfaceLength?" without walking every emitter manually'), indicating when to use this tool. However, it does not explicitly state when not to use it or name specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output (detailed info, pins) but doesn't mention side effects or constraints beyond that. It is accurate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and usage. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to detail return values. It sufficiently communicates the scope (single node info, pins) for a probe tool.
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 has two parameters with 0% description coverage. The description does not explain the parameters beyond the tool's purpose, so the agent must infer meaning from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed info for a single node including all pins, distinguishing it from sibling tools like get_material_info or get_available_material_pins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool before connecting nodes to discover pin names, providing clear context for when to use it, though it doesn't explicitly mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It describes the underlying call briefly but does not disclose whether the tool is read-only, destructive, or has side effects. The description is neutral but could be more explicit about 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?
Description is three paragraphs: purpose, background, parameters. Efficiently structured and front-loaded. Could be slightly more concise, but no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving graph actions), it explains what entries contain (display_name, category, etc.) and parameter details. Output schema exists but not used here. Missing context about required permissions or asset path format, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists all four parameters with meaningful explanations: system_path, module_name, filter (substring matching), max_results (cap). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return the full graph context-menu actions for a scratch pad module', using specific verb and resource. It distinguishes this tool from sibling Niagara operations by focusing on retrieving context menu actions, not adding/modifying nodes.
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?
Mentions it wraps the same call as the editor's right-click menu, implying when to use, but does not explicitly state when not to use or provide alternatives. No exclusions or comparisons to similar tools like add_niagara_graph_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses returned data (class, properties, instance data, tree location) but does not mention side effects, authorization, rate limits, or error conditions. Adequately describes a read-only operation but lacks depth on 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?
Three sentences plus an Args list. Purpose stated first, followed by return summary, then parameter details. No redundant information. Every sentence adds value efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an existing output schema, description doesn't need to detail return format. Explains what is returned and where the node lives. Lacks handling of invalid GUID or errors, but for a read-only retrieval tool with 2 params, it covers essential context. Could mention that node_guid must come from other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Adds clear explanations for both parameters: asset_path as 'Content path to the StateTree asset' and node_guid as 'GUID of the node (from get_statetree_state or get_statetree_evaluators)'. This provides essential context missing from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets detailed info for a single node (task/evaluator/condition) by GUID. Verb 'Get' and specific resource 'node' with types are explicit, distinguishing it from sibling tools like get_statetree_state (state info) or get_statetree_evaluators (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention when not to use it or contrast with related tools like get_statetree_state for state-level info. Implies need for a node GUID, but no decision 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?
With no annotations, the description carries the full burden. It discloses the partial update behavior, but omits important details such as whether changes are reversible, if recompilation is triggered, or any prerequisites. The agent lacks context on side effects or safety considerations.
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 short sentences. The first sentence states the purpose, and the second explains the partial update behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no parameter descriptions, no annotations) but presence of an output schema, the description is partially adequate. It covers the partial update aspect but lacks context on error conditions, side effects, and prerequisites. More details would be beneficial for a modification tool with many optional fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds general optionality semantics ('all parameters except two are optional, only provided values changed'), but with 0% schema description coverage, it does not explain individual parameters. While parameter names are somewhat self-explanatory, the description provides no additional meaning per parameter beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify properties of an existing Blueprint variable', using a specific verb and resource. It distinguishes from siblings like create_blueprint_variable (create) and set_blueprint_node_property (node properties), and the partial update behavior is noted.
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 for use is clear: when you need to modify an existing variable's properties. The second sentence clarifies that only provided values change, implying a targeted update. However, it does not explicitly mention alternatives like create_blueprint_variable or get_blueprint_variable_details, nor does it state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It reveals that the tool mutates state and supports two execution paths, but does not detail error behavior (e.g., missing parameter, type mismatch), whether changes auto-save, or what happens if both system_path and actor_name are 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 brief and efficient: two lead sentences followed by a clear bullet list. No superfluous words, and the key distinction (system_path vs actor_name) is front-loaded. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, two modes, and no annotations, the description covers core functionality but omits error handling, prerequisite conditions, and default behavior for optional params (schema shows null defaults). An output schema exists but is not shown; given the complexity, the description could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all 5 parameters beyond the schema's type-only definitions. It explains that system_path is for asset defaults and actor_name for runtime overrides, and that parameter_type must match an existing type. Given 0% schema description coverage, this provides necessary context, though it could clarify value format or valid types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'user parameter value on a Niagara System asset or level actor instance'. It distinguishes between two modes (asset default via system_path and runtime override via actor_name), which sets it apart from sibling tools like get, add, remove, and link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use system_path vs actor_name, but does not explicitly state when to use this tool over related siblings (e.g., add_niagara_user_parameter for creation) or what prerequisites are required (parameter must already exist). Lacks explicit 'when not to use' or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the target parameter (node vs instance) and notes that property values can be structs, arrays, or enums. However, it does not mention side effects, permissions, or failure behavior. For a mutation tool, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The parameter list is clear, though could be formatted with bullet points for better readability. No unnecessary information is included.
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 presence of an output schema and the simplicity of the operation (setting a property), the description is fairly complete. It covers the essential aspects. However, additional context about valid property names or how to discover them would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining each parameter: asset_path as content path, node_guid as GUID, property_name, property_value with type hints (structs as dict, arrays as list, enums as string), and target distinguishing node vs instance. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a property on a task, evaluator, or condition by GUID. It specifies the resource (StateTree node) and action, distinguishing it from similar sibling tools like set_statetree_state_property and set_statetree_transition_property.
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 setting properties on StateTree nodes but does not explicitly state when to use this tool versus alternatives like set_statetree_state_property or set_statetree_transition_property. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose potential side effects, authorization requirements, or failure modes (e.g., if the pin already exists or the node type is incompatible). It only states the action without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary, a brief usage paragraph, and an Args section. It is front-loaded and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and an output schema, the description covers all parameters and the core functionality. It lacks return value details but the output schema exists. The description is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides all parameter meanings. It explains pin_type with examples ('float, vec3, color, etc.'), direction as 'input' or 'output', and the three node identification methods. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add', the resource 'typed dynamic pin', and the context 'scratch pad graph'. It specifies that it works with Custom HLSL, Map Get, Map Set, or any node inheriting from UNiagaraNodeWithDynamicPins, distinguishing it from more specific sibling tools like add_niagara_map_get_pin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to add a pin to dynamic nodes) and how to identify the target node via exactly one of node_class, node_index, or node_id. It lists required and optional parameters but does not explicitly state when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description explains parameters but does not disclose behavioral traits such as whether results are sorted, if duplicates are possible, or if the list includes only materials currently used. The 'use sparingly' note on max_results=0 provides minor behavioral insight, but overall depth is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose sentence followed by a labeled Args section. Every sentence adds value, and it is front-loaded with the main action. No redundant phrasing.
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 presence of an output schema (not shown), the description does not need to detail return values. However, it lacks clarification on what 'available' means (e.g., only in content browser, or including those in maps). It is mostly complete for a list tool with good sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains each parameter: search_path (root to scan), include_engine_materials (include engine materials), filter (case-insensitive substring), max_results (cap). This provides meaningful context 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 'List materials that can be applied to objects' which is a specific verb+resource. It distinguishes from siblings like 'create_material' (creates) and 'apply_material_to_actor' (applies), making its role 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 the tool is for listing materials, but does not provide explicit guidance on when to use this over alternatives (e.g., 'get_material_info' for details, 'search_material_functions' for functions). No exclusions or when-not-to-use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or non-destructive, nor does it mention potential errors (e.g., invalid system path). The 'get' prefix implies reading, but the description should be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line summary followed by a brief explanatory sentence and a bulleted parameter list. Every sentence adds value, and it is front-loaded with the primary 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?
An output schema exists, so the description need not detail return values. It adequately covers purpose and parameters, though a brief hint about the output structure (e.g., 'returns list of outdated modules with versions') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for 0% schema coverage by providing clear, concise meanings for each parameter: system_path, emitter_name, and an optional filter with examples. This adds significant value beyond the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for outdated modules in an emitter and lists available versions, specifying it identifies a common source of Niagara warnings. It distinguishes from siblings by focusing on version updates rather than listing all modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to find modules that need upgrading,' providing clear context for when to invoke. However, it doesn't mention when not to use or alternative tools, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'compact overview' and lists return elements, but does not confirm read-only nature or mention performance, permissions, or side effects. Basic but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line for purpose and one line for the argument. No unnecessary words, front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema (not shown), the description provides enough for basic use. It outlines returned categories but could detail format; however, output schema likely covers missing specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning to 'asset_path' as 'Content path to the StateTree asset', which clarifies its role. Could benefit from format or example, but adequate compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get compact overview of a StateTree' and lists specific content (schema, state count, evaluator count). This distinguishes it from sibling tools that retrieve detailed parts like states or evaluators.
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 like get_statetree_full_info or get_statetree_states. The description implies a quick overview, but lacks when-not or alternative 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 burden. It says 'running and responsive' but does not define what 'responsive' means (e.g., timeout, ping). No side effects are mentioned, but it is a read-only 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?
One sentence of 10 words, front-loaded with the key action. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description is adequate. It does not explain the return format, but the output schema likely covers that. For a simple health check, this is sufficiently 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?
No parameters, so schema coverage is 100%. Description adds no parameter info, but for zero-parameter tools, a baseline of 4 is appropriate. The description explains the tool's purpose, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the UE5 editor bridge is running and responsive, which is a specific verb+resource that distinguishes it from the many sibling tools focused on specific assets or 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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident as a health check. It does not provide when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns a list of modifier types with specific fields (name, display_name, parent class, editable properties). This makes the read-only nature clear. However, it does not mention the optional filter parameter or any performance implications, which is a minor 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 extremely concise: two short sentences. The first sentence states the core purpose, and the second adds the use case and return details. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and an output schema. The description covers return fields but misses explaining the filter parameter. For a simple list tool, the description is mostly complete but the missing parameter explanation reduces completeness.
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 has 0% schema description coverage and does not mention the 'filter' parameter at all. The user has no guidance on how to use the filter, which is a significant omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available UInputModifier subclasses and their editable properties, and that it's useful for discovering valid modifier_type values. It distinguishes this tool from siblings like list_trigger_types and list_input_keys by specifying the focus on modifiers.
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 indicates the tool is useful for discovering valid modifier_type values, implying it should be used when you need to know what modifier types are available. It does not explicitly mention when not to use it or name sibling alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the action (remove) without detailing side effects, permissions, or whether changes are persistent. It does not disclose that it modifies the IMC asset or any potential destructive nature beyond the act of removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a bulleted list of args. No unnecessary words or redundancy. Structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters and no schema descriptions, the description adequately explains the two removal methods and param semantics. It does not mention prerequisites or return values, but output schema exists and purpose is clear. Could be more complete with notes on persistence or undo.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It describes all 4 parameters: context_path as path to IMC, index as mapping index from get_input_mapping_context, and action_path/key as alternative combo. This adds context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a key mapping from an Input Mapping Context, and specifies two removal methods. This distinguishes it from sibling tools like add_key_mapping or set_key_mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains removal by index or by action_path+key combination, and notes that index comes from get_input_mapping_context. It provides clear guidance on how to use, though does not explicitly state when to use this tool over others like remove_mapping_trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does not disclose behavioral traits such as error handling, side effects, or permissions. However, the operation is straightforward (removing a parameter), so score 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 extremely concise with no unnecessary words. It gets straight to the point with the action and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, the description is mostly complete. However, it does not mention any prerequisites or the effect of removing a parameter that might be in use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no param descriptions in schema). The description adds meaning by specifying 'asset_path: Content path to the StateTree asset' and 'name: Parameter name to remove', compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'tree-level parameter by name'. It distinguishes from sibling tools like 'add_statetree_parameter' and other remove operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides arguments but lacks explicit guidance on when to use this tool versus alternatives like 'remove_statetree_state' or 'remove_statetree_node'. Usage is implied but not explicitly contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it modifies editable properties on CDO and accepts JSON-compatible values. However, it does not mention whether changes persist immediately, if the blueprint needs to be loaded, or if there are side effects like triggering recompilation. The transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary, scope clarification, usage modes, and an Args list. Every sentence adds value without redundancy. Front-loaded with purpose, then details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, but has output schema), the description covers main functionality and parameter usage. Missing some contextual details like prerequisite (blueprint must be loaded) and whether changes auto-save, but overall sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates well. It explains blueprint_path format, the role of property_name/property_value for single setting, and properties dict for batch. It adds the 'JSON-compatible' constraint for values. However, it does not detail allowed types for property_value (e.g., nested objects) or keys in the properties dict, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool sets default property values on a Blueprint's generated class CDO. It clarifies scope (works on all editable properties including C++ parent and BP-defined) and differentiates from siblings like get_blueprint_class_defaults and set_blueprint_variable_properties by focusing on defaults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes (single property vs. batch via dict) but does not explicitly state when to use this tool over alternatives like set_blueprint_variable_properties or set_asset_property. No when-not-to-use guidance is provided, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that enabling shows a header and disabling clears stats, but does not mention persistence, session scope, performance impact, or required permissions. The description is decent but lacks detail on behavioral boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and provides an illustrative example of the output header. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one boolean parameter) and the description explains its behavior adequately. It does not mention whether the setting persists across sessions, but the presence of an output schema reduces the need to describe return values. Minor gap: no mention of scope or lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single boolean parameter, but the tool description explicitly explains that 'enabled=True enables, False disables and clears stats', adding critical semantic meaning beyond the schema's default 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 tool enables or disables token debug estimation on MCP responses, specifying the effect when enabled (shows a token debug header) and disabled (clears accumulated stats). It uses a specific verb-resource pairing and distinguishes from sibling tool 'get_mcp_token_stats' which gets stats rather than setting debug mode.
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 toggling token debug output but does not explicitly state when to use this tool versus alternatives like 'get_mcp_token_stats'. No when-not or contextual exclusions are provided, leaving the agent to infer usage from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of disclosing side effects. It details the entire process: finding the override pin, breaking connections, removing orphan nodes, and removing the pin from the ParameterMapSet. It also references the internal engine function, leaving no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise one-line purpose, followed by a detailed but clear step-by-step explanation, then an important usage note on nested paths, and a reference to internal code. It could be slightly more concise, but every sentence adds value and it is not verbose.
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 behavioral details are thorough, the description omits descriptions for 4 out of 5 parameters, which is a significant gap for a tool with 5 required inputs. The presence of an output schema (not shown) might explain return values, but the parameter documentation gap reduces completeness. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 required parameters with no descriptions (0% coverage). The description only explains input_name in detail with a nested path example. The other four parameters (system_path, emitter_name, module_name, script_usage) are not mentioned, leaving the user to infer their meaning. This is insufficient compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reset' and the resource 'module input', and explicitly equates it to the UI action 'Reset to Default'. This distinguishes it from siblings like set_niagara_module_input and set_niagara_dynamic_input, which modify instead of resetting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the internal steps and supporting nested path syntax, which helps the user understand how to use it precisely. However, it lacks explicit when-not-to-use guidance or alternatives, though the purpose is evident from the detailed behavioral description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the core behavior (listing actors) but does not mention details like performance, visibility filters, or whether hidden actors are included.
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 resource, no extraneous words. 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?
Given the tool has an output schema, the description does not need to detail return structure. The minimal description is adequate for a simple list operation, though it could mention if any filtering applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters exist, so description adds value beyond schema by clarifying the scope ('current level'). Schema coverage is 100% (empty schema), and description provides essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all actors in the current level', identifying a specific verb (list), resource (actors), and scope (current level). It distinguishes from sibling tools like get_selected_actors and find_actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives. However, the purpose is self-explanatory, so usage context is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains that include_schema includes 'massive structural type schemas,' warning about response size. It does not mention side effects (none anticipated) or access requirements, but covers the main behavioral trait well.
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 structured with a concise summary sentence followed by a parameter list. It is slightly lengthy due to parameter descriptions but remains front-loaded and easy to scan. No wasted sentences.
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 an output schema (not shown), so return values are documented elsewhere. The description effectively warns about potentially large responses via include_schema. It covers the core functionality and parameter semantics, making it complete enough for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It describes all 6 parameters in the docstring, adding meaning beyond the raw schema (e.g., 'Optional substring filter on input parameter names'). However, it could provide more detail on expected values (e.g., valid script_usage options).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all input parameters for a specific module,' which is a specific verb-resource pair. This tool is distinct from sibling tools like set_niagara_module_input or get_niagara_module_input_binding.
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 lists required parameters but does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_niagara_module_input for a single input, or set_niagara_module_input to modify). Usage is implied but not clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes a read operation (get info) but does not explicitly state safety, side effects, or authorization needs. The description is adequate but could be more transparent about being read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an Args list. It is front-loaded with the main purpose and structured clearly. Minor waste: 'Args:' prefix is unnecessary but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the StateTree system and the presence of an output schema (not shown), the description covers the key aspects: what information is returned and how to identify the state. It could mention error handling or return behavior, but is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by providing meaningful details for each parameter: asset_path is a content path, state is an index path with examples, state_name is case-insensitive, state_guid is a GUID string. This adds significant context beyond the schema's types and requiredness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Get detailed info for a single state: properties, tasks, conditions, transitions.' It also specifies three identification methods (index path, name, GUID), which distinguishes it from siblings like get_statetree_states that list all states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to identify the state (by index path, name, or GUID), which implicitly guides the agent on when to use this tool (when a specific state is needed). However, it lacks explicit guidance on when not to use it or alternatives for listing states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool lists available FKey values and describes filtering parameters (filter, category, max_results) clearly. While it does not specify that the operation is read-only, the 'list' verb implies no side effects, and the parameter details add 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 concise: a single sentence stating the purpose followed by a compact argument list. No unnecessary words or repetition. Every sentence earns its place, making it easy to scan quickly.
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 that an output schema exists, the description does not need to specify return values. It covers the basic context of listing keys. However, it could briefly mention that the keys come from the engine's input system, but it is adequate for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by explaining each parameter's purpose and default values. It clarifies that 'filter' is a substring filter on key name or display name, 'category' filters by category type, and 'max_results' controls the limit. Since schema coverage is 0%, this is essential and well-done.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 available FKey values for keyboard, mouse, and gamepad keys. The verb 'List' and resource 'FKey values' are specific, and the tool is easily distinguishable from sibling tools that deal with other input actions or different systems.
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. Although sibling tools include many input-related functions (e.g., create_input_action, get_input_action), the description does not mention that this tool can be used to obtain valid key names for those operations. No when-not or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it returns exact dropdown options from the editor, details output structure (input_type, dynamic_inputs, link_parameters), and explains the underlying discovery mechanism (FNiagaraEditorUtilities::GetFilteredScriptAssets, etc.). No contradictions or gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and output structure, then provides implementation details in a structured list. It is concise for the complexity but includes low-level internal function names that may not be necessary. Overall, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema has no descriptions, no annotations, but an output schema exists, the description adequately covers the tool's behavior and output. It explains the output fields in text, bridging the gap. However, it lacks guidance on error handling or edge cases (e.g., invalid input_name). Still sufficient for a read-only list tool.
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?
Despite 0% schema coverage (no parameter descriptions in input-schema), the description does not explain individual parameter semantics. It mentions 'target input' and 'input_name' but does not define required fields like system_path, emitter_name, module_name, or script_usage. The context of the UI dropdown partially compensates, but the agent would need additional knowledge to map parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Reproduce the stack-UI source dropdown for a specific input.' It provides specific verb ('reproduce'), resource ('stack-UI source dropdown'), and context ('for a specific input'). This clearly distinguishes it from sibling tools like set_niagara_dynamic_input or list_niagara_modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to see the options available for a Niagara module input's source dropdown. It also hints at a follow-up action by noting that dynamic_inputs have script_path ready to pass to set_niagara_dynamic_input. However, it does not explicitly state when not to use it or mention alternatives beyond that implied chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is non-destructive (diagnoses), categorizes nodes, and returns a boolean `healthy`. It does not detail authorization needs or side effects, but the behavior is adequately explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, bullet-like categorization, and a clear return value indication. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description satisfactorily explains the return logic. However, the lack of parameter documentation is a minor gap. Overall adequate for a single-parameter diagnostic tool.
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 only parameter `material_path` has no schema description (0% coverage) and the description adds no additional meaning. It does not specify the expected format or context, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 as diagnosing connection issues in a material graph. It lists specific node categories (orphaned, dead_ends, etc.) and their definitions, distinguishing it from sibling tools like `cleanup_material_graph` and `get_material_errors`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining the tool's diagnostic role. It does not explicitly state when to avoid using it or name alternatives, but the context of sibling tools provides some 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 provided, so description carries full burden. It discloses that any module's parent class is supported and lists input formats, but does not mention potential errors, permissions, or behavior on invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: first states purpose, second broadens scope, third provides critical usage hint. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers the main aspects: what it does, parent class formats, and prerequisite tool. Could mention that the blueprint is created at the specified path in the content browser.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by thoroughly explaining the parent_class parameter with examples. However, name and path parameters get no extra meaning beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new Blueprint asset' and the resource, distinguishing it from sibling creation tools like create_material or create_data_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using search_parent_classes first for finding the correct parent class name, and details acceptable formats for the parent_class parameter. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 behavioral disclosure. It does not explicitly state idempotency or safety (e.g., read-only), though 'Search' implies non-destructiveness. The parameter defaults (recursive=true, max_results=200) are disclosed, but no error or permission information is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence followed by an 'Args' list. It is not overly verbose; every parameter explanation is useful. Minor improvement could be trimming the list of examples for class_type, but overall it earns its length and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, and no annotations, the description covers all essential aspects for usage. It explains each parameter's semantics and defaults. Since an output schema exists (indicated by context signals), the lack of return value explanation is acceptable. The description is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides rich semantics: examples for class_type (shortcuts and 'PackagePath.ClassName'), path ('/Game/Materials'), name_pattern (case-insensitive substring match), and explains defaults for recursive and max_results. This is far beyond what the schema offers (type + default only).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Search the Asset Registry by class, path, and/or name pattern.' This specifies the verb (search), resource (Asset Registry), and criteria (three dimensions). The tool is well-distinguished from siblings like 'list_assets' or 'find_references' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details the parameters and their defaults, enabling the agent to understand how to tailor searches. It implies usage via the search criteria but lacks explicit guidance on when to prefer this over alternatives like 'list_assets' or 'find_references'. However, the context is clear for a filtered-search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses read-only nature, verbosity control, and type_filter behavior. Missing info on error conditions or permissions, but sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, structured bullet points for verbosity. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description explains response size control and filtering. Minor gap: no mention of what constitutes a valid material_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining verbosity values and type_filter substring matching. However, material_path is not explicitly described beyond the purpose statement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read expression nodes in a material graph' with a specific verb and resource, distinguishing it from sibling tools that add, delete, or modify nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on verbosity levels with token estimates and type_filter usage, but lacks comparison to alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves all Niagara actors in the current level, which is a read operation. While it doesn't detail the return format, the presence of an output schema reduces the need. The description is clear and sufficiently transparent for this type of tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. Two sentences: the first states the core purpose, the second explains the only parameter. It is front-loaded and easy to parse.
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 that an output schema exists, the description does not need to detail return values. It covers the tool's main action and the optional filter. It could marginally improve by clarifying what 'Niagara actors' encompasses (e.g., all spawned Niagara effects), but overall it provides sufficient context for an agent to decide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage). The description adds the meaning: 'Optional filter on the Niagara System name or path'. This gives the agent useful context beyond the schema's type info, though it could be more specific about matching behavior (substring/regex).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Get all Niagara actors in the current level.' It specifies the verb 'Get', the resource 'Niagara actors', and the scope 'current level'. An optional filter parameter is also mentioned, which distinguishes it from generic actor-finding tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to get Niagara actors in the current level) but does not explicitly state when not to use it or suggest alternatives. Given the large set of sibling tools, some guidance on differentiation would be helpful, though the purpose alone often suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the introspection method ('Walks the CDO via the modular FProperty introspector') and details the returned fields. It clearly indicates a read operation without side effects, though it omits error handling info for invalid class names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, details on coverage, return field list, and argument section. It is slightly verbose with the enumeration of DI types but effectively front-loads the purpose. Every sentence adds value with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 param, output schema exists, no nested objects), the description provides a thorough overview of return fields and usage. However, it lacks details on error conditions (e.g., nonexistent class) and does not mention the output schema structure explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% schema description coverage (no descriptions on parameter properties). The description fully compensates by explaining the class_ parameter, including that the 'UNiagaraDataInterface' prefix is optional, and providing examples. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Return the full editable-property schema of a UNiagaraDataInterface subclass', which is a specific verb and resource. It lists many example DI types and distinguishes from sibling tools like list_niagara_data_interfaces by focusing on schema retrieval for a single DI.
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 says 'Use to discover what fields a DI supports before configuring or instantiating one', which implies appropriate context. However, it does not provide explicit when-not-to-use guidance or mention sibling tools like list_niagara_data_interfaces for listing available DIs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the resolver modes and filter behaviors (verbosity, type_filter, name_filter) but does not explicitly state that the tool is read-only or non-destructive. The output schema is assumed to handle return format, but some gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence followed by a clear list of parameters and modes. It is slightly verbose but every sentence adds value; it could be more concise but remains 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's complexity (8 parameters, 3 modes) and lack of schema descriptions, the description is quite complete. It covers modes, parameters, filters, and offers examples. It does not mention prerequisites or side effects, but the output schema presumably covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently by explaining all 8 parameters in a structured manner, including the three modes, verbosity options, and filter substring matching. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Introspect every node inside a Niagara graph.' It distinguishes from sibling tools like get_niagara_node_info by indicating it returns all nodes and specifies three resolver modes for different contexts (scratch pad, emitter stack, standalone script).
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 defines three modes of use, each with specific parameter combinations, providing clear context. However, it does not explicitly exclude alternatives or state when not to use this tool, though the differentiation from other Niagara introspection tools is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('inspect') and mentions 'stable per session' for node_index, but does not explicitly state safety (non-destructive), permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a line about parameter selection, and a bullet list of arguments. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description adequately covers purpose, parameter selection, and alternative resolution methods. It could mention prerequisites (e.g., valid Niagara system) but is largely complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful details: it explains mutual exclusivity for node_index/node_class/node_id, gives examples ('MapGet') and format (FGuid), and clarifies the role of system_path/module_name and script_path. Some parameters (system_path, module_name, script_path) are described only briefly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Deep inspect a single Niagara node: full pin layout, connections, type-specific detail.' This distinguishes it from siblings like 'get_niagara_graph_nodes' which lists all nodes, as this tool provides detailed inspection of one node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that exactly one of node_index/node_class/node_id must be provided, and outlines alternative resolution methods (system_path+module_name or script_path). However, it does not explicitly contrast with other Niagara tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return structure (name, type, value_type) and parameter options, but does not explicitly mention that the operation is read-only or any prerequisites. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary followed by parameter details. It is concise yet informative, though it could be slightly shorter by removing the sample values from the filter example.
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 existence of an output schema, the description does not need to explain return values. It adequately covers the three parameters and their usage. However, it lacks information about error conditions or behavior when both system_path and actor_name are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the parameters beyond the input schema, which only lists types and defaults. It explains system_path as 'Path to the Niagara System asset', actor_name as 'Name of an actor in the level with a NiagaraComponent', and filter as 'Optional name filter (e.g. "Color", "Intensity", "Size")'. This fully compensates for the 0% 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 'Get user-exposed parameters from a Niagara System asset or a level actor's component.' It specifies both the action and the resources, distinguishing it from sibling tools like set_niagara_user_parameter and add_niagara_user_parameter.
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 guidance: 'Provide either system_path (asset) or actor_name (level instance). Use filter to narrow by parameter name substring.' However, it lacks explicit statements about when not to use this tool versus alternatives like get_niagara_module_inputs.
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 convey behavioral traits. It states 'get' indicating a read operation but lacks details on permissions, side effects, or whether it requires an active editor session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and free of extraneous words, clearly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters and presence of an output schema, the description is mostly complete. Minor omission: it does not specify that the selection is from the Content Browser or if it requires the browser to be open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0), so schema coverage is 100% trivially. With 0 parameters, baseline is 4; the description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource ('currently selected assets in the Content Browser'), clearly distinguishing it from siblings like 'get_selected_actors' and 'list_assets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the current selection in the Content Browser, but does not explicitly state when to avoid it or mention alternatives like 'list_assets'.
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 disclose behavioral traits. It mentions the JSON tree output and the recursion behavior controlled by max_depth, but does not discuss side effects, performance implications, or read-only nature. The disclosure is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise overview, parameter usage explanation, and an Args section. It is appropriately sized for the complexity, though some might argue the Args section is slightly redundant. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It adequately covers the tool's behavior and parameter usage. It is complete for a retrieval tool, though it could be enhanced with a brief note about permissions or performance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it explains the purpose of asset_path (content path), max_depth (recursion control with specific values), and name_filter (case-insensitive substring match). The schema has 0% description coverage (meaning the schema itself lacks descriptions), so the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get state hierarchy as a JSON tree' and specifies the contents (name, type, ID, task/transition counts). It distinguishes from sibling tools like get_statetree_state which likely returns a single state, by focusing on the hierarchical tree structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use max_depth and name_filter, providing clear examples (e.g., '0=roots only, 1=roots+children, -1=unlimited'). However, it does not explicitly state when not to use this tool or mention alternative tools for different needs, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the live scan and filtering but does not mention side effects, permissions, performance, or error handling. The read-only nature is implied but not stated, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, context paragraph, and parameter list. It is front-loaded with the key action. However, it could be slightly more concise by removing redundant phrasing.
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 an output schema, the description does not need to detail return values. It adequately covers parameters and purpose. However, it lacks behavioral details like whether the scan is cached or can fail, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter: name_filter (case-insensitive substring), exact_name (exact match), and max_results (cap, default 20). It adds meaningful usage context 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 that the tool discovers built-in dynamic-input script asset paths via AssetRegistry, replacing guessed paths. It specifies the resource (UNiagaraScript assets with Usage=DynamicInput) and the action (live scan). This distinguishes it from sibling Niagara tools like list_niagara_modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool replaces guessed paths that vary across UE versions, providing context for when to use it. However, it does not explicitly state when not to use it or contrast with alternative sibling tools for asset discovery, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It reveals the tool performs 'one load + one save,' implying a two-step operation. However, it does not detail error handling, idempotency, prerequisites (e.g., asset must exist), or merging 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 extremely concise: two sentences with no superfluous words. It front-loads the key purpose and efficiency benefit, making it easy for an AI agent to quickly grasp the tool's value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two params, with output schema available separately) and the reference to the sibling for value format, the description covers the essential aspects. Minor gaps exist, such as not explaining that properties keys must be valid property names, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by stating that the properties field uses the 'same value format as set_data_asset_property,' which clarifies the structure of the properties object. Asset_path is not elaborated, but the parameter name is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets multiple properties in a single call, distinguishing it from the sibling set_data_asset_property which handles one property at a time. The verb 'set' and resource 'data asset properties' are specific, and the efficiency advantage is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'More efficient than calling set_data_asset_property in a loop,' indicating when to use this tool. It also notes the same value format as the sibling. However, it does not provide explicit when-not-to-use scenarios or alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool modifies properties, but does not mention side effects, permissions, error conditions, or undo behavior. The parameter explanations add some transparency, but deeper behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief introductory sentence followed by a well-organized list of parameters. It is not overly verbose, though the parameter list is detailed. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (2 required) and an output schema, the description covers all parameters with useful hints (e.g., node_index from get_material_function_info). It lacks information on error handling or constraints, but for a modification tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no schema-level descriptions). The description compensates fully by explaining every parameter, including type and meaning (e.g., 'New pin name', 'New type (Scalar/Vector2/...)', and an example for preview_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 tool modifies an existing FunctionInput node's properties, using the verb 'Modify' and specifying the resource ('FunctionInput node'). It distinguishes from sibling 'add_material_function_input' which adds a new input, and 'set_material_function_output' for outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing input node, but does not explicitly state when not to use it or provide alternatives. It lacks exclusions or prerequisites, though the clear contrast with sibling 'add' tools is helpful.
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 and discloses behavioral traits: pin creation as needed, use of schema APIs and reflection, signature rebuilding, and the effect of clear_existing_pins. It could mention permissions or error handling, but overall is transparent about internal workings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a single paragraph followed by a bullet-style Args list. It could be more structured (e.g., separate sections), but the information is efficiently presented without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required) and no annotations, the description covers most aspects: purpose, parameter details, and internal process. It assumes the node exists and doesn't mention prerequisites like loading the system. However, an output schema exists, so return values are not required here. Overall, fairly complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must add meaning. It does so thoroughly with an Args block explaining each parameter, including the structured format for inputs and outputs as lists of {name, type} objects with examples. This goes well beyond the raw schema and enables correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set HLSL source on a scratch pad module's Custom HLSL node, creating pins as needed.' It provides a specific verb and resource, and clearly distinguishes from sibling tools like add_niagara_custom_hlsl_input or rename_niagara_custom_hlsl_pin by focusing on the holistic operation of setting the HLSL code and managing pins.
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 setting HLSL code on a scratch pad module but does not explicitly state when to use this tool versus alternatives like add_niagara_custom_hlsl_input or when not to use it (e.g., if only minor pin adjustments are needed). No exclusions or context for choosing this tool 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?
No annotations provided. Description indicates a write operation ('Set') via reflection. However, it does not disclose potential side effects (e.g., requires asset to be writable, changes may need saving, or error conditions if property not found). Basic transparency but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence for purpose, a list of property examples, and a clear Args section. No wasted words, easy to parse.
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 presence of an output schema (not shown), the description does not need to detail return values. It covers the tool's action and parameters adequately. Could mention that changes are not automatically saved, but overall complete for a setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in Args: system_path (path to asset), property (exact PascalCase name), value (string). Examples for value (e.g., '2.0', 'true') add clarity beyond the schema, which only specifies types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set a system-level property on a Niagara System via reflection.' Lists specific properties (WarmupTime, bDeterminism, etc.) and uses exact C++ property names. Distinguishes from sibling Niagara tools that operate at emitter or module level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains usage by listing supported properties and requiring exact PascalCase names. Provides examples like 'WarmupTime', 'bDeterminism'. While not explicitly excluding other tools, the context implies it's for system-level properties, which is distinct from emitter/module-specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains that compilation may block (via wait_for_completion parameter) and reports errors. Without annotations, this covers key behavior. However, lacks details on side effects (e.g., does compilation modify the asset? Are errors stored?)
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?
Extremely concise: two sentences plus two parameter lines. No redundant or missing information. Every sentence is necessary.
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 an output schema exists, the description adequately covers the action. Still, it could mention that compilation validates and may report errors, but lacks context on prerequisites (e.g., system must exist) or consequences (e.g., potential asset modification).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides clear semantics for both parameters: system_path is the asset path, wait_for_completion blocks until finish. Adds meaning beyond type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb 'Compile' and resource 'Niagara System' with the outcome 'report any errors'. Distinguishes from siblings like get_niagara_system_errors (which reads errors without compiling) and compile_statetree (different asset type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage is for compiling a Niagara system, but does not explicitly state when to use this tool vs alternatives like get_niagara_system_errors or validate_niagara_graph. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: error if asset exists, and force flag to delete and recreate. It does not mention permissions or side effects, but covers the main creation behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief headline, a note on error handling, and a structured Args list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers creation behavior, parameter meanings, and error handling. Minor omissions like prerequisites are acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the Args section provides detailed explanations for all 5 parameters, including examples and purposes. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Material Function asset' using a specific verb and resource. It distinguishes from sibling tools like create_material and create_material_instance by specifying 'material function'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as create_material or create_material_instance. The name implies it is for functions, but the description does not clarify selection criteria.
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. It explains the template duplication process, fallback to minimal graph, and the resulting graph structure (Input/MapGet/MapSet/Output). Missing return value details, but the behavioral insight is strong.
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 front-loaded with the purpose, followed by a concise behavioral paragraph and a clear Args list. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema documentation and not explicitly stating constraints like uniqueness or error conditions, the description covers the main workflow, template handling, and parameter details. For a tool with moderate complexity and many siblings, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's Args section fully compensates: it explains system_path as 'Niagara System asset path', module_name as 'Desired scratch script name (unique within the system's ScratchPadScripts)', and module_type with its three enumerated values and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first line clearly states 'Create a new scratch pad script on a Niagara System.' This specific verb+resource combination, along with the detailed explanation of template duplication and fallback behavior, strongly distinguishes it from sibling tools like duplicate, delete, or rename.
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 explaining it creates from a template, but it does not explicitly contrast with siblings like duplicate_niagara_scratch_pad_module. An explicit 'when to use vs alternatives' statement is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses destructive nature, reference-checking behavior, and path interpretation. It does not mention permissions or error handling, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero fluff. Front-loaded with the main action, then key details and nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of output schema, the description covers all critical aspects: action, reference-checking, path rules. Does not mention return values (handled by schema) or error cases, but is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains force: 'Checks for references first unless force=True' and asset_path: 'Paths without a dot are treated as directories.' This adds clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool deletes an asset or directory from the Content Browser, with specifics about reference checking and path interpretation. Distinguishes from siblings like delete_actor or delete_data_table_row by focusing on assets/directories.
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 (to delete assets/directories) but does not explicitly state when not to use or mention alternative tools. The reference-checking behavior gives some guidance, but no exclusions or comparisons 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?
With no annotations, the description carries the full burden. It describes the tool as a read operation (get) that reads the CDO and returns properties. However, it does not explicitly state that it is non-destructive or any potential side effects. The behavior is adequately described but not fully 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 concise and well-structured: a one-sentence main purpose, a comparison sentence, then a bullet list for parameters. Every sentence adds value without redundancy. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return format. It explains the tool's scope (all editable properties including inherited), the key differentiator from a sibling, and parameter usage. This is sufficient for an agent to correctly select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for two of three parameters: 'filter' and 'include_inherited'. The required 'blueprint_path' is not explicitly described but is self-explanatory from context. The descriptions add meaning beyond the schema, especially the case-insensitive note for filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 its purpose: 'Get all default property values from a Blueprint's generated class CDO.' It uses a specific verb and resource, and distinguishes itself from the sibling tool 'get_blueprint_variable_details' by explaining that this tool includes C++ parent properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly compares with 'get_blueprint_variable_details' to guide when to use this tool over that one. It does not provide when-not-to-use scenarios, but the alternative is clearly named and contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavior. It discloses that the tool is non-destructive, describes return content, and warns that MaterialFunctionCall without function_path returns empty pins. This is thorough, though it omits potential error conditions or performance notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet-pointed special cases, and argument details. It is informative without being verbose, though a slight reduction in repetitive phrasing could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose, usage, and special cases without needing to detail return structure. It feels complete for a lookup tool, though it could briefly mention that it works for material expression nodes (inferred from sibling tools).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds critical context: it explains type_name with examples, and function_path as specific to MaterialFunctionCall with an example path and behavioral implications. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up pin names and editable properties without creating a node, and specifies what it returns (input/output pins, properties with types and defaults). It distinguishes itself from creation tools by emphasizing 'WITHOUT creating one', and covers special node types, which clarifies its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this BEFORE creating nodes to avoid connection errors, and for MaterialFunctionCall it advises using search_material_functions first. It covers when to use and key prerequisites, but lacks explicit when-not-to-use guidance for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it returns start/end time and frame rate, which implies read-only behavior. Does not disclose side effects or permissions, but for a simple getter, 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?
Four sentences, each serving a purpose: purpose statement, return values, use case, parameter description. No redundant words, well-organized.
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?
Tool is simple with one parameter. Description covers purpose, usage, parameter, and return values (partially via output schema). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'system_path' has no schema description (0% coverage). The description's Args section adds 'Path to the Niagara System asset', providing essential meaning beyond the schema's type 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?
Description clearly states it retrieves the timeline playback range and frame rate settings. Specifies verb 'Get' and resource 'current timeline playback range and frame rate settings'. Distinguishes from sibling 'set_niagara_playback_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'Use to check if the playback range is too short (common cause of effects appearing to not play)'. Does not mention alternatives or when to avoid, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns issues from compilation and validation, implying a read-only operation. No contradictions. But it lacks details on potential side effects, idempotency, or exact output format. 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?
Well-structured and concise. First sentence states purpose, second describes return, third gives use cases, then a clean list of parameters. No wasted sentences. Front-loaded with most important info.
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 presence of an output schema (though not shown), the description adequately covers the purpose, parameters, and use cases. It does not mention error handling or pagination, but for a diagnostic tool, this is likely sufficient. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section that explains each parameter (system_path, emitter_name, severity) with their meaning, types, and defaults. This adds critical meaning not present in the schema, which only has types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get compilation errors, warnings, and validation issues for a Niagara System.' It uses a specific verb (Get) and resource (Niagara System errors), distinguishing it from sibling tools like compile_niagara_system (which compiles) and get_niagara_system_info (which gets general info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'Use to diagnose why a system isn't working, find outdated modules, or check for configuration problems.' However, it does not mention when not to use or explicitly compare to alternatives, though the context is clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description clearly identifies the tool as a read-only getter with no side effects. The behavior is straightforward, but it doesn't elaborate on the return format or whether it returns a snapshot or live references. Given the simplicity, 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 10 words, front-loaded with the key action and resource. Every word is meaningful, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and the existence of an output schema (which handles return value documentation), the description is complete. It conveys the essential purpose and scope without needing further elaboration.
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 100% schema description coverage. According to the guidelines, a 0-parameter tool receives a baseline of 4. The description adds no parameter information, which is acceptable because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Get', the resource 'selected actors', and the scope 'in the editor viewport'. It distinguishes itself from sibling tools like 'get_selected_assets' and 'find_actors' by focusing on the current selection in the viewport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to obtain currently selected actors, but it does not explicitly mention when to use this tool versus alternatives like 'find_actors' or 'get_actors_in_level'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the behavioral aspects of the three verbosity levels and section filters, explaining what data is returned at each level. However, since no annotations are provided, the description carries full burden; it lacks mention of side effects, read-only nature, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the core purpose, then detailing verbosity levels in a bullet-like format, followed by section options and parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and many sibling tools, the description sufficiently covers the tool's functionality, parameters, and output granularity. It does not need to repeat return value details. A minor gap is the lack of a note confirming the operation is read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so effectively, listing asset_path, verbosity with three explicit options, and sections with clear examples and syntax ('comma-separate multiple sections'). This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get complete StateTree data in one call with verbosity control,' specifying the verb (get) and resource (StateTree data). It differentiates itself from sibling tools that retrieve individual parts (e.g., get_statetree_states, get_statetree_evaluators) by offering a combined call with flexible verbosity and section filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for complete data with verbosity control) and how to use it via verbosity levels and sections. It implicitly contrasts with sibling tools by offering a single-call alternative, but it does not explicitly state when not to use it or directly compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description implies read-only behavior but does not explicitly state non-destructive nature, auth needs, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with zero redundancy, effectively conveying tool purpose and parameter usage.
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?
Adequately complete for a listing tool with an output schema; no additional details needed as output schema handles return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful parameter descriptions (filter narrows results, max_results limits, include_details controls compactness) beyond the schema, compensating for 0% 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 'List available material expression node types' with a specific verb and resource, distinguishing it from sibling tools like get_material_expression_info and add_material_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance for each parameter (filter, max_results, include_details), though lacks explicit comparison to alternatives or when-not-to-use cases.
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 disclosure. It explains that the tool records profiling data to a .utrace file and that stopping auto-loads for analysis. Missing details include whether it overwrites existing files, any prerequisites, or potential side effects on performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, parameter details, and usage example. The channels list is somewhat extensive but necessary for clarity. It could be slightly more concise, but overall it is focused and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional parameters and an output schema exists, the description is complete. It explains the core functionality, parameter options, and the pairing with performance_stop_trace. No critical information is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by explaining the purpose and behavior of both parameters. For file_path, it clarifies that an empty value auto-generates a path. For channels, it lists presets, individual channels, and provides a full example. This fully compensates for the 0% schema description 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 that the tool starts recording a performance trace from the Unreal Editor, specifies the data types recorded (CPU, GPU, frame timing), and the output file format (.utrace). It distinguishes itself from sibling tools like performance_stop_trace and performance_analyze_insight by positioning itself as the starting point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to stop the trace by calling performance_stop_trace and includes examples for channel presets. However, it does not explicitly state when to use this tool vs. alternatives or when not to use it, though the context implies it is the primary profiling start tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses atomic operation, default clearing behavior (clear_existing=true), and detailed structure of nodes and connections. No annotations provided, so description bears full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, interface comparison, then detailed node/connection specs. Length is justified by complexity, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: purpose, parameters, node types, connection format. Output schema exists so return values not needed. Missing any mention of prerequisites or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully compensates by explaining each parameter including function_path, nodes (with node types and fields), connections, and clear_existing default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Build the internal node graph of a Material Function in one atomic call', specifies verb and resource, and distinguishes from sibling 'build_material_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for Material Functions with same interface as build_material_graph, implicitly guiding when to use it, but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavior: returns error if asset exists, force=true deletes and recreates. It also lists all parameters with allowed values. Since no annotations are provided, the description carries the full burden and covers safety and mutation well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and error behavior. The Args section is well-structured but slightly lengthy. Every sentence adds value, though some parameter descriptions could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description doesn't need to detail return values. It covers creation, error handling, and all parameters. For a material creation tool in a game engine context, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool's description provides detailed explanations for all 7 parameters, including default values and valid options (e.g., blend_mode enum values). This adds significant value beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Material asset, distinguishing it from sibling tools like create_material_instance. The verb 'Create' and resource 'Material asset' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the force parameter (to delete and recreate if asset already exists) and implies when not to (to avoid overwriting the editor popup). However, it does not explicitly compare to sibling tools or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: creation from a parent, error on existing asset, and destructive behavior of 'force'. With no annotations provided, the description carries the full burden and adequately informs about side effects. It does not mention permissions or additional requirements, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two introductory sentences and a parameter list. Every sentence adds value without redundancy. The structure is front-loaded with the core purpose and error behavior, followed by clear parameter documentation.
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 most parameters but omits the 'path' parameter (present in schema with default). While the output schema exists, the description could mention the return type. The missing path parameter is a notable gap for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by listing each parameter with JSON examples and explanations. It clarifies what types to use for scalar_params, vector_params, and texture_params, and explains the effect of 'force'. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a Material Instance from a parent material,' which is a specific verb and resource. It clearly distinguishes itself from sibling tools like 'create_material' or 'build_material_graph' by focusing on instance creation.
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 guidance on error handling ('Returns error if asset already exists') and when to use the 'force' parameter to delete and recreate. However, it does not explicitly compare to alternative tools or specify prerequisites like required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses AND logic for filters, case-insensitive matching, fallback behavior for class_filter, and return of total count scanned/matched even when truncated. Could mention whether it is read-only (likely safe).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. It includes a detailed args list, which is necessary due to no schema descriptions, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no annotations, no schema descriptions, but has output schema), the description is fairly complete. It explains behavior, each parameter, and output characteristics. Could mention what the returned actor list contains, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed explanations for all 7 parameters, including behavior (case-insensitive, IsA vs substring, etc.). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Flexible actor search across the level' and provides concrete use cases like 'is X in the world', 'first 5 actors of class Y', etc. It distinguishes from siblings like find_actors_by_name by emphasizing combining multiple filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are given, but it does not state when NOT to use this tool or mention alternatives. However, the sibling list is large and many are specific operations, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses that the tool always returns blend mode, shading model, two-sided, and expression count, and that include can add parameters, textures, or statistics. This is transparent for a read-only inspection tool, though no mention of rate limits or performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 6 sentences), front-loaded with the core purpose, and organized with bullet-like clarity. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description appropriately avoids detailing return values. It covers the input parameter include thoroughly and states always-returned fields. While it doesn't mention prerequisites or errors, this is acceptable for a straightforward inspect tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the include parameter's possible values ('parameters', 'textures', 'statistics') and their effects. The material_path parameter is implied by the tool name. This adds sufficient meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb+resource: 'Inspect a material's properties.' It lists always-returned fields and optional sections, distinguishing it from sibling tools like get_material_errors or get_material_expression_info by focusing on basic properties and expandable info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the include parameter to request additional sections and notes that omitting it provides minimal output. While it does not explicitly state when not to use this tool, the context of siblings implies other tools for specific tasks, making usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return format (commands sorted, fields like call_count, avg/max/total estimated tokens, response chars). With no annotations, it provides good behavioral context, though could mention if stats reset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. The most important info (what it does) is first, then details, then prerequisite. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (implied), the description explains the output structure sufficiently. Could add a note on scope (e.g., session lifetime) but overall complete for a stats 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?
No parameters exist (0 params), so schema coverage is 100%. Description adds no param info as none needed. Baseline score of 4 for zero 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 it retrieves 'accumulated per-command token usage statistics' and specifies the sorting order, distinguishing it from all other sibling tools that deal with assets, blueprints, Niagara, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions a prerequisite: 'Enable debug mode first with set_mcp_debug(enabled=True).' This tells the agent when to use it (after enabling debug). No need for alternatives as it is unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses the tool returns current values and valid enum values. It implies read-only but does not mention error conditions or prerequisites. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose, tips, examples, and parameter list. A bit lengthy but every sentence adds value. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are not required. Description covers what the tool does, key parameters, and usage tips. Lacks error handling or edge cases, but overall complete for a read-only property getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% parameter descriptions. Description compensates with an Args section that explains each parameter, including filter usage and default for renderer_index. Adds meaning beyond type/required/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets editable renderer properties with current values and valid enum values. It distinguishes from siblings like set_niagara_renderer_property by focusing on reading properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit tips to use filter for token efficiency and lists common filters. Also explains property names can be used with set_niagara_renderer_property. Lacks explicit when-not-to-use vs alternatives like get_niagara_renderer_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns bindings with source/target node names, struct IDs, and property paths. It implies read-only behavior via 'Get', but could be more explicit about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear heading, an example, and bulleted parameter descriptions. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers the tool's purpose and parameters comprehensively, leaving no obvious gaps 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description clearly explains both parameters: asset_path as the content path to the StateTree asset, and node_guid as optional filter. This adds crucial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets property bindings with full path details, with an example. It distinguishes itself from sibling tools like add_statetree_binding and remove_statetree_binding by being the retrieval counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the optional node filtering but does not explicitly state when to use this tool versus other StateTree retrieval tools or provide usage context like prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (name, inputs/outputs, CPU/GPU support, description) and cites the authoritative source (GetFunctionSignatures). It implies a read-only query but does not explicitly state read-only behavior or discuss permissions, though for an enumeration tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, with the purpose front-loaded, followed by context, return information, and parameter details. It is appropriately detailed without being overly verbose. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description explains the key return fields and provides a source reference. It covers the essential aspects for an agent to use the tool correctly, though it lacks information on error handling or edge cases. Still, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain all parameters. It does so thoroughly: di_class is described as short or full path with an example, filter as an optional substring with examples, and include_pins as a boolean defaulting to true. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Enumerate member functions' and clearly identifies the resource ('Niagara data interface class'). It explains what these functions are (right-click 'Functions' submenu on a DI pin) and distinguishes them from UNiagaraScript assets, explicitly noting they don't show up in search_niagara_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 context for when to use the tool (to get data interface functions for use with add_niagara_graph_node) and explicitly states that these functions are not covered by search_niagara_functions. It gives an example of passing the result to another tool. However, it does not exhaustively list all alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only listing operation with no side effects. The description is straightforward and matches the expected behavior of a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences: one for purpose and one for parameter details. Every word adds value, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (listing templates) and the presence of an output schema, the description covers the essential functionality. It specifies the purpose and parameter details, leaving return value documentation to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the allowed values for the category parameter ('all', 'sprite', 'mesh', 'ribbon', 'light', 'audio'), which is not present in the input schema. This adds significant meaning beyond the schema, which only defines the type as string with a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing emitter templates for use with add_niagara_emitter. It distinguishes itself from sibling tools like list_niagara_systems or list_niagara_modules by specifying 'emitter templates' and linking to a specific usage, making it 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 with add_niagara_emitter, but does not explicitly state when to use this tool versus alternatives (e.g., when to filter by category). No guidance on prerequisites or when not to use it. For a simple listing tool, this is adequate but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears transparency. It details the return fields (name, friendly_name, category, etc.) and explains each parameter's effect, providing clear behavioral insight beyond a simple 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, then usage, return fields, and parameter details. Every sentence is useful, though slightly lengthy; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and detailed parameter descriptions, the description is largely complete. It covers return fields, parameter semantics, and usage context. No mention of error handling or empty results, but acceptable for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates excellently with detailed explanations for all 5 parameters: filter (case-insensitive substring matching), category (exact match with examples), exact_name, include_pins, and max_results. Examples add semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates valid UNiagaraNodeOp operations from the FNiagaraOpInfo registry, explicitly distinguishes it from sibling tools like list_niagara_node_types by noting its use case for add_niagara_graph_node with node_type='Op'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: before calling add_niagara_graph_node with node_type='Op', to get valid op names. It does not explicitly say when not to use or list alternatives, but the context is clear among many Niagara sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description covers supported types, clears reference with None, and warns about full path requirements and array replacement. It does not disclose undoability or save behavior but is generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and examples, front-loading the main purpose. The MassEntityConfig section is detailed but justified given complexity; minor verbosity prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality, parameter details, and special cases. It assumes asset existence and lacks mention of side effects or requirements, but the presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning to all three parameters: asset_path (implied), property_name (case-sensitive), and property_value (types, examples, JSON structure for MassEntityConfig).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a single property on a data asset, distinguishing it from sibling tools like set_data_asset_properties that set multiple properties. Examples and special cases reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context, including case-sensitivity, supported types, and detailed instructions for MassEntityConfig assets. It lacks explicit comparison with similar tools like set_asset_property but implicitly differentiates from set_data_asset_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. It discloses key behaviors: modifies existing traits in-place, no array replacement, uses ImportText reflection, supports any property type. It does not cover error handling or side effects like saving, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs, Args, and Examples. The first sentence front-loads the key behavior. Every sentence adds value, but the length could be slightly trimmed without losing clarity. Overall, it is efficient and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, 1 required) and the presence of an output schema (no need to detail return values), the description covers identification, setting modes, and property value formats. It lacks error scenarios (e.g., missing trait) but is otherwise complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter in the Args section, describes the alternative identifier (trait_index vs trait_class), and details the two setting modes (single via property_name+property_value, batch via properties dict). Examples demonstrate usage with different property types, providing more meaning than the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Modify properties on an EXISTING trait in a Mass Entity Config in-place.' It specifies the verb, resource, and important constraints (existing, in-place, no array replacement). This distinguishes it from siblings like get_mass_config_traits, add_mass_config_trait, and remove_mass_config_trait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use—modifying existing trait properties—and what not to do ('Never replaces the Traits array, never creates new UObjects'). It identifies trait by index or class and provides two modes (single or batch). However, it does not explicitly state when to use alternative tools (e.g., add for new traits), though the context from siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It transparently notes that it uses the same code path as the editor UI, implying equivalent behavior. All parameters and their conditional dependencies are explained. While side effects (asset modification) are implied, they are not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory paragraph followed by a clear bullet list of parameters. It is information-dense but not overly verbose. Minor redundancy: the internal code path detail may be unnecessary for typical users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, 6 required, conditional dependencies), the description covers all inputs and their relationships. It lacks explanation of return values, but an output schema likely provides that. It is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing each parameter's purpose, valid values, and conditional requirements. It explains the dynamic_input_type enum with examples (e.g., 'random_range' requires min_value/max_value as float or vector JSON), and provides guidance for script discovery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Set a dynamic input' on a module input, listing the types of dynamic inputs. Distinguishes itself from sibling tools like set_niagara_module_input by specifying it handles dynamic inputs (random range, parameter link, expression, script), not simple value assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage instructions: describes the internal code path, enumerates dynamic_input_type options with their required parameters, and advises using search_niagara_functions for script discovery. However, it does not explicitly state when to prefer this tool over alternatives like set_niagara_module_input, nor does it mention prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description details the operation (setting a value) and explains value formats for different types. It does not mention side effects or permissions, but the behavioral traits are adequately disclosed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main statement, usage tip, value format section, and argument list. It is slightly long but each part adds value; minor redundancy could be trimmed.
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 6 parameters and no enums, the description covers the tool's purpose, usage, and parameter semantics thoroughly. It lacks details on the output schema, but that is signaled separately, making the description adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining all 6 parameters in detail, including value format examples for float, int, bool, vector, and color. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a rapid iteration parameter value on a module, with specific examples like spawn rate, colors. It distinguishes from sibling tools by positioning itself as the primary way to change module inputs and points to get_niagara_rapid_iteration_parameters for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use get_niagara_rapid_iteration_parameters first to discover available parameters, providing clear context. It does not explicitly exclude alternative tools like set_niagara_module_input, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral disclosure. It accurately describes a read-only operation (tracing connections, no modification mention). While it doesn't explicitly state 'non-destructive' or 'read-only', the description's tone and detail imply no side effects. For a simple query 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 concise, front-loaded with the main purpose, and structured with a clear Args section. Every sentence is informative, with no fluff or redundancy. It earns its place efficiently.
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 existence of an output schema (not shown), the description doesn't need to cover return values. It covers the tool's use case, parameters, and behavior adequately. However, it does not mention prerequisites (e.g., material must be loaded) or error conditions, which would enhance completeness for a context-aware agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to three of four parameters via an Args section, explaining direction and max_depth clearly. However, it fails to describe the required 'material_path' parameter, which is left to the user's inference. Despite this, the overall parameter documentation is strong and compensates for the 0% schema description 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's purpose: to trace connections upstream and/or downstream from a specific node in a material graph. It specifies the verb 'trace', the resource 'connections', and distinguishes itself from sibling tools like 'connect_material_expressions' or 'trace_niagara_connection' by focusing on material pin connections.
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 guidance on when to use the tool (for inspection of pin connections) and explains the parameters (direction, max_depth). However, it does not explicitly state when not to use it or mention alternatives among the many material tools, leaving some room for ambiguity.
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, description fully specifies safety ('without clearing') and return value (node_index). Details required fields for Custom HLSL nodes. Omits error scenarios and permission requirements, but core behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with example JSON; no redundant words. Purpose front-loaded, followed by return value, next step, and parameter details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core functionality well; node parameter is fully described. Does not explain material_path, but the context of sibling tools and common pattern mitigates this. Output schema exists, so return format is covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds full parameter semantics: the node parameter is a JSON object with type, pos_x, pos_y, properties, plus optional fields for Custom HLSL. material_path is not elaborated, but the example style implies it's a path string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Add a single expression node without clearing other nodes,' clearly identifying the verb (add), resource (expression node), and key behavior (no clearing). Distinguishes from siblings like delete_material_expression and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to wire up with connect_material_expressions after adding, providing immediate next-step guidance. However, lacks explicit when-to-use vs alternatives and does not mention prerequisites or excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: atomic operation, clears existing by default but external references stay intact, auto-prefixes expression types, and details special cases like values starting with '/' becoming assets. It covers all behavioral traits needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with sections (Args for each parameter) and embedded examples. It is front-loaded with the core purpose. Slight redundancy could be trimmed, but overall it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 3 required, one boolean with default) and no nested objects in schema, the description covers all necessary details: JSON formats, special property behaviors, and material output pin names. An output schema exists for return values, so completeness for invocation is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must fully explain parameters. It does so extensively, detailing the structure of nodes (type, pos_x/y, properties with examples) and connections (from_node, from_pin, to_node, to_pin, material pins). This adds immense meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build a complete material node graph in one atomic operation' with specific verb and resource. It distinguishes from sibling tools like add_material_expression and connect_material_expressions by emphasizing that it handles multiple nodes and connections in a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameter clear_existing and notes the atomic nature, but does not explicitly state when to use this tool vs alternatives for individual node operations. It implies bulk rebuilding but lacks explicit when-not or prerequisite guidance (e.g., material must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explains that the tool reads live instances, describes two output modes, and details parameters affecting behavior (flat, filter, include_components, etc.). There are no contradictions with annotations because none exist. The description is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the complexity, with a clear first sentence stating the purpose, followed by a helpful comparison and a well-structured list of arguments. It is front-loaded and logical, but could be slightly more concise (e.g., merging some details).
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 12 parameters and an existing output schema, the description covers most behaviors and modes. It explains the critical distinction from CDO and the two output modes. However, it omits documentation for four parameters (cursor, category, max_entries, include_inherited), leaving some gaps for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains key parameters like actor_label, filter, include_components, flat, max_depth, include_metadata, expand_arrays, and array_element_limit with meaningful details (e.g., filter behavior differs by mode). However, it does not explain cursor, category, max_entries, or include_inherited, leaving a gap for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: getting property values from a live actor instance. It distinguishes itself from get_blueprint_class_defaults (CDO) by emphasizing that it reads the placed instance with per-instance overrides. This directly helps an agent select the correct tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with get_blueprint_class_defaults and explains when to use nested vs flat mode based on the user's need (quick inspection vs AI search). However, it does not mention other alternatives or when not to use this tool, missing some comprehensive 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 behavioral disclosure. It details what data is returned (alive counts, total spawned, execution state, bounds info) and the prerequisite for a running preview. It does not mention potential errors or non-running behavior, but the disclosed traits are sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences for purpose and behavior plus two parameter descriptions. It is front-loaded with the main action and includes no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no enums, and an output schema, the description covers the key aspects: purpose, output details, and prerequisites. It could mention error cases or behavior when the preview is not running, but overall it is complete enough for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must add meaning. It includes an 'Args' section explaining system_path as 'Path to the Niagara System asset' and emitter_name as 'Optional — filter to a specific emitter's stats', adding significant semantic context beyond the schema's type and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get live particle counts and emitter execution state from running preview', which clearly specifies the verb (Get) and resource (particle stats and execution state). It distinguishes from sibling tools like get_niagara_system_info or get_niagara_emitters by focusing on live counts and state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite: 'Requires the system to be previewing in the Niagara editor or spawned in level.' This provides clear usage context. However, it does not explicitly mention alternatives or when not to use the tool, missing a full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the exact enumeration logic for different property types (Instanced UObject, TSubclassOf, TArray<FInstancedStruct>, Enum properties) and warns about large responses. No annotations are provided, so the description carries the full burden. It lacks details on failure conditions but is otherwise 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 concise yet comprehensive. It starts with a clear purpose statement, then explains the logic with bullet points, includes a usage warning, and finally parameter details. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, output schema exists), the description covers all necessary aspects: how the tool works for different property types, when to use the filter, and parameter semantics. It is complete for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by explaining the purpose of each parameter (class_name, property_path, filter, include_abstract) with examples and usage details. Since schema description coverage is 0%, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns valid classes/structs/enum-values for a property dropdown, and distinguishes it from siblings by specifying the exact enumeration logic mirroring the Unreal Details panel. It uses specific verbs and resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an important usage guideline ('Use filter to avoid huge responses') and explains dot-notation for nested structs. It does not explicitly mention when not to use the tool or alternative tools, but the context implies it's the only tool for this specific task among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two input modes, defaults (replace_existing=True, extensions omitted means all files), and the destination path format. It implies write/destructive behavior (overwrite) but does not detail error handling or side effects. Still, it provides adequate behavioral context for a batch import.
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 efficiently structured: a one-line summary, a bullet for the either/or requirement, and a clean 'Args:' section. Every sentence adds value, with no redundancy or filler. It is front-loaded with the core purpose and usage pattern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, two modes, batch operation), the description covers the key aspects: mutual exclusivity, filtering, overwrite behavior. It lacks explanation of return values (output schema exists but is not mentioned) and prerequisites (e.g., file existence). Still, it is sufficient for an agent to use the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines each parameter's purpose and usage: 'files: List of absolute file paths', 'source_directory: Absolute path to a folder', 'extensions: File extensions to include when scanning', etc. This adds significant value beyond the raw schema, making parameter selection clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Import multiple files into the Content Browser in one batch.' It distinguishes from siblings like 'import_asset' by explicitly stating 'batch' and two distinct modes (files list vs. directory scan). This sets it apart from single-asset import 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 provides explicit guidance: 'Provide EITHER 'files' (explicit list) OR 'source_directory' (scan a folder).' It explains when to use each parameter and notes that extensions can filter when scanning. However, it does not explicitly state alternatives (e.g., use 'import_asset' for single files), so it is not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains it performs a live query (not cached), shows return structure based on kind (data_interface, enum, struct), and mentions the filter's case-insensitive substring matching including short name for data interfaces. It does not mention any side effects, but as a read-only list operation, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening sentence and a clear 'Args:' section. It is relatively long but each sentence adds value. Some minor redundancy (e.g., repeating default values could be omitted if schema provided them), but overall 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Niagara parameter types and the presence of many sibling tools, the description is complete. It covers all parameters, return value structure, and special behavior (filter matching short name). It also notes the output includes additional fields per type, which is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema lacks parameter descriptions. The description fully compensates by explaining each parameter with allowed values (scope options, kind options), defaults, and behavior (filter case-insensitive, matches short name for data interfaces). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'Live query of FNiagaraTypeRegistry' listing types addable as user parameters, including plugin Data Interfaces. This distinguishes it from siblings like list_niagara_available_parameters (which list actual parameters in a system) and get_niagara_user_parameters (which lists existing user parameters). The verb 'list' and resource 'parameter types' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains each parameter (scope, kind, filter, max_results) with allowed values and defaults, implying when to use this tool (e.g., default scope 'user' for User.* parameters). However, it does not explicitly state when not to use it or provide alternatives to other sibling tools, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the stopping, auto-loading, and the optional auto_load parameter. It does not mention any potential side effects or prerequisites, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. Every sentence adds necessary information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the purpose, usage, and parameter sufficiently. It implies the prerequisite of an active trace but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameter. It does so effectively by stating that auto_load controls whether the trace is automatically loaded for analysis, adding value beyond the schema 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 verb 'Stop' and the resource 'active trace recording', and distinguishes it from siblings like performance_start_trace and performance_analyze_insight by mentioning the automatic loading for analysis.
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 indicates when to use the tool (after starting a trace) and specifies the auto-load behavior, which guides usage. However, it does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full load. It accurately describes append-only behavior, no replacement, and error-on-duplicate. Could mention lack of side effects on other traits or permission requirements, but addresses key behavioral traits for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (under 150 words) and well-structured with a title, a safety note, an error condition, and a clear Args section. No superfluous content, though the safety line could be integrated into usage guidance without loss.
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 moderate complexity (add trait to config) and presence of output schema (not detailed but reduces need to explain return), the description covers all essential aspects: operation, parameters, safety, and error scenario. Could mention what happens on success (e.g., returns updated config), but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains parameter meaning beyond schema: asset_path as path to config, trait_class as full class path with examples, and properties as optional dict with supported types and example. This compensates fully for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Add a SINGLE trait to a Mass Entity Config' and specifies it operates on a config without replacing existing traits. It distinguishes from siblings like 'set_mass_config_trait_property' (which modifies existing traits) and 'remove_mass_config_trait' (which removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use: 'Returns error if the trait already exists' and safety reassurance: 'Safe for configs with complex replicator settings — only appends, never replaces.' Implicitly advises against using if trait already exists, directing users to alternative or checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for transparency. It explains the creation pattern, that it spawns on both asset and edit-copy graphs, and details conditional parameter usage. Missing specific side effects, auth needs, or rate limits, but sufficient for understanding 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 well-structured: a short opening sentence, a sentence on implementation detail, then a clear bulleted Args section. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, conditional logic), the description covers all necessary aspects: purpose, parameter dependencies, companion tools, and verification step. Complete with output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly, explaining each parameter with context, conditional usage based on node_type, and examples for op_name and di_class. Adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'node inside a Niagara graph'. It specifies multiple graph types (scratch-pad, dynamic-input, module graph) and references the Niagara editor pattern, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the tool and references companion tools like get_niagara_schema_actions, list_niagara_data_interface_functions, and list_niagara_script_parameters for discovery and verification. However, it lacks explicit 'when not to use' or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes a read-only operation (get info) with no side effects mentioned. It does not disclose auth needs or rate limits, but for a simple get operation, it is 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 well-structured with a brief summary paragraph and an Args section. Every sentence adds value, no redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists contextually, the description need not detail return values. It fully explains the parameters and the overall purpose. For a parameter-rich tool (3 params), this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description adds all meaning. It explains system_path, include (with default 'all' and sections), and filter (with examples like 'Spark'). This far exceeds the schema's minimal type/default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed info about a Niagara System, listing specific returns (system name, emitter list, user parameters, compilation status). It distinguishes from siblings like list_niagara_systems (which lists systems without details) and get_niagara_emitters (emitter-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the include and filter parameters to narrow results, which is clear. However, it does not explicitly state when to prefer this tool over alternatives like list_niagara_systems or get_niagara_emitters, missing some usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details unconditional vs conditional results, namespace filter, and parameter effects. Could mention pagination or error handling, but overall 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?
Well-structured with paragraphs and a list. Every sentence adds value, front-loads the primary purpose, and avoids unnecessary details. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and an output schema, the description covers all relevant behavior, including conditional additions. No gaps in what needs to be explained 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes an 'Args' section explaining each parameter's purpose, default, and effect (e.g., filter for substring, namespace for category). Fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists parameters that can be bound to Map Get/Map Set pins. Distinguishes from sibling tools like get_niagara_module_inputs by focusing on binding and including all relevant parameter namespaces.
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?
Explains when to use (for parameter binding) and how the list changes based on optional parameters (system_path, module_name). Does not explicitly list alternatives or state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently explains the three data sources, filtering behavior, output fields, and parameters like include_engine. It lacks mention of performance implications or error cases, but is otherwise thorough for a read-only enumeration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, three-line explanation of sources, and a bullet-style Args list. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple sources, output schema exists), the description covers all relevant details: what it returns, filtering, and how to use results with other tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains every parameter (filter, kind, include_engine, max_results) with allowed values, defaults, and behavior, compensating fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 enumerates every Niagara node type that can be added to a graph. It explicitly lists three sources (node classes, script assets, data interfaces), distinguishing it from sibling tools like list_niagara_modules or list_niagara_data_interfaces by being a comprehensive union.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering available node types before using add_niagara_module or add_niagara_node_pin, and mentions filter-first to keep output compact. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses that the tool performs a case-insensitive substring search and adds a warning about include_properties consuming tokens. It implies read-only behavior, though it could explicitly state that it does not modify any assets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise summary followed by a list-style parameter explanation and clear examples. Every sentence adds value without redundancy. It is both informative and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers all necessary aspects: purpose, when to use, parameter semantics, and examples. It is complete enough for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, but the description compensates thoroughly. Each parameter is explained: filter (case-insensitive substring), parent_class (with examples like 'MassEntityTraitBase'), max_results (default 50), and include_properties (token cost warning). Examples illustrate valid usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for UClass types by name filter and parent class constraint.' It specifies the verb (search), resource (UClass types), and output format (full /Script/Module.ClassName paths). This distinguishes it from sibling tools like search_parent_classes and find_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to find the correct class_path before calling set_data_asset_property with Mass Entity Config traits.' It also explains parameter purposes and gives examples. However, it does not explicitly mention when not to use it or alternatives, though the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It describes the tool as a search operation, implying non-destructive behavior. It explains key parameters like include_engine (restricting scan) and usage filter. Since an output schema exists, return values need not be detailed. The description adds useful behavioral context beyond what is in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short introductory sentence followed by an Args list. It is well-structured, front-loaded with the core purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward nature (search), the description covers all necessary aspects: purpose, parameters, and usage context. All 4 parameters are explained, and no required parameters exist. The tool's role among many Niagara siblings is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain each parameter. It does so thoroughly: filter (name/path substring), usage (explicit enum with default), include_engine (effect of false), and max_results (cap). This adds significant meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Niagara script assets by usage and name filter, specifying asset types (module/dynamic_input/function) and its purpose as a shortcut for subsequent operations like add_niagara_module or set_niagara_dynamic_input. It effectively differentiates from other search tools by its specific Niagara focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to find Niagara script assets for subsequent operations) and implies its dedicated nature. It does not explicitly state when not to use it or compare to related tools like search_material_functions, but the guidance is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behavior: 'Returns a filtered list of matching classes — never dumps all classes.' Adequate for a read-only search 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?
Very concise: purpose stated, usage hint, then parameter list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple search tool: covers purpose, usage, parameters, and behavioral guarantee. Output schema exists, so return format need not be detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are documented in the Args section with descriptions, defaults, and constraints (max_results 20 default, max 100). Schema coverage is 0%, so description adds all necessary 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 'search' and resource 'classes that can be used as Blueprint parents', distinguishing it from siblings like search_class_paths and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this BEFORE create_blueprint to find the correct parent class name', providing clear when-to-use context. No explicit exclusions, but strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: writes to actual placed actor, preserves editor overrides, walks struct fields and array indices, triggers PostEditChangeProperty, and marks level dirty. This is comprehensive given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points, and examples. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested property paths and multiple value formats, the description covers all necessary details: parameters, return value, and behavioral effects. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds critical meaning: explains actor_label, provides property_path examples, enumerates accepted value formats for property_value, and clarifies component_name. This significantly compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a property at any nested path on a placed level actor instance, using specific verbs and resources. It distinguishes from siblings by focusing on actor properties, as opposed to assets or blueprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool with detailed parameter descriptions and examples, but does not provide explicit guidance on when to use this tool versus alternatives like set_asset_property. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: auto-prefixing parameter name, default value formats, CDO defaults for data interfaces, and return value structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, examples, and return description. Slightly lengthy but every sentence adds value. Front-loaded with key purpose and type support mention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (many type names, optional default) and presence of output schema, description covers purpose, parameters, types, usage guidance, and return. References sibling tool for further initialization, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds extensive meaning for all parameters: system_path, parameter_name (prefix), parameter_type (with long examples), and default_value (with format details). Compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add a user parameter to a Niagara System' and specifies the scope of supported types. It distinguishes from sibling tools like set_niagara_user_parameter and remove_niagara_user_parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use list_niagara_parameter_types to discover valid type names. Includes detailed examples and references to set_niagara_user_parameter for richer initialization. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fully discloses destructive behavior (deleting nodes) and classifies which nodes are removed. Includes a dry_run option for preview. With no annotations, description carries full burden and excels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences total: one for purpose, one listing deletions, one warning, one for parameter docs. No fluff, front-loaded, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cleanup tool with 2 parameters and no annotations, the description covers purpose, exact deletions, usage caution, and parameter details. Output schema exists but not needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an 'Args' section explaining dry_run and implying function_path. Adds meaning beyond the schema's property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Remove unconnected/orphaned nodes' and the target resource 'Material Function'. Lists specific node types deleted, distinguishing it from siblings like 'cleanup_material_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit warning 'Only call when the user explicitly asks to clean up.' Provides context for appropriate use, though does not explicitly name alternative for different graph types or situational alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly discloses behavior: what is returned (flat dict with metadata, _summary with pagination info), effects of parameters like descend_into_objects and max_entries=0, and no destructive actions implied.
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?
Well-structured with a clear purpose statement upfront, followed by output explanation and parameter details. Slightly verbose but every sentence adds value; could be slightly more concise but still efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, output schema present), the description is highly complete. It covers all parameters, return values, and pagination, fully addressing the agent's needs for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds extensive meaning to each parameter, explaining how they affect output (e.g., property_path navigation, filter, depth, pagination). Complements the schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Inspect type/clamp/enum metadata for properties on a placed actor' with a specific verb and resource. It distinguishes from sibling tools that operate on other aspects like assets, materials, or Niagara systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed usage scenarios for different parameter values (e.g., empty property_path, struct, object reference) and explains the _summary header for pagination. Does not explicitly state when not to use, but the specificity makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details internal implementation (using specific Unreal Engine functions and replicating non-exported logic) and discloses key behaviors like recursive descent for dynamic inputs. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: a concise summary, then output details, then internal notes, then parameter list. A few more words than strictly necessary, but every part adds value. Front-loading the answer question helps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, 4 required) and no output schema provided, the description fully covers what the tool does, what it returns (with field details), and the meaning of all parameters. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema_description_coverage, the description compensates fully. Every parameter is explained in the 'Args' section with clear semantics (e.g., system_path: Niagara System asset, max_depth: default 3). This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves the actual binding of each module input, distinguishing it from siblings like get_niagara_module_inputs and get_niagara_rapid_iteration_parameters. It lists specific output fields (mode, value, linked_parameter, etc.), making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool answers a question that sibling tools cannot, providing explicit context for when it should be used. However, it does not explicitly state when not to use it or mention alternatives beyond the two named siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently details the returned data format (two lists with specific fields for states and meta_targets) and mentions the asset_path argument. However, it does not describe potential errors or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear breakpoints for the two return lists, usage note, and parameter description. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (discovering transition targets for subsequent mutations), the description completely covers what the tool does, what it returns, how to use it (including parameter), and its place in a workflow. The existence of an output schema complements the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single required parameter. The description adds meaning by stating 'asset_path: Content path to the StateTree asset,' which clarifies the parameter's purpose beyond the schema's type-only 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 tool gets valid transition targets for a StateTree, lists the two returned categories (states and meta_targets), and explicitly distinguishes itself from siblings like add_statetree_transition and set_statetree_transition_property by stating it should be used before them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use instructions: 'Use this before add_statetree_transition or set_statetree_transition_property to discover valid target_state values.' This directly guides the agent on proper invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It explains the resolution order, validation conditions (must be AActor subclass, not abstract, not deprecated), that it loads assets, iterates classes, and uses UEditorActorSubsystem for Undo support. This is comprehensive.
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 longer but well-structured: purpose, resolution order, validation, then parameters. It could be slightly more concise, but every sentence adds value. Front-loading with the main purpose is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, output schema exists), the description covers all necessary aspects: what the tool does, parameter semantics, validation, and even Undo support. The output schema is present, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description carries the full burden. The 'Args' section provides clear, detailed explanations for each parameter: class_path (with examples), name, location, rotation, and scale. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Spawn ANY AActor subclass by full path, short name, or Blueprint asset path.' It distinguishes itself from the sibling tool 'spawn_actor' by mentioning it 'Replaces the hardcoded whitelist of spawn_actor.' The verb is specific and the resource 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for spawning any actor subclass) and mentions it replaces spawn_actor. It provides the resolution order for class_path, which guides usage. However, it does not explicitly state when not to use it or compare to other sibling tools beyond spawn_actor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states destructive nature, explains modes and dry_run behavior. Could mention return format or confirmation message, but output schema may cover return values.
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?
Concise yet comprehensive: one sentence for purpose, a warning paragraph, and structured parameter explanations. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown), description covers all needed context: purpose, when to use/avoid, parameter details, and safety recommendation (dry_run). Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains each parameter: mode with its three options, dry_run with its purpose and recommendation. Material_path is implicit in name. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes orphaned and dead-end nodes from a material graph, using specific verb-resource pairing. It distinguishes itself from sibling tools like delete_material_expression by targeting connectivity cleanup rather than individual node deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit warning to never call unless user explicitly requests cleanup, explains rationale (users may keep disconnected nodes intentionally), and recommends using dry_run first to preview. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly indicates this is a read operation ('Read all traits') and describes what is returned. It does not mention any side effects or permissions, but as a read tool, the behavioral disclosure 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 concise and well-structured: main action first, contrast with sibling tool second, then parameter description, then return value summary. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description briefly lists the return fields, which is sufficient. The tool is simple with one parameter, and the description covers all necessary aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'asset_path' is thoroughly described with an example path. The schema has 0% description coverage, so the description fully compensates by specifying the exact type and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads all traits from a Mass Entity Config asset with expanded properties. It explicitly distinguishes itself from get_data_asset_properties, which only shows trait object paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative (get_data_asset_properties) and explains when to use this tool instead: when you need expanded editable properties with current values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description implies a safe read operation by listing enum values without side effects. It could explicitly state it is read-only, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a clear paragraph, bullet list of categories, and an Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (single parameter, output schema exists), the description covers usage, parameter semantics, and enumeration examples comprehensively, leaving no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully defines the single 'category' parameter by listing all valid values and providing examples for each, compensating entirely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'List valid enum values for StateTree properties' and distinguishes itself from sibling statetree tools by focusing on enum discovery before creation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use 'BEFORE creating states, transitions, or conditions' and notes it doesn't require an asset_path, making usage context crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses behavioral traits such as output characteristics ('compact output', 'ONE CALL full report'), query-specific behaviors (e.g., 'returns: verdict string, severity-rated findings'), and parameter effects. There is no contradiction with absent annotations, and the tool's read-only nature is implied by its analytic purpose.
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 lengthy but well-structured: a recommended workflow, then query types organized into groups, then parameter listings. While every sentence serves a purpose, there is some redundancy (query types listed both in the workflow and later in full). The front-loading of the workflow is good, but a slightly more concise presentation could improve readability without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (24 parameters, many query types) and the presence of an output schema, the description is fully complete. It covers all query modes, parameter associations, and return value hints. It also references sibling tools for trace recording, providing a complete picture of the tool's role in the larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args:' section adds rich meaning beyond the schema. Each parameter is paired with the queries that use it and a clear description of its role (e.g., 'frame_index: (bottlenecks, hotpath, compare, frame_details) Which frame (0-based)'). Defaults are also mentioned, compensating fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as analyzing profiling data from a .utrace trace, with an explicit verb ('Query profiling data') and resource ('loaded .utrace trace'). It distinguishes itself from sibling tools like performance_start_trace and performance_stop_trace by focusing on analysis after a trace is loaded, and the recommended workflow references those sibling tools for recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed recommended workflow (the 7-step sequence) and explicitly states when to use each query type (e.g., 'Start here' for 'diagnose'). It also advises on when to use performance_start_trace/stop_trace or query='load' to obtain the trace file, giving clear context on alternatives.
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/aadeshrao123/Unreal-MCP/badges/card.svg)](https://glama.ai/mcp/servers/aadeshrao123/Unreal-MCP)

Score Badge

Copy to your README.md:

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

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