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

Annotations already mark the tool as read/write and destructive, but the description adds useful concrete context: 'This can mutate the project or editor state.' It also reveals the official Bridge execution path, which is behavior beyond what the structured annotations express.

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 sentences, each earning its place: the operation, the primary parameters, and the side-effect warning. It is front-loaded and contains no filler or redundant restatement of the title.

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 code-execution tool with 6 parameters, no output schema, and destructive annotations, three sentences are insufficient. It omits how logs are captured, what execution_mode editor/play changes, how record_game_view results are surfaced, and what output or response the agent should expect.

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 needed to compensate by explaining the 6 parameters. It only clarifies that script or script_path should be provided; summary, capture_logs, execution_mode, and record_game_view are left entirely to name inference.

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 clear verb ('Executes'), a specific resource ('inline C# or an existing .cs file'), and the execution channel ('official Bridge'). This distinguishes it from siblings targeting shaders, assets, packages, or custom tools, and it explicitly names the two accepted input forms.

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 on when to use this tool versus unity_script, execute_custom_tool, or other siblings. The only directional advice is to provide script or script_path, which is invocation detail rather than usage-selection 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?

The annotations already include destructiveHint=true, so the agent knows this can be destructive. The description adds the context that the tool comes from the official Codely Bridge package, but it does not disclose that executing a custom tool may have arbitrary side effects or depend entirely on the registered tool's behavior. No contradiction with annotations exists.

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 one short sentence with no filler. It front-loads the core action and includes the relevant invocation detail without 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 generic custom-tool executor with no output schema and arbitrary parameters, this description is incomplete. It does not mention how to discover registered tool names, what parameters mean for different tools, or that behavior and return values vary by tool. The destructive annotation covers risk partially, but the operational workflow is underexplained.

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 description coverage, the description needed to explain parameter meaning, but it only restates the names: 'Pass tool_name and an optional parameters object.' It does not clarify what tool_name values are valid, how the parameters object is structured, or how it is passed to the underlying custom tool.

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 action ('Executes') and a resource class ('a custom tool registered by the official Codely Bridge package'). It is understandable on its own, though it does not explicitly differentiate itself from sibling tools like unity_custom_tools or execute_csharp_script.

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 is provided. The description tells the agent to pass tool_name and parameters, but never explains when this tool should be chosen over alternatives, when it should not be used, or how to discover valid custom tool names.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond annotations by naming the exact config file involved and explicitly promising no reconnection 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?

One clean sentence that front-loads the action ('Reads'), then the resource, then the outcome, and finally the key side-effect guarantee. There is no filler or redundant repetition of the tool name or annotations.

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 status tool with strong annotations, the description is largely complete. The main minor gap is that no output schema exists and the description does not outline what the reported connection states look like, but this is not essential for invoking 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?

There are zero parameters, so the baseline is 4. The description clarifies that the tool operates on the active config file automatically, which effectively explains why no parameters are 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?

Description states a specific verb ('Reads'), a specific resource (the active .com-unity-codely.json), and a clear outcome ('reports the adapter connection state'). It also distinguishes itself from connection-establishing operations by adding 'without reconnecting'.

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 'without reconnecting' implies this is the safe, read-only choice when only status is needed, which provides some usage context. However, it does not explicitly name alternatives or say when not to use this tool.

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

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

Annotations are all-neutral false flags (no readOnly/destructive/idempotent hints), so the description carries the burden. It discloses a real side effect ('This can update Packages/manifest.json when the Bridge package is missing'), the conditional reuse of an already-connected editor, and the blocking wait-for-readiness sequence. Minor gap: it never describes failure/timeout behavior, but the disclosed mutation side effect is well handled. No contradiction with annotations.

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

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

The content is reasonably compact and key actions are front-loaded, but the whole description is one long run-on sentence chaining four clauses with ellipses. It would be more consumable broken into clear steps; it is denser than needed but has no wasted words.

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 complex stateful tool with no output schema, neutral annotations, and 0% parameter coverage, the description covers the core flow but omits return-value semantics, success criteria, and what happens on timeout or package-install failure. These are meaningful gaps for an agent deciding whether a call succeeded.

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, but it only weakly maps to parameters: wait_timeout_seconds is implied by 'waits for Bridge readiness' and install_bridge by 'Ensures... package is present'. bridge_package_version is never mentioned, and the meaning of install_bridge=false is left ambiguous. With zero schema help, the description fails to fully explain the parameters.

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, multi-step verb chain ('Ensures the Bridge package is present... opens that project with tuanjie.exe, waits for Bridge readiness, and verifies the connected project') tied to a clear resource. It reads as a start/initialize operation and is clearly distinguishable from its close sibling tuanjie_bridge_status, which is the status-check counterpart.

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 conveys the workflow (ensure package, open, wait, verify, reuse existing connection) which implies this is the entry-point tool before other operations, but it never explicitly states when to use this tool versus tuanjie_bridge_status or the other unity_* siblings, nor gives any 'don't use when' guidance. Usage context is implicit, 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?

