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 usefully discloses the limit default (50) and cap (500), and clarifies that summary_only changes the return shape to per-session aggregates, but says nothing about read-only nature, permissions, ordering, or pagination.

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

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

One front-loaded summary sentence followed by a compact per-argument list — no filler, and each line earns its place given the 0% schema coverage. The structure is appropriate to the parameter count, though slightly list-heavy rather than prose-efficient.

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

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

For a 7-parameter query tool with no annotations and an existing output schema, the description covers all inputs and the key output-shape switch (summary_only). The remaining gaps — ordering, permissions, pagination — are minor given the output schema exists.

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

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

Schema description coverage is 0%, so the description must carry the full load, and it does: all seven parameters are documented with meaning, and the event_type and status_filter parameters are given concrete enum values (tool_call, waapi_call, tcp_command, session_start, session_end; ok, error) that exist nowhere in the schema.

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

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

States a specific verb and resource — 'Query past session log events' — with the filtering scope made explicit. It is clear and distinguishable from most siblings, though it does not differentiate itself from the closely related audit_session_stats sibling, which its own summary_only parameter arguably overlaps with.

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

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

The filter list implies the use case (retrieving/filtering historical events), and the summary_only note hints at an aggregate mode. However, there is no explicit when-to-use guidance and no routing against audit_session_stats, which appears to serve a similar aggregate purpose.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a read-only operation and it lists the returned aggregate metrics, but it does not state permissions, side effects, rate limits, or whether the data is live or cached.

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

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

The description is short and front-loaded: the purpose is stated first, followed by a compact list of returned metrics. Every sentence is relevant, though the return list is somewhat redundant given the output schema exists.

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

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

For a zero-parameter, read-only statistics tool with an output schema, the description is nearly complete. It could add usage context relative to siblings, but no critical invocation information is missing.

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

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

The tool has zero parameters, so there is no parameter semantics to clarify. Baseline 4 is appropriate; the schema is an empty object and no additional parameter meaning is needed.

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

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

States a specific verb and resource ('Get overall session logging statistics') and lists the kind of metrics returned. The purpose is clear, but it does not explicitly differentiate itself from sibling tools such as audit_history.

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

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

Provides no guidance on when to use this tool versus alternatives. It does not mention audit_history or any other sibling, nor does it state prerequisites or appropriate contexts for requesting session stats.

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

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

With no annotations, the description carries the full burden. It discloses useful preconditions (variables must pre-exist, functions must be audio-allowlisted) and implies an active Blueprint is required, but says nothing about failure behavior, whether the node is persisted or must be saved/compiled, or permission requirements 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.

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

Front-loaded with the core action, then structured into node kinds and an args list. Every line carries information; the only minor cost is that the args list partly mirrors parameter names already visible in the schema.

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

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

An output schema exists so return values need not be explained. The description covers all parameters, all four node kinds, and key preconditions, leaving only minor gaps around lifecycle (save/compile) and error behavior for a mutation tool.

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

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it does: every one of the 7 parameters is described, including the required-for relationships (function_name for CallFunction, event_name for CustomEvent, variable_name for VariableGet/Set) and the role of node_id in later connect/set_pin calls.

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

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

