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

Since there are no annotations, the description carries the disclosure burden. It documents per-call result shape ({op, ok, result} or error), states that one failing call does not abandon the rest, and notes round-trip cost. It also labels the batch as safe for exploration. It doesn't outline side effects of specific mutating ops, but the failure semantics are sufficient for a wrapper 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 structure is front-loaded with purpose and rationale, followed by an efficient code-block list of op shapes. The length is justified by the 23 op variants; every line communicates a distinct contract, and the closing result format is compact.

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 covers the two things an agent must know to invoke the batch correctly: how to encode each call and what to expect back. The omission of detailed field semantics (ref, update, kind) is a minor gap and keeps it just shy of fully self-contained.

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 provides only 'calls: array of objects' with 0% description coverage, so the description must compensate. It does substantially: every supported op key and its parameter skeleton is enumerated. It leaves 'ref' and several op-specific fields (include_super, read_soft, update, kind) semantically undefined, which prevents a 5.

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

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

The first sentence states a specific verb ('Run'), resource ('bridge operations'), and a distinguishing constraint ('in ONE round trip'), and 'return a result per call' clarifies what the batch produces. This clearly separates it from the individual sibling tools such as get_property or call_function.

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

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

The description explains the cost model — a round trip costs a poll interval plus latency versus single-digit ms of work — and therefore identifies when batching small calls is valuable. It doesn't explicitly say 'use instead of N individual calls' or name the alternative, but the context is clear.

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

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

The description reports the output fields but does not disclose whether the tool has side effects. Since no annotations are provided, the description carries the burden of indicating that this is a read-only status check, which it fails to do explicitly. It also does not clarify if any permissions are required beyond reporting 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 two sentences, with the primary purpose front-loaded in the first sentence. It is concise, with no fluff or redundant details, and each word contributes to understanding the tool's function and output.

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

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

The description provides enough context for a status-check tool: it names the outputs (game found, mod version, permissions, round-trip time) and the overall purpose. Since there is no output schema, specifying the return fields is sufficient. It lacks a note on typical use cases, but for a simple status tool, this is 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 tool has no parameters, and the schema coverage is 100% (vacuously). The description does not add any parameter-specific meaning, which is acceptable given there are none. Per the baseline rule for high schema coverage, a 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 states the tool's purpose: checking whether a UE4SS game is running and the UEBridge mod is answering. It also enumerates the reported fields, making the tool's function unambiguous. However, it could be slightly more direct by starting with 'Checks' or 'Reports status', but it is still clear.

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

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

No explicit guidance is given on when to use this tool versus alternatives like inspect_object or world_info. The description does not mention conditions or scenarios, leaving the agent to infer that this is a preliminary health check. This is a notable gap given the sibling tools.

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

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

The refusal condition ('Refused when allow_writes = false') reveals that the tool may perform write operations, which is useful behavioral info. However, it does not elaborate on side effects, error behavior, or whether it is read-only in other cases.

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

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

The description is concise, two sentences, with no redundant information. It directly states the purpose and a key constraint.

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

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

The description covers core action and a refusal condition, but lacks details on expected output format, error handling, or prerequisites for calling functions. It is adequate for a simple call but not fully comprehensive.

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 phrase 'positional JSON args' clarifies the 'args' parameter, but 'ref' and 'function' are not explicitly explained. Since the schema has no descriptions, the description only partially compensates for 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 clearly states the action: calling a UFunction on an object with positional JSON arguments and returning the result. It distinguishes itself from sibling tools like get_property or set_property by focusing on function invocation.

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

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

The description mentions a refusal condition based on allow_writes, but does not explicitly guide when to use this tool over alternatives such as eval_lua or list_functions. The condition gives some context but lacks direct comparative guidance.

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

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

With no annotations, the description must carry the full burden of disclosing side effects. It transparently states that 'Output is not captured' and that the tool is refused under a specific condition, which are important behavioral traits. It does not mention other potential side effects (e.g., persistence or state changes), but the disclosed information is valuable.

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 concise sentences, front-loading the core action and immediately providing critical caveats (output not captured, refusal condition). No unnecessary words or 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?