Annotations already declare destructiveHint=true, and the listed actions like delete, modify, move, and duplicate are consistent with that. The description adds the useful note that action-specific parameters are passed through unchanged, but it does not disclose side effects or what happens to asset metadata.

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 compact: an opening summary, an exhaustive action list, and one valuable pass-through note. It front-loads the core purpose and avoids empty 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?

This is a high-complexity dispatcher with 15 actions, an open schema, and no output schema, so per-action parameter guidance or examples are essential. The description only lists action names and gives no details on required arguments, return values, or failure behavior, leaving most actions underspecified.

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 schema only declares the action enum while allowing additional properties. The description mentions that action-specific parameters are passed through unchanged, but it names none of them, leaving the agent unable to construct parameters for actions like create_batch, edit_batch, or ensure_meta_integrity.

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 the tool manages project assets and enumerates the supported operation families and 15 concrete actions. It is easily distinguishable from siblings like unity_shader, unity_package, and unity_scene, which target other resources.

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

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

The description gives clear context: use this tool for creating, importing, modifying, searching, and inspecting project assets. It does not explicitly name alternatives or exclusions, but no sibling tool covers generic asset management, so the usage context is sufficient.

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?

Annotations already flag the tool as destructive, and the description adds that it can 'wait for' a bake, suggesting blocking behavior. However, it does not explain what clearing does in detail, whether waits can time out, or any side effects beyond what the annotation already conveys.

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 concise and front-loaded: the first sentence states the core purpose, the second lists valid actions, and the third explains parameter passthrough. 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?

Given multiple actions, destructive behavior, additionalProperties, and no output schema, the description is too thin. It omits per-action parameters, return behavior, and blocking semantics, leaving a capable agent to guess at important invocation 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%, and the description largely repeats the enum values. It mentions that action-specific parameters are passed through unchanged, but it does not enumerate or explain those parameters, so the agent still lacks enough information to construct calls for non-obvious actions.

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 that the tool starts, waits for, or clears navigation and lighting bakes, and it lists the supported actions. This makes the resource and operations identifiable, though it does not explicitly distinguish itself from sibling tools by name.

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 when to use the tool—when performing bake-related operations—but it provides no explicit guidance about when not to use it or which alternatives to prefer. The action list gives some context, but exclusions and alternative routing are absent.

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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description's 'clear' action aligns with them. The description adds the note that action-specific parameters are passed through unchanged, which is useful, but it does not clarify side effects of clearing or what a 'get' returns. No contradiction exists.

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, and every sentence contributes something: the first states the core behavior, and the second discloses pass-through behavior for extra parameters. It is efficient, though it sacrifices detail that would improve overall usefulness.

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 no output schema and the description does not describe the return format for 'get', the full consequences of 'clear', or what action-specific parameters are valid. For a tool that accepts open-ended additional properties, the lack of this context makes successful invocation uncertain.

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 parameter meaning. It only repeats the action enum from the schema and states that additional parameters are passed through unchanged, without naming or explaining any of those parameters. This leaves the parameter contract largely 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?

The description clearly states the resource (Tuanjie Editor console) and the supported actions (get, clear), using specific verbs. It is a clear, functional statement, although it does not explicitly distinguish this tool from sibling tools beyond the resource name.

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: use this tool when you need to read or clear Tuanjie Editor console entries. It does not discuss when not to use it, nor does it compare against sibling tools such as unity_dialog or execute_custom_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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about what is listed (custom tools registered by project extensions in the Codely Bridge) and that the result is a set of names usable with another 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?