States a specific verb (add) and resource (node to the active Blueprint's event graph), then enumerates the four supported node kinds with concrete examples. It is clear what the tool does, though it does not explicitly differentiate itself from similar siblings like ms_add_node or ms_add_variable_node.

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

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

The per-kind notes imply when each kind applies (VariableGet/VariableSet require a pre-existing variable, CallFunction requires an audio-allowlisted function, CustomEvent is user-defined). However, there is no explicit guidance on when to use this tool versus sibling node-creation tools, and no stated prerequisites such as needing an active/open Blueprint.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that a Blueprint function is executed, but does not describe side effects, whether the function may mutate editor or runtime state, required permissions, error behavior, or whether the call is synchronous or asynchronous. For a tool that executes arbitrary user-defined functions, this is a significant gap.

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

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

The description is appropriately short and front-loaded: the main action appears first, followed by a compact Args section. Every sentence is relevant, though the parameter explanations are minimal and could be slightly more informative without bloating the text.

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

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

The tool has an output schema, so return values need not be described. However, with no annotations, two parameters, and 0% schema description coverage, the description is incomplete: it lacks usage guidance, safety considerations, and sufficient parameter detail for an agent to invoke it reliably. Given the power of executing arbitrary Blueprint functions, more context is needed.

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

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 briefly explains both parameters: 'function_name: Blueprint function name to call' and 'args_json: JSON string of function arguments.' This adds basic meaning beyond the bare schema titles, but it does not explain how to format the JSON to match the target function's signature or how to discover valid function names.

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

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

The description states a specific verb and resource: 'Execute a Blueprint function via the UE5 plugin.' This clearly distinguishes the tool from sibling tools like bp_compile_blueprint or bp_add_bp_node, which manipulate blueprints rather than invoking a function. However, it does not explicitly differentiate from other execution or runtime tools in the sibling list.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as an active UE5 connection, whether the blueprint must be open, or what conditions make this tool preferable to siblings like ms_graph_to_commands or execute_waapi. Usage must be inferred entirely from the tool name and brief purpose statement.

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

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

With no annotations, the description carries the full burden, and it does disclose the return payload (compile status and compiler messages) plus a state prerequisite. It says nothing about whether compilation mutates the blueprint, blocks, or how failures are surfaced beyond messages, so the behavioral picture is only partially filled in.

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

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

Three short lines, action stated first, then return behavior, then the precondition. Every sentence earns its place with no filler.

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

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

For a zero-parameter tool with an output schema and no annotations, the description covers purpose, return shape, and the ordering prerequisite. Minor gap: no mention of side effects on the open blueprint or failure/error behavior.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond what the empty schema already shows. Baseline of 4 applies.

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

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

Specific verb ('Compile') plus a clear resource ('the active Blueprint'), which is meaningful in a stateful Blueprint workflow. No sibling tool performs compilation, so differentiation is implicit rather than stated, keeping it just short of a 5.

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

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

The prerequisite 'Must have called bp_open_blueprint first' gives explicit ordering guidance that an agent needs before invoking. It does not name any alternative or exclusion, but none exists among the siblings, so the context is effectively complete.

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

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 discloses the registration precondition but says nothing about whether the connection is destructive/reversible, whether an existing wire on the destination pin is replaced, whether the graph must be recompiled, or what errors arise from type-mismatched pins.

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

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

Lead sentence states the operation, followed by the precondition and a compact Args list. No filler, though the Args block largely restates the schema's parameter names.

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

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

An output schema exists, so return values need not be explained. For a mutation tool with no annotations, the description covers the essential precondition but leaves error behavior, idempotency, and post-connect workflow (e.g., compiling) unaddressed.

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

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, and it documents all four parameters with roles: from_node/from_pin as the source/output side and to_node/to_pin as the destination/input side. This directional semantics is genuinely useful beyond the bare parameter names, though it omits expected ID/pin-name formats.

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

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

States a specific verb (connect) and resource (pins between registered Blueprint nodes), which is distinct from siblings like bp_set_bp_pin (single pin value) and bp_list_node_pins (read-only listing). An agent can identify exactly what this tool does without opening the schema.

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

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

Provides an explicit precondition: both nodes must already be registered via bp_add_bp_node or bp_register_existing, and it names those two alternatives for the setup step. It does not state when-not to use this tool or what happens if the connection already exists, so it falls short of full routing guidance.

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

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

With no annotations, the description carries the full burden and mostly meets it: it discloses the runtime dependency ('Requires the UE5 C++ plugin to be running'), the exact subgraph scope (audio nodes + 1-hop neighbours), and what data comes back (pin data, connections). It does not explicitly state read-only/non-destructive nature or failure behavior for a missing plugin, leaving a small gap.

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

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

Front-loaded with the core action and scope, then usage rationale, then the environment prerequisite, then args. Every sentence earns its place and there is no filler.

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

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

An output schema exists so return values need not be spelled out, and the description still summarizes the returned structure. For a one-parameter read tool, the prerequisite, scope, and format guidance make it complete enough to invoke correctly.

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

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

Schema description coverage is 0% for the single asset_path parameter, so the description must compensate. It does so by giving a concrete path example ('/Game/Blueprints/BP_Character'), which conveys the expected UE5 asset-path format the bare schema does not.

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

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

States a specific verb and resource ('Export the audio-relevant subgraph from a Blueprint') and immediately narrows the scope: 'Returns only audio nodes + their 1-hop neighbours, with pin data and connections.' This is precise enough to distinguish it from generic graph/scan siblings like bp_scan_blueprint or ms_export_graph.

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

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

Gives a clear use case: 'Useful for understanding how Blueprint events drive MetaSounds/Wwise parameters.' That tells the agent when this tool is the right pick, but it names no alternatives or explicit exclusions among the many graph-related siblings.

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

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

No annotations were provided, so the description carries the full burden. It does disclose the dependency on the UE5 C++ plugin and reveals the query mechanism (Asset Registry), which is useful. But it does not discuss pagination behavior despite a 5000 default limit, truncation, or permission requirements, leaving important operational details implicit.

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

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

Front-loaded with the core action in the first sentence; the Args section is compact and readable. Slight redundancy between first sentence and the 'Queries the Asset Registry' follow-up, but no filler.

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

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

An output schema exists (return values need not be described), and the description covers all three parameters plus the plugin precondition. Remaining gap is guidance on how this tool relates to sibling enumeration tools and pagination behavior.

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

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: it explains class_filter as an asset class name (with examples), path as a prefix to search under (with default), and names the default limit. It does not explain the limit's semantics (e.g., truncation).

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

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

States a specific verb (List), resource (project assets), and mechanism (Asset Registry, by class type). However, it does not differentiate itself from sibling tools like bp_search or bp_list_categories, which also enumerate blueprint/asset metadata. An agent might struggle to pick the right enumeration tool without opening schemas.

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

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

Provides a vague use case ('discovering Blueprints, MetaSounds, SoundWaves ... before scanning') but no explicit when-to-use vs when-not, and no comparison to sibling tools like bp_search or bp_list_categories. The 'before scanning' hint is the only routing signal.

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

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

No annotations are provided, so the description carries the full burden. It implies a read (listing) but never states that it is non-mutating, whether results are cached, how counts are computed, or anything about ordering. For a zero-annotation tool this is thin.

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

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

Two short lines with no padding; the purpose is front-loaded. The "Args:" style block is slightly awkward for a single optional argument but costs little.

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

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

An output schema exists, so return structure needn't be explained, and the tool is a simple single-parameter list. Still, with no annotations and no usage context, an agent lacks the when-to-use and read-only assurances it needs to select confidently among many sibling list/search tools.

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

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

Schema description coverage is 0% and the schema gives only a default of "all" with no enum, so the description is the sole source for the three accepted values ("all", "curated", "scraped"). That is a genuine addition beyond the schema, though it doesn't explain what "curated" vs "scraped" actually means.

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

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

States a specific verb and resource — listing Blueprint node categories, with counts — which is concrete and distinguishable from bp_search or bp_node_info. It stops short of explicitly differentiating itself from the near-identical sibling ms_list_categories.

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

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

No statement of when to call this versus alternatives like bp_search, ms_search_nodes, or ms_list_categories. The `source` argument hints at a curation/scraping distinction but never says which context calls for which value.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return payload and hints at the 'registered' prerequisite, but says nothing about error behavior for unregistered nodes, whether it is purely read-only, or how connections are represented beyond 'connection status'.

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

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

Purpose and return fields are front-loaded in the first two sentences, which is well structured. The trailing 'Args:' block largely restates the single required property and adds little, a minor redundancy.

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

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

For a single-parameter read tool with an output schema, the description covers purpose, returned fields, and the registration precondition adequately. The remaining gap is the absence of any behavioral notes given zero annotations.

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

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

Schema coverage is 0% and the sole parameter node_id is undocumented in the schema, so the description must compensate. 'Registered node ID' adds a meaningful qualifier over the bare schema, but does not explain the ID's format or where to obtain it.

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

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

States a specific verb and resource ('List all pins on a registered Blueprint node') and names the returned fields, so the agent knows exactly what it retrieves. It does not, however, distinguish itself from close siblings like bp_node_info, which an agent might reasonably pick instead.

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

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

The word 'registered' implies a precondition (the node must first be registered, likely via bp_register_existing), which is useful. But there is no explicit when-to-use guidance and no routing to alternatives such as bp_node_info, so the usage is only implied.

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

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

No annotations exist, so the description carries the behavioral burden. It usefully discloses the data-source preference and fallback ('prefers scraped data, falls back to curated'), which tells the agent results may vary in richness. However it omits whether the call is read-only/safe, what happens if the node_name is not found, and any error or rate-limit behavior.

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

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

Front-loaded with the core purpose in the first sentence, followed by the data-source behavior and a clearly labeled args section. No filler sentences, though the docstring-style Args block is slightly more verbose than necessary for a single parameter.

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

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

Output schema exists, so return values need not be explained, and the description covers purpose, data source, and the single parameter with examples. With no annotations it leaves safety/error behavior implicit, but for a read-style info lookup that gap is minor.

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

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

Schema coverage is 0% and there is one required parameter, so the description is the only place semantics could be added. It does specify the parameter must be an exact node name and gives concrete examples ('PlaySound2D', 'SpawnSoundAtLocation'), which is genuine value over the bare schema — but it stops short of format details like case sensitivity or namespace.

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

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

States a specific verb and resource: 'Get full Blueprint node info including pin specs.' An agent can tell this retrieves metadata about a Blueprint node. It does not explicitly contrast with close siblings like bp_list_node_pins or ms_node_info, which limits it below a 5, but the purpose is unambiguous.

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

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

Usage is implied — call it to inspect a node — but there is no explicit when-to-use, when-not-to-use, or alternative guidance despite many related Blueprint node tools (bp_list_node_pins, ms_node_info, bp_search). The data-source fallback note hints at behavior but does not route the agent between tools.

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

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

With no annotations, the description carries the behavioral burden and discloses a non-obvious side effect: 'Resets any previously registered node handles.' It also establishes the ordering prerequisite. It omits error/failure behavior (e.g., invalid asset_path, already-open asset), so it stops short of full transparency.

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

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

Front-loads the core action, then the prerequisite and side effect, then the argument. Every sentence earns its place with no filler.

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

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 an output schema covering returns, the description supplies purpose, prerequisite, side effect, and parameter example. It could be more complete by mentioning failure modes or what happens if the asset is already open.

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

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

Schema description coverage is 0% and the single parameter has only a bare title, but the description compensates with a concrete example path and clarifies it is a Blueprint asset path, which is more than the schema provides.

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

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

States a specific verb+resource ('Open a Blueprint asset for editing via the UE5 plugin') and its role as a prerequisite, clearly distinguishing it from read-only siblings like bp_scan_blueprint and bp_list_assets.

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

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

Explicitly states when to call it ('Must be called before adding nodes or connecting pins'), which is strong context. It does not name alternatives (e.g., bp_register_existing) or when-not-to-use cases, so it falls short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the registration intent and the source of the GUID, but says nothing about idempotency, whether reusing a node_id overwrites, failure modes for a bad GUID, or what internal state changes. Adequate but incomplete for a stateful mutation.

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

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

Three short, front-loaded lines: purpose, workflow, then parameter notes. No filler, and the essential constraint (register before connecting) appears before the args.

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

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

An output schema exists, so return values needn't be explained, and both parameters plus the prerequisite call are covered. Missing only edge-case behavior (duplicate registration, invalid GUID handling), which is a minor gap for a two-param tool.

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

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

Schema coverage is 0%, so the description must compensate and largely does: node_id is 'MCP handle ID you want to use for this node' and node_guid is 'the node's FGuid string from the Blueprint scan', including where to obtain it. Only the expected format/uniqueness of node_id is left implicit.

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

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

States a specific verb (register) and resource (an existing Blueprint node) with an explicit purpose clause ('so it can be wired to'), which distinguishes it from the read-only sibling bp_scan_blueprint that merely discovers nodes.

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

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

Gives an explicit workflow -- call bp_scan_blueprint with include_pins=true to obtain GUIDs, register them here, then connect pins. It names the preceding tool and the condition, but offers no when-not guidance (e.g., versus bp_add_bp_node for new nodes).

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

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

With no annotations, the description carries the full behavioral burden. It discloses the plugin requirement, the scope of inspection ('all graphs'), and the filtering behavior of audio_only, which is useful. However, it does not explicitly state that the operation is read-only, whether it mutates state, or what permissions are needed, 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.

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

The description is front-loaded with the core action and then uses a structured Args block for parameter details. It is appropriately sized and avoids redundancy, though the opening sentence could be slightly tighter. Overall, every section earns its place.

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

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

An output schema exists, so the description need not explain return values. Given the lack of annotations and 0% schema coverage, the description adequately covers parameters and key behavioral context (plugin requirement, scope, audio filtering). The main missing piece is explicit usage guidance versus sibling tools, which is already reflected in the usage_guidelines score.

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

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, and it does. It gives an example path for asset_path and explains that audio_only restricts output to audio-relevant nodes and include_pins adds full pin details per node. This adds clear meaning beyond the bare schema property names.

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

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

The description states a specific verb and resource: 'Deep-scan a Blueprint asset to extract graph nodes, function calls, and audio relevance.' It goes further by detailing what is inspected (all graphs, macros) and what is detected (audio-relevant nodes). However, it does not explicitly differentiate this deep scan from siblings like bp_search or bp_node_info, which likely cover related but narrower inspection tasks.

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

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 such as bp_search, bp_node_info, or bp_list_categories. It only notes a runtime prerequisite ('Requires the UE5 C++ plugin to be running'), which is a condition, not a routing rule. An agent must infer usage from the tool's purpose alone.

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

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

No annotations exist, so the description carries the full burden. 'Search' implies a safe read, and the curated/scraped scope is useful context, but it says nothing about result limits, ranking, case sensitivity, or pagination behavior.

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

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

Front-loaded purpose sentence, then a compact Args block covering every parameter with no filler. Slightly terse relative to the behavioral gaps it leaves open.

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

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

An output schema exists, so return values needn't be explained, and the read-only nature of a search is self-evident. The only material omission is matching semantics (partial vs exact, ordering) for a tool whose core purpose is retrieval.

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

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, and it does: it names all three parameters, explains query matches name and description, labels category as an optional filter, and enumerates the source values 'all', 'curated', 'scraped' that the schema lacks as an enum.

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

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

States a specific verb and resource ('Search Blueprint nodes by name or description') and clarifies the searchable fields. The 'Blueprint' domain distinguishes it from ms_search_nodes and other ms_* tools, though no sibling is named explicitly.

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

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

The description indicates the search spans 'curated and scraped Blueprint data', which implies when it applies, but it never says when to prefer this over bp_node_info, bp_list_assets, or ms_search_nodes, nor any exclusion conditions.

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

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

No annotations are provided, so the description carries the full burden. It implies mutation via 'Set a default value' but does not disclose side effects, whether the blueprint must be compiled or saved afterward, permission requirements, 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.

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

The description is short, front-loaded with the action, and uses a tight argument list with no wasted sentences. Every line contributes directly to invoking the tool.

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

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

An output schema exists, so return values need not be explained. However, for a mutation tool with no annotations and 0% schema description coverage, the description remains thin on prerequisites and side effects, making it only minimally complete for correct invocation.

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

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 gives brief meanings for all three parameters, including the useful detail that node_id is a 'Registered node ID', but it does not explain formats, how to obtain the registered ID, or acceptable value forms.

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

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

The description states a specific verb and resource: setting a default value on a Blueprint node's input pin. It is clear enough to distinguish from generic node/pin tools, but it does not explicitly differentiate from close siblings such as ms_set_default or bp_connect_bp_pins.

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

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

The description provides only the argument list and gives no when-to-use guidance, no prerequisites for obtaining or registering node_id, and no indication of when another tool like bp_connect_bp_pins or ms_set_default would be preferred.

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

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

With no annotations, the description does real work: it reveals the underlying engine call, the conditional upsert into the blueprint_nodes_scraped table, and the read-only behavior when update_db is false. It omits error/failure behavior and any engine-connection prerequisite, but the core side-effect profile is disclosed.

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

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

Front-loaded with the purpose sentence, then a mechanism sentence, then structured Args/Returns blocks. Slightly verbose in repeating the list_blueprint_functions detail, but nearly every sentence carries information.

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

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

For a five-parameter ingestion/sync tool with no annotations, the description covers mechanism, side effects, parameters, and defaults. The Returns block is somewhat redundant given an output schema exists, and sibling disambiguation is absent, but the definition is otherwise sufficient to invoke correctly.

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

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

Schema description coverage is 0%, so the description must carry the load, and it documents all five parameters with meaning and defaults (audio_only, update_db, filter, class_filter, limit). It explains what each filter acts on (function or class name), which the bare schema does not.

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

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

States a specific verb and resource — sync the Blueprint function catalogue from the running UE5 engine — and explains the mechanism (enumerating BlueprintCallable UFunctions via list_blueprint_functions). It does not, however, distinguish itself from near-siblings like ms_sync_from_engine or bp_scan_blueprint, leaving the agent to infer the difference.

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

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

The description implies usage (fetch engine function data, optionally persist it) and describes the update_db branch, but never states when to choose this over bp_scan_blueprint or the equivalent ms_ sync tool, nor prerequisites such as an established ue5_connect session. Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full behavioral burden and usefully enumerates the sequence of side effects: opening the Blueprint, optionally registering a source node, adding a SetFloatParameter call, setting the parameter name, connecting the source, and compiling. It does not cover error behavior, save state, or reversibility, but the composite mutation is clearly disclosed.

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

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

The description is front-loaded with the purpose, then gives a compact ordered step list and an Args section. Every sentence earns its place, and there is no redundant or filler text.

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

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

For a four-parameter composite tool with no annotations, the description supplies the operation sequence and parameter meanings, and an output schema exists to cover return values. Minor gaps remain around failure modes and whether the asset is saved after compiling, but the definition is largely complete.

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

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, and it does: all four parameters are explained with meaning beyond the schema titles, including a MetaSounds parameter example and the role of source_node_guid and source_pin. It stops short of specifying asset path format or pin-name constraints, but the added meaning is substantial.

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

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

The description names a specific verb and resource: wire a SetFloatParameter call into a Blueprint. It also flags the tool as high-level, which distinguishes it from lower-level siblings like bp_add_bp_node or bp_connect_bp_pins, though it does not explicitly name those alternatives.

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

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

The 'High-level' label implies this tool should be preferred over manually combining lower-level node and pin operations, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives are not named, so usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden and does well: it describes auto-detection of connection state, side effects (infrastructure creation, content generation, routing, moving objects), and the offline dry-run return. It still omits idempotency/overwrite behavior and permission requirements, so it is strong but not fully exhaustive.

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

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

The description is front-loaded with the core purpose, then structured into mode behaviors and an Args section. It is appropriately sized for a complex build tool, though it is long enough that a few additional trims would be possible without loss.

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

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

Given the tool's complexity, the lack of annotations, and the presence of an output schema, the description is complete enough to call it correctly. It covers purpose, connection-state behavior, parameter semantics, and expected outcomes (commands/manifest) without needing to duplicate return-value documentation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents both parameters well: categories as a comma-separated filter with default all and an explicit list of valid values, and setup_params as JSON overrides with a concrete example key and value.

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

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

The description states a specific verb (Build) and a compound resource (AAA audio project: infrastructure + content for all categories). It also enumerates the concrete outputs (Wwise buses/work units/switches/states, 3-layer content, bus routing, work unit moves), which lets an agent distinguish this from narrower siblings like template_aaa_setup or build_audio_system.

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

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

The description provides clear usage context by explaining the auto-detected connection states and the resulting behavior in each mode (full, Wwise-only, offline dry-run). However, it does not explicitly name alternatives or give when-not-to-use guidance against sibling tools such as build_audio_system or template_aaa_setup.

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

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, and it does so well: it discloses graceful degradation across three backends, what each mode returns (created IDs, deferred MetaSounds commands, or JSON layer specs), and that offline mode is a non-mutating dry-run preview. It omits permission/connection prerequisites and whether re-running overwrites existing assets, which keeps it short of 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.

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

Front-loaded with the core purpose, followed by tightly scoped bullets for the degradation behavior, the pattern enumeration, and an Args block. Every sentence conveys information an agent needs to select a backend mode or fill a parameter; nothing is padding.

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

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

For a mutation-style orchestration tool with no annotations, the description covers modes, return shapes, and all parameters, and an output schema exists so return-value detail is not required. What remains thin is the prerequisite surface: it never states that Wwise/UE5 must be connected first or what happens to pre-existing assets with the same name.

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

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, and it does: pattern is documented with concrete examples ("gunshot", "footsteps"), name is described as an asset-name prefix defaulting to the pattern name, and params_json is explained as per-layer JSON overrides with a worked example. All three parameters gain meaning not present in the bare schema.

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

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

States a specific verb (Build) and resource (a complete 3-layer audio system spanning Wwise + MetaSounds + Blueprints) from a pattern, which distinguishes it from the single-layer siblings (wwise_create_object, ms_build_graph, bp_compile_blueprint) and even from single-template siblings like template_gunshot. An agent can tell this is the multi-layer orchestrator without opening any schema.

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

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

Gives clear operating context by enumerating the three execution modes (full / Wwise-only / offline dry-run) and the ten available pattern names, which is directly actionable for selection. It stops short of naming alternatives explicitly (e.g., 'use template_gunshot for a single-layer Wwise-only build') or stating 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.

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 says execution is 'direct' but does not disclose side effects, required permissions, whether the call can mutate or destroy Wwise state, or error-handling behavior — all important for an arbitrary-execution escape hatch.

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

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

The purpose is front-loaded in a single sentence, followed by a compact bullet list of parameters. Every element is relevant and there is no filler, though the argument list is minimal rather than rich.

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

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

An output schema exists, so return values need not be explained, and the three parameters are at least named. However, for a powerful arbitrary WAAPI execution tool with no annotations and 0% schema coverage, the description lacks critical safety, permission, and usage context.

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

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 names all three parameters and gives a concrete URI example ('ak.wwise.core.object.getTypes'), but args_json and options_json are only described generically as 'JSON string of arguments/options' with no format or schema detail.

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

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

The description states a clear verb and resource: 'Execute any WAAPI call directly (escape hatch).' The 'escape hatch' framing distinguishes it from the many specific wwise_* sibling tools, though it does not explicitly name an alternative. An agent can tell this is the generic low-level path rather than a specialized operation.

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

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

The phrase 'escape hatch' implies the tool is for cases not covered by specialized siblings, which is useful implied guidance. However, it does not explicitly state when to prefer this tool over siblings like wwise_query or wwise_set_property, nor does it list exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. 'Find' implies a read-only operation, and the note that limit is 'clamped by the plugin' adds useful behavioral context. However, it does not explicitly state read-only safety, permissions, or any other runtime behavior an agent might need.

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

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

The purpose is front-loaded in one sentence, followed by a clean Args block. Every line earns its place with no repetition or filler.

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

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

The tool is simple and has an output schema, so return values need not be described. The description covers purpose and all parameters, but it omits usage routing and explicit safety behavior, leaving minor gaps for an agent selecting among many sibling tools.

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

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, and it largely does: all three parameters are explained with matching semantics, including examples for class_filter and the clamping behavior for limit. It stops short of details like case sensitivity or matching rules, but the meaning of each parameter is clear.

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

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

States a specific verb and resource: 'Find actors in the current editor or PIE world.' The scope is clear enough to distinguish from domain-specific search tools like bp_search or wwise_query, but the description does not explicitly name or exclude any sibling tool.

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

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

The scope 'current editor or PIE world' implies when the tool is applicable, but there is no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. Usage is left to inference.

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

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

No annotations exist, so the description carries the full burden. It does disclose the key behavioral knob (active_viewport_only moves only the active viewport camera) and that it targets the editor viewport rather than the game, but it omits whether an editor connection is required and whether the change is transient or persisted.

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

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

Front-loaded purpose sentence followed by a tight Args block with no filler. Slightly formal structure but every line earns its place.

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

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

An output schema exists so return values need no explanation, and both parameters are documented. What is missing for a viewport-mutating tool is context about prerequisites (e.g., needing ue5_connect first) and persistence, so it is adequate but not complete.

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

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

Schema coverage is 0%, so the description must compensate, and it does: actor accepts a label, object name, or full path, and active_viewport_only is explained as restricting the move to the active viewport. Only the default value and boolean false-case are left to the schema.

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

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

Specific verb+resource: 'Frame an actor in the Unreal Editor viewport camera.' An agent immediately knows this changes camera framing on a named actor. It does not differentiate itself from the nearby sibling set_view_target, which could plausibly be confused with this operation.

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

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

Usage is only implied through the workflow hint that the actor value comes from find_actor, which is genuinely helpful routing. There is no statement of when to prefer this over set_view_target, nor any precondition such as requiring an active editor connection.

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

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 usefully discloses the accepted file formats (.wav/.ogg) and that the file comes from disk, but says nothing about overwrite/name-collision behavior, whether the destination folder must already exist, or permission requirements for a mutation that writes into the Content folder.

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

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

Front-loaded single sentence stating action, formats, and destination, followed by a compact Args block that is justified because the schema itself has zero descriptions. Slight redundancy with the schema's parameter names, but no wasted prose.

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

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

With an output schema present, return values need not be explained, and both parameters are documented despite 0% schema coverage. What is missing for a write operation into the project's Content folder is conflict/overwrite handling and folder-existence semantics.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning, and it delivers: file_path is an absolute disk path and dest_folder is a Content-relative path with a concrete example ("/Game/Audio/SFX"). It does not clarify whether dest_folder is auto-created.

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

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

States a specific verb (Import) and resource (a .wav or .ogg sound file) with the target location (UE5 Content folder), which is more precise than the bare tool name. It does not name or contrast with the obvious sibling wwise_import_audio, so an agent must infer which import path applies to UE5 content versus Wwise.

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

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

The description says what the tool does but never states when to choose it over alternatives such as wwise_import_audio or bp_export_audio, nor any prerequisites (e.g. that ue5_connect must be established first). Usage is only implied by the tool's name and target folder.

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

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. 'Add' implies mutation, and 'Unique ID' hints at a uniqueness constraint, but the description does not state what happens on a duplicate node_id, whether the edit is saved or reversible, or whether an editor session must be active. For a graph-mutating tool with zero annotation coverage, this is a substantial gap.

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

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

The primary action sentence is front-loaded and the Args block is compact with no filler. It is appropriately sized for a four-parameter tool, though the example strings could be tightened.

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

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

An output schema exists, so return values need not be explained. But with no annotations and a bare schema, a mutating graph tool should at least note the uniqueness/duplicate behavior and any editor-session prerequisite; those omissions leave the definition only marginally complete.

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

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, and it does: it names all four parameters with meaning ('Node type name' with concrete examples like 'Sine', 'Wave Player (Mono)', 'Unique ID for this node instance', editor X/Y positions). This is more than the bare schema offers, though it could clarify units/coordinate space for position.

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

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

States a specific verb and resource: 'Add a MetaSounds node to the current graph.' An agent immediately knows this creates a node in the MetaSounds graph. However, it does not distinguish itself from siblings like ms_add_variable_node or ms_add_variable, which also add nodes to the same graph.

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

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

There is no when-to-use guidance, no prerequisites (e.g. whether a graph must be open or created first via ms_create_source/ms_build_graph), and no mention of alternatives such as ms_add_variable_node for variable nodes. The agent is left to infer context entirely.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the UE 5.7+ version requirement, the uniqueness constraint on names, and the allowed data types, but it does not mention mutation side effects, permissions, whether the graph must be saved afterward, or what happens on duplicate names.

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

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

The description is front-loaded with the action and resource, then adds concise context and a clean Args section. Every sentence contributes useful information without repetition or filler.

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

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

For a three-parameter mutation tool with an output schema and no annotations, the description gives enough detail to call it correctly: purpose, required parameters, type values, and uniqueness constraint. It remains slightly incomplete because it does not address when to choose this tool over related alternatives or whether saving is required.

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

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

Schema description coverage is 0%, so the description must fully compensate. It documents all three parameters, including the unique-name constraint for name, the complete allowed type list (Float, Int32, Bool, Trigger, Audio, Time, String), and that default_value is optional and passed as a string.

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

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

The description clearly states a specific verb and resource: adding a graph variable to the current MetaSounds builder. It distinguishes the concept from generic node addition by explaining that graph variables store state readable/writable by Get/Set Variable nodes, but it does not explicitly differentiate itself from siblings such as ms_add_variable_node or ms_add_node.

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

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

The description explains what a graph variable is but gives no guidance on when to use this tool versus alternatives like ms_add_node, ms_add_variable_node, or ms_set_default. It also omits any prerequisites beyond the UE 5.7+ requirement.

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

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 usefully discloses that 'set' is a write and 'get_delayed' reads the previous frame, which is genuine semantic info, but it stays silent on failure modes (missing variable, no active graph) and on whether the operation mutates the graph immediately or is deferred until build.

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

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

One lead sentence plus a compact Args block; nothing is padded and the purpose is front-loaded. The Args list mildly duplicates the schema but adds the mode enum semantics, so it earns its place.

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

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

An output schema exists, so return values needn't be explained. What remains missing is the interaction boundary with the very similar sibling tools and the preconditions for adding a node, which matters for a graph-mutation tool with no annotations to fall back on.

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

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 and largely does: it defines node_id, variable_name, and enumerates the three legal mode values ('get', 'set', 'get_delayed') with their meanings, which the schema itself does not (no enum present). It stops short of full coverage because it doesn't state the uniqueness scope of node_id or what happens if the variable_name doesn't exist.

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

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

States a specific verb and resource ('Add a Get, Set, or GetDelayed variable node') plus the scope ('to the current graph'), which is far more precise than the bare name. However, it never distinguishes itself from the near-identical siblings ms_add_node and ms_add_variable, so the agent cannot route between them from the text alone.

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

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

Usage is only implied: the description tells the agent this adds to 'the current graph' and that three access modes exist, which hints at the read-vs-write use case. It gives no when-to-use condition, no prerequisites (does a graph have to be open?), and no guidance for choosing this over ms_add_variable or ms_add_node.

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

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

No annotations are provided, so the description carries the full burden. It states nothing about what auditioning does behaviorally: whether it starts audio playback, produces side effects, requires an open editor, or how playback is terminated. For a playback-triggering tool, this is a significant gap.

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

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

One-line purpose followed by a compact arg note; nothing is wasted and the core action is front-loaded. The 'Args:' block is slightly mechanical but efficient.

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

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

An output schema exists, so return values need no explanation. However, for a playback-initiating tool with no annotations, the description omits prerequisites (open editor/asset context) and the relationship to ms_stop_audition, leaving the agent with partial operational context.

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

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

Schema description coverage is 0% and the single parameter has no description in the schema, so the description compensates by explaining that 'name' is an optional audition target and that empty means the current graph. This clarifies the default behavior meaningfully.

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

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

States a specific verb (preview/audition) and resource (the current MetaSounds graph), and 'in the editor' indicates the environment. It does not name the obvious counterpart ms_stop_audition, so it falls short of full sibling differentiation.

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

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

The description implies usage by clarifying 'current graph' vs a named asset, but gives no explicit when-to-use guidance, no prerequisites (editor must be open), and no mention of the alternative ms_stop_audition for ending playback.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that this is a full mutating pipeline that executes commands against UE5, which is useful. However, it omits preconditions (does UE5 need to be connected?), whether it overwrites existing graph state, and what happens on validation failure.

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

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

The pipeline summary is front-loaded and efficient, capturing the whole operation in one sentence before the Args block. The 'Args:' boilerplate is slightly redundant with the single-parameter schema but not costly.

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

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

An output schema exists, so return values needn't be explained. For a high-complexity orchestration tool, however, the description leaves gaps around preconditions and failure behavior, and gives no help on the one opaque input it requires.

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

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

Schema coverage is 0% for the single required parameter. The description only restates that graph_spec is a 'JSON string of the MetaSounds graph specification,' adding almost no meaning beyond the schema's title 'Graph Spec' and offering no structural or format guidance an agent would need to construct it.

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

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

The description uses specific verbs and resources: 'validate a graph spec, convert to Builder commands, and send all to UE5.' It also self-identifies as the high-level orchestrator, implicitly distinguishing it from the step-wise siblings ms_validate_graph and ms_graph_to_commands. It stops short of explicitly naming those siblings as alternatives.

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

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

'This is the high-level tool that does everything' implies you should reach for this instead of the individual validate/convert steps, but it never states when NOT to use it or explicitly names the alternative tools. Usage is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation ('Connect') but does not disclose side effects, validation behavior, error conditions, or whether an editor/graph must be open. This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is front-loaded with the core action and then uses a compact Args block with zero waste. Every sentence and entry earns its place.

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

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

An output schema exists, so return values need not be explained. However, with no annotations and zero schema descriptions, the definition still lacks behavioral context such as side effects or prerequisites. The essential parameter roles are covered, but the description is only minimally complete for a mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by listing all four parameters with their semantic roles: source node ID, source output pin name, destination node ID, and destination input pin name. This meaningfully clarifies directionality beyond the bare schema titles, though format details remain absent.

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

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

States a specific verb and resource: 'Connect two node pins in the current MetaSounds graph.' This clearly distinguishes the operation from generic graph tools. However, it does not explicitly differentiate itself from similar sibling tools like bp_connect_bp_pins or ue5_connect.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. The phrase 'in the current MetaSounds graph' implies context but does not tell the agent when this tool is appropriate versus other pin-connection tools.

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

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

With no annotations, the description carries the full burden and discloses important behavioral traits: the builder's graph becomes read-only, inherits the referenced asset's topology, and only exposed input defaults can be overridden. It does not cover permissions, side effects like saving, or failure modes, so it falls short of 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.

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

The description is front-loaded with the core action, then adds behavioral constraints, then documents the argument. It is appropriately sized and every sentence contributes useful information with no filler.

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

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

An output schema exists, so the description need not explain return values. Given that, it covers the key behavioral change and the single parameter well, but lacks prerequisites such as whether a builder must be open or selected, and does not route to alternatives like ms_preset_swap.

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

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 for the single parameter. It does so by explaining that referenced_asset is a 'Content path of the source MetaSound' and giving an example path, which is enough to use the parameter correctly. It stops short of stating format constraints or whether the asset must already exist.

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

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

The description states a specific verb ('Convert') and resource ('current MetaSounds builder to a preset of a referenced asset'), so the agent knows exactly what the tool does. It does not differentiate against similar siblings such as ms_preset_swap or ms_preset_morph, which keeps it short of a 5.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It implies action on 'the current MetaSounds builder' but leaves the agent to infer context and compare with related preset and graph tools on its own.

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

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 states that a new asset is created, but does not disclose side effects, permissions, whether the asset is persisted automatically, or how it interacts with the UE5 project.

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

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

The description is short and front-loaded: the first sentence states the action, and the Args section efficiently documents both parameters. There is no redundant or filler text.

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

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

For a two-parameter creation tool with an output schema, the description covers the core action and parameter meanings. However, with no annotations and no sibling guidance, it leaves gaps around prerequisites, side effects, and when this tool is preferred over other MetaSounds tools.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that name is the MetaSound asset name and that asset_type accepts Source, Patch, or Preset, adding useful semantics beyond the bare schema titles.

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

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

The description states a specific verb and resource: 'Create a new MetaSounds source builder in UE5.' It is clear what the tool does, but it does not distinguish itself from nearby siblings such as ms_convert_to_preset or ms_build_graph.

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

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. It mentions valid asset_type values, but never states when a Source, Patch, or Preset should be created, nor which sibling tool handles other related tasks.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return payload ('Returns the full graph data') and the side option that a template conversion also occurs, but it never states that this is a non-mutating read, nor mentions permissions, cost, or whether the asset is left untouched — gaps for an unannotated tool.

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

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

Front-loaded with purpose, then return payload, then the optional flag, then a clean Args block. Slightly redundant ('Export a complete... graph' followed by 'Returns the full graph data'), but every segment is short and earns its place.

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

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

An output schema exists, so return-value explanation is not required, and the description still names what is exported and documents both parameters, including the optional template conversion path. Complete enough to call correctly, missing only the guidance about when to pick this tool.

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

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, and it does: asset_path is given with a concrete path format example (/Game/Audio/MySound) and convert_to_template is explained as converting to the reusable template format. Both parameters gain meaning beyond the bare schema types.

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

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

States a specific verb and resource ('Export a complete MetaSounds graph from UE5') and even enumerates the contents (nodes, pin types, defaults, variables, interfaces), which lets the agent distinguish it from the import-direction sibling ms_graph_from_template. No sibling is named explicitly and no boundary against ms_graph_to_commands/ms_list_nodes is drawn, so it falls short of a 5.

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

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

The description implies a read/export use case but never states when to choose this over alternatives such as ms_graph_to_commands, ms_list_nodes, or ms_graph_from_template. The only conditional offered ('Optionally converts to our reusable template format') describes a flag, not a selection criterion.

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

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 templates are auto-discovered from a specific directory and that output is 'ready for validation', which usefully implies a downstream ms_validate_graph step. It does not state whether generation is read-only, what happens if template_name is unknown, or whether defaults are persisted.

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

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

Front-loaded with the core action, followed by a brief discovery note. The Args/Returns docstring block is conventional and slightly boilerplate, but nothing is wasteful for a 2-parameter tool.

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

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

An output schema exists, so not explaining return values is acceptable even though it briefly does. The description covers the mechanics of both parameters at a high level but omits the relationship to the many template_* siblings and the expected params JSON structure, leaving an agent with gaps on routing and input format.

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

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

Schema description coverage is 0%, so the description must compensate. It explains template_name with concrete examples ('gunshot', 'footsteps') and clarifies that params is a JSON string that overrides defaults. It still does not describe the shape or keys of that JSON params object, leaving the main flexibility parameter partly opaque.

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

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

States a specific verb and resource: 'Generate a complete graph spec from a template.' This is clear and distinct from low-level build tools like ms_add_node or ms_connect_pins. However, it does not differentiate itself from the numerous template_* siblings (template_gunshot, template_footsteps, template_ambient), which appear to do the same job by template identity.

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

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

No guidance on when to choose this over the template_* siblings, ms_build_graph, or building a graph manually. The only implied context is that templates are auto-discovered from the metasounds template directory, which hints at a discovery workflow but does not state when this tool is the right call.

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

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 this is a pure transformation producing an ordered command list, which signals no direct side effects, but says nothing about failure modes on invalid specs 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.

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

Front-loaded one-line purpose followed by Args/Returns blocks; no wasted text, appropriately sized for a single-parameter transform tool.

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

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

An output schema exists so return values needn't be detailed, yet the description still notes the ordered command list. For a simple pure-transform tool with one param, this is close to complete, with only the validation prerequisite left implicit.

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

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

Schema coverage is 0%, but the description documents the single parameter as a JSON string of a valid graph specification and the 'validated'/'valid' wording implies a prior validation step (ms_validate_graph), adding meaning beyond the bare schema.

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

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

The description gives a specific verb+resource+output: convert a validated graph spec into a Builder API command sequence. This distinguishes it from ms_validate_graph and ms_build_graph, though it doesn't explicitly name those siblings.

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

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

It states the downstream consumer (UE5 plugin Phase 3 / Builder API), which implies the workflow context, but offers no explicit when-to-use vs alternatives or prerequisites beyond 'validated'.

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

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

With no annotations, the description carries the full burden, and it does disclose the return shape (category names + node counts). It says nothing about whether categories are static or engine-synced, permission needs, or whether the engine connection must be live, which matters given the ue5_*/ms_sync_from_engine siblings.

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

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

Two short sentences, purpose front-loaded, no filler. The trailing 'Returns:' block is mildly redundant given the output schema but is one line and not wasteful.

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

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

For a zero-parameter read with a full output schema, the description covers what the tool produces and needs no return-value elaboration. The only gap is the absence of any hint about when in the MetaSounds workflow to call it.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate and no parameter semantics are missing.

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

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

The description names a specific verb and resource ('List all MetaSounds node categories') plus the payload characteristic ('with counts'), which cleanly separates it from ms_list_nodes (nodes) and ms_search_nodes. It never explicitly names those siblings, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is a discovery/introspection call to run before drilling into nodes, but there is no statement of when to prefer it over ms_list_nodes, ms_search_nodes, or bp_list_categories, and no exclusions or prerequisites.

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

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 implies a read-only listing operation and describes return fields, but it does not explicitly state safety, side effects, permissions, or engine/connection requirements.

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

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

The definition is front-loaded and compact, using clear Args and Returns sections. Every sentence contributes to understanding the tool, with no wasted text.

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

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

Given the simple two-parameter listing operation and the presence of an output schema, the description is adequate. However, it lacks annotations and does not explain how it relates to sibling listing/search tools, leaving some routing ambiguity.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains both optional parameters and gives concrete examples for category ('Filters', 'Generators') and tag ('underwater', 'oscillator'), adding useful meaning beyond the bare schema.

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

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

The description states a clear verb and resource: 'List MetaSounds nodes.' It adds the optional filtering scope by category or tag. It does not distinguish itself from close siblings such as ms_search_nodes or ms_list_categories, so it falls short of a 5.

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

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

The description mentions optional filters but gives no guidance on when to use this tool versus alternatives like ms_search_nodes or ms_node_info, and no exclusions or prerequisites. Usage is only implied by the word 'List.'

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

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

With no annotations, the description must carry the behavioral burden. It discloses the step structure and action types ('set_default' or 'convert_to_preset'), which tells the agent what mutations will occur. But it does not say whether the sequence is atomic, whether changes are saved automatically, what side effects might occur, or what permissions are required – significant 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.

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

The description is front-loaded with the tool's purpose, then describes the step format, use cases, and arguments in a compact list. It is appropriately sized and every sentence contributes, though the 'Args' section slightly repeats parameter names without much added explanation.

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

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

Given the tool's complexity (a macro executor), the poor schema coverage (0%), and the absence of annotations, the description provides essential parameter structure and use cases. However, it omits behavioral caveats such as whether the operation is destructive, whether it saves automatically, or error handling, leaving the agent without full context for safe invocation. The output schema exists, so return values need not be explained.

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

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, and it does. It explains that 'name' is a descriptive name and 'steps_json' is a JSON array of step dicts, including the required 'action' field and action-specific fields like node_id/input/value or referenced_asset. This is substantial semantic detail beyond the bare schema types.

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

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

The description states a specific verb and resource: 'Execute a named sequence of parameter changes and/or preset swaps.' It is clear what the tool does, but it does not explicitly differentiate itself from siblings like ms_set_default, ms_convert_to_preset, or ms_preset_swap, so the agent must infer that this tool is for multi-step macros.

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

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

It gives use cases ('cinematic audio cues, dynamic music transitions, and scripted sound design sequences'), which implies when to use it. However, it does not state when not to use it or name alternative tools for single parameter changes or preset swaps, leaving the agent to infer the distinction.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the return shape (JSON node definition with pins and defaults) and stresses the name must be exact, but says nothing about read-only nature, where valid names come from, or failure behavior for an unknown name.

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

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

Front-loaded one-line purpose followed by a compact Args/Returns block. Structured and efficient; the Args/Returns headers are slightly formal but nothing is wasted.

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

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

For a single-parameter lookup tool with an output schema, the definition is nearly self-sufficient. The remaining gap is that it never tells the agent where a valid exact node name originates (the ms_search_nodes/ms_list_nodes siblings).

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

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

With 0% schema coverage on the single parameter, the description must compensate and largely does: it specifies the argument is the 'Exact node name' and supplies two concrete examples ('Biquad Filter', 'Wave Player (Mono)'), which meaningfully exceeds the bare schema type: string.

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

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

States a specific verb (Get) and resource (full details for a specific MetaSounds node), and the word 'specific' implicitly separates it from list/search siblings like ms_list_nodes and ms_search_nodes. It stops short of naming those alternatives, so it is clear but not fully differentiated.

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

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

Usage is only implied: call it when you already have a node name and need full details. There is no explicit when-to-use/when-not guidance and no routing to ms_search_nodes or ms_list_nodes for discovering node names, which is the natural prerequisite.

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

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

With no annotations, the description carries the full burden. It usefully discloses the save-first prerequisite and that a visual graph editor opens showing nodes and connections, but it never states whether the operation is side-effect-free, whether it requires a live editor/connection, or what happens when no asset has been built.

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

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

Three short lines, front-loaded with the core action, then the prerequisite, then the observable result. Every sentence earns its place with no filler.

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

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

For a zero-parameter tool that has an output schema (so return values need not be described), the description covers purpose, precondition, and visual outcome adequately. It could be more complete by noting editor/connection requirements or failure behavior when no asset exists.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing parameter-related the description could add or omit.

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

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

States a specific verb and resource ('Open the last built MetaSound asset in the UE5 MetaSounds editor'), so the agent knows exactly what action and target are involved. It does not explicitly contrast with nearby siblings like ms_audition or ms_export_graph, so it stops short of full sibling differentiation.

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

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

Gives a concrete precondition ('Must call ms_save_asset first to create a .uasset on disk'), which tells the agent the ordering required before invocation. It does not name alternative tools or state when NOT to use this one, so it lacks explicit exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool constructs Map Range nodes per parameter and InterpTo transitions, and that the morph input operates on a 0.0-1.0 range. It omits overwrite/asset-collision semantics and creation failure behavior, which matter for a mutating asset-creation tool, keeping it short of 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.

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

The purpose sentence is front-loaded, followed by the interpolation mechanics and then an Args block. The Args block partly duplicates the schema, but given 0% schema description coverage that duplication is functional rather than wasteful.

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

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

For a graph-construction tool with an output schema and no annotations, the description covers purpose, morph semantics, and every parameter. It stops short of covering overwrite behavior or what happens on invalid, but an agent has enough to invoke it correctly.

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

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

Schema coverage is 0%, so the description must compensate, and the Args block documents all four parameters including the defaulted asset_path, which the raw schema leaves as bare titles. It adds meaning (set A at Morph=0, set B at Morph=1) but does not specify the JSON value typing or the required shape beyond 'param_name -> value'.

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

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

The description gives a specific verb and resource: it builds a MetaSound Source that morphs between two parameter sets, with the morph semantics (Morph 0.0-1.0 interpolating set A to B) spelled out. It does not, however, name or contrast with any sibling such as ms_preset_swap or ms_create_source, which is the natural alternative an agent would weigh.

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

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

Usage is only implied: an agent can infer this is for creating a parameter-morphing source, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives like ms_preset_swap or ms_create_source. The morph range is stated but is a mechanic, not guidance about choosing this tool.

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

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

With no annotations, the description carries the burden. It explains that the preset shares the referenced asset's graph topology, which is crucial. It also clarifies the overriding behaviour. However, it could mention if the referenced asset must exist or if the operation is non-destructive.

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

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

It is well-structured, front-loaded with the purpose, and every sentence adds value. The parameter list is clean and directly follows the description.

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

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

It is complete enough for an agent to use it, especially since an output schema exists. The only minor gap is the absence of details about the output asset or potential errors, but that is not critical.

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

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

Schema description coverage is 0%, so the description must compensate. It provides a clear meaning for each of the four parameters, including what the JSON object represents ('input_name -> value overrides'), going well beyond the schema.

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

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

It states a specific verb and resource ('Create a preset variant'), explains what a preset shares and overrides, and provides a concrete use case ('weapon/surface/character variants'). This clearly distinguishes it from siblings like ms_convert_to_preset and ms_preset_morph.

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

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

It gives clear context for when to use it ('create variants without duplicating the graph'), which implies when not to use it (full graph duplication), but it doesn't explicitly name alternative tools or routing conditions.

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

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 names the operation and default path. It does not say whether an existing asset is overwritten, whether the editor must be open, what permissions are needed, or what side effects occur. The one useful addition is the default path for generated content.

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

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

The description is short and front-loads the action before listing arguments. It avoids filler, though the argument list is minimal and could be slightly more informative without bloat.

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

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

For a two-parameter tool with an output schema, the description covers the basic action and both parameters, so an agent can invoke it. However, missing annotations and absent when-to-use or side-effect details leave gaps for a tool that writes an asset.

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

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

Schema description coverage is 0%, so the description is the main source for parameter meaning. It documents both parameters ('name: Asset name', 'path: Content path (default /Game/Audio/Generated/)'), which is better than nothing, but 'Asset name' is nearly tautological and no format or validation details are added.

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

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

States a specific action ('Build the current MetaSounds graph to a UE5 asset') and names the resource (MetaSounds graph) and target (UE5 asset). However, it does not distinguish this tool from closely related siblings like ms_build_graph or ms_export_graph, and the verb 'Build' could be confused with save semantics.

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

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 such as ms_build_graph, ms_export_graph, or ms_graph_to_commands. It only lists the two arguments and does not say when saving/building to an asset is appropriate or what prerequisites exist.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the search mechanism ('TF-IDF embeddings for meaning-based search with tag fallback') and the return shape ('ranked results (name, score, category, description)'), which gives an agent useful context. It does not mention permissions or rate limits, but these are less critical for a read-only search tool.

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

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

The description is front-loaded with the core purpose, followed by method, examples, and structured Args/Returns sections. Every sentence adds value without redundancy or waste.

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

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

For a simple search tool with one parameter and an output schema, the description covers purpose, method, parameter meaning, and return structure adequately. The only notable gap is the lack of explicit routing to sibling tools, but otherwise it provides what an agent needs to invoke the tool correctly.

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

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

The input schema provides no description for the single query parameter (0% coverage), so the description must compensate. It does so by describing it as a 'Natural language search query' and providing example queries, which clarifies the expected format far beyond the schema's bare type information.

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

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

The description states a specific verb and resource: 'Semantic search for MetaSounds nodes by description or purpose.' It clearly communicates what the tool does, but does not explicitly differentiate itself from sibling tools like ms_list_nodes or ms_node_info, which likely cover browsing or fetching node details.

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

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

Usage is implied through examples such as 'underwater effect' and 'random variation,' which show the kind of natural-language queries expected. However, there is no explicit guidance on when to use this semantic search versus alternatives like ms_list_nodes or browsing categories, and no exclusions are stated.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It notes encoding for complex values but does not disclose mutation side effects, persistence, prerequisite node state, or error behavior.

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

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

The description is tightly front-loaded: one sentence states the action, followed by a compact argument list. Every line adds useful information without filler.

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

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

An output schema exists, so return values need not be described. However, with no annotations and no usage guidance, the description leaves behavioral prerequisites and when-to-use context incomplete for a graph mutation tool.

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

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 briefly documents all three parameters, including that node_id is a node instance ID, input_name is an input pin name, and value is JSON-encoded for complex types.

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

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

The description states a specific verb and resource: setting a default value for a node input pin. It is clear enough to distinguish from tools like ms_connect_pins or ms_add_node, but it does not name or contrast with any sibling tool.

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

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

The description explains what the tool does but gives no guidance on when to use it, when not to use it, or which alternatives exist. It lists arguments only, leaving usage context to inference.

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

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

With no annotations, the description carries the full behavioral burden, yet it only says it stops playback. It does not state whether it is safe/idempotent, what happens if nothing is playing, whether it returns an error, or whether it affects saved assets.

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

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

A single front-loaded sentence with no filler; every word earns its place.

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

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

For a zero-parameter stop action with an output schema documenting the return, the description is nearly sufficient. The only missing piece is behavioral context (no-op/error behavior), which keeps it from a 5.

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

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

The tool takes zero parameters, so there is nothing for the description to add; the baseline for a no-param tool applies.

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

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

Specific verb+resource: 'Stop ... MetaSounds audition preview.' The 'any currently playing' scope qualifier makes the effect unambiguous, and it is clearly distinct from ms_audition. It stops short of a 5 only because it does not name the sibling it pairs with.

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

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

There is no explicit when-to-use guidance and no mention of ms_audition as the counterpart that starts the preview. The usage context (after auditioning) is only inferable from the tool name, not stated.

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

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

With no annotations, the description carries the full behavioral burden and does reasonably well: it discloses the side effects (updates the in-memory METASOUND_NODES dict and optionally upserts into the SQLite DB) and the delegation to an engine command. It does not state the engine-connection requirement, whether existing entries are overwritten/lost, or any failure mode.

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

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

Front-loaded with the core action in the first line, then a short mechanism sentence, then Args/Returns. The Returns block is somewhat redundant given an output schema exists, but the overall structure is clean and each section is brief.

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

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

For a sync tool with three optional params and an output schema present, the description covers purpose, mechanism, side effects, and parameter meaning adequately. It omits the engine-connection prerequisite and the overwrite semantics of the sync, which are the main remaining gaps.

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

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, and it does: update_db is explained as an optional SQLite upsert, filter as a substring filter on node class names, and limit as the max nodes to fetch with its 5000 default. All three parameters gain meaning beyond the bare schema types.

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

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

States a specific verb and resource ('Sync MetaSounds node catalogue from the running UE5 engine') and explains the mechanism (calls list_metasound_nodes against the engine registry, refreshes the in-memory METASOUND_NODES dict). This clearly distinguishes it from read-only siblings like ms_list_nodes/ms_search_nodes and from the analogous bp_sync_from_engine.

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

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

The description implies usage (refreshing the local catalogue from the engine) but never states when an agent should call this versus ms_list_nodes, ms_node_info, or bp_sync_from_engine. No prerequisites (e.g. an active ue5_connect session) or exclusions are given, so the agent must infer context.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the validation checks and the return shape (errors list, empty means valid), but it does not state whether the operation mutates state, requires an active editor/connection, or has any side effects.

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

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

The description is front-loaded with purpose and checks, then structured with Args and Returns blocks. It is compact overall, though the Returns block slightly duplicates the available output schema.

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

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

For a one-parameter validation tool with an output schema, the description covers purpose, checks, argument meaning, and error return format adequately. Missing side-effect or permission context is minor for a validator, especially since the output schema handles return details.

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

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 identifies graph_spec as a JSON string of the graph specification, adding type and intent beyond the bare schema, but it does not describe the expected JSON structure or fields.

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

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

The description states a specific verb and resource: validate a MetaSounds graph specification. It further enumerates the exact checks performed, so the agent can distinguish it from sibling build/connect/save tools without opening schemas.

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

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

No explicit when-to-use guidance, prerequisites, or alternatives are provided. The agent must infer that this is a pre-build validation step from the name and sibling context.

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

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

With no annotations, the description carries the full behavioral burden. It reveals that this mutates an animation asset, but says nothing about whether the asset must be open, whether changes are saved/persisted, what happens to existing notifies, or whether special permissions are needed. For a write operation with zero annotation coverage this is a real gap.

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

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

Purpose is front-loaded in the first sentence, the usage rationale follows, and the parameter block is necessary given 0% schema coverage. No filler sentences, though the layout could be slightly tighter.

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

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

The output schema exists, so return values need not be explained, and the parameter block is adequate. But for a mutation tool with no annotations, the description omits sibling differentiation and persistence/save semantics, leaving meaningful gaps for correct invocation.

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

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, and it largely does: it documents all four parameters including a concrete asset-path example, that time is in seconds, that sound is optional, and the default for notify_name. Minor imprecision remains (path format conventions, SoundBase vs. other asset types), but coverage is solid.

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

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

The description gives a specific verb+resource (place an AnimNotify_PlaySound on an animation) with a scoping detail (at a specific time), which is far more than a restatement of the name. However, it never distinguishes itself from the sibling place_bp_anim_notify, leaving the agent to guess which notify-placement tool applies to a given asset type.

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

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

It offers a strong contextual hint by calling itself 'the proper way to sync sounds to animation frames' with a footstep example, which implies preferred usage. But it names no alternative (notably place_bp_anim_notify) and states no when-not condition, so the routing guidance is only implicit.

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

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 real behavioral traits: reverb/interior settings activate on player entry, and priority governs precedence when volumes overlap. However, it omits operational context such as whether an editor/UE connection is required, whether the actor persists or is saved, and what the call returns.

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

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

Front-loaded with the essential verb+resource and purpose, followed by a short usage line and a clean Args list. No filler sentences; only the usage line and the args list could be marginally tighter.

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

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

With an output schema present, return values need not be explained, and the parameter semantics are covered in the Args block. What remains missing is environmental preconditions (editor connection, save/persistence behavior), which matters given siblings like ue5_connect and ue5_status.

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

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, and it largely does — it defines all five parameters, including non-obvious semantics like 'half-size of the volume box' for extent and 'higher = takes precedence' for priority, plus a default for extent. Minor gap: location units/frame are not specified.

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

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

States a specific verb ('Place') and resource ('AudioVolume actor'), then immediately defines what that actor is ('defines an ambient audio zone'). This distinguishes it from sibling spawn_audio_emitter and from Wwise-side tools.

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

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

Gives concrete usage context — 'Use for rooms, caves, outdoor areas with different acoustic properties' — which tells the agent when this tool applies. It does not name an alternative or state when NOT to use it (e.g., vs. spawn_audio_emitter or template_ambient), so it falls short of 5.

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

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 reveals what the placed notify can do, but never states whether placement mutates/saves the animation asset, whether it overwrites an existing notify at that time, permission prerequisites, or idempotency. For a mutation tool with zero annotation coverage, key operational traits are missing.

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

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

Front-loaded statement of what the tool does, followed by a useful sibling contrast, then an Args block. Every section earns its place with little padding; the only minor redundancy is restating the example path inline in both prose and the Args list.

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

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

An output schema exists, so return values need not be explained. Parameters are well covered, but for a mutation tool with no annotations the description leaves side effects (asset save, existing-notify handling) unspecified, which is a meaningful gap for an agent deciding how to invoke it safely.

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

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 — and it does: all four parameters are documented with concrete example paths, the units for time (seconds), and the default value for notify_name. It adds real meaning beyond the bare types in the schema, though it doesn't specify path format constraints or valid ranges.

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

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

Specific verb (place) + resource (Blueprint-based AnimNotify on an animation) + scope (at a specific time). It explicitly distinguishes itself from the sibling place_anim_notify by naming what that tool creates (engine AnimNotify_PlaySound) versus what this one places. An agent can route between the two without opening either schema.

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

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

The description names the alternative (place_anim_notify) and the condition that selects it — use this one when you need BP notify classes that perform surface detection, line traces, and material-based sound selection, the 'Lyra footstep pattern'. This is an explicit when-to-use-this-instead-of-that statement.

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

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 explains the set_view_target_on_possess flag, but does not disclose what happens to the previously possessed pawn, whether a local player/controller must exist, multiplayer constraints, or whether the operation is reversible. These are significant omissions for a control-changing operation.

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

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

The core purpose is front-loaded in one clear sentence, followed by a compact Args list for parameters. There is no wasted text, and every element earns its place.

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

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

An output schema exists, so return values need not be described. However, with no annotations and 0% schema description coverage, the definition only covers parameter semantics; it lacks usage guidance, safety/behavioral disclosure, and environment prerequisites. For a runtime control operation, these gaps are substantial.

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

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

Schema description coverage is 0%, but the description documents all three parameters: actor formats (label, object name, full path from find_actor), player_index as a local player/controller index, and set_view_target_on_possess as a camera-targeting behavior. It compensates well for the schema gap, though it does not restate defaults or add constraints beyond the basic meanings.

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

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

The description states a specific verb ('Possess'), resource ('Pawn/Character'), and runtime context ('runtime player controller'). It is the only possession tool among the siblings, and the resource scope distinguishes it from find_actor and set_view_target.

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

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

No explicit when/when-not guidance or alternative tools are named. However, the actor parameter note that a value can be a 'full path returned by find_actor' implies a prerequisite workflow. This is implied usage rather than full routing guidance.

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

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

No annotations exist, so the description carries the load. It usefully discloses the target context (editor or PIE world) and the side effect of focus_camera (frames the actor), but says nothing about reversibility, failure when an actor cannot be resolved, or undo behavior.

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

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

Front-loaded summary plus a tidy Args block; every line earns its place and there is no filler. Structure is appropriate for an args-heavy tool.

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

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

An output schema exists so return values need not be explained, and all params are covered. However, with no annotations and a mutation tool, the description omits failure/permission/reversibility behavior, leaving an agent without key operational context.

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