Given the tool's simple nature and the absence of an output schema, the description covers the essential information: what it does, the key limitation (output not captured), and a condition that affects invocation. It could arguably mention that the command may have arbitrary side effects, but that is implied by 'console command' in a world context.

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

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

The schema fully describes the single parameter 'command' as a string, so the description adds no extra semantic depth. The parameter is self-explanatory given the tool's purpose, and the baseline of 3 is appropriate since schema coverage is 100%.

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 ('Execute a console command') and the resource ('in the running world'), making the purpose understandable. It does not explicitly differentiate from sibling tools like eval_lua or call_function, but 'console command' is distinct enough in most contexts.

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 a condition for refusal ('Refused when allow_writes = false'), which gives some guidance on when the tool might be blocked. However, it does not explicitly state when to use this tool over alternatives or mention any prerequisites, so the guidance is only partial.

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 and does so thoroughly. It discloses read-only behavior, the exact return shape, truncation limits, the meaning of `stored_path` when the reference resolves to a different object, and the error behavior for unknown labels.

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 dense but every sentence adds essential information: purpose, parameter behavior, return format, edge cases, truncation, and error handling. It is front-loaded with the core purpose, then proceeds logically into details without filler.

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

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

There is no output schema and no annotations, so the description is the only source of runtime semantics. It fully covers invocation, return values, limits, mutation behavior, and failure modes. An agent has enough information to call diff_object correctly and interpret 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?

Schema description coverage is 0%, so the description must explain every parameter, and it does. It explains `label` as the snapshot identifier, `ref` as overriding the snapshot's reference, and `update` as replacing the snapshot after diffing. This goes well beyond the bare schema.

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

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

The description states a specific verb and resource: 'Re-walk an object and report what changed since the snapshot stored under label.' This clearly differentiates diff_object from siblings like snapshot_object or inspect_object by focusing on comparison against a stored snapshot. It also explicitly marks itself read-only.

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

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

It gives clear context for when to use the tool: when you need to compare an object's current walk against a snapshot, optionally with a rolling diff via update=True. It does not explicitly name sibling alternatives or state when not to use it, but the described use case is sufficiently specific.

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?

It discloses output location and runtime expectations for certain kinds, but does not mention side effects such as file overwriting, required game state, or potential errors. With no annotations, the description bears full responsibility and could be more transparent.

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

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

The description is concise and to the point, with no fluff. The list of kinds is compact, and additional notes about output location and timing are useful without being verbose.

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 tool with no output schema, the description covers the essential aspects: what it does, the parameter's meaning, output location, and timing caveats. It could mention return values or error conditions, but overall it is reasonably 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?

The sole parameter 'kind' is not described in the schema, but the description lists possible values in the text (usmap, jmap, etc.), providing partial semantic coverage. It does not exhaustively enumerate all valid options or explain the effect of each kind.

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 ('Trigger a UE4SS dumper') and lists the specific dump kinds (usmap, jmap, uht, cxx, actors, objects, static_meshes). It is unambiguous and distinct from sibling tools like inspect_object or eval_lua.

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 provides some usage context (output lands in the ue4ss directory, jmap and uht take minutes) but does not explicitly say when to prefer this tool over alternatives or when not to use it. The guidance is implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses that execution happens on the game thread, captures print() output, and is refused when allow_eval=false. It does not cover error handling or side effects, but the refusal condition is a valuable behavioral note.

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 long due to the detailed API listing, which is useful for an eval tool but could be trimmed. The main purpose is front-loaded, and the structure is clear, though the API enumeration may be oververbose.

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

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

With no output schema, the description explains the return value (Lua result and print output) and the available Lua environment. It lacks error-handling details but is otherwise sufficiently complete for an agent to understand the tool's capabilities and constraints.

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

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

