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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the script is not executed. It also states the return content: compilation success/failure and compiler errors. It does not mention potential side effects like generated build artifacts, but the core behavior is disclosed clearly.

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. The primary action and key distinction are front-loaded, followed by return behavior and usage guidance. 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 single-parameter compile tool with no output schema, the description covers the purpose, behavior, return value, and usage context. It could be slightly more complete by mentioning side effects or explicitly routing away from execution tools, but it is largely adequate.

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 100% coverage and already clearly describes the single `path` parameter as a script name or absolute file path. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Compile a C# script', and explicitly distinguishes itself from running tools by adding 'without running it'. This clearly differentiates it from sibling tools like execute_script or execute_code.

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 'Useful for validating scripts before execution' gives clear context for when to use the tool. It does not explicitly name alternatives or state when not to use it, so it falls short of a full 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 burden of behavioral disclosure. It discloses the underlying evaluator (Mono.CSharp.Evaluator) and the expression-only input constraint, but for a tool that executes arbitary code in a live Unity context, it omits the most important traits: that execution can mutate game state with side effects, what happens on compile/runtime errors, and whether the expression result is returned. The safety profile of a code-execution tool is completely undisclosed.

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 zero filler. The action ('Execute C# expressions') comes first, and the evaluator detail plus input restriction follow in one compact clause. Every word 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 high-complexity, potentially state-mutating tool (arbitary code execution in Unity) with no annotations and no output schema, the description is thin. It doesn't state what the evaluator returns, how errors are surfaced, whether execution is sandboxed, or that arbitrary expressions can alter the running game. An agent has no way to predict the outcome or risk of invoking 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?

Schema description coverage is 100%, so the baseline is 3. The schema already documents the 'code' parameter and its 'Cannot use return statements' restriction; the description reinforces this with 'expects expressions, not statements' but adds no format, lifecycle, or context details beyond what 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?

The description states a specific verb and resource ('Execute C# expressions in the Unity context') and adds a scoping constraint ('expects expressions, not statements') that conceptually separates it from sibling scripting tools like execute_script. However, it doesn't explicitly name any sibling, so differentiation is implied rather than stated.

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 'expects expressions, not statements' implies what inputs are valid and hints that this tool is for expression evaluation rather than script execution, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives (e.g., use execute_script for multi-line scripts). Usage must be 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?

With no annotations, the description carries the full behavioral burden. It discloses the execution model via Main()/Unload(), mentions ScriptContext for Harmony, logging, and arguments, and notes that some scripts run until unloaded. It does not explicitly state the side-effect/risk profile of arbitrary C# execution, error behavior, or cleanup guarantees beyond optional Unload().

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 definition is front-loaded, and the library scripts are organized in a clear bulleted list where each entry carries selection-relevant information. Somewhat long, but the length is justified by the number of built-in script variants and their differing arguments.

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?

Covers invocation path and args, supported code constructs, lifecycle hooks, and the available library scripts with their parameters. The main gaps are the lack of return/output behavior and error handling, which is more significant given there is no output schema.

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 already covers both parameters at 100%, so the baseline is 3. The description adds value by enumerating library script argument patterns (typeName, maxResults, action, etc.) and tying args to ScriptContext.Args, going beyond the generic schema 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?

