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

No annotations are provided, so the description carries the full burden. The verb 'Report' implies a read-only operation, and the listed output fields give some transparency. However, it does not explicitly state whether the tool has side effects, what happens if the bridge is disconnected, or the exact return format (e.g., booleans, nested tables). This is adequate for a simple status check but leaves room for more 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 sentence, front-loaded with the verb, and lists all relevant output fields without any filler or redundancy. It is perfectly concise 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?

The tool has no output schema, so the description must convey return semantics. It lists the included game info fields (name, placeId, client version, capabilities) and indicates a connection status. For a simple status-check tool, this is fairly complete, though it could explicitly state the format of the connection status or error handling. Overall, it covers the essential information.

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 input schema fully covers the parameter space. The description adds no parameter details, but none are needed. Baseline for 0 parameters is 4, and the description does not detract from that.

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 the specific verb 'Report' and clearly identifies the resource (Roblox bridge connection status and basic game info). It also enumerates the exact fields reported (name, placeId, client version, capabilities), making it distinct from sibling tools that focus on properties, search, or code 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 establishes a clear context for when to use the tool: whenever the agent needs to verify the Roblox bridge is connected or retrieve basic game information. There are no direct exclusions or alternative tool references, but the tool's purpose is unambiguous enough that no further guidance 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?

No annotations are provided, so the description must fully disclose behavior. It states the core action but omits critical context such as potential network failures, permission requirements, side effects on the server, or behavior when the RemoteEvent is invalid. This is a significant gap for a tool that triggers remote execution.

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, succinct sentence with no redundant words. It is appropriately brief, though it could benefit from additional essential details 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?

Given the complex args schema with numerous Roblox-specific types, the lack of an output schema, and the presence of sibling tools with overlapping purposes, this description is severely inadequate. It does not explain how to construct arguments or how this tool fits into the broader remote event workflow, making correct usage unlikely.

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 description coverage is 0%, so the description must compensate. It only says 'with the given arguments' and fails to explain that 'ref' is an instance reference to the RemoteEvent or how 'args' should be structured (e.g., the supported Roblox types in the schema). This adds no interpretive value beyond the raw 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 clearly states the action 'Fire' on a 'RemoteEvent' and mentions 'FireServer', which is the Roblox API for client-to-server remote events. This distinguishes it from sibling tools like invoke_remote (which handles RemoteFunction) and remote_spy_* 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 implies usage by specifying the action, but it does not explicitly mention when to use this tool versus alternatives like invoke_remote. No exclusions or alternative references are provided, leaving the agent to infer the context from the tool name and 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 provided, the description must disclose behavioral traits, but it only states the resolution action and output. It does not mention read-only safety, error handling (e.g., missing path), or any side effects. This is insufficient for a tool without annotation support.

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, front-loaded with the verb and resource, and includes a concrete example. Every word earns its place—there is no fluff 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?

The tool is simple (one parameter, no output schema), and the description covers the core purpose and parameter format. However, it lacks usage context, return value details (beyond 'ref'), and error behavior, which are more critical given the absence of annotations and 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?