Schema coverage is 0%, so the description must explain parameters. It implicitly covers 'code' but does not describe the timeout parameter or its purpose. The extensive API list adds context but not parameter-specific 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 clearly states the tool's purpose: 'Run a Lua chunk inside the game on the game thread and return what it returns.' This is a specific verb and resource, and it distinguishes from sibling tools like call_function or console_command by emphasizing arbitrary Lua execution.

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 this is the general-purpose Lua execution tool but does not explicitly state when to prefer it over alternatives. It mentions the refusal condition (allow_eval=false) and that other tools keep working, but lacks direct comparison to 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?

The description mentions the primary behavior (resolving and returning information) but does not disclose any side effects, error cases, permissions required, or other behavioral traits. Since no annotations are provided, the description carries full responsibility but only partially covers transparency.

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

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

The description is a single concise sentence with no redundant words. It is well-structured and easy to read, containing exactly the essential information without fluff.

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

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

Given the lack of parameter descriptions and output schema, the description is incomplete. It does not explain what constitutes an object reference, what format the path should take, or what the returned name, class, and address look like, leaving significant gaps for an agent to use the tool correctly.

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

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

The only parameter 'path' has no description and the schema coverage is 0%. The word 'path' is generic and ambiguous; the description does not explain what kind of path or object reference it expects, leaving the parameter's meaning entirely unclear.

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 resolves an object reference and returns its full name, class, and address, which is a specific and unambiguous purpose that distinguishes it from sibling tools like 'list_functions' or 'get_property'.

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 alternatives, nor does it mention any conditions or prerequisites for using it. It simply states what it does without context.

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

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

There are no annotations describing side effects, read-only status, or potential impacts. The description does not indicate whether the tool queries, modifies, or creates anything, so the agent cannot anticipate behavioral outcomes.

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

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

The description is short and to the point, but its brevity sacrifices clarity. It is a single sentence without wasted words, yet it omits essential details and does not follow a clear 'verb + object' structure, making it less effective despite being concise.

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

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

The description is incomplete for the given context. It does not mention the output format, return value, or any interaction with the system. Given the sibling tools, it is likely a query but lacks any information about what the caller receives or how to interpret 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 description indirectly references 'class_name' by mentioning a 'short class name' but provides no detail about the 'limit' parameter. With zero schema descriptions for parameters, the agent has insufficient information about the meaning, constraints, or default behaviors of the inputs.

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 is a fragment, not a clear verb phrase. It mentions 'instances of a short class name' which implies finding objects, but it does not explicitly state the tool's function. The tool name 'find_objects' provides some clarity, but the description alone is ambiguous.

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 siblings like 'find_object' or 'list_types'. The description does not mention any conditions, prerequisites, or alternatives, leaving the agent to guess the appropriate context.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose a side effect, 'frees memory in the game process,' but it also states 'Read-only,' which is misleading since dropping snapshots is destructive. It does not mention irreversibility, whether references to snapshots become invalid, or any other consequence.

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

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

The description is short and front-loaded with the main action, but the 'Read-only' phrase is contradictory and muddles the message. Not every clause earns its place because the misleading label detracts from the otherwise efficient 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 one-parameter tool with no output schema and no annotations, the description covers the main action and a meaningful side effect. Still, it leaves uncertainty about the return value, whether the operation is reversible, and what 'Read-only' actually means in this destructive context.

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

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

The single parameter, label, has no schema description coverage, so the description compensates by explaining that it selects one stored snapshot or all snapshots via label='*'. It adds the crucial wildcard behavior beyond the bare parameter name, though it does not specify matching rules or where labels come from.

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, 'Drop', and names its resource, 'stored snapshot', making the core action clear. It also distinguishes itself from snapshot-related siblings by implying deletion rather than creation or listing, though it does not explicitly name alternatives.

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

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

The description implies when to use the tool: when memory used by stored snapshots should be freed. However, it gives no explicit guidance about when not to use it, how it compares to list_snapshots or snapshot_object, or any prerequisite such as listing snapshots first.

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 transparency burden. It explicitly notes that 'an unknown property name raises rather than returning junk,' which is a key behavioral detail. However, it does not mention whether the operation is purely read-only, though the verb 'read' implies that.

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

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