Two short sentences with no filler. The first sentence states the tool's action and scope; the second gives actionable guidance for using the result. Everything 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, read-only listing tool, the description fully covers what an agent needs: what is listed, where the tools come from, and how to use the returned names. Annotations cover the safety aspects, and no output schema is necessary for such a simple list.

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 and the schema is empty, so there is nothing to document. This is the baseline for a no-parameter tool, and the description correctly avoids inventing parameter guidance.

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 a specific verb and resource: 'Lists custom tools registered by project extensions in the official Codely Bridge.' It also distinguishes itself from the sibling execute_custom_tool by explaining that returned names are meant for that 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 clearly implies usage: call this tool to discover custom tool names, then pass them to execute_custom_tool. It does not explicitly state when not to use it, but the context is clear enough for a zero-parameter listing 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?

Annotations already indicate destructiveHint=true and non-idempotent behavior, so the safety profile is covered. The description adds that parameters are passed through unchanged and that the context is a modal editor dialog, but it does not explain what the click actually applies to or what side effects may occur.

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 with the core action. Both sentences earn their place, though 'Supported actions: click' is mostly redundant with the verb 'clicks'.

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?

This is a destructive tool with no output schema and no parameter-level documentation. The description omits how the target dialog or button is identified, what the accepted pass-through parameters are, and what consequences the click may have, leaving an agent with insufficient detail to invoke it reliably.

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 description only restates the 'click' enum value without adding meaning. The claim that additional action-specific parameters are passed through unchanged is useful, but no names, types, or purposes are provided, so the description does not compensate for the schema's total lack of parameter documentation.

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 the tool's action and resource: it clicks a button in a modal editor dialog. This distinguishes it from the sibling tools by focusing on dialog interactions, though it doesn't explicitly contrast itself with any sibling.

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 when to use the tool: whenever a click action in a modal editor dialog is needed. However, it provides no explicit when-not-to-use guidance or alternatives, leaving the selection logic largely inferred.

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?

The annotations already mark destructiveHint=true, and the description adds little behavioral context beyond the list of action names. The pass-through note about action-specific parameters is mildly useful, but the description does not explain side effects, compilation behavior, editor state changes, or what agents should be cautious about given the destructive hint.

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 a clear opening, but most of it is a 28-item action list that duplicates the schema enum. This is not an efficient use of the description and pushes out room for more useful behavioral or parameter documentation.

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 28-action dispatcher with no output schema and no per-action parameter documentation, this description is grossly incomplete. It does not tell agents what any action returns, which actions are destructive, when compilation is needed, or how to invoke even common actions like play or set_active_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?

Schema description coverage is 0%, and the description only repeats the action enum and says additional action-specific parameters are passed through unchanged. This gives agents no meaningful detail about what parameters each action expects, how to format them, or which ones are required for specific actions.

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 opening phrase 'Controls and inspects the Tuanjie Editor' states a clear verb and resource, and the tool is reasonably distinguished from sibling tools by targeting the editor itself. However, the purpose is extremely broad because it is a 28-action dispatcher, and the description does not clarify what each action accomplishes.

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 about when to use this tool versus the many specific sibling tools such as unity_gameobject, unity_scene, or unity_script. The description neither states exclusions nor recommends this tool for particular workflows, leaving the agent to infer usage solely from the action names.

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?

Annotations already mark the tool as destructive, and the description aligns by mentioning delete and modify among supported actions. It also adds the useful pass-through note for action-specific parameters. However, it does not disclose per-action side effects, required state, or return behavior.

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

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

The description is front-loaded with a clear summary, but the long 'Supported actions' list duplicates the enum already present in the input schema. The pass-through note is valuable, but the enumeration adds little beyond what structured data already conveys.

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?

This is a high-complexity tool with 16 actions, no output schema, and no per-action parameter documentation. The description is sufficient for selecting the tool, but not for correctly invoking any specific action, since required parameters and return semantics are almost entirely unspecified.

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 description only says that action-specific parameters are passed through unchanged. It lists the action enum values that are already present in the schema, but provides no meaning, names, or formats for the additional parameters an agent would need to actually call each action.

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 first sentence clearly states the tool's scope: creating, modifying, finding, and inspecting GameObjects and components. The resource domain is explicit and distinct from sibling tools like unity_shader, unity_asset, and unity_scene.

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 context by naming the exact resource types and listing 16 concrete actions, so an agent can infer when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the domain is specific enough to route most GameObjects tasks here.

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?