Schema description coverage is 0%, so the description must compensate. It does clarify the 'path' parameter by specifying it is a 'dotted instance path' and provides an example. However, it does not elaborate on edge cases (e.g., leading dots, case sensitivity) or the exact format expected beyond the example.

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 ('Resolve') and clearly states the resource ('dotted instance path') with an illustrative example ('game.Workspace.Part') and the output ('a node with a ref'). This distinguishes it from sibling tools like get_root (no path) and get_children (operates on a ref).

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 (when you have a dotted path) through its example and phrasing, but it does not explicitly state when to use this tool versus alternatives like get_root or search. No exclusions or alternative scenarios 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 full burden of behavioral disclosure. 'List' implies a read-only operation, which is safe, but the description does not detail any potential side effects, error handling, ordering of results, or behavior for invalid refs. It adds minimal context beyond the obvious read nature.

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—two short clauses that immediately convey the core functionality and the optional filter. Every word earns its place, with no redundant or filler 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 relatively simple read-only tool with two parameters and no output schema, the description provides enough to understand its purpose and parameters. However, it omits mention of the return value format (e.g., an array of child instances) and any edge-case behavior. Given the tool's simplicity, this is adequate but not exhaustive.

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 explicitly mentions both parameters: 'by ref' explains the required ref parameter, and 'Optionally filter by className' clarifies the purpose of the classFilter parameter. This adds meaning beyond the schema, though the slight naming mismatch (className vs classFilter) could cause minor confusion.

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: 'List the direct children of an instance by ref.' It specifies the action (list), the resource (direct children), and the distinguishing factor (by ref, as opposed to siblings like get_root or get_properties). The optional filter adds additional specificity.

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—when you need to list direct children of a specific instance. It mentions an optional filter by className, which gives a hint of usage scenarios. However, it does not explicitly mention when not to use it or suggest alternative tools for recursive traversal or other related operations.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a useful behavioral nuance: property names come from a cached Roblox API dump when available. However, it does not mention output format, error behavior, or any other side effects beyond implying a read-only operation.

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

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

The description is two sentences long, with no wasted words. It front-loads the core purpose and includes the important cache caveat in a concise 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?

The tool is simple with one parameter and no output schema, but the description is minimal. It tells what the tool does but does not describe the return structure or edge cases. While not a complex tool, a bit more detail about the output format would make it more complete.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter information. It mentions 'by ref,' but this merely echoes the parameter name 'ref' without explaining what a ref is, how to obtain it, or its expected format. This is insufficient given the parameter is the sole 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?

The description clearly states the tool's function: 'Read the properties of an instance by ref.' The verb 'Read' is specific, and 'properties of an instance' defines the resource. It distinguishes itself from sibling tools like get_children (reads children) and get_by_path (gets by path).

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 you have a ref and need properties), but it does not explicitly mention alternatives or exclusion criteria. No guidance is given on when not to use it or which sibling might be preferred in certain situations.

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

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

No annotations are provided, so the description must disclose behavioral traits. The word 'Get' indicates a read-only operation, and the description specifies the output (root instance and services), but it does not mention potential errors, performance implications, or any special permissions required. For a simple getter, this is adequate but not fully transparent.

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

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

The description is a single, clear sentence with no unnecessary words. It front-loads the action ('Get') and resource ('root instance'), making it highly concise and well-structured.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description is fairly complete. It explains what the tool returns (root instance and top-level services), which is sufficient for an agent to understand its function. It could elaborates on edge cases or error scenarios, but these are not critical for a basic getter.

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 input schema is empty and schema coverage is 100%. The description adds meaning by explaining what the tool returns, which is helpful. Since there are no parameters to describe, the baseline of 4 is appropriate.

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

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

The description clearly states the tool's function: get the root instance (game, ref 0) and its top-level services. The verb 'Get' and specific resource ('root instance') make the purpose unambiguous, and it is distinct from sibling tools like get_children or get_by_path.

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 for retrieving the root instance and top-level services, which is clear context. However, it does not explicitly state when not to use this tool or suggest alternatives for other scenarios, such as getting children or searching.

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

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

With no annotations, the description must disclose behavior. It mentions 'if readable' but does not specify what happens when the source is not readable (e.g., error, null, empty). There is no mention of return format, permissions, or 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 sentence that is direct and free of fluff. It effectively communicates the core action and scope in minimal 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 single-parameter getter, the description gives the essential purpose and a hint of limitations ('if readable'). However, it lacks details on return behavior and error conditions, making it only minimally complete given the absence of annotations and 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?

Schema coverage is 0%, so the description must explain the 'ref' parameter. It only says 'by ref' without detailing what a ref refers to (e.g., instance ID, path). The integer type is in the schema, but the description adds minimal meaning.

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 reads the source of a Script/LocalScript/ModuleScript, which is a specific action on a specific resource. It distinguishes from siblings by the resource type (source vs. properties/children), but does not explicitly contrast 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios like debugging or inspecting source, nor does it exclude situations where other getters would be appropriate.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions 'invoke' and 'return its result', but does not disclose potential side effects of server-side execution, error behavior, or that the call may block/yield. This is insufficient for a network-calling mutation tool.

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

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

