MCPBridge Server

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation2/5
Several tools overlap: blueprint_info, blueprint_inspect, and blueprint_document all inspect Blueprint structure; blueprint_build_from_json and blueprint_build_from_description both build graphs; bridge_clear_log and clear_output_log are exact aliases. While many tools are domain-specific, these overlaps create selection ambiguity.
Naming Consistency3/5
Most tools follow a consistent <domain>_<action> pattern (actor_spawn, asset_list, material_create), but outliers like undo, redo, help, test_connection, python_proxy, and ue_logs break the pattern. There are also mixed conventions such as level_actors vs actor_spawn and clear_output_log as a bare verb.
Tool Count1/5
With 122 tools, this is an extreme over-scoping for a single server. The calibration guide marks 50+ as extreme, and this is more than double that, making it difficult for an agent to efficiently select the right tool.
Completeness3/5
The tool surface is remarkably broad, covering assets, actors, blueprints, materials, viewport, input, AI, data tables, and C++, but it lacks basic delete operations for many asset types (e.g., asset_delete, material_delete, blueprint_delete) and has no rename or list for data tables. It's extensive but not fully comprehensive.
Average 3.7/5 across 100 of 122 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to supplement, the description carries the full burden of behavioral disclosure. It fails to mention any effects, side effects, or prerequisites, leaving the agent completely uninformed about what happens when the tool is invoked.
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 terse, but it under-specifies rather than being efficiently concise. It provides only an alias reference and no substantive information, so it fails to earn its place as a useful description.
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?
The tool has no annotations, no output schema, and only a minimal alias description. Given the existence of a sibling tool with a similar name, more context is essential to disambiguate and explain the tool's role, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage by default. Therefore, the description does not need to explain parameters, and the baseline of 4 is appropriate since no semantic gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Alias for bridge_clear_log,' which does not convey what the tool actually does. It references another tool name without explaining the action or resource affected, leaving the purpose entirely dependent on external knowledge of bridge_clear_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or context, making it impossible for an agent to decide between this and the similar bridge_clear_log sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the operation ('snap') but does not disclose side effects (e.g., overwrites actor transform), error handling for missing sockets, or any permissions or requirements. The term 'snap' implies a move, but the consequences are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no extraneous words. Every word carries meaning, and it is structured efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 required params, no nested objects, no output schema), the description is still too sparse. It omits critical operational context such as whether both actors must be present in the level, what happens if the socket name is invalid, and whether the snap preserves orientation. The agent would need to infer or test these behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter ('Actor to move', 'Socket name', 'Actor with the socket'). The tool description adds a relational context (which actor moves to which socket) but doesn't add new meaning beyond the schema's own descriptions. Per the rubric, baseline is 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'snap' and identifies the resource ('another actor's named socket'), which clearly distinguishes it from sibling tools like actor_spawn, actor_duplicate, and actor_modify. However, 'snap' could be ambiguous (exact transform behavior) and lacks detail about what snapping entails geometrically.
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 like needing actors to exist or sockets to be present, nor does it name any alternative tools for similar purposes. The usage context is entirely implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not state whether the operation is read-only, whether it triggers any side effects (e.g., loading assets, compiling classes), or whether it has any prerequisites. The description only lists topics it covers, so an agent would be unaware of the tool's operational footprint.
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 a front-loaded verb and a series of concrete diagnostic areas. It avoids fluff and communicates its scope efficiently. However, it is somewhat of a list without additional structure, so it does not reach the level of the most polished examples.
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 and no output schema, so the description must carry significant contextual weight. It only offers a brief list of diagnostic subjects and lacks information about return values, usage examples, or how results are presented. For an agent to invoke this tool correctly, more context is needed about what 'diagnose' produces and when it is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaningful parameter-level detail beyond the schema; it mentions categories like 'dependencies' and 'referencers' which map to include_dependencies and include_referencers, but it does not clarify their values, defaults, or interactions. The schema already provides adequate descriptions, so no significant value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Diagnose' and lists distinct diagnostic areas (asset loads, Blueprint generated classes, dependencies, referencers, script class availability), making it clear this is a diagnostic tool. It distinguishes itself from sibling tools like asset_info or asset_list by focusing on load/class/dependency issues rather than general asset information or listing.
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, no exclusions, and no context about appropriate scenarios. The only implicit indication is the verb 'Diagnose', which weakly suggests troubleshooting but does not clarify when this should be preferred over sibling tools like asset_info or blueprint_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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits, but it only states that a Blueprint class is created. It omits important details such as what happens if the asset already exists, whether compilation occurs, or any side effects, leaving the agent under-informed about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and scope. Every word contributes meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested arrays for variables and components), the absence of an output schema, and no annotations, the description is too minimal to be contextually complete. It does not cover return values, error conditions, or operational context, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all parameters, so the baseline is 3. The description adds minimal semantic value by mentioning 'optional components and variables', but it doesn't explain parameter formats, constraints, or interactions beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the resource ('Blueprint class') along with the scope of optional components and variables. It clearly conveys what the tool does, though it doesn't explicitly distinguish it from sibling tools like blueprint_build_from_json or blueprint_build_from_description.
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 blueprint_build_from_json or blueprint_build_from_description. It merely describes the action without mentioning prerequisites, exclusions, or contextual readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Show operation history with timestamps and parameters.' It does not mention return format, ordering, whether it is read-only, or any limitations. This is minimal disclosure beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is appropriately sized for a simple tool and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values, but it only hints at 'timestamps and parameters' without specifying the format. There is also no mention of ordering, limits, or default behavior. For a simple tool, it is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'count', which is described as 'Number of recent entries to show'. The description does not add any parameter details beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows operation history, and specifies that it includes timestamps and parameters. It is distinct from sibling tools like undo/redo/checkpoint, though it doesn't explicitly name alternatives or scope (e.g., 'all' vs 'recent').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Users must infer that history_list is for viewing past operations, but no explicit context 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 explains what the resulting spec does, but not the tool's own side effects, such as whether it writes to disk, requires existing assets, or returns an asset path. Mutation, error behavior, and output format are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. It is efficiently structured, though brevity trades off some necessary detail that could have been included without harming readability.
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 a complex nested manifest schema, five parameters, no output schema, and no annotations, the description is far too minimal. An agent cannot determine what inputs are needed, what the tool produces, or how it integrates with related title tools, making the overall context inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 40%, and the tool description mentions no parameter specifics. It does not explain the 'manifest' structure, how 'id' or 'manifest_path' are used, or how the manifest maps to the created controller. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating a BP_TitleController implementation spec, with a specific responsibility (owning the widget and updating cues from Sequencer frame numbers). This distinguishes it from similar create/manifest tools, though 'implementation spec' could be more explicit about whether it generates an asset or a description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a title controller but provides no explicit context on when to choose this over alternatives like title_manifest_create or blueprint_create. No exclusions or guiding scenarios are mentioned, leaving the selection partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It clearly indicates mutation ('changing'), but it omits critical behavioral aspects: whether the manifest is modified in place, whether validation occurs, whether a new manifest is written to output_path, and what side effects or prerequisites exist. This is insufficient for an agent to understand the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It communicates the core action and scope efficiently, which is ideal for conciseness even though it lacks depth.
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?
This is a complex tool with five parameters, nested object schemas, no annotations, no output schema, and only 20% schema description coverage. The description provides only a summary of what fields can change, and omits how corrections are supplied, how manifests are referenced, and what the output represents. It is far from sufficient for correct 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 only 20%, and the description does not compensate. It names high-level field types but never maps them to the required 'adjustments' array or explains the semantics of key parameters like box_delta versus box, manifest_path versus manifest, and output_path. An agent would struggle to construct a valid call from the description 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 a specific verb ('Apply') and resource ('manifest'), and enumerates the exact field categories affected: cue boxes, frame timing, text, role, or name. It clearly distinguishes this from sibling tools like title_manifest_create and title_manifest_validate by naming the adjustment operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, and does not mention any workflow context such as being run after title_render_compare or title_manifest_from_reference. The phrase 'measured correction passes' hints at a comparison-driven workflow but does not state it, leaving the agent without actionable usage 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?
With no annotations, the description carries the full burden. It mentions the tool is a v1 scaffold, which is a useful maturity caveat, but it does not disclose side effects, file requirements, whether existing specs are overwritten, or any other behavioral traits beyond the creation act.
Agents need to know what a tool does to the world before 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 scaffold note adds important context without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, nested objects, and no output schema, the description is too sparse. It doesn't mention expected inputs, return values, validation, or how it fits into the broader workflow of title creation and binding.
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 five parameters. While parameter names like manifest_path and sequence_path are self-descriptive, the description adds no semantic detail about how they relate to the binding process or what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 Level Sequence binding spec to drive BP_TitleController from frame numbers. This is a specific verb+resource+scope, and it distinguishes the tool from siblings like title_manifest_create or title_controller_create.
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 note 'v1 scaffold until the bridge has full Sequencer event-track authoring' implies when to use it as a temporary solution, but it does not explicitly name alternatives or prerequisites. It gives some context but lacks clear 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'shared validation' without explaining what that entails. It does not clarify whether operations run sequentially, are atomic, fail as a group, or support partial success. This is a significant gap for a meta-tool that executes multiple operations.
Agents need to know what a tool does to the world before 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 zero filler. It front-loads the key action ('Execute multiple tool calls') and includes the only additional detail ('shared validation'). The structure is economical and appropriate for its brevity, though other dimensions penalize the lack of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too thin for a tool of this complexity. It omits essential context such as execution order, error handling, atomicity, and practical use cases. The one-line description leaves the agent without enough information to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, describing 'operations' as an array with 'command' and 'params' fields. The description adds minimal parameter-related meaning beyond the schema, only hinting at 'shared validation' without detailing how operations interact. Per the baseline for full schema coverage, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute multiple tool calls in a single request.' The verb 'Execute' plus resource 'multiple tool calls' is specific, and it naturally distinguishes itself from sibling tools like 'batch_spawn' or 'asset_save_many' which are domain-specific batching 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 given on when to use this tool versus alternatives. It does not specify whether it is appropriate for dependent operations, ordering requirements, or how it compares to individual tool calls. The description only mentions 'shared validation' but does not explain the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists command names without explaining side effects, value formats, reversibility, or performance impact. For example, freeze_rendering likely stops rendering, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence states the purpose, followed by a list of all valid commands. No filler or redundant information is present.
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 16 commands with diverse value requirements (booleans, numbers, etc.), but the description lacks per-command semantics or value constraints. An agent cannot reliably invoke all commands correctly without additional knowledge, making the description incomplete for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters ('Effect command' and 'Command value') and lists all enum values, so coverage is 100%. The description adds no extra meaning about expected value types or per-command behavior, but since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Toggle rendering features via console commands') and lists the specific commands. However, 'toggle' is slightly misleading for commands like screen_percentage or tonemapper, which may set values rather than simply toggle.
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 is given on when to use this tool versus alternatives. The command list implies it is for adjusting rendering settings, but no direct alternative is mentioned or excluded.
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 mentions 'Returns validation by default' but that is ambiguous—what validation? It does not state that this mutates the actor, whether the change is reversible, or whether it overrides the existing material. The description is too minimal to provide adequate 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 one short, front-loaded sentence followed by a brief note on return behavior. No wasted words, easily scannable.
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, no output schema, and no annotations, the description is insufficient. It does not explain what 'validation' means, what happens with default slot selection, preconditions like valid material paths, or the mutating nature of the operation. This is a significant gap for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully described in the schema itself. The description adds no additional parameter context. Baseline of 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Apply a material to an actor's mesh component.' This is a specific verb (apply) and resource (material, actor's mesh component), distinguishing it from related tools like material_create (creating materials) or material_info (inspecting materials).
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 material_create or material_instance_set_params. The usage intention is only implied by the verb 'apply', with no 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states that creation occurs and gives a prerequisite for instances. It does not mention potential overwrites, permission needs, failure modes, or return values. For a mutation operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and contains no redundant words. Every sentence contributes essential information without padding.
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 five parameters including a nested object for parameters, but the description gives no context about how those parameter values work, what constitutes a successful creation, or how to interpret errors. The lack of an output schema and annotations makes this brief description inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all five parameters with descriptions, achieving 100% coverage. The description's parameter hint ('Provide parent and type \"instance\"') duplicates what the schema already states for the parent field. Thus, the description adds no meaningful value beyond the schema, earning the baseline score.
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 the core action clearly: 'Create a new material or material instance.' However, it does not differentiate from the sibling tool material_instance_create, which appears to have overlapping functionality. The verb and resource are specific, but the scope boundary is ambiguous.
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 instruction 'Provide parent and type \"instance\" for material instances' gives conditional usage guidance for instances. It implies when to use the instance path, but it does not mention alternatives like material_instance_create or when to prefer a plain material. This is implied usage, not explicit contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the core conversion behavior but omits any mention of side effects like writing to output_path, the need for frame_size/reference_size, error handling, or how it treats cues that lack pixel_box. This leaves significant ambiguity about what the tool actually does beyond the conversion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words and precise technical vocabulary. It is appropriately concise for a high-level summary, though arguably too terse for a tool with this many parameters and nested objects. Still, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, nested objects, and no output schema or annotations, the description is insufficient. It does not explain the relationship between frame_size, resolution, and reference_size, nor what the output manifest looks like or the role of output_path. The agent would need to infer too much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate. It connects 'measured reference-frame pixel boxes' and 'normalized screen boxes' to the pixel_box and box fields, but fails to explain parameters like fps, style, gapFrames, output_path, or reference_size. The brief cue description in the schema says 'Cues may include pixel_box instead of normalized box,' but the tool description adds no detail about how these parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ("Create a manifest"), the source data ("measured reference-frame pixel boxes"), and the transformation ("converting them into normalized screen boxes"). This distinguishes it from sibling tools like title_manifest_create or title_manifest_adjust, which likely operate on different input forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have measured reference-frame pixel boxes that need conversion, but it does not explicitly state when to use this tool over alternatives such as title_manifest_create or title_manifest_adjust. No exclusions or alternative tool references 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 are provided, so the description carries the full burden. It discloses the validation criteria (boxes, cue types, frame rate, timing), which is useful behavioral context, but it omits what happens on failure, whether mutations occur, or any return value 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?
The description is a single sentence of 15 words, front-loaded with the action and resource. It is concise and without filler, though it could be expanded to include invocation context.
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 nested manifest object and the absence of an output schema, this description is under-specified. It does not explain the return format, what 'normalized boxes' means, or how to choose between manifest and manifest_path, leaving the agent with insufficient information 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 description coverage is 0% and the description provides no explanation of the three parameters (id, manifest, manifest_path). The agent cannot determine whether to pass a manifest object or path, what 'id' refers to, or how the nested structure is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Validate' and resource 'title manifest', and lists concrete validation aspects (normalized boxes, valid cue types, positive frame rate, frame timing). This clearly differentiates it from sibling tools like title_manifest_create or title_manifest_adjust.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for checking a manifest before use, but provides no explicit when-to-use guidance, alternatives, or exclusions. The usage context is only implied by the verb 'validate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only states the action without explaining what 'recent' means, the number of entries returned, the return format, or any side effects or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word is informative and directly states the tool's 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?
Although the tool is simple, there is no output schema and no annotations. The term 'recent' is vague, and the description does not clarify how many entries are returned or how filtering interacts with 'recent'. This leaves notable ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'category' and 'severity' have descriptions in the input schema. The tool description adds no parameter-specific meaning, but the baseline of 3 applies because the schema already documents the filters sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Fetch') and resource ('recent UE4 log entries'), clearly stating what the tool does. It distinguishes itself from sibling tools like 'clear_output_log' or 'bridge_clear_log' which perform log-related but different 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 given about when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or relationships to sibling tools such as 'clear_output_log' or 'bridge_clear_log'.
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 behaviors. It states the action but does not explain failure handling, atomicity, return values, or permissions. Referencing actor_spawn for format is helpful but insufficient for a batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and the second sentence directs to a sibling for format. 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?
For a batch operation with nested object parameters and no output schema or annotations, the description is too sparse. It does not explain what the call returns, whether it is atomic, or how errors are handled. The reader must infer from actor_spawn, but even that may not cover batch-specific behavior.
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 points to actor_spawn for the format of each spawn definition, which is a strong reference. The schema lists the fields, but without this reference, parameter meanings would be unclear. This compensates for lack of individual field 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 spawns multiple actors in one call, using a specific verb and resource. It distinguishes from the sibling actor_spawn by the batch nature, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch spawning when multiple actors are needed, but does not explicitly state when to prefer this over repeated actor_spawn calls. There is no mention of exclusions or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool generates a text summary, implying a read-only operation, but it does not explicitly state whether the Blueprint is modified, what happens if the path is invalid, or any side effects. The absence of additional behavioral context makes it insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the tool's purpose without waste. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description states the output is a 'human-readable text summary', but it does not mention potential edge cases (e.g., missing Blueprint) or provide guidance on when to prefer this over related blueprint tools. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description does not add meaning beyond the schema; it only hints at the content of the summary ('structure, variables, and components') without elaborating on the detail_level parameter or the path format. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (generate a summary) and a specific resource (Blueprint's structure, variables, and components). It distinguishes itself from sibling tools like blueprint_info or blueprint_inspect by focusing on a 'human-readable text summary', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a human-readable summary of a Blueprint is needed, but it does not state when to use this tool versus alternatives such as blueprint_info or blueprint_inspect. No exclusions or prerequisites are mentioned, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, and listing the returned content adds context. However, it does not explicitly state that the operation has no side effects, nor does it mention authentication requirements, error behavior, 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 a single sentence that is front-loaded with the action and resource, followed by specific content categories. There is no filler or redundant wording, making it highly concise 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?
For a simple single-parameter info retrieval tool, the description covers the main result areas and is reasonably complete. However, given the large number of Blueprint-related sibling tools, the lack of differentiation from blueprint_inspect and blueprint_document leaves some contextual ambiguity that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for the single required parameter, blueprint_path, with a clear description ('Asset path of the Blueprint'). The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving detailed Blueprint structure, enumerating the specific contents: components, variables, functions, event graphs, and parent chain. It uses a specific verb ('Get') and resource ('Blueprint structure'), but does not distinguish it from related sibling tools like blueprint_inspect or asset_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?
No guidance is provided about when to use this tool versus alternatives such as blueprint_inspect, blueprint_document, or asset_info. There is no mention of use cases, prerequisites, or when 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 provided, the description carries the full burden of behavioral disclosure. It mentions the composite nature (level save + metadata snapshot) but does not disclose potential side effects, overwrite behavior, permission requirements, or whether the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. There is no redundant information or filler, making it immediately scannable 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?
The description provides the essential purpose but lacks deeper context about what a checkpoint entails, when it should be used relative to level_save, or what happens after creation. It is minimally complete for a simple two-parameter tool with no output schema, but leaves room for important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both name and description parameters clearly documented. The tool description adds little beyond saying 'named save point', which aligns with the required name parameter but does not clarify the significance of the optional description or the metadata snapshot relationship. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a named save point, specifying it's a level save plus metadata snapshot. This distinguishes it from sibling tools like level_save (which only saves the level) and checkpoint_restore (which restores), leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 level_save or checkpoint_restore. The description implies a composite save operation but does not explicitly state when this is preferable or when to avoid it, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals wildcard support but omits crucial details for a destructive operation: whether deletion is permanent, whether it can delete multiple actors, or whether it is reversible. This gap is significant for a delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and includes essential wildcard behavior. It is concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a destructive tool with no output schema and no annotations, the description should provide more context about consequences, such as irreversibility or bulk deletion. The current description is too thin for an operation that removes actors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the actor_name parameter with the exact same wildcard semantics, so the description adds no new meaning beyond the schema. Baseline of 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'actors' and the method 'by name or name pattern', making the tool's purpose unmistakable. It clearly distinguishes itself from sibling tools like actor_spawn, actor_duplicate, and actor_modify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: deleting actors by name or pattern. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or preconditions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the PIE prerequisite, but gives no information on side effects, error behavior (e.g., what happens if PIE is not running), whether it affects camera state, or any return values. Major behavioral aspects are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core action and requirement without waste. It is front-loaded and easy to parse. However, it is quite terse, which is slightly offset by its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (three parameters, one required, no output schema, no annotations), the description is insufficient. It does not clarify how camera_shake_play differs from sibling tools like camera_shake_trigger or camera_shake_spawn, what happens in error conditions, or how parameters affect behavior. The PIE requirement is helpful but not enough for correct 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 does not reference any parameters. Schema coverage is 67% (scale and shake_class have descriptions, play_space does not), but the description adds no value beyond the schema. The missing explanation for play_space is not compensated by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Play a camera shake') and the context ('during PIE'), which distinguishes it from sibling tools like camera_shake_blueprint and camera_shake_spawn. The phrase 'Requires PIE to be running' further scopes the purpose. Specific verb + resource + context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context ('during PIE') and a prerequisite ('Requires PIE to be running'), which tells the agent when to use it. However, it does not explicitly mention alternatives or when not to use it (e.g., when PIE is not running), so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core overlap-triggered behavior and the Python/C++ pattern, but omits potential side effects, prerequisites like a compiled C++ class, or behavior outside PIE.
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 concise sentences with the main purpose front-loaded. The second sentence about Python/C++ pattern adds architectural context but is not strictly essential, making it efficient but slightly padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This 5-parameter tool with nested objects, no annotations, and no output schema requires more context. The description does not mention prerequisites (e.g., compiled C++ class), what the tool returns, or how parameters like location and box_extent affect spawning. This is a significant gap.
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 60%, so the description should compensate for undocumented parameters like 'name' and 'location'. It does not mention any parameters, leaving the agent without additional semantic insight beyond the schema's partial 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 spawns a C++ ShakeTriggerActor that plays camera shake on player overlap during PIE. The verb 'Spawn' and specific resource distinguish it from sibling camera shake tools like camera_shake_play or camera_shake_spawn.
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 usage context (trigger box overlap during PIE) but provides no explicit guidance on when to choose this tool over camera_shake_play or camera_shake_spawn, nor any exclusions or 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'check,' which suggests a read-only operation, but it does not state whether it modifies actors, what the output/return format is, or how errors are reported. No side effects or limitations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with 5 parameters and no output schema. It does not explain what the validation returns, whether thresholds are configurable, what 'alignment issues' means, or whether the tool has side effects. The agent would have to rely on the schema and guess at behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds high-level context ('gaps', 'overlaps', 'alignment') which maps to the check_gaps and check_overlaps parameters, but it also mentions 'alignment issues' with no corresponding schema parameter, causing minor 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 a specific verb ('check'), a specific resource ('actors'), and the exact aspects being checked ('gaps, overlaps, and alignment issues'). This is unambiguous and distinguishes it from sibling tools that spawn, modify, or delete actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for validating actor placement, but it does not explicitly state when to use it vs. alternatives, nor does it mention any exclusions or prerequisites. The intended use case is inferable from the verb 'check' and the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It states 'Creates or updates a PP volume,' which is a key behavioral trait, but omits details such as whether existing settings are overwritten, how intensity scales values, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the verb 'Apply.' The preset list is useful but duplicates the schema enum, adding minor redundancy. Overall, it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and side effect but lacks usage guidance and detailed behavioral side effects. With no output schema, it also doesn't describe return values, though the tool is likely straightforward. Adequate for a simple tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter documentation. The description adds little beyond the schema, except listing presets (which are already in the enum). It does not clarify name or intensity behavior beyond their 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 ('Apply a named post-processing preset') and the effect ('Creates or updates a PP volume'), distinguishing it from lower-level volume spawn/modify tools. It also enumerates all available presets, making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for applying presets but gives no explicit guidance on when to choose this tool over alternatives like pp_volume_spawn or pp_volume_modify. No exclusions or alternative recommendations are provided, leaving the agent to infer 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 disclose side effects. It only says it 'creates' a widget blueprint, but does not mention whether it overwrites existing assets, requires specific paths, or returns any output. This is inadequate for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. It is efficient, though it could include a bit more detail 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?
With 16 parameters, nested objects, no output schema, and no annotations, the description is far too sparse. It does not explain return values, potential side effects, or how it differs from similar title-related sibling tools.
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 only 50%, and the description does not compensate. It vaguely references 'styled text, background treatment, and FadeIn/FadeOut animation specs', but does not map these to the 16 parameters or explain important ones like font sizes or colors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a specific resource ('centered cinematic title-card Widget Blueprint'), clearly distinguishing it from sibling tools like widget_lower_third_create. It also names key features: styled text, background treatment, and fade animation specs.
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 for cinematic title cards by mentioning 'centered cinematic' and 'title-card', which distinguishes it from lower-third or other widget tools. However, it does not explicitly state when not to use it or name 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?
With no annotations, the description carries full behavioral burden. It adds one useful trait: 'Returns validation results by default.' However, it omits other important details like whether changes are applied before validation, what validation results mean, or if any destructive side effects exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, then lists the affected attributes. No wasted words; every segment contributes to understanding.
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 7 parameters with nested objects, no output schema, and no annotations. The description conveys the core purpose and a validation-default behavior, but it does not explain validation result structure, how fields combine, or prerequisites like actor existence. It is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists the modifiable properties but does not add significant meaning beyond the schema. The mention of 'by default' loosely aligns with the validate parameter, but no extra parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and clearly identifies the resource ('an actor') plus the exact properties affected: location, rotation, scale, mesh, or visibility. This clearly differentiates it from sibling tools like actor_spawn or actor_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?
The description implies usage for modifying existing actors, but it provides no explicit guidance on when to choose this tool over alternatives such as actor_organize or actor_snap_to_socket. No when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the move action and fails to mention side effects, failure modes, whether folders are created automatically, or if the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and contains no redundant or filler words. It is highly efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters and no output schema, the description is minimally adequate, but it leaves open important questions such as whether folders are created on demand and how invalid actor labels are handled. Given the lack of annotations, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('Actor labels to move' and 'Target folder path'), achieving 100% coverage. The tool description adds no extra meaning beyond what is already in the schema, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move'), the resource ('actors'), and the destination ('World Outliner folders'), making it distinct from sibling tools like actor_spawn, actor_delete, and actor_modify. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for organizing the World Outliner hierarchy, but it does not explicitly state when to use this tool over alternatives or mention any prerequisites (e.g., whether target folders must already exist). There is no guidance on exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of safety disclosure. It says 'List' and states return fields, implying a read-only operation, but it does not explicitly confirm it is non-mutating or disclose potential side effects like asset loading. The verb provides some transparency but not a full safety profile.
Agents need to know what a tool does to the world before 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, with the main action front-loaded and no filler words. Every word adds value, 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?
The tool is straightforward, and the schema covers parameters fully. The description states the return fields, which is important because no output schema exists. However, it omits context about default behavior (e.g., default path /Game/) and how filters interact, leaving some gaps in operational 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?
Schema coverage is 100%, giving complete descriptions for all four parameters. The description's mention of 'optional filters' adds no semantic value beyond what the schema already specifies, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List assets' and explicitly states the output (paths, types, names). This distinguishes it from asset_info (which likely targets a single asset) and material_list (which targets materials 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 like asset_info. There is no mention of exclusions, prerequisites, or when a different listing tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the creation of an asset but does not disclose side effects, potential overwrites, required permissions, or return values. This lack of 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 a single, well-structured sentence that is front-loaded with the action and resource. It includes essential detail (the key types) without unnecessary words, making it highly 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?
The description covers the core purpose and key types, but it omits information about optional parameters (keys is optional given only path and name are required), error handling, or any constraints. Given the moderate schema coverage and lack of annotations, the description is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by enumerating the valid key types (Bool, Int, Float, etc.) that are not fully explained in the schema's enum. It also clarifies that keys are typed. However, it does not describe the 'keys' array structure in detail, leaving some burden on 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 verb 'Create' and the resource 'BlackboardData asset', and it specifies the typed keys. This distinguishes it from other create tools like blueprint_create or material_create, as it is uniquely about BlackboardData.
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 exclusions or prerequisites. It simply states what it does, leaving the agent to infer usage 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 provided, the description carries the full burden of disclosing side effects. It does mention that exec flow is auto-wired, but it omits the important destructive behavior that clear_existing defaults to true, meaning the existing graph is cleared unless explicitly set to false.
Agents need to know what a tool does to the world before 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 exactly two sentences, front-loaded with the primary purpose, and the pattern list is compact yet useful. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the core purpose and pattern inventory, making it minimally viable. However, it lacks usage guidance, fails to mention the destructive clear_existing default, and does not explain pattern-specific parameters or how to verify the built graph, leaving clear gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 3 parameters at 100% coverage, so the baseline is 3. The description adds meaningful value by enumerating the allowed pattern names, which are not constrained via enum in the schema, and by clarifying that each step has optional 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 verb ('Build'), the resource ('Blueprint event graph'), and the method ('from high-level pattern templates'). It lists available patterns and notes auto-wired exec flow, which helps distinguish it from sibling tools like blueprint_build_from_json.
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 is given about when to use this tool versus alternatives such as blueprint_build_from_json or blueprint_create. The pattern list implies usage scenarios, but there are no exclusions, prerequisites, or 'use when' 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?
The description discloses a key side effect—'then compile and save'—which is significant and not present in annotations (since there are none). However, it does not explain behavior when the variable doesn't exist, whether default_value is optional, or the reversibility of changes. With no annotations, the description carries more burden and only partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the key side effects. Every word earns its place; nothing is redundant.
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 mutation tool with no annotations and no output schema, the description is thin. It states the operation and side effects, but lacks usage context, error/edge-case behavior, and details about optional parameters. The schema covers parameters, but overall contextual completeness is moderate at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions, so the description does not need to add parameter details. It does add a small semantic clarification that the variable is a 'member variable,' but overall it provides no meaningful parameter info beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('member variable's default value'), clearly distinguishing it from sibling tools like blueprint_add_variable or blueprint_compile. It also notes the post-actions (compile and save), which further clarifies the tool's full purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It only states the action, leaving the agent to infer usage from the name and schema. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List materials' and does not explicitly state that this is a read-only operation, nor does it mention any side effects, permissions, pagination, or defaults. The absence of such details leaves significant uncertainty for an agent deciding whether to invoke this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It front-loads the action ('List materials') and immediately mentions the optional filters, making it easy to parse and understand.
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 listing tool with four optional parameters and no output schema, the description is minimally adequate. It tells the agent what the tool does but does not mention the default limit, default path prefix, or return format. Given the absence of annotations and output schema, a bit more context (e.g., that it returns material paths or includes only assets under /Game/) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all four parameters, each with descriptive text. The description merely repeats the filter names (path, name, type) without adding extra meaning about wildcard behavior, default values, or how filters interact. This meets the baseline for high schema coverage but adds no additional insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'List materials in the project' with a specific verb and resource. It also mentions the filtering dimensions (path, name, type), which distinguishes it from sibling tools like material_info (which likely fetches a single material) and material_create (which creates a 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?
The description implies the tool is used to enumerate materials, especially when filtering is needed, but it does not explicitly contrast it with sibling tools like asset_list or material_info. No 'when to use' or 'instead of' guidance is provided, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool spawns a volume with settings control, but does not mention side effects such as unbound affecting the entire level, auto-enabling override flags, default values, or any potential performance impact. Absence of this contextual information leaves the agent without a clear behavioral profile.
Agents need to know what a tool does to the world before 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, tightly written sentence that front-loads the verb and resource, then lists supported effects concisely. No filler or repetition; every word contributes to the tool's purpose and capabilities.
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?
Despite the large nested settings object, the description remains generic. It omits critical context like the fact that all settings are optional, the volume defaults to unbound (affecting the whole level), and how blend weight/radius interact. The schema covers details, but the description does not tie the tool's behavior to broader use cases (e.g., cinematic, immersive effects). A bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), so the baseline is 3. The description lists high-level effect categories but does not add meaning to individual parameters beyond what the schema already provides. It does not compensate for the few undocumented parameters or explain relationships between settings, so no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Spawn a PostProcessVolume with full settings control', using a specific verb ('Spawn') and resource ('PostProcessVolume'). It lists supported effects (bloom, exposure, DOF, etc.), which clearly distinguishes it from sibling tools like pp_volume_modify (modify existing) and pp_preset (apply presets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: creating a new PostProcessVolume with extensive settings. However, it does not explicitly state when to use this tool versus alternatives like pp_volume_modify or pp_preset, and provides no exclusion criteria. The 'Spawn' phrasing gives clear context, but no direct comparison or guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action without disclosing side effects, state modifications, or prerequisites. For a mutation tool, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, front-loading the verb and resource. It is appropriately sized for a simple tool and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and full schema coverage, this minimal description is adequate. However, it lacks context about the operation history, relationship to 'undo', and no output schema or annotations clarify behavior, leaving gaps for a 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 input schema fully describes the 'count' parameter (number, default 1), so the description adds nothing beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('redo') and resource ('previously undone operations'). It is distinguishable from sibling tools such as 'undo' and 'history_list' by implying an inverse action.
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 mention alternatives. However, the phrase 'previously undone operations' implies it should be used after an undo, providing implicit 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 of behavioral disclosure. It only states 'using UE4's transaction system', which hints at the mechanism but does not explain side effects, reversibility, prerequisites, or whether it modifies the current level. This is a significant gap for a tool that mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and scope, and every word contributes to understanding.
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 optional parameter, no output schema), the description covers the core functionality. However, it lacks behavioral context such as what happens after undoing (e.g., whether the redo history is cleared) and whether there are any prerequisites. A bit more detail would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the only parameter 'count', describing it as 'Number of operations to undo (default 1)'. The description's use of 'N' maps directly to this parameter, adding minimal additional meaning. The baseline of 3 applies because the schema already handles the 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 ('Undo'), the target ('the last N operations'), and the mechanism ('UE4's transaction system'). This is a specific verb+resource that distinguishes it from the sibling 'redo' and other history-related tools like 'history_list' and 'checkpoint_restore'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'Undo' and the phrase 'last N operations' – it's obvious when to use it. However, the description does not explicitly mention alternatives or provide guidance on when not to use it (e.g., for reverting to a specific checkpoint, use checkpoint_restore). This is a clear but unstated 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 burden of behavioral disclosure. It states 'read-only query,' indicating no side effects, but does not elaborate on return format, potential staleness, or performance characteristics. Minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, and zero wasted words. The 'read-only query' tag is concise and adds behavioral clarity 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?
For a simple parameterless read-only query, the description is mostly complete. It names the returned data categories (position, rotation, state) but does not detail return structure or edge cases. Given no output schema, a bit more detail would help, but the low complexity keeps it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is trivially 100%. The baseline for zero parameters is 4; the description does not need to explain parameters, and none are missing.
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 viewport camera position, rotation, and state, with 'read-only query' clarifying its getter nature. It distinguishes from mutation tools but could be more distinct from sibling tools like viewport_camera or viewport_mode.
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 viewport_camera or viewport_screenshot. The 'read-only query' hint implies it is for querying, but no specific when-to-use/when-not-to-use instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral effects. It states the action and return value but does not mention side effects, such as whether the camera view is permanently changed, whether the operation is reversible, or what happens if the actor does not exist. This leaves uncertainty about the tool's impact on the scene.
Agents need to know what a tool does to the world before 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 entire description is a clean two-part sentence: it states the purpose and the return value. Every word earns its place, with no redundant wording 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?
The tool is relatively simple (2 params, no output schema, no annotations), and the description covers the core behavior and return info. However, it lacks context about side effects, potential errors, and how it differs from sibling camera tools, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description does not add meaningful parameter semantics beyond what the schema already provides; it only restates 'named actor' concept but does not clarify distance, default values, or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Focus' with a clear resource ('viewport camera') and object ('named actor'), making its purpose unambiguous. It also distinguishes from siblings like 'viewport_fit' and 'viewport_look_at' by emphasizing the named actor target and the return of bounding box.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: focus the camera on a named actor. However, there is no explicit guidance on when to choose this tool over similar siblings like 'viewport_look_at' or 'viewport_fit', nor any mention of exclusions or prerequisites.
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 discloses that the tool mutates the blueprint and performs compile and save operations. However, it does not clarify behavior if the interface already exists, whether it is additive, or error conditions, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that front-loads the primary verb and object, and includes the important side effects (compile and save) without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully documented parameters, the description covers the core action and immediate side effects. However, it omits details about prerequisites (e.g., blueprint must exist) and return behavior, but the absence of output schema and annotations is partially compensated by the schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with clear descriptions (100% coverage). The description adds no parameter-level meaning beyond saying 'on a Blueprint,' so it does not improve on what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Implement a Blueprint Interface on a Blueprint') and notes it compiles and saves, clearly distinguishing it from sibling tools like blueprint_add_variable, blueprint_add_function, and blueprint_remove_interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., blueprint_remove_interface) and no prerequisites or exclusions. It simply states the action without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does state that the tool will 'compile and save' after renaming, which is a meaningful side effect. However, it does not address error cases, name uniqueness requirements, or impact on references, 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 a single concise sentence that front-loads the primary action. Every word earns its place, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple rename tool with no output schema and no annotations, the description provides the core action and a key side effect. However, it lacks context about prerequisites, failure modes, or what happens to references, which would enhance completeness but is not strictly required for basic 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 only 33% (only blueprint_path is described). The description does not elaborate on old_name or new_name beyond what the tool name implies, nor does it provide any constraints or valid values. Since coverage is low and the description fails to compensate for the missing parameter details, it falls short.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 (rename a component), the target resource (SCS node on a Blueprint), and the follow-up side effects (compile and save). This distinguishes it from sibling tools like blueprint_component_remove and blueprint_node_set_enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is implied by its name and description, but there is no explicit guidance on when to use it over alternatives, nor any exclusions or prerequisites. It does not mention, for example, when to prefer blueprint_node_move or blueprint_node_set_enabled instead.
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 disclose behavioral traits. It explicitly mentions the significant side effects of compiling and saving, which is helpful for a mutation tool. However, it omits error behavior, permissions, and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and every word contributes to understanding the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is sparse. It covers the main action and side effects but does not explain graph_name usage or potential errors, leaving it minimally complete for a 4-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 schema only describes blueprint_path (25% coverage). The description adds minimal semantics by referencing GUID for node_guid and enable/disable for the enabled boolean, but graph_name remains unexplained and other parameter details are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 (enable/disable), target (a node by GUID), and side effects (compile and save). It is specific and distinguishes from sibling tools like blueprint_node_add and blueprint_node_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies the tool is for toggling a node's enabled state, but it provides no explicit when-to-use or alternative guidance. It lacks exclusions or references to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It states 'Create a ... asset,' which indicates a write operation, but it does not specify whether existing assets are overwritten, whether permissions are needed, or what error behaviors occur. This is insufficient for a tool that creates files in a content directory.
Agents need to know what a tool does to the world before 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: one sentence states the purpose, and a second sentence details presets and parameter options. No filler or repeated schema information. It is instantly scannable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 21 parameters, no annotations, and no output schema, the description is too high-level. It provides an overview of presets and parameter categories but does not cover critical operational details such as defaults, required fields (though none are required), conflict resolution, return behavior, or failure modes. An agent would need to infer too much before invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some value beyond the schema by grouping parameters (e.g., 'rot_pitch/yaw/roll_amp/freq', 'loc_x/y/z_amp/freq') and listing preset names. However, schema coverage is only 33%, and the description does not explain the meaning or units of many parameters (e.g., duration, blend times, shake_scale), so it only partially compensates for the low 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 with a specific verb and resource: 'Create a CameraShake Blueprint asset.' It also lists available presets and the types of oscillation parameters, which distinguishes it from sibling tools like camera_shake_play or camera_shake_spawn that appear to operate on existing shakes.
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 create a CameraShake Blueprint asset. It does not explicitly mention alternatives, but the 'Create' action and asset context are sufficient to differentiate from runtime shake tools. No misleading or contradictory guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'replace[s]' rows and 'save[s]', indicating a mutation, but does not disclose whether the operation is destructive, whether it requires specific permissions, or what happens to the existing table structure. Returns are mentioned but side effects are not elaborated, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and return value. Every word contributes meaning, with no redundancy or filler. It is an appropriately concise summary for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the purpose, the operation, and the return value sufficiently. It doesn't explain error conditions or detailed row format, but given the tool's simplicity, it is mostly complete. Missing usage guidance is handled under another dimension, so this remains reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with 'data_table' already described as 'DataTable asset path.' The description adds context for 'rows_json' by saying 'from DataTable JSON', which implies the expected format, but it does not detail the JSON structure or array/string variants. This partially compensates for the schema gap but leaves room for more explicit 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 ('Replace an existing DataTable's rows from DataTable JSON, then save') and the return value ('Returns the resulting row names'). It distinguishes from the sibling tool 'data_table_create' by explicitly referencing an existing DataTable, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing DataTable' implies this tool is for modifying an already-created table, providing some usage context. However, it does not explicitly state when to use this versus alternatives like 'data_table_create', nor does it mention exclusions or prerequisites beyond the existence of the table. This is enough for basic usage but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic purpose and does not describe what the returned documentation looks like, whether the output is a list or a formatted text block, or that omitting tool_name returns all tools. This is a significant lack of transparency beyond the bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately concise for a tool with a single optional parameter and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only help tool with one optional parameter and no output schema, the description is adequate. It covers the tool's core function, and the schema fills in parameter details. It could elaborate on the returned documentation format, but given the low complexity, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter tool_name is described as 'Specific tool to get help for. Omit for all tools.' The description adds no additional semantics beyond this, so the baseline 3 is appropriate where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show documentation for available tools' uses a specific verb ('Show') and a clear resource ('documentation for available tools'). It unambiguously indicates this is a help tool and is distinct from siblings like project_info or asset_info, which focus on specific data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—call this tool when you need help understanding other tools—but it does not explicitly state when to use it vs. alternatives or mention the optional tool_name parameter's behavior. There is no exclusions or alternative tools referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing side effects. It does reveal that changes persist to Config/DefaultInput.ini and gives key format examples, which are useful. However, it does not disclose overwrite behavior, conflict handling, or whether a project reload is required, leaving significant behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the core action, file target, and key format examples. There is no waste; every phrase contributes useful 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?
For a mutation tool with 8 parameters and no annotations, the description is adequate but incomplete. It covers the fundamental action and persistence location, but lacks detail on parameter semantics, duplicate behavior, and effects on existing mappings. The absence of an output schema and annotations adds burden that this description does not fully meet.
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 low (38%), and the description does not compensate. It provides FKey string examples for the key parameter, but does not clarify the meaning of modifier flags (alt, cmd, ctrl, shift), the kind enum (beyond schema), or the scale parameter beyond the schema's terse description. Most parameter semantics remain 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 uses a specific verb 'Add' and identifies the resource ('action or axis mapping to project input settings'). It also distinguishes from siblings like input_mapping_remove and input_mapping_info by clearly framing this as the add operation. The mention of the target file adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to project input settings' implies the use case of adding a new mapping, but there is no explicit guidance on when to use this tool versus alternatives like input_preset_apply or input_mapping_remove. No exclusions or alternatives are mentioned, leaving the agent to infer from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior that settings merge with existing values, meaning unspecified parameters remain unchanged. It also implies non-creation by 'existing'. However, without annotations, it lacks information about error behavior, required permissions, or side effects beyond merging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant phrasing. It gets straight to the point and avoids 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?
The tool has a complex nested settings schema, but the description only covers the merge behavior and existing-volume prerequisite. It doesn't mention that actor_name is required or what happens if the volume doesn't exist. The schema provides rich detail on settings, but the description leaves gaps for successful 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 low (33%), and the description doesn't explain individual parameters beyond stating that settings merge. The merge semantics clarify that the settings object is a partial update, but actor_name, unbound, priority, blend_radius, and blend_weight are left to the schema with minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Modify') and resource ('existing PostProcessVolume's settings'), clearly distinguishing from pp_volume_spawn and pp_preset. The phrase 'existing' indicates this acts on already-created volumes, not creating new ones.
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 adjusting an already-created PostProcessVolume, but doesn't explicitly state when not to use it or name alternatives like pp_volume_spawn or pp_preset. The 'merge' hint is useful for partial updates, but no explicit when-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It reveals that the tool modifies the .uproject and checks restart requirements, but does not mention additional side effects, failure modes, or permissions. This is a moderate level of transparency, better than a bare 'Enable plugins' but lacking deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Enable one or more plugins') and includes the important outcome (restart reporting). Every phrase earns its place; no fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter, no output schema, and no annotations, the description covers the essential function and the key behavioral outcome. It lacks thorough error-handling or prerequisite info, but given the low complexity, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'plugins' parameter, including its type (string or array of strings) and description. The tool description adds no extra semantic detail beyond what the schema already states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Enable') and resource ('plugins in the current .uproject'), and further specifies an outcome (reporting whether an editor restart is required). This distinguishes it from all other sibling tools, which focus on different project assets or 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 explicit guidance on when to use this tool versus alternatives, or any prerequisites/conditions. It only states the action and result, leaving the agent to infer usage from the name and description 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?
No annotations are provided, so the description must carry the behavioral burden. It states the core behavior (compare images and report pixel error) and the optional full-image vs. region scope. However, it does not disclose output format, units, error conditions, or prerequisites, leaving notable behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the action, inputs, and output scope. Every word contributes meaning, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should clarify the return value, but it only says 'report pixel error' without specifying format, magnitude, or structure. It also does not mention any prerequisites or assumptions about image formats or paths. This leaves the tool under-specified for an agent to fully anticipate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers reference_path and render_path with short descriptions, giving 67% coverage. The description mentions the 'full image or region' capability, which hints at the region parameter's optionality but does not explain its format (e.g., order or meaning of the four integers). Thus the description adds minimal semantic value beyond the schema for the region 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 uses a specific verb ('Compare') and clearly identifies the resources (UE-rendered title frame vs. reference still) and the output (pixel error). It also distinguishes this from siblings like title_manifest_validate, which is about manifest validation rather than visual comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a rendered title frame needs to be compared to a reference still) but does not explicitly state alternatives or exclusions. No sibling tool appears to perform a similar pixel comparison, so there is no direct alternative named, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects or constraints. It only states the action and options, omitting whether it resets zoom, affects camera orientation, or has any irreversible consequences. This is a minimal behavioral disclosure for a tool that mutates viewport state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and immediately lists the available options. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one enum parameter and no output schema. The description covers the essential behavior and enumerates all allowed values. It omits minor details like side effects, but for this low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with an enum and description 'View mode'. The tool's description lists the enum values, but adds no extra semantics about the meaning of each mode or how they affect the view. Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'switch' and the resource 'standard view', then enumerates the exact view options (top, front, right, left, back, bottom, perspective). This unambiguously distinguishes it from sibling tools like viewport_camera or viewport_render_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 setting standard viewport orientations but does not explicitly contrast with alternatives such as viewport_camera or viewport_look_at. There is no when-not-to-use guidance, leaving the agent to infer the appropriate context from sibling names.
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 alone must disclose behavior. It indicates a mutation ('Change') but gives no details on side effects, persistence, or what happens when a mode is selected. The list of modes is factual but not 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?
One sentence, front-loaded with the action, and the list of modes is the minimal required content. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description sufficiently captures the operation and options. However, missing behavioral details like whether the change persists or affects rendering only the current session slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides the enum and description for the single parameter. The description repeats the enum values but adds no additional meaning about their semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Change') and resource ('viewport render mode'), and enumerates the exact modes. Clearly distinguishes from sibling tools like viewport_mode, viewport_screenshot, etc., by naming its unique action.
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 direct command, but does not explicitly state when to use this tool vs alternatives, nor any exclusions. Given many viewport siblings, clearer guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the creation intent but does not disclose whether existing assets are overwritten, required permissions, or any side effects. The verb 'Create' implies a write operation, but the lack of detail about what happens to an existing asset with the same name is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the core purpose without any redundant wording. Every word earns its place, and it is appropriately concise for a creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, nested color objects, no output schema, no annotations), the description is far too thin. It does not mention asset naming/overwrite behavior, package path semantics, or return values. The many font size and color parameters are left entirely unexplained, and the absence of an output schema means the description should have provided at least a hint about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must compensate for the undocumented parameters. It adds context for title, subtitle, and fade durations, which maps to several properties, but does not clarify the many color, font size, package_path, and asset_name parameters that lack schema descriptions. This partial compensation is insufficient for the number of opaque parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a specific resource 'broadcast-style lower-third Widget Blueprint', and further details the styled title/subtitle text and FadeIn/FadeOut animation specs. This clearly distinguishes it from generic widget creation tools and even from titles-related siblings like widget_title_card_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating a lower-third widget, which is helpful. However, it does not explicitly state when to use this tool over alternatives such as widget_build_from_json or title_widget_build_from_manifest, nor does it mention any 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 the burden. It discloses that validation results are returned by default (useful given the validate parameter), but does not explain failure behavior, whether the original is modified, or permissions. It adds some transparency but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no unnecessary words. Efficient 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 tool with 4 parameters and no output schema, the description is somewhat brief. It covers core purpose and default validation behavior, but lacks information about return results, edge cases, and relationship to sibling spawn/modify tools. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds only 'optional offset' which is already implied by the schema's required list. No additional semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplicate') and resource ('existing actor'), plus optional offset, making it distinct from sibling tools like actor_spawn, actor_delete, or actor_modify. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case - duplicating an actor - but does not mention when to prefer this over alternatives such as actor_spawn or actor_modify, nor provides exclusions. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds that the tool returns validation results by default, which clarifies the validate parameter's effect, but it does not mention prerequisites, error behavior, or the actual world modification. The transparency 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 concise sentences, front-loaded with the primary action. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters including nested objects but no output schema or annotations. The description provides a high-level summary and mentions validation results, but it fails to clarify default transform values or the nature of validation output. Given the 100% schema coverage, it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All seven parameters have descriptions in the schema, giving 100% coverage, so the baseline is 3. The description only references asset_path and location/rotation/scale generically without adding new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool spawns a single actor from an asset path with optional location, rotation, and scale. The verb 'Spawn' is specific and distinguishes this from sibling tools like actor_duplicate or level_actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for spawning a single actor, but it does not explicitly state when to prefer it over batch_spawn or mention exclusions. Usage context is implied rather than directly guided.
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 transparency burden. It only says 'Rebuild navigation data' without disclosing potential side effects, performance costs, or whether this invalidates existing nav data. The parenthetical command reference adds a little clarity but not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It states the action, target, scope, and an equivalent console command in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, so the description is mostly adequate, but it lacks information about prerequisites, side effects, or what happens after rebuild. Given no output schema and no annotations, a bit more context about the rebuild's impact 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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema is empty and there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Rebuild') and target resource ('navigation data in the loaded level'). It distinguishes this from sibling tools like project_index_rebuild by explicitly focusing on navigation data within the level.
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 by mentioning 'in the loaded level,' but it does not explicitly state when to use this vs. alternatives, nor does it mention any prerequisites or exclusions. Basic context is present but no clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool 'Compiles and saves' the blueprint, which is a key side effect, and notes that asset assignment and auto-activate are optional. However, it does not explain behaviors such as overwriting existing components or failure modes, leaving some transparency 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 two short sentences, front-loaded with the action and no filler. Every phrase adds value, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and the description covers the main operation and side effects but omits details like prerequisites, error behavior, or what the return value is. Given the moderate complexity and lack of annotations, the description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 4 of 5 parameters (80%), and the description echoes 'optional' for sound and auto_activate. It adds little beyond the schema, such as clarifying blueprint_path, so the parameter semantics are adequately but not richly conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') with a clear resource ('AudioComponent to a Blueprint'), and mentions optional asset assignment and auto-activate. This distinguishes it from sibling tools like blueprint_component_remove or blueprint_node_add, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly say when to use it or provide exclusions. The context implies it is for adding audio components, but no alternative tools are mentioned, so the agent must infer usage from the 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.
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 explicitly states the destructive action (breaking links) and the side effects (compiling and saving the blueprint), which goes beyond merely inferring from the tool name. However, it does not cover reversibility, error handling, or effects on dependent nodes.
Agents need to know what a tool does to the world before 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 13-word sentence that front-loads the primary action and includes the key side effects. It is efficient and free of unnecessary words, earning a top score for 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?
For a tool with 4 required parameters, no annotations, and no output schema, the description is too sparse. It does not document 3 of 4 parameters, does not mention prerequisites (e.g., graph loaded), and does not describe success/failure behavior or return values. This makes the description insufficient for an agent to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only blueprint_path is described), and the tool description does not explain the other three parameters (pin_name, node_guid, graph_name). The parameter names are somewhat self-explanatory, but the description fails to add meaning beyond the schema, leaving a significant gap for three required 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 a specific action ('Break all links on a single pin of a node') and the additional behavior ('compile and save'). This distinguishes it from siblings like blueprint_pins_connect, which connects pins instead of breaking them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for disconnecting pins, but it does not explicitly state when to use it over alternatives such as blueprint_pins_connect, nor does it provide exclusions or prerequisites. The usage context is clear from the name and description but not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the PIE-only limitation and the radius-based behavior, which is useful context. However, it omits side effects, persistence of the spawned actor, potential idempotency issues, or what the agent can expect as a result, leaving significant transparency 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 two sentences, front-loaded with the primary action, and contains no wasted words. Every phrase adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (including a nested location object), no output schema, and no annotations. The description lacks crucial operational details such as how to specify location, what shake_class should contain, whether parameters are optional, and what the tool returns. It is too incomplete for an agent to reliably invoke without further investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate. It only refers to 'inner/outer radius', which partially explains those parameters, but provides no added meaning for 'name', 'location', or 'shake_class'. The schema's own descriptions for these fields are minimal, and the description adds little beyond reinforcing the radius concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: 'Spawn a CameraShakeSourceActor in the level.' It specifies the resource (CameraShakeSourceActor) and distinguishes from sibling tools like camera_shake_play and camera_shake_trigger by mentioning the emission within radii during PIE.
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 ('during PIE') and the tool's behavior (emits shake within inner/outer radius), indicating when it is relevant. However, it does not explicitly mention exclusions or alternatives, such as using camera_shake_play for direct playback, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool 'Saves the table', which is important persistence behavior, and notes that filling is optional. However, it does not mention what happens if the table already exists, whether it overwrites or fails, or any permissions required. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and includes important details (optional rows, saving) without unnecessary verbosity. Every phrase 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?
The description adequately covers creation, optional filling, and saving. However, with no output schema and no annotations, it leaves out details like return value, error behavior, or relationship to sibling tools. For a tool with 4 parameters, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so most parameter meaning is already structured. The description adds an example JSON format for rows_json, which is helpful, but does not significantly enhance understanding beyond the schema properties. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action: 'Create a DataTable for a row struct'. It also mentions optional filling from JSON and saving, which specifies the resource and outcome. This distinguishes it from sibling tool 'data_table_fill_from_json' by emphasizing creation rather than just filling.
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: use when you need to create a new DataTable, optionally filling it with rows. However, it does not explicitly mention when to use an alternative (e.g., data_table_fill_from_json) or provide exclusions. The phrase 'optionally filling' hints that filling is not the primary purpose, but 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.
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, but it only states the action. It does not mention side effects (e.g., whether unsaved changes are discarded), behavior when no PIE session is active, or any return value. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tight sentence that precisely conveys the action without filler. Every word is necessary, and the structure is ideal for a tool with no 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's simplicity (zero parameters, no output schema), the description is minimally viable but leaves gaps: it does not specify prerequisites (e.g., an active session) or post-conditions. A short note about error behavior or state changes 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 tool has zero parameters and the schema is empty (100% coverage), so there is no need for parameter clarification. The description appropriately omits parameter details, aligning with the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('End') and identifies the resource ('current PIE session'), clearly distinguishing it from the sibling tool gameplay_pie_start. While 'PIE' is not expanded, it is a well-known term in Unreal Engine context, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and pair with gameplay_pie_start: this tool ends what the opposite starts. However, there is no explicit guidance on prerequisites (e.g., an active session) or alternatives, leaving the agent to infer when to invoke 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 discloses the side effect 'Saves the instance', but does not detail overwrite behavior, error handling, or requirements such as the parent material being valid, which are relevant for a mutating create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action and includes the key optional overrides. There is 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?
With no output schema and full parameter documentation, the description adequately covers the main action and the saving side effect. However, it omits important context like overwrite semantics and failure conditions, leaving some gaps for an agent deciding whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—all six parameters have descriptions. The description's 'optional scalar/vector/texture parameter overrides' maps to the corresponding params but adds no extra detail beyond what the schema already 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 uses the specific verb 'Create' with a clear resource 'MaterialInstanceConstant' and mentions optional parameter overrides. It distinguishes from siblings like material_create (creates a material, not an instance) and material_instance_set_params (sets parameters on an existing instance).
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 action 'Create' implies the use case (creating a new material instance), but the description does not explicitly mention alternatives or when not to use it. Sibling tools exist that could be confused, but no comparisons or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and behavior fully. It mentions the fallback mode (cached index vs fresh read) and that it compares snapshots, but does not state whether it is read-only, whether it triggers any index refresh, or what kind of output is returned. This leaves significant ambiguity about the tool's operational 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?
Two sentences, no redundant wording. It front-loads the core action and resource scope, then explains a key behavioral branch efficiently. Every clause adds meaningful 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 no output schema and no annotations, the description should explain return values and side effects. It covers the two operating modes and scope, but lacks any indication of output format, result details, or whether the operation modifies state. This is adequate but has clear gaps for a complex comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds a small semantic layer by explaining how omitted snapshots cause a fallback to cached-index-vs-fresh-read, which ties to the before_snapshot/after_snapshot parameters. This interaction adds value beyond the 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 compares indexed before/after snapshots for semantic changes, specifying resource types (Blueprints, widgets, materials, level actors, dependencies). This distinguishes it from sibling tools like project_index_query or asset_list by focusing on diffing snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for comparing snapshots or falling back to cached vs fresh data. However, it does not explicitly state when to use this tool over alternatives (e.g., project_index_query) or provide exclusions. The conditional behavior is clear but no guidance on choosing between tools 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 carries the burden of behavioral disclosure. It transparently mentions the return values, and 'ping' strongly implies a non-destructive read-only operation. However, it does not explicitly state that no changes are made, nor does it cover failure behavior or permissions, leaving some implicit assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates both the action and the returned data. Every word serves a purpose 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 low complexity (no parameters, no output schema, no annotations), the description covers the essential behavior and return values adequately. It could be slightly more explicit about what 'connection status' entails, but overall it is reasonably complete for a simple health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline per rubric is 4. The description adds no parameter information, but none is needed given the empty 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 the tool's action ('Ping the UE4 Python listener') and its return values (connection status, engine version, project info). However, it does not explicitly distinguish itself from siblings like 'project_info' which likely also returns engine/project info, so it falls short of full differentiation.
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 verb 'Ping' implies a connectivity check, so usage context is indirectly conveyed. Yet the description provides no explicit guidance on when to use this tool versus alternatives, and does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key side effect of persisting output to Saved/MCP/titles by default, but does not mention overwrite behavior, return values, or any validation process. This is moderate disclosure for a create/persist 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?
Two sentences, both informative and front-loaded with the primary function and default output path. No wasted words or redundant 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?
For a tool with 8 parameters and nested objects, the description provides only a high-level overview. It does not clarify return values (no output schema) or the relationship between top-level parameters and the nested 'manifest' object. It covers the essential purpose and default path but leaves gaps for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds a high-level summary tying together normalized screen boxes, frame timing, and style metadata. However, it does not explain individual parameters or the relationship between 'cues' and 'manifest' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Create and persist' and identifies the resource as a 'JSON title manifest'. It also mentions key inputs (normalized screen boxes, frame timing, style metadata) and default output path, clearly distinguishing it from sibling tools like adjust or validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating and persisting manifests but provides no explicit when-to-use guidance or alternatives. It does not mention when not to use it or how it relates to sibling tools like title_manifest_adjust or title_manifest_validate.
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 behaviour. It explicitly states that the tool compiles and saves after adding the variable, which is a significant side effect. However, it does not mention permissions, duplicate variable handling, or failure modes, so it only partially covers behavioural transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the action and includes the important compile/save behaviour. 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?
The tool is a mutation with a nested type parameter, but the schema fully specifies parameter semantics, and the description covers the core operation and its side effects. It slightly lacks context about what happens if the variable exists or how to revert, but it is complete enough for a well-documented schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all five parameters, including the nested type descriptor with categories and container types. The description adds no additional information about parameters, but the schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'member variable to a Blueprint', and distinguishes it from sibling tools like blueprint_remove_variable by specifying the add operation. It also mentions the follow-up compile and save steps, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implied usage context: it is for adding a variable to a Blueprint. However, it does not explicitly mention when to choose this over alternatives such as blueprint_set_variable_default or blueprint_add_function, nor does it list any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: links are broken first, and the blueprint is then compiled and saved. This goes beyond a simplistic 'deletes node' and informs the agent of the mutation scope and ordering, though it stops short of noting error cases 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and packs the essential side effects into a short parenthetical and concluding clause. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with three required parameters and no output schema, the description covers the core workflow and side effects but omits expected return behavior, failure scenarios, or any prerequisites related to graph_name and blueprint_path. It is adequate but not fully complete for an agent to predict all invocation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only blueprint_path is described), and the tool description adds little parameter-level detail beyond mentioning 'GUID' for node_guid. It does not explain graph_name or how blueprint_path is used, so the description fails to compensate for 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 a specific action ('Delete a node by GUID') on a specific resource (a blueprint node), plus the subsequent side effects of compiling and saving. This distinguishes it from sibling tools like blueprint_node_move, blueprint_node_add, and blueprint_node_set_enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to delete a node by GUID and have it break links, compile, and save) but does not explicitly mention alternatives or when not to use it. No exclusions or sibling comparisons are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It transparently discloses that moving a node also triggers 'compile and save', which is a significant side effect. However, it does not elaborate on failure modes or whether the operation is reversible, leaving some gaps in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is entirely on-topic and front-loaded. It conveys the core action and side effects without any redundant or irrelevant wording, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the main purpose and side effects for a relatively simple tool, but lacks completeness in some areas: it does not mention prerequisites (e.g., blueprint must exist), what happens on failure, or the return value. Given the absence of annotations and output schema, these gaps prevent a higher score, though the description is sufficient for basic 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?
Schema description coverage is only 50%, with graph_name and node_guid lacking descriptions. The description does not compensate for these missing parameter explanations; it only restates the action ('Move a node to a new graph position') without clarifying what each parameter represents. The schema already covers position and blueprint_path, so the description adds no new 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 primary action: 'Move a node to a new graph position', using a specific verb and resource. It also adds the distinct side effects 'compile and save', which differentiates it from sibling tools like blueprint_node_add or blueprint_node_set_enabled. This leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when repositioning a node in a graph, but provides no explicit guidance on when to use this tool versus alternatives like blueprint_node_set_enabled or blueprint_compile. There are no stated exclusions or comparisons to siblings, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose the additional behavior of compiling and saving after removal, which is useful. However, it does not mention whether the operation is irreversible, if it requires specific permissions, or what happens if the function graph does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word adds value, and it avoids restating the tool name or schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and no output schema, the description fully explains what it does and its side effects. It is adequate for the simplicity of the operation, though it could mention irreversible consequences or error behavior for extra completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value by indicating the 'name' parameter is used for identifying the graph, but it does not elaborate on 'blueprint_path' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (remove), the resource (user function graph), and the method (by name), followed by side effects (compile and save). This distinguishes it from sibling tools like blueprint_add_function or blueprint_compile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to remove a user function graph by name, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. No mention of alternative tools or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It mentions 'deterministic heuristics' and 'indexed' sources, providing some insight into how it works. But it does not disclose that results may rely on a cached index (only hinted by the 'fresh' parameter), nor does it explain any potential staleness or performance implications. This is adequate 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 two concise sentences, front-loaded with the action ('Find') and the resource ('reusable gameplay patterns...'). The list of pattern types is useful and placed compactly. 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 a non-mutating search tool with 100% schema coverage, the description provides sufficient context for selection: it clarifies scope (indexed Blueprints/widgets/level actors), method (deterministic heuristics), and example patterns. However, it omits any mention of return structure or result ordering, which would be helpful since there is no output schema. Still, for the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description lists pattern types that directly mirror the enum values in the schema, offering little additional semantic value. It does not clarify the 'fresh' or 'path_prefix' parameters beyond their schema descriptions, so the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding reusable gameplay patterns in indexed Blueprints, widgets, and level actors. It lists specific pattern types, distinguishing it from sibling tools like project_index_query or blueprint_inspect by focusing on high-level gameplay heuristics rather than raw asset queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description: it is used when you need to locate gameplay patterns such as overlap logic or key-door flows. However, it does not explicitly state when to use this tool versus alternatives like project_index_query or blueprint_build_from_description, leaving some ambiguity for an agent selecting among 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 of behavioral disclosure. It honestly states that the subprocess is terminated, implying irreversibility, but does not mention what happens if the job is not running, whether cancellation is asynchronous, or any side effects on job status. It adds useful context but is 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 a single sentence with a parenthetical clarification. Every word is useful, the action is front-loaded, and there is no redundant or filler text. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description provides the core action and effect but lacks guidance on locating job_id and handling edge cases like already-completed jobs. It is adequate for simple usage but has clear gaps in 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?
Schema description coverage is 0%, so the description must compensate. It does not explain job_id beyond its name, nor does it mention how to obtain it (e.g., via job_list). The description adds no parameter-specific meaning, which is a gap for a 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?
The description uses a specific verb 'Cancel' and a clear resource 'running background job', while the parenthetical 'terminates its subprocess' adds precise behavioral detail. This distinguishes it from sibling tools like job_status and job_list, which concern querying rather than mutating jobs.
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 indicates that this tool applies to 'running' background jobs, which provides context for when to use it. However, it does not explicitly name alternatives or mention exclusions, such as 'use job_list to find job_ids' or 'not for completed jobs', though the target context is reasonably 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 carry the transparency burden. The verb 'List' and the return-field sentence imply a read-only operation and describe outputs, but the description does not disclose default limits, pagination, or explicitly state that it makes no modifications. This is adequate for a simple read tool but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the purpose, scope, and return values without any redundant or filler 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?
For a straightforward read/list tool with a fully documented schema, the description covers the key context: current level, optional filters, and returned fields. It does not mention edge details like default inclusion of transforms, but the schema provides those specifics, making it acceptably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all six parameters, so the description adds little beyond the generic phrase 'optional filters.' With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('List actors in the current level') and clearly states the resource and scope, distinguishing it from mutation tools like actor_spawn or actor_delete. It also lists return fields (name, class, folder, optional transforms/components), 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving actors from the current level, but it does not explicitly compare this tool with sibling tools such as level_outliner or state when to prefer one over the other. It provides clear context but no exclusionary or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 uses the read-only verb 'Return,' indicating no mutation, but it does not clarify whether actor counts are recursive or direct-only per folder, nor how invalid root_folder values are handled. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of about 15 words, front-loading the verb and resource. Every word earns its place with no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query with one optional parameter and no output schema, the description gives a clear high-level result and is distinct from siblings. It does not detail the exact response format or count scoping, but it is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single optional parameter with a description ('Optional subtree root to start from'), meeting the high coverage baseline. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and names the resource 'World Outliner folder tree structure' with the further detail 'actor counts per folder.' This clearly differentiates it from sibling tools like level_actors (which lists actors) and actor_organize (which modifies folders).
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 folder hierarchy, but it does not explicitly state when to prefer this over alternatives like level_actors. There are no exclusions or alternative tool references, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that it 'uses existing read-only bridge handlers,' indicating no mutation of source assets, and it writes to Saved/MCP/index. However, it does not disclose whether the rebuild is destructive to the existing index, whether it is incremental, or any performance/cost implications. With no annotations, the description carries the full burden but provides only moderate 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?
Two sentences, front-loaded with the verb, no wasted words. Every phrase adds value: target location, scan scope, and safety mechanism (read-only handlers).
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 provides the purpose, location, scan scope, and safety mechanism for a tool with six optional, well-documented parameters and no output schema. It lacks details like return values or whether the operation is synchronous, but the core context is sufficient. Given no annotations, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions, so the baseline is 3. The description does not add parameter-level details beyond what the schema already provides; it merely lists the categories scanned, which maps to the 'categories' parameter but without specific 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 (rebuild), the specific object (project intelligence index), and its location (Saved/MCP/index). It also enumerates the scan scope (assets, Blueprints, etc.), which distinguishes it from siblings like project_index_query and project_semantic_diff.
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 guidance or alternatives are provided. The verb 'Rebuild' implies it is used to refresh the index after changes, but the description does not mention when to use it vs querying or diffing the index. Usage is implied rather than directed.
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 safety and side effects. It does reveal the dry_run behavior (returns spec without creating an asset), which is valuable. However, it does not mention whether the tool overwrites existing assets, requires specific permissions, or what happens on failure. The core 'Build' action implies mutation but lacks detail on reversibility or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main purpose and clearly states the dry_run alternative. No wasted words, perfect for quick scanning.
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 6 parameters, nested objects, and no output schema, yet the description omits several key aspects: how to supply the manifest (object vs. manifest_path), what the non-dry-run build returns, overwriting behavior, and any prerequisites. The description is too brief for the tool's complexity, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description should help clarify remaining parameters. It clarifies 'manifest' and 'dry_run' somewhat, but does not explain 'id', 'asset_name', 'package_path', or 'manifest_path'. The meaning of those parameters is partly inferable from names and defaults, making the overall semantics adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: building WBP_TitleRenderer from a title manifest. It also distinguishes the dry_run mode for generating a widget spec instead of creating an asset. This is specific and differentiates it from sibling tools like widget_build_from_json or title_manifest_create.
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 have a title manifest and want to build the WBP_TitleRenderer widget. It does not explicitly state when not to use it or mention alternatives, but the context of 'manifest' and the dry_run option provide clear usage context. No exclusions or alternative recommendations are given, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses the default behavior for empty actor_names ('fits all actors in the level'), but it does not state whether the operation changes the camera, modifies actors, or has side effects. This adds some context but lacks comprehensive transparency for a viewport 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: the first states the core purpose, and the second adds a crucial behavioral detail. It is front-loaded, concise, and every word earns its place. There is no redundancy or 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?
For a simple tool with two optional parameters and no output schema, the description covers the main aspects: what it does and the default behavior. It lacks explicit details like whether it affects the camera or requires an open level, but given the tool's simplicity and the rich schema, this is largely complete. A 4 reflects that it could add a bit more context about the operation's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both padding and actor_names have descriptive schema entries, including the default padding multiplier and the empty-for-all meaning. The description adds only a minor clarification that 'omitted' also fits all actors, which the schema's optional property partially implies. The baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fit actors into the viewport frame.' This is a specific verb+resource combination that distinguishes it from sibling tools like viewport_focus or viewport_bounds. It also clarifies the default behavior when actor_names is empty, which adds purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly say when to use it versus alternatives. There is no mention of when not to use it or references to other viewport tools. The guidance is purely implied: an agent can infer it should be used when actors need to be framed in the viewport.
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 discloses the main action (creates the asset, populates the anim graph) but omits critical behavior such as whether an existing asset is overwritten, required preconditions (e.g., skeleton compatibility), or failure modes if the JSON is invalid. This is a significant gap for a build tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and outcome, with no redundant or filler content. Every phrase 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?
The tool has moderate complexity, no output schema, and no annotations. The description explains the creation and population of the graph but lacks details on overwrite behavior, return values, or error handling. It is adequate but leaves clear gaps given the absence of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The description adds extra meaning by elaborating what the json_spec contains ('state machines, blend spaces, slots, etc.'), which helps the agent understand the expected input beyond the generic 'JSON specification string' in the schema. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and identifies the resource ('Animation Blueprint from a JSON specification'). It clearly distinguishes from siblings like blueprint_build_from_json by specifying Animation Blueprint and AnimBP asset, making the tool's scope 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 clearly indicates the tool is for building Animation Blueprints from JSON, which is a specific use case. It doesn't explicitly mention alternatives or exclusion cases, but the naming and context (vs. blueprint_build_from_json) provide clear guidance on 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. The term 'Inspect' implies read-only behavior, but the description doesn't explicitly state that no modifications are made, what the return format is, or behavior when no filters are supplied. This is a notable gap, but the inspection nature is somewhat self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the purpose, the second gives a practical use case. All content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description gives the essential purpose and a concrete use case, but it does not describe return values or behavior with no filters. This leaves moderate ambiguity, making it minimally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for each parameter (e.g., 'Exact key name to filter, such as Escape'), so the baseline is 3. The description adds a combined example of action and key (PF_Pause to Escape), which provides some relational context but no additional semantic detail beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Inspect Unreal input action and axis mappings.' It distinguishes from siblings input_mapping_add/remove by focusing on inspection, and gives a concrete example (PF_Pause to Escape) to illustrate 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?
Provides a specific use case: 'Use this to validate bindings like PF_Pause to Escape when physical key injection is unavailable.' This states when to use but doesn't explicitly name alternatives or when-not conditions, so it falls short of a fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It states the mutating nature ('set') and the persistence ('then save'), but does not explain whether parameters are overwritten entirely, what happens if a parameter name is invalid, or any side effects on the asset's saved 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?
One sentence, front-loaded with a specific verb and resource, and no filler. It efficiently conveys the core operation and the save step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is relatively thin for a tool involving 4 parameters and nested objects. It conveys the essential action but omits details like error behavior, whether all parameters must be overridden or only provided ones, and what the saved outcome looks like. Still, it is adequate for straightforward invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptive text for each parameter, including types and structure. The description groups parameters into scalar/vector/texture, which adds minimal additional meaning beyond the schema's own 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 the specific action ('Set scalar/vector/texture parameters') and the resource ('existing material instance'), distinguishing it from sibling tools like material_instance_create (creation) and material_apply (applying a material). The inclusion of 'then save' adds a clear end-to-end behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the context: modifying parameters on an existing material instance. This implies it is not for creating new instances or applying materials, which are covered by sibling tools. However, it does not explicitly name alternatives or state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It notes the index is 'cached,' implying results may not be live, which is useful. However, it does not explicitly state that the operation is read-only or non-mutating, nor does it mention potential side effects or data freshness issues. The description adds some transparency 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 two sentences, front-loaded with the verb 'Search' and a clear object. Every word contributes to illustrating the tool's function and usage context. It is appropriately sized, with no redundant phrases or filler, 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?
The tool has 5 parameters, no output schema, and no annotations, so the description should compensate by explaining return values or execution behavior. It covers purpose and when to use, but fails to indicate what results look like (e.g., list of paths, JSON objects) or any limitations of the cached index. This gap in the absence of an output schema makes the description incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description mentions types of content to search (assets, Blueprints, dependencies, patterns), which loosely maps to the 'category' enum but does not add meaning beyond the schema. It neither explains parameter nuances nor provides examples, so it converges to the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the cached project intelligence index.' It specifies the resource (cached project intelligence index) and the purpose (finding assets, Blueprint structures, dependencies, patterns). The qualifier 'cached' distinguishes it from build/rebuild tools like project_index_rebuild, 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 clear usage context: 'Use this before editing to find existing assets, Blueprint structures, dependencies, and patterns.' This explicitly recommends using the tool in a specific workflow. However, it does not name alternative tools or state when not to use it, so it lacks explicit exclusions but offers clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implicitly signals a read-only operation through 'List' and specifies the output content fields, but it does not explicitly state side effects, error conditions, or ordering behavior. This leaves some ambiguity for a completely self-contained description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and no redundant words. Every phrase adds value, making it highly 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 simple zero-parameter list tool with no output schema, the description is complete: it names the source directory and lists the exact fields each entry shows. No additional return-value explanation is needed beyond these fields, and the low complexity does not require more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so no parameter documentation is needed. The baseline for zero-parameter tools is 4, and the description adds no parameter-related information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'previously generated build specs', and the scope 'from the PromptBrush output directory'. It also defines the output fields, distinguishing it from siblings like prompt_status and prompt_generate.
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 prompt_status or prompt_generate. No prerequisites, exclusions, or recommended scenarios are mentioned, so the agent is left to 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior (restart listener without restarting Unreal) but does not mention side effects like dropped connections, prerequisites (listener must be running), or whether it is a blocking operation. With no annotations, more detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no fluff. Every word is purposeful.
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 restart tool, the description covers its core purpose and usage context. However, it lacks mention of return values/behavior (e.g., success/failure output) and any prerequisites. Given the lack of output schema and annotations, slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (host and port) with defaults, so the description adds no extra parameter meaning. The baseline of 3 applies since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restarts the Python listener and explicitly distinguishes it from restarting Unreal. This is a specific verb+resource combination that sets it apart 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 clear guidance on when to use the tool ('Use after modifying listener code'). It does not name alternatives or when-not-to-use conditions, but the usage context is explicit.
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 must carry the full burden of behavioral disclosure. It explicitly mentions that the tool compiles and saves the Blueprint, which is a notable side effect. However, it does not describe what happens on name collisions, whether the Blueprint must be loaded, or any permission requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create an event dispatcher') and compactly conveys the optional signature and compile/save steps. There is no wasted content, and it is 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?
Given the lack of an output schema and the moderate complexity of the nested signature object, the description is reasonably complete: it explains the primary action, the optional signature, and the follow-up compile/save. It doesn't describe return values or error cases, but for a create operation the core behavior is covered sufficiently. A small gap remains around expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-documented in the schema. The description mentions 'optional parameter signature' which aligns with the 'signature' parameter, but adds no new semantic detail beyond what the schema provides. Hence a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') with a specific resource ('event dispatcher (multicast delegate)') and includes the key behavior of compiling and saving. It distinguishes itself from sibling tools like 'blueprint_remove_event_dispatcher' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for creating a new event dispatcher in a Blueprint. It doesn't explicitly mention when to avoid using it or name alternatives, but the action is unambiguous and well-scoped. No exclusions are stated, but the purpose itself provides sufficient 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 are provided, so the description carries the full behavioral burden. It explicitly discloses that the tool compiles and saves the Blueprint, and that it returns the graph name. This is meaningful side-effect disclosure for a mutation tool, though it does not mention potential failures or overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action, includes the key parameters, mentions side effects, and states the return value. 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?
With a rich schema and no output schema, the description adequately covers the operation: creation, compile, save, and return value. It lacks only minor contextual details like whether the Blueprint must already exist or if an existing function with the same name is overwritten, but overall it is sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed descriptions for blueprint_path, name, inputs, and outputs. The description's mention of 'typed inputs/outputs' aligns with the schema, but it adds no extra parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create a user function graph on a Blueprint'), includes key features ('typed inputs/outputs'), and mentions the side effects (compile and save). This clearly distinguishes it from sibling tools like blueprint_create, blueprint_compile, or blueprint_add_variable.
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 its use case—adding a function graph to a Blueprint—but does not explicitly list when to use it over alternatives or mention any prerequisites/exclusions. With many blueprint-related siblings, some additional guidance would help.
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 does disclose key behavioral aspects: supported node types, optional 'params' key for pin defaults, and the 'nodeId.exec' connection format. However, it does not mention side effects like clearing existing graphs, whether it compiles or saves, or error behavior. The clear_existing parameter is only documented in the schema, not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences. The first sentence states the purpose, the second lists supported node types, and the third explains two critical formatting details. It is front-loaded with the core purpose and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential input format (JSON nodes and connections), including supported types and pin wiring. It does not explain the return value or the behavior of clear_existing, but the schema covers clear_existing's default and description. Given the moderate complexity and nested objects, the description is sufficiently complete for an agent to construct a valid graph, though more detail on required fields for CallFunction would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers blueprint_path and clear_existing, and nested properties have descriptions. The description adds meaning beyond the schema by explaining the supported node types, the structure of the params object ('PinName' keyed defaults), and the exact connection format ('nodeId.exec'). This helps the agent understand how to assemble the graph correctly, going 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's primary function: 'Builds a Blueprint event graph from a JSON node/connection description.' This is a specific verb (Builds) and resource (Blueprint event graph) with a clear input format (JSON). It also distinguishes itself from sibling tools by mentioning 'event graph' and the JSON source, which differentiates it from anim_blueprint_build_from_json and blueprint_build_from_description.
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 by specifying supported node types and the JSON format, but it does not explicitly state when to prefer this tool over alternatives like anim_blueprint_build_from_json or blueprint_build_from_description. No exclusions or alternative guidance are provided, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It reveals an important non-obvious trait: 'Success' refers to the compile run, not the compile result, and directs users to 'compiled' and 'had_errors'. This is valuable beyond the basic operation, though it does not describe other side effects or preconditions.
Agents need to know what a tool does to the world before 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, efficient sentence that leads with the action and appends a clarifying clause. No filler or redundant content - 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?
No output schema exists, so the description must cover return semantics. It does so by naming success/failure, error details, and the 'compiled'/'had_errors' fields. For a one-parameter tool, this is sufficient, though a more enumerated return structure would be slightly clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents blueprint_path with a pattern and description, so schema coverage is 100%. The description adds no further parameter-level meaning, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Compile') and resource ('Blueprint') and immediately clarifies the distinction between the compile operation and its result. This distinguishes it from sibling tools like blueprint_create or blueprint_build_from_json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description: to compile a Blueprint and obtain result details. However, there is no explicit guidance about when to prefer this over related Blueprint tools (e.g. blueprint_build_from_json) 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 carries the burden. The verb 'List' implies a read-only operation and the scope is stated, but it doesn't disclose return format, limits, or any other behavioral traits beyond the schema. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the operation and all key filtering options with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description plus schema sufficiently cover input parameters and purpose. There is no output schema, and the description doesn't explicitly describe return fields, but 'List' implies a list of blueprints. A small note about returned data would make it complete, hence not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly paraphrases the schema (path, name, parent class) and omits the limit parameter, adding no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource ('Blueprint assets') and explicitly names the optional filtering dimensions (path, name, parent class). This clearly distinguishes it from sibling tools like blueprint_info or asset_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for use: enumerating Blueprint assets with optional filters. It stops short of explicitly mentioning when not to use it or pointing to alternatives like asset_list for all assets, so it doesn't reach a 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?
With no annotations, the description carries the full transparency burden. It discloses validation via UEdGraphSchema_K2::CanCreateConnection, clean failure with no graph change, and that it compiles and saves on success. This covers key side effects and failure behavior, though it omits details like undoability 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 two sentences, front-loaded with the primary action, and contains no unnecessary wording. Every sentence earns its place by adding behavior information (validation and side effects).
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 medium-complexity mutation tool with no output schema, the description covers the essential context: the operation, validation, failure behavior, and success side effects. It does not explain return values, but that is less critical for this action. Overall, it provides sufficient context to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, with 5 of 6 parameters documented. The description adds no extra parameter-specific context beyond the schema's own descriptions, so the baseline of 3 applies. The text reinforces the source/target relationship but does not clarify formats or edge cases 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 what the tool does: 'Connect two pins between nodes.' It uses a specific verb and resource, and the operation is unambiguously distinct from the sibling tool blueprint_pins_break, which disconnects 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 the tool is for creating pin connections but provides no explicit guidance on when to use it versus alternatives (e.g., blueprint_pins_break for disconnecting) or exclusions. It does offer behavioral context (validation, failure mode) but not usage boundaries.
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 side-effect that the tool will compile and save after removal, which is valuable information. Since there are no annotations, this description carries the full burden and does well by mentioning the post-removal actions, though it does not cover error cases or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the primary action and the important side-effect. It contains zero wasted words and is appropriately concise for a simple tool.
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 low complexity (two well-documented parameters, no output schema), the description is essentially complete. It states the operation and subsequent actions, and the schema fills in parameter details. A minor gap is not addressing the 'dispatcher not found' case, but this is not critical for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema, and the description only reinforces the 'name' parameter by saying 'by name'. It does not add additional semantic detail beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 an event dispatcher by name, which is a specific action on a specific resource. The verb 'remove' and the target 'event dispatcher' distinguish it from sibling tools like blueprint_remove_variable or blueprint_remove_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to remove an event dispatcher from a Blueprint) but does not explicitly compare with alternatives or state when not to use it. There is no mentioning of exclusions or related tools, leaving room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing side effects. It explicitly notes that the tool 'deletes its generated function graphs' and then 'compile[s] and save[s]', revealing destructive and mutating behaviors. This is useful transparency, though it does not delve into reversibility 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 a single, concise sentence that immediately states the core action and the key side effect. Every clause adds information without redundancy, achieving high clarity with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters) and the absence of an output schema, the description covers the essential aspects: what it removes, what it deletes, and the compile/save behavior. It is complete enough for an agent to understand the tool's effect, though it could mention whether the operation is irreversible or if any confirmation 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 input schema provides 100% coverage with descriptions for both blueprint_path and interface_class. The tool description adds no additional parameter-level detail, so the baseline score of 3 is appropriate since the schema already documents the parameters 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's function: 'Remove an interface implementation' with the additional detail of deleting generated function graphs. This distinguishes it from sibling tools like blueprint_remove_function or blueprint_add_interface by specifying the resource (interface implementation) and the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (removing an interface implementation) but does not explicitly discuss when to use this tool versus alternatives like blueprint_remove_function or blueprint_add_interface. There is no mention of exclusions or prerequisites, so guidance is limited to the implied 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 does disclose important side effects (compile and save) beyond just removing the variable, which is useful. However, it does not mention potential errors, reversibility, or other behavioral details, so it's only 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 a single, well-structured sentence that front-loads the action. Every word contributes value; there is no irrelevant detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter mutation tool with a clear schema. The description covers the action and side effects, which is sufficient for the likely use cases. It does not explain return values or error conditions, but no output schema exists and the behavior is straightforward, so this is 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 100%, with each parameter clearly described (e.g., 'Variable name to remove' and 'Content path of the Blueprint asset'). The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove') with the resource ('member variable from a Blueprint') and the additional side effects ('compile and save'). This clearly distinguishes it from sibling tools like blueprint_add_variable or blueprint_remove_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (removing a variable), and the context is clear enough given the sibling set. There are no explicit alternatives or exclusions, but the purpose is so specific that a user would know when to invoke 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 adds context about the 'live' state and 'currently registered', implying a runtime view, but does not disclose potential side effects (likely none), failure modes if the listener is not alive, or return format. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does without extra words. It is concise 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?
For a simple tool with no parameters and no output schema, the description provides adequate context: it names the resource (live Unreal listener) and the result (command names). It could mention that these names are for later use with other tools, but that is not essential.
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 zero parameters, the baseline is 4. The description correctly implies no input is needed beyond the tool call itself, aligning with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('command names currently registered in the live Unreal listener'), making it clear what the tool does. It distinguishes this from siblings like test_connection or restart_listener by focusing on listing registered command names rather than testing or restarting the listener.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use it to discover available commands in the Unreal listener. However, no explicit when-to-use or alternative tools are mentioned, so it relies on the user to infer the 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 provided, the description carries the burden of disclosing behavior. It explains the mechanism (undoing operations) but does not mention side effects such as whether the restore is reversible, whether the checkpoint is preserved, or any destructive implications beyond the implicit 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?
A single, concise sentence that is front-loaded with the core action and mechanism. 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?
For a tool with one parameter and no output schema, the description is sufficient for an agent to understand what it does. It could further elaborate on interaction with undo/redo or checkpoint lifecycle, but the current level is 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 schema already has 100% coverage for the single 'name' parameter with a description. The tool description adds no extra semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restore), the resource (named checkpoint), and the mechanism (undoing operations since it was created). It distinguishes itself from step-by-step undo/redo tools by targeting a named checkpoint.
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 when a named checkpoint exists and the user wants to revert to it. However, it does not explicitly mention alternatives like undo/redo or checkpoint_create, nor does it state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that the tool does not compile and that the editor restart is required, which are important behaviors. However, it does not mention other potential side effects like file system changes, overwriting existing files, or any permissions needed, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the action, the second clarifies a limitation, and the third gives a post-condition. Every sentence adds necessary information, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and multiple parameters, the description covers critical operational context: it clarifies that compilation is not performed and provides the necessary next step (cpp_build) and post-condition (editor restart). It could be slightly more complete by mentioning prerequisites or what the tool returns, but overall it is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all 5 parameters, so the description adds limited additional semantics. It references the wizard-style boilerplate which gives context for parameters like parent_class and uclass_specifiers, but it doesn't delve into parameter-specific details beyond what the schema covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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: generating a UCLASS header/source pair in a game module. It provides specifics like UE4.27 wizard-style boilerplate, GENERATED_BODY, and constructor, which distinguishes it from other creation tools like blueprint_create or material_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear follow-up guidance: it does not compile, so run cpp_build afterwards, and notes that new classes require an editor restart. This implies the appropriate usage context and next steps, though it doesn't explicitly contrast with alternatives beyond the implicit C++ class creation scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the return format (pass/fail per predicate with observed value) and the predicate categories, but does not explicitly declare whether the tool modifies game state or is safe to run concurrently, a notable gap for a test 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 compact, front-loads the action, and uses a structured list for predicates without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It provides prerequisites, predicate syntax, return expectations, and default timeout behavior via schema, which is adequate for a tool with no output schema and only two parameters; it could mention side effects but the core functionality is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described; the description adds the semantic meaning of each predicate type and clarifies the 'survive' predicate, but largely mirrors the schema's examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as running structured acceptance test predicates against a live PIE session, using a specific verb and resource, and lists the predicate syntax, distinguishing it from the PIE start/stop 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?
It explicitly states the prerequisite that PIE must be running and directs the user to call gameplay_pie_start first, though it doesn't mention alternatives like gameplay_telemetry_snapshot.
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 idempotency, which is valuable, but does not mention whether applying a preset overwrites existing custom mappings or any other side effects. The behavioral disclosure is partial but not contradictory.
Agents need to know what a tool does to the world before 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 verb and resource, and every word earns its place. The enumeration of presets and idempotency note are efficiently packed 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?
For a single-enum-parameter tool with no output schema, the description is largely complete: it covers the parameter values, behavior (idempotent), and expected actions. Missing is any mention of how existing keybindings are affected, which would make it 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?
Schema coverage is 0%, but the description explains that the preset includes WASD movement, mouse look, and Jump/Fire/Interact actions, adding meaning beyond the raw enum list. It does not detail each preset individually, but the general explanation compensates well 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 tool applies a standard control scheme preset and enumerates the four specific values (first_person, third_person, top_down, tank). This is a specific verb+resource combination that distinguishes it from sibling tools like input_mapping_add/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 implies usage by listing preset types and their contents, but provides no explicit guidance on when to use this tool versus manual input mapping alternatives. The context of sibling tools suggests alternatives, but no exclusionary or comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool saves the level and optionally all dirty assets, which implies a write/mutation operation. However, it does not disclose potential side effects such as overwriting files, whether a level must be loaded, or any permission requirements. The description is not misleading, but it could be more transparent about the operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes all essential information without wasted words. It is front-loaded with the primary action and clear about the optional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, no output schema, and no annotations, the description is adequately complete. It states the action, the resource, and the optional parameter's effect. It does not explain the return format or error behavior, but for a save operation this is often implicit and acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single boolean parameter 'save_all' with a description. The tool description's phrase 'optionally all dirty assets' mirrors what the schema says ('Also save all modified assets'), adding no additional meaning beyond the schema. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save the current level and optionally all dirty assets.' The verb 'save' with the specific resource 'current level' makes the purpose unambiguous, and the optional dirty assets scope distinguishes it from sibling tools like asset_save_many which focus on assets specifically.
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 conveys clear usage context: use this tool when you need to save the current level, optionally including modified assets. It doesn't explicitly compare to alternatives like asset_save_many, but the wording implies the distinction. No exclusions or when-not-to-use guidance is provided, but the context is straightforward.
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 transparency burden. It indicates the tool is a read operation ('Get') and specifies the kind of information returned, which is useful. However, it does not mention error behavior, permissions, or side effects, leaving some gaps. A 3 reflects that the description provides basic behavioral context but not exhaustive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the main action and includes illustrative examples. Every word contributes value, and it is not padded with unnecessary text. A 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has one parameter, no output schema, and no annotations. The description provides some insight into the return contents ('parameters, textures, parent chain') but does not specify the structure or potential errors. For a low-complexity getter, this is largely sufficient, but not fully complete, so a 4.
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 only parameter, material_path, is fully described in the schema with its pattern and meaning. The description adds no additional semantic detail about the parameter itself, so it appropriately gets a baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('material'), and clarifies the scope with examples ('parameters, textures, parent chain'). This clearly distinguishes it from sibling tools like material_list or material_create, earning a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving details about a single material, providing context for when to use it. However, it does not explicitly mention alternative tools or exclusion cases, so it gets a 4 rather than 5.
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 transparency burden. It lists the returned fields, indicating a read-only query by the verb 'Return', but does not explicitly state that it has no side effects, what happens when no project is loaded, or any error conditions. It adds value by enumerating the returned data but lacks deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action 'Return' and immediately lists the returned data. Every word contributes meaning; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no annotations, no output schema), the description is largely sufficient: it lists all returned fields. It does not specify the exact return format or data types, but for a simple info-getter this is a minor gap. Overall, it provides a complete picture for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema to supplement. The baseline for 0-param tools is 4. The description appropriately focuses on outputs rather than inputs, and no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'current UE project', listing specific fields (name, engine version, path, content directory, loaded level). This distinguishes it from sibling tools like asset_info or level_actors, which target different aspects of the Unreal environment.
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: one would use this when needing project-level metadata. However, there is no explicit 'when to use' context, no mention of alternatives, and no exclusions for when this tool should not be used. The usage context is self-evident but not explicitly articulated.
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 transparency burden. It signals a read-only health check by using 'Check' and lists exactly what is reported (two availability states, output path, manifest count), but it does not disclose return format, error behavior, or whether any side effects occur. The bare minimum is met, but richer detail would be expected for a tool with no 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?
A single, front-loaded sentence with a colon introducing a compact list of checks. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status probe, the description covers the key behavior and output components. It would benefit from explicitly stating that it returns a structured status object or boolean availability flags, but the current description is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific detail because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with a clear resource ('PromptBrush system status') and enumerates four concrete status components (BlueprintGraphBuilder availability, WidgetBlueprintBuilder availability, output directory path, manifest count), making the tool's purpose unmistakable and distinct from sibling tools like project_info or bridge_command_manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Check PromptBrush system status' implies this tool should be used when the agent needs to verify PromptBrush readiness, but it does not explicitly compare against alternatives such as test_connection or bridge_command_manifest, nor state when not to use it. This is adequate but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It states that it writes a PNG file and returns the absolute path, which is useful. However, it does not mention potential side effects, failure conditions, or whether the viewport is altered, leaving some gaps for a file-writing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys both the action and the key return value. Every word earns its place, with no extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple screenshot tool with rich schema documentation and no output schema, the description covers the essential points: what it captures and what it returns. It could add niche details like coordinate spaces or error behavior, but these are not critical for this tool's use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (show_ui, filename, resolution) is already well-documented in the schema. The description adds no additional parameter semantics beyond what is provided, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') and resource ('active viewport') and specifies the output format ('PNG file'). It clearly distinguishes from sibling viewport tools like viewport_camera or viewport_mode by focusing on screenshot capture.
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 the tool: when a screenshot of the viewport is needed, especially for visual inspection. It mentions returning a filesystem path for Claude Code to read, providing context for usage. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It reveals that the tool writes an asset to package_path/asset_name and populates the designer tree, which are key side effects. However, it does not disclose overwrite behavior, error conditions, or whether the asset is saved or compiled, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and key side effect. The mention of WidgetBlueprintBuilderLibrary gives implementation context without noise. Every word contributes to understanding, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required parameters, full schema descriptions, and no output schema, the description covers the core purpose and destination. It lacks details about overwrite/runtime behavior and the exact structure of widget_json, but the schema covers the nesting fields, so overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all three parameters (package_path, asset_name, widget_json), including an example for asset_name. The description adds minimal parameter-specific meaning, only reinforcing that package_path/asset_name determine the asset location, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Widget Blueprint from a JSON widget tree using WidgetBlueprintBuilderLibrary, and mentions the exact output location and designer tree population. This distinguishes it from sibling tools like blueprint_build_from_json and anim_blueprint_build_from_json by specifying 'Widget' blueprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of creating a widget blueprint from JSON is clear, and the name/description implies this is the tool for widget-specific blueprint generation. However, it does not explicitly mention alternatives or when-not-to-use, such as directing general blueprints to blueprint_build_from_json.
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 critical behavioral trait—this tool only returns a spec and does not create an asset—and adds detail about named fade-in/fade-out animations. However, it omits details about defaults and output structure, so it is not a 5.
Agents need to know what a tool does to the world before 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 an action verb upfront and no filler. Every word earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with no output schema or annotations, the description is minimally adequate: it conveys the core function and side-effect boundary. However, it lacks detail about output structure, default behavior, and how the returned spec connects to widget-building sibling tools, leaving gaps for full invocation 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 coverage is 61%, and the description adds no parameter-level detail. It only hints at 'title or lower-third' and 'fade-in/fade-out,' which loosely maps to style and fade parameters, but it does not compensate for the undocumented color and font size 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 returns a UMG title or lower-third widget JSON spec with named fade animations, using a specific verb ('Return') and resource ('widget JSON spec'). It explicitly distinguishes itself from asset-creating siblings with 'Does not create an asset.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Does not create an asset' provides a clear exclusion and helps the agent decide when not to use this tool (asset creation). It does not explicitly name alternatives like widget_title_card_create, but the context is clear enough for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool wires GameMode class defaults, compiles, and saves all created assets, which are important side effects. However, it does not disclose overwrite behavior or failure scenarios, so it is 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 a single, information-dense sentence followed by a short clause about compile/save. Every part contributes to understanding the tool's core function, naming, wiring, and side effects, with 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?
The description explains the main action and side effects, but it does not specify return values or error handling, which is notable since no output schema exists. It also leaves ambiguity about whether all listed blueprint types are always created or only those specified in the pieces parameter. Overall, adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline of 3. The description adds extra meaning by explaining the naming convention with base_name and suffix, and clarifying that the pieces parameter determines which blueprints are created and wired. This goes beyond the schema's simple parameter 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 creates a linked set of gameplay framework Blueprints, listing the exact blueprint types involved and the naming convention. This distinguishes it from sibling tools like blueprint_create, which handles single blueprints, and blueprint_build_from_json, which builds from structured data.
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 its use case (creating a full gameplay framework with wiring), but it does not explicitly state when to use it versus alternatives or provide any exclusion criteria. No mention of prerequisites or situations where a different 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself discloses key behaviors: it returns a status, structured result (e.g., parsed compiler errors), and output tail. This goes beyond a simple 'get status' and gives the agent useful expectations about the response content. It does not mention side effects, but the 'Get' verb implies 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?
The description is a single sentence, front-loaded with the core purpose, and every phrase adds value: status values, structured result example, and output tail. There is no redundant or vague wording.
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 (2 params, no output schema, no annotations), the description covers the essential aspects: what it returns (status, structured result, output tail). It could be more complete by explaining behavior for invalid job IDs or how structured results vary, but for a simple status check, it is sufficiently 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?
Schema coverage is 50%; only include_output has a description in the schema. The description does not explain the required job_id parameter (format, how to obtain it), which is a significant gap. It mentions 'structured result' and 'output tail' but does not tie these to the parameters, leaving the main parameter's semantics under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'background job's status' and enumerates possible statuses ('running/succeeded/failed/cancelled'). It also distinguishes itself from sibling tools like job_list and job_cancel by specifying it retrieves the status of a single job, including structured results and output tail.
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 the status of a background job, including structured results or output tail. While it does not explicitly mention alternatives or exclusions, the context is clear, and the distinction from job_list (list jobs) and job_cancel (cancel job) is evident.
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 explicitly lists the returned information (type, bounds, material slots, LOD count), giving the agent a concrete expectation. It does not mention error handling or performance, but for a read-only info tool this is reasonable and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. Every word earns its place, listing the return content efficiently. It is concise and structured well for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is sufficient: it names the tool's purpose and key return fields. It doesn't provide return format or usage examples, but these are not critical for such a straightforward info tool, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'path' parameter, which has a descriptive example (e.g., /Game/Meshes/SM_Cube). The description adds no extra parameter semantic detail, so it meets the baseline of 3 without further 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 clearly states 'Return detailed info for a single asset' with a specific verb+resource, and enumerates the exact data returned (type, bounds, material slots, LOD count). It distinguishes itself from sibling asset_list by specifying 'single asset' versus a list.
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 individual asset inspection by specifying 'single asset' and mentioning detail fields, which contrasts with asset_list. However, it does not explicitly state when not to use it or name an alternative tool, but the context is clear enough for an agent to select it for one-asset queries.
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 discloses a dependency ('existing Blackboard') and a side effect ('Optionally adds keys to the blackboard first'), which is useful. But it omits other behavioral traits like whether an existing asset is overwritten or validation behavior for the tree spec.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, followed by optional aspects. The parenthetical listing node types is dense but purposeful, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 params, nested objects, no output schema, and no annotations, the description provides a solid high-level overview including prerequisites and options. It could add details on return values or failure modes, but the schema covers parameter structure, making it sufficient for selection and basic 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 covers 100% of parameters, so baseline is 3. The description adds meaning beyond the bare schema by enumerating the 26 supported node types and their categories, helping an agent build a valid 'tree' JSON. It also explains the relationship between 'keys' and the blackboard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('BehaviorTree asset') with clear scope: bound to an existing Blackboard, optionally from a JSON spec. It also distinguishes from generic build-from-JSON siblings by naming the BehaviorTree-specific 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: intended for creating a BehaviorTree asset with an existing Blackboard, with optional node graph and blackboard keys. However, it doesn't explicitly state when to prefer this over sibling build_from_json tools or list exclusions, so it doesn't reach the 'explicit alternatives' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It explicitly mentions 'Compiles and saves' and the re-parenting of children, which are important behavioral traits beyond a simple 'remove'. It lacks details on irreversibility or prerequisites, but the disclosed behaviors are significant and beyond what the schema suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action, then adds critical behavioral context (re-parenting and compile/save) without any fluff. 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?
The description covers the core operation, side effects (re-parenting, compile/save), and clarifies the target type. It doesn't mention error conditions, prerequisites (e.g., asset must exist or be loaded), or return values, but given the simplicity of the tool and the rich schema, it is reasonably complete. A 5 would require more on edge cases or explicit undo guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both blueprint_path and component_name have clear descriptions in the schema. The tool description does not add new parameter-level details beyond what is already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a component (SCS node) from a Blueprint', specifying the resource (Blueprint) and the target (component/SCS node). It distinguishes from sibling tools like blueprint_node_delete (graph nodes) by clarifying it applies to SCS nodes, and re-parenting behavior adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the tool targets components (SCS nodes) and notes the re-parenting behavior, which helps the agent know when to use it versus blueprint_node_delete or blueprint_component_rename. However, it does not explicitly state exclusions or name alternative tools for non-component removals, so it stops short of a 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?
With no annotations, the description carries the full burden for behavioral disclosure. The verb 'Read' and the phrase 'use before editing' make it clear this is a non-mutating inspection tool, and the list of inspectable elements provides useful scope. It does not disclose error handling or return formats, but for a read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the action and resource, followed by a compact list of inspectable aspects and a one-line use case. Every clause carries meaning, and there is no redundant 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?
Considering the tool's breadth (10 action enum values, 5 parameters, nested query object) and absence of an output schema, the description covers purpose and usage well. The schema fully documents parameters, and the description adds the important strategic context of 'use before editing'. It is slightly thin on return-value expectations, but the lack of an output schema makes that less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond the schema, though 'resolve graph names, node GUIDs, and pin names' loosely reinforces the roles of graph_name and node_guid. The schema adequately handles the rest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 opens with 'Read Blueprint structure'—a specific verb with a clear resource—and enumerates concrete sub-resources (graphs, functions, variables, nodes with pins and links). This clearly distinguishes it from sibling tools like blueprint_list and blueprint_info, which are separate 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?
'Use before editing to resolve graph names, node GUIDs, and pin names' explicitly states when this tool should be used. However, it does not mention any exclusions or name alternative tools for cases where this tool would not be 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 provided, the description carries the full burden of behavioral disclosure. It reveals that the tool 'Compiles and saves,' which is a significant side effect, and details the preset configurations. However, it does not disclose whether existing camera/spring-arm components with the same name are overwritten or if there are prerequisites like the blueprint existing beforehand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that starts with the action and target, then lists presets with concise technical details, and ends with the side effects. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a focused tool: it explains what it does, the available presets, and that it compiles/saves. It does not discuss return values (though no output schema exists) or prerequisites like whether the blueprint must already exist, which could matter given sibling tools like blueprint_create.
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 covers 50% of parameters (arm_name, camera_name) but leaves blueprint_path and preset without descriptions. The description compensates richly for the preset parameter by enumerating each preset and its specific values, adding meaning beyond the schema's enum list. It does not add detail for blueprint_path, but the use is clear from the tool's 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 states a specific action ('Add a camera rig to a Pawn/Character Blueprint') and specifies the exact resource and scope. It also distinguishes from sibling tools by naming preset configurations, making it clear this tool is dedicated to rigging cameras, not general blueprint creation or compilation.
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: whenever you need to attach a camera rig to a Pawn/Character Blueprint with one of the listed presets. It does not explicitly mention alternatives or exclusions, but the specificity of the presets and the action makes the intended use obvious.
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 transparency burden. It discloses that the build runs in the background, returns a job_id immediately, and that compiler errors will be structured (file, line, code, message). It doesn't mention potential side effects (e.g., generated files) or failure modes, but it gives a clear behavioral model for an async job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the verb 'Compile', states the resource, and immediately provides the key workflow (returns job_id, poll job_status). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a build tool with 5 optional parameters, no output schema, and no annotations, the description covers the essential workflow: start async build, get job_id, poll status for structured errors. It could additionally mention timeout behavior or success output, but the schema documents timeout_seconds, and the overall usage pattern is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all five parameters (target, platform, extra_args, configuration, timeout_seconds) with defaults where applicable. The description adds no per-parameter detail, which is fine given the schema's completeness. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Compile the project with UnrealBuildTool') and the asynchronous nature (background job). It clearly distinguishes this from sibling tools like job_status or cpp_class_create by stating it returns a job_id for polling, making it obvious this is the build initiation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use it (to compile the project) and that you should poll job_status afterward. However, it does not explicitly mention when not to use it or alternatives (e.g., blueprint_compile for Blueprint scripts), though the context of UBT implies C++ only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the incremental behavior ('new log lines since last snapshot') and the PIE requirement, which is useful. However, it does not state whether the tool is read-only, whether it resets or consumes the log buffer, or any side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear action verb ('Capture') and a compact, comma-separated list of captured items. Every word contributes information; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description adequately covers what the tool returns and the key prerequisite. It could be more explicit about side effects or error conditions, but for a telemetry snapshot, the provided information is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description does not need to explain any parameters, and the baseline for 0 params is 4. The description's enumeration of captured data indirectly explains what the tool returns, 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's function: capturing the current PIE runtime state, and lists specific data points it captures (log lines, pawn class, widget names, AI controller states, world name). This distinguishes it from sibling tools like gameplay_pie_start and gameplay_pie_stop, which control PIE lifecycle rather than snapshot 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 provides a clear context by stating 'PIE must be running', which tells the agent when the tool is applicable. It does not explicitly mention alternatives or when-not-to-use cases, so it falls short of a perfect score, but the prerequisite 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, the description carries the full behavioral burden. It is transparent about the generated artifacts, optional map/default game mode behavior, and the return value (a manifest). It also notes that class defaults are 'wired', giving insight into the integration level. This is strong for a generator tool, though it doesn't discuss potential side effects like asset overwrites or project setting persistence beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences. The purpose is front-loaded in the first sentence, the template list is a compact second sentence, and the return value is noted in the third. No words are wasted; every sentence contributes distinct, 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 multi-artifact generation tool with no output schema and no annotations, the description covers the core behavior: what is created, what options exist, and what is returned. It doesn't mention error cases or prerequisites, but given the complexity and the detail provided, it is reasonably complete. The 'manifest' return mention partially compensates for the lacking output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4/5 params described), so the baseline is 3. The description adds meaningful context by mapping 'optionally a new map and project default game mode' to the create_map and set_as_default flags, and by listing the template enum values inline. This goes beyond the schema's sparse descriptions, especially for the template parameter, which lacks a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb phrase 'Generate a playable game skeleton' and enumerates the concrete components (GameMode/Character/PlayerController/HUD, camera rig, input preset, optional map and default game mode). This clearly distinguishes it from related sibling tools like gameplay_framework_create, camera_rig_create, or input_preset_apply, which focus on narrower pieces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as an all-in-one game skeleton generator by listing what it creates, and the template list clarifies which game types it supports. However, it does not explicitly state when to prefer this tool over more targeted siblings, nor does it mention any exclusions or alternative tools. Context is present but no explicit when-not/alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It warns that the tool 'switches the editor's loaded level' and 'refuses if unsaved changes exist,' which is critical side-effect information. It also states that the result is saved, providing a clear picture of the mutation. This goes beyond a generic description, though it does not detail return values or other 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 two sentences: the first states the core action concisely, and the second provides a critical warning. There is zero wasted text, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is reasonably complete. It explains the main functionality, the optional template, and the key side-effect and failure condition. It doesn't describe the success response, but that is a minor omission given the clear action and warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers both parameters at 100%, so the baseline is 3. The description adds marginal value by noting that the template is optional and used for copying, but the schema already documents both 'path' and 'template' clearly. No additional syntax or format details are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create and load a new level (optionally from a template map), then save it.' It names the resource (level) and specifically distinguishes this from sibling tools like level_save, which only saves the current level, and level_actors, which deals with actors in a level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended usage context: creating a new level, with the optional template parameter. It also gives a clear precondition by warning that it refuses if unsaved changes exist, which guides when to use it. However, it does not explicitly mention alternatives or say 'use this instead of level_save,' 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.
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 adds the useful behavioral fact that changes persist to Config/DefaultEngine.ini, which is a concrete side effect. However, it does not disclose whether it overwrites existing values, creates the file if missing, or requires a project restart, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 24 words, yet it conveys the action, parameters, and persistence target. It is front-loaded with the verb and resource, contains no filler or repetition, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three optional string parameters and no output schema, the description covers the essential context: what it does, what it affects, and where it persists changes. It does not describe return values, but none are critical for a settings mutator, and the low complexity means the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with editor_startup_map lacking a schema description. The tool description compensates by naming all three parameters ('game default map, editor startup map, and/or global default game mode'), ensuring each parameter's purpose is clear. It also reinforces the optionality of each parameter, matching the schema's zero 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 begins with the specific verb 'Set' and clearly identifies the resource: default maps and game mode. It enumerates the exact settings (game default map, editor startup map, global default game mode) and adds the persistence target, making the tool's purpose unambiguous and distinguishable from sibling tools focused on assets, blueprints, or viewport operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for configuring project-level startup defaults, and the 'and/or' phrasing indicates partial updates are possible. It does not explicitly contrast with alternatives, but given the sibling list, no other tool directly overlaps with setting project-wide maps and game mode, so the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly states that the tool creates several asset types and that dry_run=true previews the build spec without creating assets. The main gap is a lack of detail on potential side effects such as overwriting existing assets or required project state, but what is disclosed is accurate and useful.
Agents need to know what a tool does to the world before 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 compact two-sentence structure, front-loaded with the primary purpose and immediately followed by asset types and supported genres. The dry_run guidance is a useful addition without any wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating multiple asset types) and the absence of an output schema or annotations, the description covers the essential aspects: scope, asset types, supported genres, and the safe preview mode. It does not describe the exact return shape of the build spec, but the dry_run hint implies a JSON structure, which is adequate for a tool of this breadth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters (prompt and dry_run), but the description adds meaningful context by listing the supported genres and explicitly recommending dry_run for previewing. This helps the agent understand what kinds of prompts are valid and how to safely use the tool, exceeding the bare 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 specific purpose: generating complete UE4.27 gameplay systems from a natural language prompt. It enumerates the types of assets produced (Blueprints, Widget Blueprints, materials, data assets, maps, actors, input mappings) and lists supported genres, distinguishing it from more granular tools like blueprint_build_from_description.
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 high-level, multi-asset system generation by noting supported genres and the dry_run option, but it does not explicitly state when to use this tool over alternatives like blueprint_build_from_description or actor_spawn. There is no mention of when not to use it or which sibling tools are better suited for simpler 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does explain the non-moving-camera behavior and the actor priority rule, which is helpful. However, it omits edge cases like what happens when neither parameter is supplied, invalid inputs, or whether the operation affects only the editor viewport versus saved camera state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and immediately follows with the critical 'without moving camera position' constraint and the priority rule. 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?
The tool is relatively simple, and the schema covers parameter details. The description adds the crucial look-at behavior and priority. Still, it does not specify expected return values or error handling, but for a viewport command this is acceptable and mostly 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 schema already documents both parameters at 100% coverage, but the description adds meaningful interactive semantics by explaining the priority order between actor_name and location. This additional guidance helps the agent decide which parameter to populate, exceeding the baseline schema 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 action: 'Point camera at coordinates or actor' while adding the key constraint 'without moving camera position.' This distinguishes it from related viewport tools like viewport_focus or viewport_camera, 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 gives clear context on when to use the tool (for look-at targeting) and explicitly states the precedence rule when both parameters are supplied. However, it does not mention alternatives or specific scenarios where a different viewport tool should be used.
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 transparency burden. It clearly states that only explicitly passed paths are saved, and the safety comparison adds useful behavioral context. However, it does not mention side effects like overwriting or error handling, but for a simple save operation 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 two short sentences with no filler. The primary action and scope are front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete. It explains what it does, its scope, and a safety characteristic, which is sufficient for an AI agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'paths' parameter with 100% coverage. The description does not add any additional parameter details beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('save') and resource ('explicit asset paths'), clearly delineating its scope. It also distinguishes itself from a broader 'save-all' operation, which helps differentiate it from potential 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 implies when to use this tool: when you want to save only specific assets rather than the entire project. It provides a clear context and a safety rationale, though it does not explicitly name an alternative tool or exclusion 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 the full burden. It discloses that the tool compiles and saves, returns the GUID, and provides extensive detail about node_type and config keys, including an exception for snake_case input nodes. It does not cover failure scenarios or overwrite behavior, but the disclosed side effect of save/compile is significant.
Agents need to know what a tool does to the world before 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 dense but each sentence contributes: main action, return value, node_type list, config examples, and naming exception. It is front-loaded with the core purpose and returns for pin wiring. No wasted words; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, a nested config object, and no output schema, the description covers the essential output (GUID), detailed parameter semantics, the compile/save side effect, and the naming convention exception. It is comprehensive for a tool of this complexity, leaving little ambiguity for the 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?
While schema coverage is 100% for the basic properties, the 'config' parameter is an open object with no structure. The description compensates by enumerating many node_type factory names and per-type config key examples, plus explaining class path formats and the snake_case exception. This adds essential semantic 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 opens with a specific verb and resource: 'Add a node to a Blueprint graph.' It also states the return value (new node's GUID for pin wiring), which clearly distinguishes it from sibling tools like blueprint_node_move or blueprint_node_delete.
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 its usage for adding nodes but does not explicitly state when to use this tool versus alternatives, nor does it list exclusions or alternative tools. The purpose is evident from the verb 'add,' but no direct guidance is provided beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the action (resets cursor) and a key non-behavior (does not delete/truncate the log), which is valuable. However, it does not elaborate on any side effects or what the cursor reset entails beyond the literal meaning, leaving some room for interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that are perfectly front-loaded. Every word earns its place, with no redundancy or off-topic 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 zero-parameter tool with no output schema, the description provides the essential context: what it does and what it does not do. It is complete enough for an agent to select and invoke it correctly, though it could briefly mention the relationship to 'clear_output_log' to fully resolve any ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the input schema confirms this. Per guidelines, a baseline of 4 is appropriate since the description does not need to explain parameter semantics. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reset') and a clear resource ('MCP output-log cursor marker'), and explicitly distinguishes itself from a sibling tool by stating it does not delete or truncate the UE log. This makes 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 implies when to use this tool by clarifying it does not clear the log, which contrasts with the sibling 'clear_output_log'. However, it does not explicitly state an alternative or provide a direct 'use this when' guideline, so it falls just short of a 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?
With no annotations, the description carries the transparency burden. It discloses the blocking wait up to 30s, the success condition (PIE-ready log marker found), and the purpose. It does not mention failure modes, side effects on existing PIE sessions, or permissions, but the disclosed behavior is meaningful and goes beyond a bare 'start'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then a success condition, then usage guidance. Every sentence contributes information, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and no annotations, the description covers the main behavior, timeout, success marker, and intended usage. It lacks failure conditions and edge cases (e.g., what if PIE is already running), but is otherwise fairly complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter level_path, which is fully documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch a Play In Editor (PIE) session') and the resource (game world), and includes the waiting behavior. It distinguishes from siblings by naming dependent tools (gameplay_run_acceptance_tests, gameplay_telemetry_snapshot) that should follow this start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Call this before gameplay_run_acceptance_tests or gameplay_telemetry_snapshot.' This provides clear context for invocation order and prerequisites, even though it doesn't list when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key behavioral trait: omitting 'key' removes every key bound to the name, which prevents accidental full-scale removal. This goes beyond the basic 'remove' action and gives the agent important information about the tool's default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action in the first sentence. The second sentence adds a critical nuance without any fluff. Every word contributes to understanding, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the essential behavior: what it removes, the two kinds of mappings, and the optional key behavior. It does not mention error handling or return values, but for this level of complexity, the coverage is sufficient and complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains the 'kind' parameter indirectly via 'action or axis', clarifies that 'key' is optional and its omission triggers bulk removal, and implies 'name' is the mapping identifier. This adds meaning beyond the raw schema fields, though 'name' is not explicitly elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Remove') and identifies the resource ('action or axis mappings'). It also distinguishes the tool from siblings like 'input_mapping_add' (which adds) and 'input_mapping_info' (which queries) by focusing on removal. The note about omitting 'key' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: omit 'key' to remove all bindings, implying that providing a key removes only that specific binding. It does not explicitly name alternative tools, but the usage context (removing mappings) is unambiguous and follows naturally from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the session scope and ordering, which are behavioral constraints. The word 'list' implies read-only, and there are no side effects described, which is appropriate for a listing 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?
A single, front-loaded sentence efficiently conveys the operation, scope, and ordering. Every word earns its place, and there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no parameters, no output schema, and no annotations, the description provides essential context: what is listed, the session scope, and sort order. It lacks detail on the return format, but this is not critical for selecting or invoking 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 tool takes zero parameters, so the baseline is 4. The description correctly does not attempt to describe parameters since there are none, and nothing more 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 'List', the resource 'background jobs', and specific scope 'in this editor session' with ordering 'newest first'. This distinguishes it from sibling tools like job_status and job_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you need to enumerate background jobs from the current editor session. It does not explicitly mention alternatives or exclusions, but the context is clear and sufficient for a simple list operation.
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 executes 'arbitrary' Python code and has 'full access to the unreal module,' signaling its powerful and potentially risky nature. It could add more explicit warnings about side effects, but it conveys the key risk 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 three concise sentences, each providing necessary information: what the tool does, its access level, and when to use it. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description provides clear purpose, access scope, and usage guidance. A minor gap is that it does not describe the return behavior (e.g., what output the agent can expect), but given the arbitrary nature of Python execution, this is a modest omission.
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 covers 100% of parameters with a clear description ('Python code to execute in the UE4 editor'). The tool description adds value by noting 'full access to the unreal module,' which clarifies what the code can do within the execution environment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute arbitrary Python code inside the UE4 editor.' It identifies the specific resource (Python environment in UE4) and the verb (execute). It also distinguishes itself from sibling tools by noting it handles 'operations not covered by dedicated tools.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use for prototyping or operations not covered by dedicated tools.' This indicates when to use and implicitly when not to (when dedicated tools exist). However, it does not name specific alternative tools, so it falls short of a 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 are provided, so the description carries the burden. It discloses the key partial-update behavior, ensuring the agent understands that omitted parameters remain unchanged. This is sufficient for a simple setter 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?
Single sentence, 16 words, front-loaded with the action and resource. No redundant 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 simple parameter set (3 optional, no output schema, no annotations), the description fully captures the tool's purpose and behavior. The coordinate system and units are defined in the schema, and the partial-update semantics are explicit. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying that parameters can be combined ('and/or') and that omitted ones are preserved, giving the agent insight into partial updates beyond individual parameter 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 the specific verb 'Set' with the resource 'viewport camera', enumerating position, rotation, and FOV. This clearly distinguishes it from sibling tools like viewport_fit or viewport_look_at.
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 direct camera manipulation and the partial-update behavior ('Preserves existing values for parameters not provided') implies that you can call it to update any subset of parameters. It does not explicitly name alternatives, but the context is distinct from other viewport tools.
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:

[![MCPBridge-Server MCP server](https://glama.ai/mcp/servers/RBG-WebDesign/MCPBridge-Server/badges/card.svg)](https://glama.ai/mcp/servers/RBG-WebDesign/MCPBridge-Server)

Score Badge

Copy to your README.md:

[![MCPBridge-Server MCP server](https://glama.ai/mcp/servers/RBG-WebDesign/MCPBridge-Server/badges/score.svg)](https://glama.ai/mcp/servers/RBG-WebDesign/MCPBridge-Server)

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/RBG-WebDesign/MCPBridge-Server'

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