Two concise sentences with no filler. Every word adds meaning, and the key behavioral note is included 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 simple single-property read, the description covers the essential behavior (raising on unknown names). It lacks explicit details about return types or error conditions beyond the note, but given the simplicity of the operation, it is reasonably 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?

The input schema provides no descriptions for 'ref' or 'name', and the description does not explain them. While 'ref' as an object reference and 'name' as a property name are inferable, the lack of explicit definition leaves ambiguity—especially for 'ref,' which could refer to different kinds of references.

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 function: 'Read one property of an object.' It distinguishes from siblings like set_property (mutation) and inspect_object (likely whole-object inspection) by focusing on a single read.

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 this tool—when you need one property of an object—but it does not explicitly contrast with alternatives like inspect_object or mention when a different tool would be preferred. The guidance is minimal but sufficient for the simple case.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the callback copies parameters and the calling object's name and does nothing else, that calling a hooked function from eval_lua can crash the game with an access violation, and that it counts as a write requiring allow_writes. This is unusually candid and actionable.

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?

Although the description is substantial, every sentence earns its place: purpose, write semantics, parameter explanation, output retrieval, crash warning, permission gating, and stop mechanism. Safety-critical details are front-loaded and clearly separated.

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-risk hooking tool with no annotations and no output schema, the description covers invocation, parameter meaning, output retrieval via poll_events, unregistration via stop_stream, write-permission constraints, and a crash hazard. The only minor omission is the `label` parameter, but the tool is still safe and callable with this description.

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

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

With 0% schema description coverage, the description must compensate. It explains `function` as a UFunction path with a concrete example and `max_args` as a per-call parameter cap with default 8. However, the required `label` parameter is never described, leaving a gap for a required input.

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 concrete action ('Record every call of a UFunction, with its parameters'), names the resource (a UFunction path), and explicitly notes that it counts as a write. This distinguishes it clearly from read-style siblings like poll_events and from call_function or eval_lua.

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

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

Explicitly tells the agent to read hook output via poll_events, to stop a hook with stop_stream, and to avoid calling a hooked function from eval_lua in the same session. It also states that hooking is refused when allow_writes=false, giving concrete selection and safety 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?

The description mentions that SoftObjectProperty values are skipped, which is a notable limitation. However, it does not explicitly state that the operation is read-only or side-effect-free, though this is implied by the inspection nature. No annotations are provided to contradict or supplement this.

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

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

The description is concise and well-structured, with a clear opening sentence and separate parameter notes. It avoids unnecessary fluff, though it could be slightly more explicit about return format or usage comparisons without becoming verbose.

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 must indicate what the tool returns. It states 'Every reflected property of an object with its current value', which implies a map or listing, but does not specify the exact structure (e.g., dictionary vs list). It also covers the skipping behavior, but lacks details on error handling or 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?

The description explains pattern (optional Lua pattern) and include_super (defaults to False), providing examples. It does not explicitly explain ref, though it is clearly the object reference from context. The schema provides titles and defaults, but the description adds meaning for only two of the three parameters.

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

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

The description clearly states it inspects every reflected property of an object with its current value, and it specifies usage on CDOs and actors. This distinguishes it from get_property (single property) and find_object (search for objects), though it does not explicitly mention 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?

It gives some guidance on when to use (on CDOs and actors) and how to filter with pattern, but does not explicitly compare to sibling tools like get_property or dump. The context implies a bulk inspection, but the description does not state when to prefer this over get_property or when to avoid it.

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

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

No annotations are provided, so the description carries full responsibility. It states the tool lists functions but does not clarify whether it has side effects, requires special permissions, or how it handles errors. The read-only nature is implied but not explicit.

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 extremely concise and free of unnecessary words. It delivers the essential information in a single sentence without dilution.

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 simplicity of the tool, the description is adequate for the basic action but lacks important context. It does not explain the 'ref' parameter, what the output format is, or how the results relate to the class hierarchy, leaving gaps for an agent attempting to use it.

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

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