The description is a single, front-loaded sentence with no redundant information. Every word contributes to conveying the tool's core 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?

Given the complexity of invoking a RemoteFunction (network call, potential side effects, error handling, return value), the description is too sparse. It does not explain how to obtain 'ref', what the result looks like (no output schema), or how it differs from firing an event. The description is minimally viable but leaves significant gaps.

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

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

Schema description coverage is 0%, so the description must compensate. However, it provides no explanation of the 'ref' and 'args' parameters beyond 'given arguments', leaving their meaning entirely to the schema's technical type definitions. This adds no semantic value.

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

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

The description states a specific verb ('Invoke') and resource ('RemoteFunction') and clarifies the mechanism ('InvokeServer'). This clearly distinguishes it from sibling tools like fire_remote, which likely handles RemoteEvents. The purpose is unambiguous.

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

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

The description implies usage for invoking RemoteFunctions but does not explicitly state when to use this tool versus alternatives like fire_remote, nor does it mention any exclusions or prerequisites. It provides clear context but lacks explicit guidance or comparison.

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 full responsibility for behavioral disclosure. It states that the tool returns captured traffic, but does not disclose whether the operation is read-only, whether it flushes or clears the buffer, or any other side effects. 'Dump' suggests retrieval, but the lack of explicit safety information is a 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, well-structured sentence that conveys the core behavior without any wasted words. It is front-loaded with the main action and is appropriately concise for the simplicity of the tool.

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

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

For a zero-parameter, no-output-schema tool, the description provides adequate information about what is returned. It lacks explicit details about the format of the traffic or dependencies on remote_spy_start, but given the tool's simplicity and sibling context, 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 tool has zero parameters, which by the rubrics sets a baseline of 4. The empty schema confirms no parameter documentation is needed, and the description adds no conflicting information. Nothing further 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 'Return the remote traffic captured since the spy started' clearly states a specific verb (return), resource (remote traffic), and temporal scope. It is not a tautology and distinguishes from sibling start/stop tools by focusing on retrieval.

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 on when to use this tool versus alternatives. The phrase 'since the spy started' weakly implies a prerequisite, but there is no mention of needing remote_spy_start first, nor any comparison to other siblings like get_by_path or remote_spy_stop.

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 behavioral disclosure. It discloses a key failure mode (error if hooks missing) but does not explain the logging lifecycle, such as whether logging is persistent, how to stop it, or what happens to collected logs. This is partial 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 two sentences, front-loaded with the primary purpose and no filler. Every word earns its place, making it highly concise and well-structured.

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

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

For a simple start-command tool, the description covers the core action and a failure condition, but the unexplained 'filter' parameter and lack of annotation context leave gaps. It is minimally viable but not fully self-sufficient.

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 'filter' is completely undocumented in the schema and description. Schema description coverage is 0%, so the description must compensate but does not, adding no meaning beyond the parameter name itself.

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

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

The description clearly states a specific action (start logging) and resource (outgoing remote traffic), distinguishing it from sibling tools like remote_spy_stop and remote_spy_dump. The verb is precise and the scope is unambiguous.

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

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

Usage is implied by the name and verb 'start', but the description does not explicitly mention when to use this tool versus alternatives like remote_spy_stop or remote_spy_dump. It does mention the prerequisite of hooks, which is a useful condition, but no explicit guidance or exclusions are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the core action and omits what happens to captured logs, whether the operation is reversible, and whether it affects any active spy session. This lack of detail could leave an agent uncertain about 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 with no wasted words. It efficiently conveys the core purpose and is appropriately sized for a tool with no parameters.

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 minimally adequate for a simple zero-parameter stop action, but it lacks lifecycle context (e.g., what a session is, whether logs persist, or when it should be called). Given the sibling tool named remote_spy_start, the role is inferable, but the description itself is somewhat sparse.

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 schema already reflects this with 100% coverage. No additional parameter documentation is needed, so the baseline score 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 'Stop logging remote traffic' clearly states the action (stop) and the resource (remote traffic logging). It distinguishes itself from siblings like remote_spy_start and remote_spy_dump by explicitly using 'Stop' as the verb.

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

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