Opening sentence names the specific action (compile and run), resource (C# script file), and environment (Unity runtime). It distinguishes itself from siblings like compile_script and list_scripts by covering execution, and further clarifies scope with supported constructs and library scripts.

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 usage context: use this tool when a C# script needs to be compiled and run in Unity, including advanced scenarios like MonoBehaviours, Harmony patches, and private member access. It does not explicitly name alternatives or exclusions, but the built-in library script examples give concrete invocation use cases.

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?

Without annotations, the description carries the burden for behavioral traits. It makes clear this is a read-only, high-level summary operation with a 'single call' convenience. It doesn't elaborate on return format or failure behavior, but for a zero-parameter query tool the description gives sufficient 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?

One sentence, directly to the point, front-loaded with the action and contents of the summary. Every word earns its place; 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?

For a zero-parameter, no-output-schema tool with low complexity, this description fully covers what an agent needs: what it returns, at what granularity, and when to use it. Nothing critical 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?

Tool has zero parameters, so there is nothing for the description to annotate beyond the schema. Baseline 4 is appropriate: no parameter documentation burden exists.

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 ('Get a high-level summary') and a clear resource ('current game state'), then enumerates the fields covered: scene, game mode, level info, player status, and bro type. This clearly distinguishes it from targeted siblings like inspect_player or inspect_gameobject.

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 'Single call to orient yourself' communicates clear context for when the tool is useful: getting a broad overview of game state. However, it does not explicitly name alternatives or state when not to use it (e.g., when targeted inspection is needed).

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 provided, the description carries the full burden of behavioral disclosure, but it only restates the action without detailing side effects, prerequisites, or whether this changes the current game state. It is unclear if this simply selects a level or actively loads/starts it.

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 a single concise sentence with no filler or redundant content. The core action and target are immediately visible and front-loaded.

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 two-parameter navigation tool, the description is minimally sufficient, but it omits context about what 'go to' actually does in the game environment and what outcome the agent should expect. Since there is no output schema or annotations, a bit more behavioral context would improve completeness.

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 already describes both parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter meaning beyond what 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?

The description uses a clear verb-resource pairing: 'go directly' to a 'specific campaign level', so the basic purpose is easy to grasp. It does not explicitly differentiate itself from siblings like restart_level or list_campaigns, so it falls 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 description gives no guidance about when to use this tool instead of alternatives such as restart_level or list_campaigns. The word 'directly' hints at bypassing normal progression, but this is not made 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?

No annotations are present, so the description must convey behavioral context. 'Inspect' implies a read-only operation, but the description does not disclose side effects, error behavior, or what happens if the path or component type is invalid. It is not misleading, but it is under-specified.

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, focused sentence with no filler. The action and target are front-loaded, making the tool's purpose immediately clear without any 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?

There is no output schema, so the description should provide some indication of what 'inspect' returns or the expected behavior, but it does not. The tool is simple and parameters are documented, but return semantics and usage context are 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?

Schema coverage is 100%; both path and componentType have descriptions in the input schema. The description adds no extra parameter-level detail beyond the schema, so the baseline score of 3 applies.

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

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

The description states a specific action ('inspect') and resource ('specific component on a GameObject'). This clearly separates it from sibling tools like inspect_gameobject (whole object) and modify_component (mutation).

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 choose this tool over alternatives like inspect_gameobject or modify_component. The intended context is implied by the name and verb, but not explicitly stated. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'Inspect' implies a read-only operation, and the detailed parameter note gives some sense of response weight, but the description does not state the return shape, failure behavior, or explicitly confirm the absence of 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 a single front-loaded sentence that conveys the resource, scope, and key usage condition with no wasted words. It is appropriately sized for the tool's simplicity.

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

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

For a two-parameter inspection tool with no output schema, the description is mostly adequate, but it leaves the return value unspecified and does not reference nearby inspection alternatives. It would be more complete with a brief note about what is returned and a pointer to inspect_component for component-level inspection.

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 100%, so both path and detailed are already documented. The description adds little beyond restating the path-based scope and the lightweight/detailed distinction already present 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?

The description uses a clear verb (Inspect) and resource (specific GameObject by path), so an agent knows exactly what the tool operates on. It distinguishes itself from list_gameobjects and query_gameobjects by requiring a path for one object, though it does not name a sibling 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 phrase 'by path' establishes clear context: use this tool when you have a specific GameObject path and want to inspect that object. It does not include explicit when-not-to-use guidance or route to alternatives such as list_gameobjects or inspect_component, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of explaining behavior. It indicates a read-only operation with 'Get', but does not disclose what details are returned, whether it applies to the current player or all players, or any edge/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 a single concise sentence with the verb front-loaded and no filler. The 'player(s)' parenthetical is slightly awkward, but overall the structure is 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 tool with no annotations, no output schema, and no parameters, the description must explain what 'detailed information' includes and how the target player is determined. It does neither, leaving an agent to guess whether the tool returns all players, the current player, or a specific one.

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 and the schema description coverage is 100%, so the input schema already provides complete parameter information. The baseline of 4 applies, though the vague 'player(s)' wording leaves some selection semantics unstated.

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 ('Get') and resource ('player(s)'), and the resource distinguishes it from sibling inspect_gameobject. However, 'detailed information' is generic and 'player(s)' does not specify whether it targets one player or all players.

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 related tools like inspect_gameobject, query_gameobjects, or game_state. The only clue is the tool name itself; no context, prerequisites, or alternatives are mentioned.

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 provided, the description carries the behavioral disclosure burden and does well by covering the environment-variable override, Steam app fallback, waiting for responsiveness, and the warning-on-already-running edge case. It could also mention timeout or failure behavior, but the core externally visible behavior is well 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 only three sentences and each one earns its place: the launch-and-wait action, the launch mechanism, and the already-running edge case. It is front-loaded and contains no filler or redundant repetition of schema defaults.

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 no output schema or annotations, this description is nearly complete: it covers launch behavior, launch mechanism, waiting, and the restart edge case. It lacks explicit failure or timeout behavior and success return details, but these are minor for a game-launching tool with sibling tools like wait_for_game.

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 already documents both parameters with 100% coverage. The description adds meaningful context by tying restart to the warning behavior, which the schema does not state, and vanilla is adequately covered by its schema 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 uses a specific verb 'Launch' with the resource 'Broforce' and adds the waiting-for-responsiveness behavior, making it immediately clear what operation is performed. The scope is distinct from sibling tools like stop_game and wait_for_game.

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 clearly explains the game-already-running condition and how restart changes behavior, giving useful context for when to invoke the tool with or without restart. It does not explicitly name alternative tools such as stop_game or wait_for_game, so it stops 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?

No annotations are present, so the description carries the full burden. It discloses meaningful behavior: the tool lists all bros, reports the selected bro for a given player via currentBro, and reports all active players' selections via currentBros. It also notes that lists and currentBros are always returned. This is helpful, though it doesn't cover error cases or side-effect confirmation.

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 compact sentences that immediately state the tool's purpose and relationship to sibling tools, then describe the returned information. Every sentence earns its place; no filler or redundant repetition of 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?

For a tool with one optional parameter and no output schema, the description adequately explains what the agent will get (currentBro, currentBros) and how it relates to swap_bro/set_bro. Minor gaps such as precise output structure are understandable without an output schema but leave slight room for interpretation.

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 100%, so the baseline is 3. The description repeats that playerNum selects a player for the currentBro readout, but the schema already states this and the default. No significant new parameter meaning is added beyond structured 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?

Description states a specific verb ('List') and resource ('available bros'), and distinguishes itself from sibling action tools by noting these are bros 'that can be used with swap_bro and set_bro.' It also clarifies that it reports both currentBro and currentBros, making the tool's role 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?

The description clearly implies this is the inventory/read tool to use before invoking swap_bro or set_bro, providing useful usage context. It doesn't explicitly state 'use this when...' or mention exclusion cases, but no alternative listing tool exists among siblings, so the guidance is adequate.

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 of behavioral disclosure. It correctly communicates a simple read-only enumeration and the inclusion of indices, but it does not mention ordering, output format, or whether any state is affected, leaving some behavioral detail 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?

The description is a single, front-loaded sentence with no filler. It efficiently states the action, the resource, and the key output detail.

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, low-complexity list tool, the description is mostly complete: it says what is returned and that indices are part of it. It would be slightly stronger if it clarified what an index refers to or how results are ordered, but the absence of an output schema is partially offset by the explicit mention of indices.

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 the baseline is 4; there are no parameter semantics for the description to clarify. Saying 'all available' reinforces the no-filter behavior and adds slight meaning beyond the empty input 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 names a specific verb ('List'), a distinct resource ('campaigns'), and notes that indices are included, which clearly states what the tool does and distinguishes it from siblings like list_gameobjects and list_enemies. It stops short of explicitly contrasting itself with those siblings, but the resource name is enough to avoid confusion.

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 prefer this tool over an alternative. The phrase 'all available' implies there is no filtering, but it does not state exclusions or point to a sibling tool for more targeted queries.

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 clarify that this is a read-only listing operation and defines the scope as 'the scene', but it does not explain what qualifies as an enemy, whether inactive or hidden enemies are included, or what the returned list contains.

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 a single, front-loaded sentence with no filler. Every word contributes to the meaning, and the scope is stated immediately.

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 very simple tool, but there is no output schema or annotations to fill in missing context. The description gives the broad behavior but does not define the enemy criteria or the structure of the returned list, which could matter when an agent needs to use the results.

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 and the input schema is empty, so there is no parameter detail for the description to add. The 0-parameter baseline applies and is handled appropriately.

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 ('List') and resource ('all enemies') and adds the scope 'in the scene'. It clearly distinguishes this from sibling tools like list_gameobjects and list_bros by narrowing the subject to enemies.

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 intended use is implied: use it when you want to enumerate all enemies in the current scene. However, there is no explicit guidance about when to prefer this over alternatives such as query_gameobjects or list_gameobjects, 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 alone must disclose behavior. It only states 'List all GameObjects in the scene' and does not mention return format, pagination, ordering, or the fact that maxResults caps the result set. The word 'all' is also potentially misleading given the default maxResults of 100.

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 a single, clear, front-loaded sentence with no filler. It is concise and easy to parse, though its brevity omits important qualification about limits and return behavior.

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 annotations and no output schema, the description is the only behavioral guide. It does not explain the return shape, how maxResults interacts with 'all', whether inactive objects are included by default, or how this differs from query_gameobjects. An agent cannot fully anticipate the tool's output or handle edge cases.

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 100%, so the schema already documents both parameters. However, the description adds no extra meaning and even conflicts with maxResults: saying 'all' contradicts the parameter's purpose of limiting the number of returned GameObjects.

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 ('List'), a concrete resource ('GameObjects'), and a clear scope ('in the scene'). It is immediately understandable, though it does not explicitly differentiate itself from the sibling tool query_gameobjects.

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 instead of query_gameobjects, inspect_gameobject, list_enemies, or other siblings. No conditions, exclusions, or alternative descriptions are provided.

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 provided, the description carries the behavioral burden, and 'List' clearly signals a read-only enumeration with no mutation or execution. It also discloses what kind of data is returned, though it does not address edge cases like empty libraries or script availability semantics.

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 a single, front-loaded sentence with no filler. Every part adds information: the action, the target resource, and the returned metadata fields.

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 listing tool with no output schema, the description is complete: it states the resource and the fields the agent can expect. There is no additional context an agent needs 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?

The tool has zero parameters and the schema is empty, so parameter documentation is unnecessary. The description appropriately focuses on the output rather than inputs, and no parameter details 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 ('List'), a clear resource ('available C# scripts in the script library'), and the returned metadata shape. It is easily distinguishable from siblings like list_test_scripts because it scopes to the script library and describes metadata fields.

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 makes the basic use case obvious: enumerate available scripts and their metadata. However, it does not explicitly guide an agent on when to prefer list_scripts over siblings such as list_test_scripts or run_test_script, leaving the routing decision 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 are provided, so the description carries the behavioral disclosure burden. It clarifies the tool is a listing operation scoped to specific directories, which suggests read-only behavior, but it does not explicitly state that nothing is executed or modified, nor what 'available' means if scripts 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?

The description is a single concise sentence with no filler. The verb and target are front-loaded, and the directory scope is stated immediately after the action.

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 parameterless list tool, the description covers what the tool lists and where. It lacks an explicit note about return format or how it relates to sibling tools, but given the low complexity and absent output schema, the description is nearly complete for safe 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 tool has zero parameters and 100% schema description coverage, so no parameter explanation is needed. The description adds no parameter details because none exist, which is appropriate for this 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 states a specific verb ('List') and resource ('test scripts') with explicit scope ('scripts/ and scripts/examples/'), making it clearly distinguishable from sibling tools like list_scripts or run_test_script. The purpose is obvious and 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?

The use case is implied: the agent should call this to discover available test scripts before running or inspecting them. However, it does not explicitly contrast with alternatives such as list_scripts, run_test_script, or execute_script, so the when-to-use 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 of behavioral disclosure. It only states the mutation action and gives no information about side effects, failure modes, persistence, reversibility, or permissions.

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

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

The description is a single, focused sentence with no filler. The action and target are 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?

For a mutating tool with no annotations and no output schema, the description leaves too much unspecified: return behavior, error handling, component existence requirements, and the expected structure of the 'properties' object. The agent cannot fully infer how to call it correctly or what to 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 100%, with each parameter having a basic description. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Modify') and a clear resource ('properties of a component on a GameObject'). It also distinguishes itself from read-only sibling tools like inspect_component and inspect_gameobject.

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 guidance on when to use this tool versus inspect_component, query_gameobjects, or other alternatives. It does not state prerequisites, exclusions, or preferred workflows.

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 and no output schema, the description carries the full burden of explaining behavior, but it only restates the core purpose. It does not disclose what the result looks like, whether it throws on failure, or whether any connection state is affected.

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 short, front-loaded sentence conveys the entire tool purpose without wasted words. Nothing is redundant for a zero-parameter connectivity check.

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 trivial complexity, the description is adequate for basic invocation, but because no output schema exists and no result semantics are described, an agent cannot know what a successful or failed connection test returns. That leaves a clear gap.

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 parameters and is fully described, so no parameter documentation is needed; baseline for zero-parameter tools is 4. The description adds no parameter detail, but none is required.

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 action ('test connection') and resource ('Unity Inspector'), so an agent can tell what it does. It is clear, though it does not actively differentiate from any sibling because no similar connectivity tool exists.

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 verb 'test' implies this should be used to verify connectivity to the Unity Inspector, but no explicit when-to-use or when-not-to-use guidance is given, and alternatives are not mentioned. For a no-parameter diagnostic tool this is minimally adequate.

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 transparency burden. 'Search' signals a non-mutating lookup, which is the most important behavioral trait, but it does not describe output shape, match semantics, result limits, or any special behavior. This is minimally transparent for a read-only query tool but lacks detail.

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 a single front-loaded sentence with no filler or repetition. It states the action and the two key search criteria, and 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 simple, fully schema-documented tool with no nested objects and no required parameters, the one-line description plus schema covers the basic call shape. However, missing usage differentiation from sibling tools and unspecified search behavior leave noticeable gaps, making it 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 description coverage is 100%, so the baseline is 3. The description adds only that searching is by name or component, which maps to namePattern and componentType, but it does not explain filter combination behavior or how maxResults and includeInactive affect results beyond the schema defaults.

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 ('Search') and identifies the resource ('GameObjects') plus the search criteria ('by name or component'), so the core purpose is clear. It does not explicitly differentiate this tool from siblings like list_gameobjects or inspect_gameobject, 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?

No guidance is provided on when to use query_gameobjects versus list_gameobjects or inspect_gameobject. There are no when-not-to-use conditions, alternatives, or context hints beyond the word 'Search'. The usage situation is only implied, 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?

No annotations are provided, so the description carries the full burden. It discloses the default line count and filter behavior, but it does not clarify return format, error behavior, whether the filter applies before or after limiting lines, or what happens if the log file does not exist. This is a read operation, so side-effect risk is low, but the behavioral detail 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?

The description is a single, tightly written sentence with no filler. It front-loads the primary purpose and then states the two key behaviors efficiently.

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 read-only tool with a fully documented schema, this is minimally adequate. However, the interaction between lines and filter is ambiguous—whether filtering returns the last N matching lines or filters the last N lines—and there is no mention of watch_log for continuous reading. An agent could call it, but not with full confidence.

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 100%, with lines and filter already documented including defaults and case-insensitivity. The description largely restates these facts and adds no extra semantic detail 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?

The description uses a specific verb and resource: 'Read the UMM mod manager log file.' It also clearly states the output behavior: returns last N lines by default or filtered by pattern. It does not explicitly contrast with sibling watch_log, so it stops short of a full 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?

There is no guidance on when to use read_log versus watch_log or any other tool. No exclusions, prerequisites, or alternative conditions are mentioned. The distinction from watch_log is only implicit in the verb 'Read.'

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 explicitly discloses side effects beyond the name: clears checkpoints and trigger state, making the reset semantics clear. It doesn't cover every possible consequence, but it covers the key behavioral traits.

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

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

Two short sentences with no filler. The main action is front-loaded, and the second sentence adds only the essential side-effect detail needed for correct use.

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 parameterless restart action with no output schema, the description is complete: it states the target, the operation, and the meaningful side effects. No additional detail is necessary for an agent to call 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?

The tool has zero parameters, so the schema is trivially complete and there is no parameter ambiguity. Per the rubric, 0 params receives a baseline of 4.

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 ('restart the current level') and clarifies the action as a full reset from the beginning. It does not explicitly name sibling tools, so it lacks the strongest form of sibling differentiation, but the meaning 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?

The description implies when to use it: when the agent needs to restart the current level cleanly. However, it gives no explicit guidance about when not to use it or when to prefer alternatives like go_to_level or stop_game.

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 disclosure burden. It clearly states that scripts are JSON files with command sequences and wait delays, and that execution happens directly against the game with a hard constraint against server-side tools. It does not mention side effects or prerequisites, but the core behavioral context is well covered.

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 composed of three sentences, each earning its place: the purpose, the script format, and the execution constraint. It is front-loaded with the core action and contains 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 simple single-parameter tool with no output schema, the description covers the essential aspects: what the tool does, what the script file looks like, and a key runtime constraint. Minor operational details like whether the game must already be running or what the result returns are not stated, but they are not critical for understanding how to invoke the 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?

The schema already provides 100% coverage for the 'script' parameter by explaining name/path conventions. The description adds meaningful extra context by explaining that the script is a JSON file with command sequences and wait delays, which helps an agent understand what content is expected beyond just the parameter name.

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: 'Execute a test script'. It further distinguishes itself by clarifying that scripts are JSON command sequences that run directly against the game, and that server-side tools cannot be used as steps, which separates it from sibling script-related 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 provides clear context for when to use the tool: it runs game-side test scripts. It also gives an explicit exclusion by listing server-side tools that are not usable as steps, which helps an agent understand the tool's boundaries. It stops short of naming a specific alternative tool, so it does not earn a 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the change applies only to the next spawn/respawn/level, not immediately, and clarifies it does not modify the current bro. This is meaningful behavioral context beyond the bare operation, though it does not cover potential errors, persistence, or validation behavior.

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

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

The description is only two sentences long, front-loads the main action and timing, and appends the key limitation without redundancy. Every word contributes meaning.

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 simplicity, two clearly documented parameters, and no output schema, the description plus input schema fully equips an agent to call it correctly. The key behavioral nuance (deferred application) is explicitly covered.

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 100%, with clear descriptions for both broName and playerNum, including an example and a pointer to list_bros. The tool description itself adds little parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a clear verb and resource: 'Set which bro the player will spawn as next.' It also defines the timing explicitly with 'on death/respawn/next level' and differentiates itself from a mid-level swap by saying 'Does NOT change the current bro mid-level.' This makes the tool's purpose unambiguous and distinguishable from siblings like swap_bro.

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 explains the tool's scope and timing, and it explicitly warns that it does not change the current bro mid-level, which serves as a useful when-not-to-use signal. However, it does not explicitly name an alternative such as swap_bro or provide more detailed decision guidance, so it stops short of a full usage guideline.

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 only states the action and 'time scale'; it does not mention whether the change is persistent, whether zero or negative values are allowed, whether a running game is required, or how the change affects gameplay. The parameter examples are useful but are already in the schema.

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

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

One short, front-loaded sentence with no filler. The parenthetical 'time scale' adds useful semantic context 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 single-parameter setter with full schema coverage, the essential invocation data is present. However, with no annotations and no output schema, the description leaves behavioral gaps such as valid range, persistence, and prerequisites, making it minimally viable but not rich.

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 100% and the parameter description already explains the multiplier semantics clearly. The description adds only the phrase 'time scale', which does not materially extend the schema, so the baseline of 3 is appropriate.

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

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

Uses a specific verb ('Set') plus a clear resource ('game speed') and clarifies the meaning with 'time scale'. No sibling tool overlaps this capability, so an agent can distinguish it immediately 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?

The invocation context is self-evident: use this tool when the game's time scale needs to be changed. There are no speed-related sibling tools, so the absence of explicit exclusions is not a meaningful gap.

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 of disclosing behavior, but it only restates the core action. It does not explain what happens when health is set to 0, whether values are clamped, whether playerNum=-1 applies to all active players, or whether the change persists or affects gameplay state.

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 a single short sentence with no wasted words. It is appropriately concise for such a simple tool, though it sacrifices substance for brevity.

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 lack of annotations, the absence of an output schema, and a broad sibling list, the description is incomplete. It does not convey the broader player state context, the special all-players behavior of playerNum, or how this fits into the testing/debugging workflow.

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 100%, so the input schema fully documents both parameters. The description adds no additional meaning beyond what the schema already provides, which is acceptable given the high 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 states a specific verb and resource: 'Set a player's health.' This is clear and distinguishes the tool from siblings like teleport_player or set_game_speed, though it does not explicitly contrast itself with those 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?

There is no guidance on when to use this tool versus alternatives, no mention of intended workflow, and no exclusions or prereqisites. An agent must infer from the tool name that this is for debugging or test setup, which the description does not support.

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, but it only states the basic action. It does not mention side effects on the game state, whether events are injected synchronously or asynchronously, whether a running game or focus is required, or what happens with invalid actions. The agent must infer most behavioral traits.

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

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

The description is a single economical sentence with no filler, and it front-loads the core purpose. It is concise to the point of being thin for a five-parameter tool, but the brevity itself is not the failure here; the missing operational context is captured in other dimensions.

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 no annotations and no output schema, the description covers only the bare purpose and none of the surrounding context an agent needs to call it with confidence. The rich parameter schema explains what to send, but it says nothing about expected return behavior, side effects, or prerequisites such as a running game. The combination of minimal description and absent annotations makes this only minimally viable.

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 100%, so the baseline of 3 applies even though the description adds no parameter-level detail. The schema already explains action options, count, duration, interval, and player. The description's phrase 'keyboard/controller input' loosely aligns with the schema but does not enhance or clarify any parameter further.

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 ('Simulate') and resource ('keyboard/controller input'), so an agent can tell it apart from sibling inspection and mutation tools. It is clear and unambiguous about the domain, though it does not add scope details or contrast with a sibling. It falls just short of a 5 because it stops at the generic capability.

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. With siblings like execute_code, set_player_health, and run_test_script present, the description does not state that simulate_input is the right choice for key/controller events or when scripted execution would be preferable. The intended usage is only implied by the name and schema.

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 disclosure burden. It does not state side effects, whether spawned entities persist, what 'limited implementation' actually limits, or any prerequisites or consequences. The phrase hints at limitations but provides no concrete detail.

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 a single concise sentence and is front-loaded with the core action. However, 'limited implementation' is vague and could be replaced with specific constraints without increasing length much.

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 mutating tool with no annotations and no output schema, so the description should clarify side effects, return value, and constraints. It only provides a bare one-liner, leaving an agent uncertain about what happens after spawning and what 'limited' means in practice.

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 100%, so the parameters are already well documented by the schema. The description adds little beyond restating that an entity is placed at a position; it does not enrich parameter meaning beyond what 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?

The description clearly identifies the action (spawn), the resource (entity), and the location (specific position). The phrase 'limited implementation' adds a caveat but does not obscure the core purpose, though it doesn't differentiate from sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives like execute_code, run_test_script, or other entity manipulation tools. The vague 'limited implementation' hint is not sufficient to help an agent decide when this is the right choice.

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 the action but does not say whether the stop is graceful or forceful, whether unsaved state is lost, or what happens if no process is running. For a potentially destructive process-control tool, this is a meaningful 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 a single six-word sentence with no filler or redundancy. It front-loads the verb and target, making it quick for an agent to parse and act on.

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 parameterless tool with no output schema, the description supplies the core precondition ('running') and the exact action. However, it does not mention what happens when the game is not running or whether the call returns any confirmation, leaving minor edge-case 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?

This tool has zero parameters and an empty input schema, so there are no parameter semantics for the description to clarify. The description adds no parameter information, but none is needed; this matches the baseline for a parameterless 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 uses a specific verb ('Stop') and a clear resource ('the running Broforce process'), making the action and target unambiguous. This distinguishes it from sibling tools like launch_game and restart_level without needing to inspect 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?

The word 'running' implies the tool should only be called when a Broforce process is active, but the description does not explicitly address when to use it versus alternatives such as launch_game or wait_for_game. There are no exclusions or alternative routing, so usage context is implied rather than directly 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 zero annotations, the description carries the full transparency burden, and it delivers the most critical disclosure: the tool 'kills the current bro', making the destructive nature unmistakable before invocation. It also reveals the mod intesgration and direct-game-manipulation fallback. It loses a point because 'direct game manimulation' is left vague — the agent gets no sense of what risks or state divergences that path might introduce.

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 sentences with each earning its place: core purpose with scope, destructive mechanics, then implementation detail. It is front-loaded — the most important fact (kill-and-swap) appears in the first two sentences — and contains no filler or repetition of the tool name.

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 destructive consequence and fallback behavior are covered, which matters given there are no annotations. But with no output schema and no result contract, the description leaves out what the agent should expect after invocation — success/failure reporting, error behavior for an invalid broName, and whether the swap is recoverable. For a destructive tool these are meaningful 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 coverate is 100%, and both parameter descriptions are already informative: broName includes concrete examples and routes to list_bros, while playerNum specifies the 0-3 range and default. The tool description adds no parameter-specific meaning, so the baseline of 3 applies as the schema already does the heavy lifting.

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 ('Swap the current player's bro') with a scope qualifier ('mid-level'), and the second sentence grounds the operation further by explaining the mechanics: kills the current bro and spawns the new one at the same position. It stops short of a 5 because it never explicitly differentiates from the sibling tool set_bro, which an agent could plausibly confusee with this 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 'mid-level' qualifier implies this tool is for mid-play swaps rather than setup-time assignment, and the mod/fallback remark indicates it works across envionments. However, there is no explicit when-to-use guidance and no routing to alternatives — notably set_bro is a sibling that likely handles non-destructive bro assignment, and the description gives no criterion for choosing between them.

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 provided, the description carries the full burden. It does disclose the key behavior: a screenshot is saved and its path is returned. However, it does not mention file format, save location, or whether the action blocks, which are minor gaps for this tool.

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

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

The description is two short sentences with no filler. The action is stated first, followed by the return value, and every word contributes meaningful 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 zero-parameter utility with no output schema, the description adequately covers what the tool does and what it returns. Additional details like where the file is saved would be nice but are not needed 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 tool has zero parameters, so the schema is complete and the description has no parameter meanings to add. The zero-parameter 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?

The description clearly states the action and resource: 'Take a screenshot of the game.' It is specific, and no sibling tool appears to offer the same functionality, so the purpose is unambiguous even though it does not explicitly contrast with 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 intended use is implied by the name and description, but there is no explicit guidance about when to use it, exclusions, or alternatives. For a simple zero-parameter tool this is adequate, though not instructive.

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 only states the action without mentioning side effects, failure behavior, handling of playerNum=-1 versus the default, or whether a running game session is required. For a mutation tool with zero annotation coverage, 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 one short, front-loaded sentence with no filler or repetition. It efficiently states the core purpose and earns its place without duplicating schema content.

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 schema fully covers parameter semantics, but with no annotations and no output schema the description lacks context about multiple-player behavior, coordinate system assumptions, success/error reporting, and prerequisites. It is adequate for a simple invocation but not complete for robust decision-making.

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 describes all four parameters with 100% coverage, including the playerNum default and special '-1 for all active players' case. The description adds no parameter meaning beyond 'specific position', so the baseline score of 3 is appropriate.

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

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

The description clearly names the action ('teleport'), the resource ('a player'), and the target ('a specific position'), which is enough to distinguish it from sibling tools like set_player_health or spawn_entity. It does not explicitly address which player or player group is affected, but that nuance appears in the parameter 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?

There is no explicit 'use when' statement, prerequisites, or comparison to alternatives. However, the unique teleport semantics imply the use case strongly enough for an agent to select this tool over nearby 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?

With no annotations, the description carries the full burden, and it discloses the key side effects: Harmony patch cleanup, GameObject cleanup, and invocation of Unload() when present. It does not specify behavior for inactive/nonexistent scripts or whether unloading is reversible, which keeps it from 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 a single sentence that front-loads the action and then lists only necessary cleanup consequences. There is no filler or repetition of schema content.

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 tool with no output schema, this is nearly complete: it names the target, the action, and the side effects. It would be fully complete with a note on error/return behavior when the specified script is not active or does not exist.

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 100% and the single parameter is documented as 'Name of the script to unload', so the description adds no extra parameter-level detail. The baseline of 3 is appropriate because the schema fully handles parameter semantics.

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 ('Unload') and resource ('active C# script'), and adds concrete cleanup details that separate it from script lifecycle siblings like compile_script and execute_script. It is immediately obvious what the tool does and which operation it targets.

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 'active' establishes a clear precondition: this is for scripts that have already been loaded and are currently running. No alternative unload tool exists among siblings, so the usage context is clear, although explicit when-not-to-use guidance is not provided.

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 well by disclosing the polling behavior, the success condition (ping succeeds), and the timeout boundary. It could add what happens on timeout (error vs. false return), but it already gives an accurate expectation of the tool's blocking 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?

Two tightly written sentences with no filler. The purpose is front-loaded, and the polling/timeout mechanic is stated efficiently in the second sentence.

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 no output schema, the description does not specify what the agent will receive on success or on timeout. It also assumes the agent knows this should be used after launch_game. The core behavior is covered, but the outcome semantics are 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 100% and both timeout and interval are already described with defaults in the schema. The description adds no new parameter semantics beyond reinforcing that polling happens; this is an adequate baseline.

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: waiting for the game to start and for the Unity Inspector TCP server to become responsive. It distinguishes itself from sibling tools like launch_game and ping by focusing on readiness-waiting rather than launching or one-off checking.

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 clear usage context: call this after launching the game and before issuing commands that require a responsive server. However, it does not explicitly mention alternatives such as ping for a quick connection check, nor does it state when not to use it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly reveals the stateful cursor behavior and baseline semantics. The reset parameter is documented in the schema, so the core behavioral surprises are covered, though the description itself does not elaborate on them.

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 three short, purposeful sentences. The core behavior is front-loaded, the baseline behavior is explained, and the intended use case is stated without any 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 simple stateful log watcher, the description plus schema covers the essential behavior and usage. It does not describe the exact return format, but that is a minor gap given the straightforward nature of the tool and its focus on iterative loops.

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 100% coverage for the single reset parameter, and the parameter description already explains its meaning. The tool description adds useful context about the first-call baseline but does not need to explain the parameter further.

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 identifies the tool's purpose: returning log entries since the previous call, with a first-call baseline of the last 20 lines. This distinguishes it from a plain full-log reader like read_log by emphasizing the incremental, stateful behavior.

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 explicitly states the intended use case: iterative debug loops. It does not explicitly mention when to prefer the sibling read_log tool instead, but the incremental-watch framing provides enough context for an agent to choose appropriately.

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