Annotations already mark the tool as destructive and non-read-only; the description reinforces this by saying it 'changes' the resolution, and it further clarifies that get_resolution is a read and set_resolution is a mutation. It adds the pass-through behavior of extra parameters, but it does not disclose side effects, reversibility, or required editor state beyond what annotations already imply.

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 two sentences with no wasted words: the first states the core operation and lists actions, and the second notes pass-through behavior. It is front-loaded and easy to scan.

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 tool with additionalProperties=true and no output schema, the description should document the action-specific parameters and what each action returns. It provides the action enum but leaves set_resolution's required values unspecified and gives no return expectations, so an agent has to guess or look elsewhere.

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 description merely restates the action enum that is already in the schema. The line about action-specific parameters being 'passed through unchanged' acknowledges their existence but never names or describes them, such as width/height for set_resolution, leaving the agent unable to construct a valid call from the description.

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 opens with a specific verb and resource ('Reads or changes the Game View resolution') and enumerates the three supported actions, so an agent knows exactly what the tool can do. The action list differentiates it from broader Unity tools like unity_screenshot or unity_editor.

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 supported actions imply the tool is for getting, setting, or listing resolutions, which is a clear enough context for straightforward use. However, there is no explicit when-to-use versus alternatives, no exclusions, and no mention of when a sibling such as unity_screenshot would be more appropriate. The 'passed through unchanged' clause is useful but is not usage 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?

Annotations already convey destructive/non-read-only/non-idempotent behavior. The description adds that virtual devices can be created/destroyed and that extra parameters pass through unchanged, but it does not disclose effects such as OS-level input injection, required Play Mode state, or cleanup obligations.

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 sentences with no filler; the purpose is front-loaded and the action list is compact enough to scan. Every sentence 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 multi-action input tool with no output schema and no parameter descriptions, this is under-specified. An agent cannot determine required parameters for each action, ordering dependencies (e.g., creating virtual devices first), or return/error behavior, which are necessary 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?

Schema description coverage is 0%; the only documented parameter is the action enum. The description repeats the enum and adds a pass-through note, but it never explains action-specific parameters (e.g., coordinates, buttons, key codes, text content), leaving the main invocation detail undocumented.

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 'simulates' with clear resources: mouse, keyboard, and virtual input devices. The supported action enum is listed, and 'input simulator' clearly separates this from the sibling Unity editor/tooling 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 a clear context: 'primarily in Play Mode' and enumerates exactly which actions are supported. It does not explicitly exclude alternatives, but with a single input-focused tool among siblings the usage context is reasonably clear.

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

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

Annotations already convey destructiveHint=true, and the description aligns by including 'cancel'. The description adds useful context that additional parameters are passed through unchanged, but it does not disclose side effects, return format, or whether non-cancel actions are safe reads.

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 two sentences with no filler. It front-loads the core purpose and action list, making it quick to parse and appropriately sized.

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 an open and potentially destructive dispatcher with no output schema, the description lacks job targeting details, return/status semantics, and examples of supported pass-through parameters. It is not complete enough for an agent to invoke all actions 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 carries the burden of explaining parameters. It only states that extra parameters are passed through unchanged, without naming or describing action-specific parameters, leaving the agent without enough detail to construct them confidently.

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 ('Checks, lists, or cancels') and identifies the resource ('asynchronous Bridge jobs'), with an explicit action list. It is clear about the tool's function, though it does not explicitly differentiate itself from siblings such as tuanjie_bridge_status.

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 provided on when to use this tool versus alternatives, nor are there any exclusions or context for choosing among status/check/list/cancel. The usage context is only implied by the action names.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent with that by saying it can execute menu items. It adds one useful behavioral detail—that additional action-specific parameters are passed through unchanged—but it does not describe side effects, return shape, or state changes. No contradiction with annotations.

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

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

The description is compact and front-loaded: the core function appears in the first sentence, followed by supported actions and the pass-through note. The action enumeration is somewhat redundant with the schema enum, but there is no filler and the structure is scannable.

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 no output schema, no parameter descriptions, and a destructive action, the description needed to explain what execute expects and what get_available_menus returns; it does neither. An agent cannot reliably know what additional properties to pass. Only the action enum is fully specified.

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 needed to compensate, but it only restates action enum values already present in the schema. It says action-specific parameters are passed through unchanged without naming them or giving their format; for execute, the required menu identifier/path is left unspecified. This is insufficient for invoking the tool correctly beyond the two enum choices.

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 the resource ('Tuanjie Editor menu items') and the core verbs ('Lists or executes'), giving a clear statement of function. It also enumerates the supported actions explicitly. It does not contrast itself with sibling tools such as execute_custom_tool or unity_script, so sibling differentiation remains implicit.

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 exclusions, and no reference to alternatives. The supported-actions list implies intended operations but does not tell an agent when to choose unity_menu over execute_custom_tool, execute_csharp_script, or the many unity_* 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?