The only parameter 'ref' has no description in the schema, and the tool description does not explain what it represents. A user cannot infer whether it is an object reference, a string identifier, or something else, making the parameter effectively undocumented.

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

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

The description clearly states the tool lists callable functions on an object, with scope 'across its class chain'. The verb 'list' and resource 'functions' are specific. The only ambiguity is what 'ref' refers to, but the core purpose is understandable.

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 like call_function or inspect_object. The description does not mention any conditions, prerequisites, or comparisons to sibling tools.

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

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

With no annotations at all, the description carries the full behavioral burden. It clearly states the operation is read-only and specifies the timestamp format ('wall-clock timestamp in whole seconds') and returned fields. This gives an agent enough behavioral context to understand the tool's output and side-effect profile.

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

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

The description is compact and front-loaded: it states the resource first, then enumerates the key output fields, and ends with the read-only qualifier. Every clause adds useful information with no wasted words.

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

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

For a parameterless read-only listing tool, the description is fairly complete: it identifies the operation, the output fields, timestamp semantics, and safety profile. It could add explicit context about ordering or what happens when no snapshots exist, but those are minor 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?

The tool accepts zero parameters, so there is no parameter semantic burden. The baseline of 4 applies, and the description's mention of returned fields further clarifies what the no-argument call will produce.

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 resource (snapshots currently held in the game) and enumerates the exact fields returned: label, object path, taken timestamp, and property count. It implicitly differentiates from sibling tools like snapshot_object and forget_snapshot by describing a listing operation, though it never uses an explicit verb like 'list'.

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

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

The description provides no guidance on when to use this tool versus alternatives such as diff_object, snapshot_object, or forget_snapshot. It notes that the tool is read-only, but does not explain scenarios like enumerating snapshots before comparing or deleting 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 behavioral disclosure burden and does so well by explicitly stating 'Read-only.' It also reveals that only currently running watches/hooks are shown and lists the fields that will appear. This is sufficient transparency for a simple listing operation.

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

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

The description is a single sentence that front-loads the core purpose and packs the output fields into a compact list. Every element earns its place, and there is no filler or repetition.

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 provides enough information to call and interpret the result: what is listed, which field names to expect, and that it is read-only. Minor ambiguity remains around terminology such as 'streams' versus 'watches and hooks,' but overall the definition is 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 tool has zero parameters, so there is nothing for the description to compensate for. The field list in the description adds useful context about what the response contains, which is more than 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 clearly identifies the resource as currently running watches and hooks and enumerates the fields returned. It is easy to distinguish from sibling tools like watch_property, hook_function, and stop_stream. It stops short of an explicit verb like 'list' or 'enumerate', 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 phrase 'currently running' implies this tool is for inspecting active watches/hooks rather than creating or removing them. However, it does not explicitly reference sibling tools or state when to choose this over alternatives such as poll_events or stop_stream. Usage guidance is therefore only implied, not explicit.

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

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

With no annotations, the description carries the full behavioral burden and handles it well: it discloses that invalid ref inputs raise, the base class is excluded from results, pattern matching applies to the short name, results are sorted by path, and the underlying scan takes about 1.5 seconds on large games. These details meaningfully shape invocation expectations.

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 information-dense but well organized: purpose first, then parameter notes, then return shape and performance caveat. Every sentence earns its place and avoids repetition, making the content easy to scan 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?

There is no output schema and no annotations, yet the description fully specifies the return structure ({base, count, types}), row shape ({name, kind, path, parent}), sorting, error behavior, and performance cost. An agent has everything necessary to decide whether to call the tool and understand its result without external context.

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

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

Schema description coverage is 0%, so the description must explain parameters itself. It defines ref as a class path with a required type, notes that non-Class/BlueprintGeneratedClass inputs raise, explains pattern as an optional Lua pattern on short names, and clarifies limit via 'count is the number of matches before limit'. All three parameters are given meaningful semantics 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 immediately states the tool enumerates every loaded class derived from a base class, including Blueprint classes. This clearly identifies the operation and scope, and implicitly distinguishes it from sibling tools like list_types by focusing on the subclass relationship.

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

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

