execute_luau

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 disclose two useful traits: the snippet runs as a temporary ModuleScript and it returns both the return value and printed output. However, for arbitrary code execution it omits sandbox scope, error behavior (throw vs. returned error), mutation risk to the open place, and any timeout/limit — significant gaps for a tool this powerful.

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

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

Three short sentences, purpose front-loaded, warning second, execution model third. Nothing is redundant, though the warning is vague enough that it spends words without fully paying off.

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

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

For a code-execution tool with no annotations and no output schema, the description covers the essentials of what it does and roughly what comes back, but leaves out error semantics, sandbox/security scope, and limits. An agent could invoke it correctly for a trivial snippet but lacks what it needs to reason about risk.

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 one parameter and 0% schema description coverage, the description must compensate; it adds that the argument is a Luau snippet executed as a temporary ModuleScript, which is more than the bare 'code: string' schema. It still doesn't clarify whether imports/requires are allowed, whether the code is a body or full chunk, or formatting constraints.

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

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

States a specific verb and resource ('Run a Luau snippet inside Studio') and even describes the return contract (return value plus printed output). It doesn't name a specific sibling to prefer, only a generic 'dedicated tools are safer', so differentiation from read_script/write_script/set_property is left to inference.

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 a genuine usage directive — 'Use sparingly: dedicated tools are safer' — which tells the agent this is a fallback. But it never says which dedicated tool covers which case, nor when this tool is legitimately necessary, so the agent must guess at the boundary.

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