Annotations already mark the tool as non-read-only and destructive, and the description adds that action-specific parameters are passed through unchanged. It does not explain wait_for_upm's blocking behavior, timeouts, or side effects beyond remove/install, so behavioral coverage remains partial.

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 sentences front-load the purpose and supported actions, then give the pass-through rule. No filler or duplicated schema content beyond the necessary action 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?

For a dispatcher tool with one enum parameter and dynamic additional properties, the description is workable but thin: it omits what wait_for_upm waits on, what list_packages returns, and what the action-specific parameters are called. This weakens an agent's ability to invoke install_package or remove_package correctly without external knowledge.

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 one declared parameter, action, is fully enumerated by the JSON schema; the description mostly restates those enum values. The useful extra is that additional action-specific parameters are passed through unchanged, but the description does not name or explain the meaningful per-action parameters.

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 first sentence uses specific verbs (installs, removes, waits for, lists) attached to a concrete resource (UPM packages), and the enumerated action list matches the schema enum. This clearly identifies the tool's function and separates it from the sibling Unity/Tuanjie 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?

The description establishes clear context: use this tool for UPM package operations, with the action enum delimiting the supported operations. It does not explicitly compare against alternatives, but no sibling tool claims package management, so the resource scoping is sufficient.

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?

Annotations already mark it readOnly, idempotent, and non-destructive; the description adds concrete behavior by naming the exact config file re-read, the reconnect to the dynamic port, and the project-root verification. No contradiction with annotations.

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

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

A single front-loaded sentence lists the full sequence of actions with no filler. Every clause 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, idempotent refresh operation with rich annotations, the description covers the essential behaviors: config re-read, reconnect, and verification. A minor gap is not stating what happens if the config file or project root is missing, but this is low complexity.

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 and 100% schema coverage, so there is nothing for the description to add. Baseline 4 is appropriate.

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 resource (.com-unity-codely.json), a clear action (re-reads and reconnects to the Bridge port), and a verification step. This is enough to distinguish unity_refresh from siblings like tuanjie_bridge_status or unity_editor.

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 the mechanics but gives no explicit guidance on when to call it versus alternatives such as tuanjie_bridge_status or tuanjie_start. There is no mention of prerequisites or situations where refresh is appropriate.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds that multiple actions exist and that extra parameters pass through unchanged, but it does not disclose specifics like overwriting unsaved changes or side effects on the project. No contradiction with annotations.

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

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

The description is two sentences long, front-loads the core purpose, and then provides the complete action list plus a crucial note about extra parameters. Every sentence adds value without redundancy or fluff.

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?

Despite a clear overview, the tool is a multi-action dispatcher with no per-action parameter documentation, no output schema, and no side-effect details. Agents can understand what the tool does but not reliably execute actions that require action-specific arguments, making the description incomplete for real 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?

The schema only documents the action enum, and the description essentially repeats those enum values. It mentions that action-specific parameters are passed through unchanged, but it does not explain what those parameters are, which actions require them, or their formats. With 0% schema description coverage, this leaves agents guessing on how to correctly call most actions.

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 the tool's scope with specific verbs ('Creates, opens, saves, and inspects scenes') and then enumerates every supported action. This makes the tool's purpose unmistakable and naturally distinguishes it from sibling tools that operate on shaders, assets, packages, or UI elements.

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 when to use the tool: whenever a scene-related operation such as opening, saving, loading, or inspecting is needed. However, it does not explicitly mention alternatives, exclusions, or when a sibling tool would be more appropriate, leaving usage guidance mostly 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds that the tool can both capture views and control Game View recording, and that action-specific parameters are passed through unchanged, but it does not detail side effects, output artifacts, or recording lifecycle 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 compact: two sentences, front-loaded purpose, and a necessary enumeration of supported actions. There is no filler or repetition of schema data.

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?