The description gives clear context for using the tool: pass a class path, avoid non-Class/BlueprintGeneratedClass objects, and optionally use a Lua pattern. It does not explicitly name when-not-to-use or point to an alternative sibling, but the intended use is evident and no exclusions are 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 present, the description carries the full burden. It transparently mentions the walk over GUObjectArray and the approximate runtime, giving useful side-effect information. No contradictions are present.

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 information. It efficiently communicates the core 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?

The description gives sufficient context for basic invocation: what it lists, how the pattern works, and a performance caveat. The limit parameter's meaning is not fully elaborated, but the default value mitigates ambiguity. Overall, it is adequately 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?

The description explains the 'pattern' parameter as a Lua pattern and clarifies that empty matches all. The 'limit' parameter is not described, though its default of 200 provides some context. Overall, partial parameter coverage.

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

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

The description clearly indicates a listing operation for loaded reflected types, with a specific name-matching pattern. It distinguishes from siblings like find_object or dump by focusing on type enumeration, though the verb is implicit.

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

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

It provides guidance on the empty pattern meaning 'all' and notes the performance cost (~400 ms), implying when to use it. However, it does not explicitly contrast with alternatives like find_object or list_functions, so the usage context is only partially clear.

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

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

With no annotations available, the description carries the full burden and handles it well: it declares read-only behavior, explains clear semantics, discloses the 2000-event buffer cap, and defines what dropped counts. It also provides the exact return shape and row fields, which is especially valuable given no output schema.

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

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

The description is compact and front-loaded: purpose and safety first, then parameter semantics, then return contract. Every sentence carries essential information, with no filler or repetition of schema titles.

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

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

The description is nearly complete for an event-polling tool: it covers return values, row shapes, buffer behavior, and the incremental polling pattern. The main gap is the undocumented limit parameter, and there is no explicit statement of what happens when the buffer cap is approached beyond the dropped count.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain since (exclusive sequence number), label (single-stream filter), and clear (drops returned rows), but it does not explain the limit parameter or its relationship to the 2000-event buffer. This is a meaningful omission.

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

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

The opening line 'Drain events recorded by watches and hooks' names a specific verb, a clear resource, and the source of events. This distinguishes it from siblings like watch_property or stop_stream by framing it as the consumption side of the watch/hook lifecycle.

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

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

The description implies usage through the polling pattern ('pass back the next from the previous call') and the note that label filters to one stream. However, it never explicitly says when to choose this tool over siblings like list_streams or stop_stream, nor does it state exclusions.

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

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

With no annotations provided, the description carries the full burden, and it does so well: it explicitly states the operation is read-only, touches only the mod's settings, works under restricted flags, and describes the return values including settings and generation number.

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

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

The description is compact and front-loaded: the core purpose appears in the first sentence, followed by concise details on safety and return values. Every sentence adds meaningful information 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 zero-parameter tool with no output schema, the description is fully sufficient: it states what happens, when to use it, why it is safe, and what the caller can expect in return. No critical information is missing.

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

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

The tool has zero parameters)Skip; the schema already covers everything. The description adds relevant context about what the operation does and returns, which is useful even though no parameter documentation is needed.

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

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

The description states a specific action: re-read settings.lua and re-run the UEBridge mod in place, with the explicit outcome of no game restart. This clearly distinguishes it from status or evaluation tools like bridge_status and eval_lua.

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 conditions for use: it works when allow_eval and allow_writes are falseais and is the recovery path after eval was turned off. It does not explicitly name alternative tools or when-not-to-use scenarios, but the recovery-path framing gives strong situational guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses side effects (writes are never undone), return values ({previous, current}), error behavior (unknown property raises), and inhibition conditions (allow_writes = false). This is thorough and transparent.

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

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

The description is concise and to the point, covering essential behavioral aspects in a few sentences. It avoids unnecessary fluff and front-loads the core action and return type.

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

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

