Inspect running code

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description usefully reinforces this ('Only reads') while adding execution-environment requirements (needs getscriptclosure/getupvalues/getconstants/getgc/getconnections, reports which one is missing, requires the connected state) and the shape of connection results. These are real value-adds beyond the annotations, but it says nothing about failure modes for non-existent paths, rate/cost of a gc scan, or result size behavior beyond the limit default.

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?

It is one dense but front-loaded block that leads with purpose before enumerating actions and requirements; essentially every clause carries information. It is slightly run-on as a single paragraph, and a short bulleted action breakdown would have scanned better, keeping it from a 5.

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 10-parameter, four-action tool with no output schema, the description covers what each action does, which parameters pair with which action, the executor dependency and its error reporting, the connection-state prerequisite, and even the fields returned for connections. Little an agent needs in order to invoke this correctly 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?

Schema coverage is already 100%, so the baseline is 3; the description earns the extra point by tying parameters to actions (path means a script path for upvalues/constants but an instance path for connections; function_name only applies to ModuleScript tables) and by stating the gc filter constraint that the schema cannot express. The 40/25 limit defaults are left to the schema, which is fine.

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 verb+resource ("Look inside code that is running in the game, for reverse engineering") plus the enumeration of the four actions (upvalues, constants, gc, connections) makes the tool's scope unmistakable and cleanly separates it from static-source siblings like get_script_source by stressing 'running' code. It never names a sibling explicitly, so it stops short of a 5.

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

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

The description gives per-action context and prerequisites: path for upvalues/constants vs. instance path + signal name for connections, function_name only when targeting a function of a ModuleScript's returned table, and 'at least one filter is required' for gc. That is strong when-to-use guidance, though it never points an agent to alternatives when this tool is the wrong choice.

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