There is no output schema, yet the description does not explain return values, output files, or effects of starting/finishing recording. With ten actions and open passthrough of extra parameters, plus a destructive annotation, the description leaves key invocation-relevant details unstated.

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 schema has one required enum parameter with 0% description coverage, so the description must compensate. It enumerates all ten actions and groups them conceptually as captures versus recording controls, adding meaning beyond the raw enum. However, it does not describe what the action-specific parameters are or how they affect each action, only noting that they are passed through unchanged.

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 opens with an active verb ('Captures') and names the concrete resources: editor, scene, camera, asset, and UI views, plus Game View recording control. This clearly distinguishes it from sibling tools like unity_gameview or unity_ui_toolkit, which have different scopes.

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, and no exclusions or selection conditions are stated. The supported-actions list implies usage, but an agent is left to infer when this screenshot tool should be preferred over the many related sibling 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description honestly lists non-destructive actions (read, validate) alongside destructive ones (update, delete), so there is no contradiction. It adds the 'under Assets' scope but does not explain side effects, file rewrite behavior, or Unity refresh implications.

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 concise and front-loaded with the resource and operations. The action list is slightly redundant ('update', 'edit', 'apply_text_edits' overlap), but there is no filler or unnecessary length.

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 multi-action destructive file-management tool with an open additionalProperties schema and no output schema, this is incomplete. It omits per-action parameter expectations, return values, and behavioral outcomes, so an agent cannot reliably invoke it without guessing.

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 schema has zero description coverage and only defines the action enum. The description says additional action-specific parameters are passed through unchanged, which is useful but vague; it does not name or document the parameters required for each of the eight actions, leaving a significant gap.

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 resource ('C# scripts under Assets') and a clear set of operations (create, read, edit, validate, delete), so an agent knows what the tool manages. It doesn't explicitly contrast with sibling tools like execute_csharp_script or unity_shader, but 'C# scripts under Assets' scopes it well enough.

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 such as execute_csharp_script or unity_custom_tools. The description does not mention prerequisites, exclusions, or when each action should 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?

The description adds the useful behavioral note that action-specific parameters are passed through unchanged, and it lists the action categories, which goes beyond the annotations. However, it stays silent on the concrete effects of compile or preview despite destructiveHint=true, so agents get no context about what may be modified.

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 concise sentences with no filler; the supported actions and pass-through behavior are front-loaded. It is compact, though it could use a bit more per-action detail without becoming bloated.

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 multi-action dispatcher with no output schema and no parameter documentation, this is under-specified: per-action inputs, outputs, side effects, and failure modes are absent. The enum names convey intent but not enough to invoke compile or ensure_material_shader_for_srp 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 parameter coverage is 0% and the description mostly restates the action enum already present in the schema. The note that extra parameters are passed through is informative but does not tell the agent what parameters each action expects, leaving the additionalProperties space completely undocumented.

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 opens with a clear verb-and-resource statement, 'Inspects render pipelines and manages shader compilation or previews', and enumerates all four supported actions, distinguishing it from the sibling asset/package/scene tools. It is not a 5 because the individual actions are only named, not explained, so an agent still has to infer what each one does.

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 or comparison with alternatives such as execute_csharp_script or unity_menu. The phrase 'Inspects render pipelines' gives a rough context, but nothing tells the agent when to prefer this tool over a sibling or when not to use it.

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

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

Annotations already declare destructiveHint: true, so the description does not need to repeat that. The description adds the note that 'Additional action-specific parameters are passed through unchanged', which gives insight into how the tool handles extra parameters. However, it does not elaborate on potential side effects or overwrite behavior beyond what annotations imply, so it adds only modest behavioral context.

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

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

The description is concise: two sentences with no fluff. The first sentence states the purpose and lists the supported actions, and the second clarifies parameter handling. The key information is front-loaded, making it easy to scan.

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 description is not complete enough for an agent to use the tool correctly. While it lists the action names, it does not explain what each action does or what parameters each requires. The schema also lacks descriptions, and the 'additionalProperties' are not enumerated. The agent is left with significant ambiguity about how to construct a valid call, especially for actions like 'create_uxml' or 'link_uss_to_uxml'.

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 schema has only the 'action' parameter with an enum and allows additional properties. The description lists the action values, which duplicates the enum, but also explains that extra parameters are passed through unchanged, which clarifies the additionalProperties behavior. However, it does not specify what those action-specific parameters are, so it only partially compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's role: 'Creates and links UI Toolkit assets' and enumerates four specific supported actions. This distinguishes it from sibling tools like unity_asset or unity_shader by targeting UI Toolkit resources specifically. It lacks a bit of precision on what 'links' means, but the action list helps.

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 does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or contrast with other Unity tools such as unity_asset or unity_shader. The agent is left to infer usage from the purpose statement alone.

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