The description covers the tool's primary purpose, side effects, error conditions, and return shape. It doesn't need to explain more for a simple property setter. A minor gap is not stating what a 'ref' is, but given sibling tools like inspect_object and find_object, the context is likely familiar. Overall, the tool is well-contextualized.

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 lacks any parameter descriptions, and the description provides limited clarification. It implies ref is an object reference, name is a property name, and value is the value (with type restrictions), but these are not explicitly defined. The description does not adequately compensate for the 0% schema coverage, leaving ambiguity for parameter meanings.

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

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

The description clearly states the action (write one property), the resource (an object), and the allowed types (number, bool, string). It distinguishes from sibling tools like get_property by explicitly focusing on writing, making the purpose unambiguous.

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

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

The description gives clear usage context: it mentions that writes are irreversible, unknown property names raise errors, and refusal occurs when allow_writes is false. While it doesn't explicitly state 'use when you want to modify a property,' this is implied by the verb 'write' and the contrast with get_property. Minor gap in not naming alternative tools explicitly, but 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?

The description discloses several important behaviors beyond the schema: snapshots live in the game process, survive UEB.reload() but not a game restart, reusing a label replaces the snapshot, and the return value includes a wall-clock timestamp. Since no annotations are provided, the description carries the full burden and does so well, though it could mention whether the operation is read-only in more explicit terms.

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

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

The description is compact and front-loaded with the core purpose, then adds essential behavioral details in a structured way. Every sentence earns its place: the first defines the action, the second explains the relationship to siblings, the third covers storage semantics, and the fourth covers return value and lifecycle.

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 the key facts an agent needs: what it does, how it relates to siblings, what parameters are stored, what the return value contains, and the snapshot lifecycle. It could be slightly more explicit about the exact format of ref, but the overall context is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that include_super and pattern are stored with the snapshot and affect the diff re-walk, adding meaning beyond the schema's bare type definitions. It does not explicitly define ref or label, but their names and the description's context make them reasonably clear.

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

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

The description clearly states the tool walks an object's reflected properties and stores the result under a label, explicitly distinguishing it from inspect_object and positioning it as the companion to diff_object. The verb 'walk' plus the resource ('object's reflected properties') and the storage behavior make the purpose unambiguous.

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

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

The description explicitly says this is the same walk as inspect_object but kept for diff_object, and explains that include_super and pattern are stored with the snapshot so the diff re-walks the same set. This gives clear when-to-use guidance and implicitly distinguishes it from inspect_object and diff_object.

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

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

With no annotations, the description carries the full burden. It discloses that the operation unregisters a hook, which is useful behavioral context beyond the verb 'stop.' It does not mention idempotence, error behavior, whether stopping all is irreversible, or what happens to active callbacks, so some behavioral gaps remain.

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

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

Two short sentences with no filler; the primary action and special label behavior are front-loaded, and the second sentence clarifies the underlying side effect. Every clause adds 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 single-parameter tool with no output schema, the description is nearly complete: it explains target selection, the all-case wildcard, and the unregistering effect. It lacks only minor operational details such as return value or error handling, which are not required for basic correct invocation.

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

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

The schema provides no description for label (0% coverage), so the description must compensate. It does: label identifies a single watch/hook or the special value '*' to stop all. This covers the key semantics for the only parameter, though it omits details like exact-match requirements or not-found behavior.

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 concrete resource ('one watch or hook') and adds the special label '*' for stopping all. It is clear and distinct from sibling creation tools such as watch_property and hook_function, though it does not explicitly name an alternative or contrast itself with them.

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

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

The description implies usage: call this when you want to stop a watch/hook or all of them, and the label parameter is explained. However, it gives no explicit guidance about when not to use it or which sibling tools to prefer (e.g., watch_property/hook_function for creation), leaving the when-to-use decision mostly 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 full burden. It discloses the read-only nature ('Read-only: it works with allow_writes = false'), the miss behavior ('Returns {hit} alone on a miss'), the full hit result shape, and the materials truncation behavior ('first 32'). This is substantial behavioral disclosure. It doesn't mention performance cost or whether the trace respects collision complexity, but for a read-only query tool the disclosed behavior is strong.

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

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