Usage timing is only implied by the tool's name and its sibling tools (remote_spy_start, remote_spy_dump). The description does not explicitly say 'use after remote_spy_start' or mention any prerequisites or alternatives, leaving the agent to infer the lifecycle.

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 disclosure. It mentions execution and return behavior, but fails to warn about potential side effects, client crashes, or security implications of running arbitrary code. 'Power tool' is a vague hint rather than a clear safety warning, leaving significant transparency gaps.

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

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

The description is two short sentences plus a two-word fragment, front-loaded with the core purpose. Every word adds value: the first sentence defines the action and output, and 'Power tool' conveys risk and advanced usage. There is no wasted text.

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

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

Given the tool's high complexity (arbitrary code execution) and absence of annotations and output schema, the description is insufficient. It briefly mentions return values but omits crucial context such as side effects, whether the execution is synchronous, how errors are reported, and what 'best-effort' serialization 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?

The schema coverage is 0%, so the description must compensate for the single 'code' parameter. It implies the parameter is the Luau code to execute, but does not elaborate on expected format, limitations, or error handling. The description provides some meaning beyond the schema, but not enough for full parameter understanding.

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 executes arbitrary Luau in the Roblox client, which is a specific verb+resource. It also explains the output (captured output plus serialized return value), distinguishing it from sibling tools that operate on specific game objects or remotes.

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 'Power tool' implies this is for advanced or unrestricted use, but the description does not explicitly state when to use it over alternatives or when not to use it. The use case is implied by 'execute arbitrary Luau' but no exclusions or alternative references 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?

It discloses recursion, the result cap, and the default limit of 100, adding useful behavioral context. But with no annotations, it leaves gaps: it does not mention ordering, case sensitivity, the meaning of root or maxDepth, or the return format.

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

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

Two sentences, front-loaded with the core action, every word contributes meaning. Excellent conciseness.

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, no output schema, and incomplete parameter coverage, the description is not sufficient for a 5-parameter tool. Missing details about root, maxDepth, and the response shape reduce the agent's ability to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains query (name substring), limit, and optional classFilter, but completely omits root and maxDepth, leaving two parameters unexplained.

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 specifies the action (recursive search), target (instances), filter (name substring, optional className), and constraint (limit). This distinguishes it from sibling tools like get_children and get_by_path.

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 the appropriate use case—searching instances by name substring—without explicitly contrasting alternatives or providing when-not-to-use guidance. However, the context is clear enough for an agent to choose this tool appropriately.

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 adds one meaningful behavioral detail: 'The value is coerced to the property's declared Roblox type when known.' This goes beyond a bare mutation statement. However, it does not disclose other important behaviors such as what happens on failure, whether there are permission requirements, or whether the operation is reversible. The disclosure is minimal but not absent.

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 immediately states the core action and a key behavioral nuance. It is front-loaded, and every word contributes value. No redundant or filler 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?

Given the complexity of the value schema (many Roblox types), the absence of annotations, and no output schema, the description is too sparse. It does not explain how to discover refs, how to handle complex value encoding, or what the tool returns/does on error. Sibling tools provide some implied context, but the description alone leaves significant gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter semantics. It mentions 'instance by ref' (ref) and 'property' (name) implicitly, and 'value' is referenced via coercion. But it does not explicitly define what ref is, how to obtain it, or how to construct valid value types. The schema itself lists types, but the description adds little semantic meaning beyond the action itself.

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: 'Set a property on an instance by ref.' It clearly identifies the action (setting) and the target (a property of an instance). This distinguishes it from sibling tools like 'get_properties' and 'get_by_path', and there is no ambiguity about what the tool does.

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

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

The description implies usage (when you need to set a property) but does not explicitly state when to use it versus alternatives or mention any exclusions. There is no guidance about prerequisite steps like obtaining a ref, though sibling tools like 'get_by_path' and 'get_root' likely provide refs. Usage context is inferable but not clearly articulated.

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