The description is dense but well-organized: a one-line plain-language summary, then parameter explanations, then return shape, then read-only note. Every sentence adds information. It could be slightly more scannable with line breaks, but it is not bloated.

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

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

For a read-only trace tool with 3 optional parameters and no output schema, the description covers the purpose, parameter semantics, return values, and safety profile. The only missing context is how to specify the ref actor (name vs. ID) and perhaps an example call. But the description is complete enough for an agent to invoke the tool correctly in most cases.

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

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

Schema description coverage is 0%, so the description must compensate. It explains all three parameters: distance (unit and default), channel (enum-like mapping), and ref (meaning and use case). The only minor gap is that it doesn't explicitly state that ref is an actor reference or how to specify it (e.g., by name or ID), but the description's explanation of ref is still meaningful.

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

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

The description opens with a plain-language statement of what the tool does ('What the player is looking at') and then gives a precise technical definition: a line trace from the camera along its forward vector. It clearly distinguishes itself from sibling tools like find_object/find_objects (which search by criteria) and inspect_object (which inspects a known object). The verb+resource+mechanism are all specific.

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 explains when to use the ref parameter ('which is how you ask what an NPC faces'), and the channel parameter's meaning is given with its values. It also states the default distance and unit. While it doesn't name sibling alternatives explicitly, the usage context is clear enough that an agent can decide when to call this tool versus find_object or inspect_object.

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 full behavioral burden and does so thoroughly. It discloses interval clamping/defaulting, per-pass cost, object revalidation with IsValid(), resumed/lost event behavior, baseline resets, and that only stop_stream ends a watch. This goes far beyond what a typical description provides.

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 long but each sentence carries substantive information, from purpose to parameters to event semantics to lifecycle. It is front-loaded with the core purpose and read-only note, then organized by parameter and behavior. No filler or tautology is present.

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 5 parameters, no annotations, and no output schema, this description is remarkably complete. It covers what the tool does, how parameters behave, performance implications, event semantics, lifecycle, and how to retrieve results via poll_events. An agent has enough context to invoke and manage the watch correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains names (one name or list), every (records every sample vs. changes only), interval_ms (clamped, default, performance guidance), label (unique, reuse raises), and ref implicitly through examples like 'first:PlayerController' and reference-following behavior. All five parameters are meaningfully described.

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

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

The description opens with a specific verb and resource: 'Sample properties on a timer and record an event whenever a value changes.' It also labels the operation as read-only, which clearly distinguishes it from mutation tools and frames its streaming nature. It is immediately distinguishable from siblings like get_property, poll_events, and stop_stream.

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 practical guidance on when and how to use the tool: read results with poll_events, nothing is pushed, stop with stop_stream, and labels are unique. It also advises keeping watches few and slow due to game-thread cost. It does not explicitly contrast with one-shot alternatives like get_property, but the usage context is clear enough.

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

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

With no annotations, the description carries full burden for behavioral transparency. It does not indicate whether the tool is read-only, what side effects it has, or whether it returns current state or modifies anything. The bare list of items gives no clue about behavior.

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

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

The description is extremely short and free of fluff, but it is so terse that it sacrifices clarity. It fits in one sentence but fails to convey meaningful information about the tool's function.

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

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

The description lists game-related entities but does not explain what the tool does with them—whether it retrieves, modifies, or reports their status. It lacks context about return format or purpose, making it incomplete for an agent deciding to call it.

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

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

The tool has zero parameters, so there are no parameter semantics to describe. The baseline of 4 applies because the absence of parameters is clear and no description is needed.

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

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

The description is a noun phrase listing game objects (world, player controller, pawn, game instance, game mode) but does not state what the tool does with them. It lacks a verb like 'get' or 'list', making the purpose ambiguous compared to sibling tools like inspect_object or get_property.

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 such as dump, get_property, or inspect_object. The description does not explain scenarios where world_info is preferred.

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