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

With no annotations, the description carries the full burden and does well: it defines severity semantics (interactive=high, visual=low), states that parent-child overlap is normal and ignored, and describes the return payload (overlap pairs with bounds, overlap rectangle, area in px). It stops short of stating permission/auth needs or whether the operation is purely read-only, which is the remaining 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?

Front-loads the one-line purpose, then uses two tight bullets for the modes and one closing sentence for the return shape. No filler; every sentence carries information.

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

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

For a 4-parameter, no-required-arg detection tool with no output schema and no annotations, the description compensates well by documenting the return format and the overlap classification rules. It could still be more complete by declaring the read-only nature and any cost/pagination considerations.

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

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

Schema coverage is 100%, so the baseline is 3, but the bullets add real meaning to the 'mode' enum by explaining why interactive overlaps matter (unreliable clicks) versus visual ones, which the schema alone does not convey. The description does not add detail for screen, include_hidden, or min_overlap_area 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?

States a specific verb+resource ('Detect overlapping elements') and immediately scopes it to layout bugs and broken click targets. The two bullets further distinguish the internal interactive vs visual cases, so an agent knows exactly what this tool produces and can separate it from neighbors like inspect_element or find_element_at.

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 through the stated goal (finding layout bugs / unreliable clicks) and the severity framing, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings. It leans on the reader to infer that this is the layout-validation tool.

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 important behavioral traits: bypassing hit testing and working when the button is off-screen or obscured. But it omits side effects, permissions, reversibility, or return behavior for a mutation-like action.

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 tightly written sentences, front-loaded with the core action and its key differentiator. Each sentence adds useful 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 mutation-like tool with no annotations and no output schema, the description covers the unique mechanics well. However, it omits side effects, error handling, and return information, which an agent would need to use it confidently.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't elaborate on the screen parameter or ID format beyond the schema's own description).

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

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

States a specific verb (click) and resource (interactive button by ID), and distinguishes itself from coordinate-based hit testing. The bypass mechanism and off-screen/obscured support make its scope 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?

Provides a clear prerequisite (use list_interactives to discover button IDs) and implies when to prefer it over coordinate-based clicking. However, it does not explicitly name alternative tools or state when not to use this tool.

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

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

With no annotations, the description carries the burden and discloses key behavior: it sets up both DevBridge and SSE connections and is a prerequisite for all other tools. It does not cover connection lifecycle details such as what happens on repeated calls or on failure, but for a connect operation it provides substantial useful context.

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

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

Three efficiently ordered sentences: purpose first, then what connections are established, then the critical prerequisite and port guidance. Every sentence earns its place, and nothing is buried or redundant.

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 foundational connect tool with no output schema and full schema coverage, the description is complete enough. It covers purpose, dual connection behavior, prerequisite ordering, and how to obtain the port, leaving no essential gap 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 100%, so the baseline is 3. The description adds meaning beyond the schema by specifying the default port (9001), the recommended source for the actual port from game stdout, and an example log line, which helps the agent supply the required port correctly.

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: 'Connect to a game instance on a specific port (and optionally host).' It also explains the dual connection setup (DevBridge and SSE) and that it must be called before any other tools, clearly distinguishing it from sibling tools.

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

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

Explicitly tells the agent when to use it: 'Must be called before using any other tools.' It also gives practical guidance for obtaining the correct port from stdout and notes the default port, covering both the prerequisite and the parameter acquisition path.

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 implies a pure read/compute operation (no mutation), which is helpful, but doesn't disclose error behavior, coordinate system conventions (e.g. Y-axis direction, scale/rotation handling), or performance characteristics. Some behavioral context is implied but not stated.

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

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

Two compact sentences, front-loaded with the action and followed by the mode routing. Every clause earns its place with no filler.

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

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

Given 5 well-documented parameters and no output schema, the description covers the essential usage. It could go further by explaining what the return format is (a point pair) or how the optional 'screen' parameter scopes element search, but it 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 100%, so the schema already documents all five parameters including the direction enum. The prose adds a small clarification of the direction values, but otherwise repeats what the schema provides. Baseline 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?

States a specific verb+resource ('Transform coordinates between local and global space relative to a named element') and immediately distinguishes the two modes with the direction enum values. No sibling tool covers coordinate transformation, so 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?

Explicitly tells the agent when to use each direction: 'to_local to convert scene coords to element-local, to_global to convert element-local to scene coords.' This is clear context, though it doesn't address edge cases like what happens if the element isn't found or whether the 'screen' parameter changes behavior.

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 return structure (node names, buildErrors[]) and error payload shape, but does not state whether the parse is side-effect-free (read-only), whether it runs the builder or just statically validates, or how runtime failures are triggered during a 'parse' 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?

Three sentences, each adding information about the return artifact; no filler. Slightly dense but well front-loaded with the action first and the diagnostics detail after.

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 validation tool with no output schema, the description explains what is returned (node names and structured errors), which is the key missing piece. It could be improved by stating side-effect behavior, but it is nearly complete for the task complexity.

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

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

Schema coverage is 100% and the single parameter 'source' is documented in the schema. The description implies source is .manim code but adds no format, size, or encoding details beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Parse and validate a .manim source snippet'), clearly distinguishing it from siblings like get_errors or inspect_programmable. An agent knows immediately this tool takes raw source and returns validation diagnostics.

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 description (validate source before building), but no explicit when-to-use / when-not-to-use guidance or alternatives are named. Given the many sibling tools, some routing guidance would help, but the purpose is clear enough for an agent to infer correct usage.

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 usefully discloses that results are hit-tested against real coordinates and returned sorted front-to-back by depth, which is genuine behavioral context. However, it does not state the read-only nature, permissions, empty-result behavior, or connection requirements.

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

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

A single sentence with no waste. The action ('hit-test a screen position') is front-loaded and the depth-ordering detail is appended efficiently.

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

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

For a simple parameterized read tool with no output schema, the description tells the agent what is queried and how results are ordered. Minor gaps remain (behavior on a miss, whether relative_to affects returned ordering), but nothing critical is missing.

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

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

Schema description coverage is 100%, so x, y, and relative_to are already documented in the schema; the description adds no format or unit detail beyond what is there and does not mention the relative_to local-space option at all. Baseline 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?

States a specific verb ('hit-test') and resource ('scene graph objects at the given coordinates'), and even specifies the result ordering (front-to-back by depth). This is readily distinguishable from siblings like inspect_element or scene_graph, which operate on named elements or the whole tree.

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?

Use is implied by the description — you call it when you have coordinates and want to know what is there — but there is no explicit guidance on when to prefer this over siblings such as coordinate_transform, inspect_element, or scene_graph, and no prerequisites are stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape and error codes ('not_found', 'internal'), but it does not say whether command ops mutate state, require permissions, or are idempotent, which matters for an arbitrary game-op invoker.

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 tight sentences cover purpose, discovery, and return/error behavior in a front-loaded order. Every sentence earns its place with no 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 generic game-op dispatcher, the description gives a usable return shape, error codes, and a discovery path. It stops short of safety/side-effect disclosure that would be valuable for commands when no annotations or output schema exist.

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

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

Schema coverage is 100%, and both parameters already have descriptions in the schema. The description reinforces that op values come from list_game_ops and that param shapes are discoverable there, but it adds no syntax or format detail beyond what the schema provides.

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

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

The description states a specific verb and resource: invoke a game-specific custom query or command registered by the running game. It also distinguishes this tool from the discovery sibling by pointing to list_game_ops. An agent can tell this is the execution/dispatch tool, not the discovery tool.

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

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

It explicitly says to use list_game_ops to discover available ops and their param shapes, giving clear context and naming an alternative. However, it does not specify when not to use this tool or how it relates to other command/event siblings beyond discovery.

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

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

With no annotations, the description carries the full burden and does well: it discloses the hit shape, that paused=true means the game is paused, and the exact resume path via pause({paused:false}). It omits buffer-size or polling-frequency behavior, so it stops short of 5.

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

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

Well front-loaded, starting with the action and resource before detailing hit fields, cursor semantics, and the pause interaction. Dense but every sentence carries information; the hit-field enumeration is borderline but justified since there is no output schema.

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

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

With no output schema, the description compensates by spelling out the returned hit fields and the cursor workflow. Combined with the fully documented params and the pause/resume dependency, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so clear/limit/since_id are already documented. The description reinforces since_id as a cursor but adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb ('Poll') and resource ('recent hits from DevBridge.debugger() calls') and clarifies the mechanism (JS-debugger-style breakpoint). This clearly distinguishes it from siblings like get_traces, get_errors, and get_game_events.

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?

Explains cursor usage ('Use since_id from a previous call to get only new hits') and notes the streaming alternative (SSE 'debugger' events), which routes the agent between polling and real-time. It does not explicitly state when not to use this tool, keeping it short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose the accumulation/cursor semantic ('accumulated ... since last query'). However, it omits the most consequential behavior: reading drains the buffer by default (the 'clear' default is only visible in the schema), plus any return format or error-shape details.

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

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

A single tight sentence with the scope constraint ('since last query') front-loaded and 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 one-optional-parameter read tool with no output schema, the description plus schema cover what an agent needs to invoke it. The drain-on-read behavior is documented on the parameter itself, which is the natural place for it.

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

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

Schema description coverage is 100%, so the single 'clear' parameter is already fully documented in the schema, including its default of true. The description adds no syntax or format meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('get accumulated runtime errors/exceptions') and pins the scope with 'since last query'. It does not distinguish itself from sibling diagnostics tools like get_traces, get_debugger_hits, or get_game_events, so an agent has no basis for choosing among 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. The only hint is the implied debugging context of 'runtime errors/exceptions', which the agent must infer.

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 useful behavior: events originate from Haxe-side emitEvent calls, they coexist with an SSE channel, and the cursor mirrors get_debugger_hits. However, it omits buffer/retention behavior, the destructive effect of `clear`, and any return shape for event objects.

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 tightly packed sentences that are front-loaded with the purpose, then the alternative channel, then the cursor usage. No filler, though the parenthetical emitEvent signature and the get_debugger_hits reference make it slightly dense.

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 4-param tool with no output schema and no annotations, the description covers purpose, source, and pagination, but does not describe what a returned game event looks like (id/name/data) or the side effect of the `clear` flag, leaving an agent to infer the response shape.

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

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

Schema description coverage is 100%, so all four parameters are already documented (clear, limit, types, since_id). The description only reinforces since_id cursor usage and adds no new semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb (poll/get) and resource (custom game events emitted via DevBridge.emitEvent(name, data)), and clarifies it complements the real-time SSE 'game_event' channel. An agent can tell it retrieves buffered user-defined game events, though it does not directly distinguish itself from siblings like get_debugger_hits or send_event beyond the cursor-pattern mention.

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?

Provides clear operational context: use since_id from the previous response to fetch only new events, and notes that events also arrive in real time as SSE notifications, hinting at when polling is appropriate. It references get_debugger_hits as a pattern, but states no explicit when-not-to-use or prerequisites.

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 behavioral burden. It conveys only that values are read from a live instance; it says nothing about permissions, whether the instance must be idle/running, or whether the read has side effects, which matters alongside siblings like wait_for_idle and pause.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though terse enough that it leaves real questions unanswered rather than being maximally informative.

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 and no annotations, the description partially compensates by naming what comes back ('values and definitions'). However, it omits structure of that return and any behavioral constraints, so an agent still lacks a full picture for a getter over a live runtime object.

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 required parameter 'programmable' is fully documented in the schema as 'Programmable name' (100% coverage). The description adds no syntax, naming, or lookup detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a specific verb ('Get') and resource ('current parameter values and definitions') scoped to 'a live programmable instance'. An agent can distinguish it from a definition-only or write-oriented tool, though it never explicitly contrasts itself with the sibling set_parameter.

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 'for a live programmable instance' hints at the required context but gives no explicit when-to-use, when-not-to-use, or prerequisites. The obvious alternative, set_parameter, is never mentioned, leaving the read-vs-write choice 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 supplied, so the description carries the full burden. 'Get ... state' reasonably implies a read-only, side-effect-free inspection, and the enumerated fields tell the agent what it will learn, but it does not confirm the operation is non-mutating, note cost, or say whether state is captured live or cached.

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

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

A single front-loaded sentence naming the verb and resource first, with the return contents listed as a compact colon-delimited clause. No filler, no restatement of the name.

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

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

With no output schema, the description must communicate the return shape, and it does so by enumerating the five state facets. With zero parameters and a simple read operation, that is nearly sufficient; only the live-vs-cached nature of the state remains unspecified.

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, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly adds no misleading parameter talk.

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 ('Get') and resource ('screen manager state'), then enumerates the exact facets returned: mode, active screens, transition status, pause state, element/interactive counts. It implicitly separates itself from list_screens (which enumerates screens) by focusing on aggregate state, though it never names a sibling explicitly.

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

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

There is no guidance on when to call this versus list_screens, scene_graph, or get_tween_state, and no stated preconditions such as requiring an active connection. The agent must infer the diagnostic use case from the field list alone.

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 does disclose a useful behavioral detail (the 200-line ring buffer bound), which gives an agent the size limit of available data. However, it says nothing about permissions, whether the buffer retains or discards older lines, or the return shape beyond the buffer claim.

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

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

A single well-formed sentence with the resource front-loaded and the buffer-bound detail appended where it is useful. No filler 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?

It is a low-complexity read tool with two optional, fully documented parameters, and the description adequately covers what it returns (trace lines, capped at 200). Only the absence of any routing versus sibling debug tools keeps it from a 5.

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

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

Schema description coverage is 100%, so both the 'clear' and 'limit' parameters are already fully documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (trace() output) and clarifies the return as a ring buffer of the last 200 lines. It is clear what the tool does, but it never distinguishes itself from similar inspection siblings like get_errors or get_debugger_hits.

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 'from the running application' implies a debugging/live-inspection context, but there is no explicit when-to-use, when-not-to-use, or alternative named among the many debug siblings. Usage is left 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?

With no annotations, the description carries the full behavioral burden, but it does disclose the shape of the returned data (targets, duration, elapsed time, progress). It does not state that this is a side-effect-free read, nor mention rate limits or behavior when no tweens are active.

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

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

A single front-loaded sentence that names the verb, the resource, and the payload with no filler 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?

There is no output schema and no annotations, so the description must stand alone. It enumerates the key returned fields, which is sufficient for a zero-parameter read tool, though it omits any indication of return format or empty-result behavior.

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, so the baseline is 4; there is nothing in the schema that the description needs to clarify. The quoted fields in the description describe outputs, not inputs, which is helpful but not a parameter concern.

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 ('Get all active tweens/animations') and enumerates the returned data points. It is clearly distinguishable from siblings like get_screen_state or list_active_programmables, though it does not explicitly name or contrast with any sibling.

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

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

The description gives no guidance on when to call this versus alternatives (e.g., get_screen_state, list_active_programmables, wait_for_idle) and no preconditions. Usage is only implied by the word 'active', so an agent must infer the debugging/inspection 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?

No annotations are provided, so the description carries the full behavioral burden. It reveals the read-only nature implicitly ('get info') but says nothing about permissions, error behavior when the element doesn't exist, throttling, or side effects. For a tool with zero annotation coverage this is a notable gap, though the read nature is at least implied.

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

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

A single, front-loaded sentence with no filler. The parenthetical clearly enumerates the returned fields, keeping the definition tight and informative.

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 a simple 2-parameter read tool with no output schema and no annotations, the description covers what is returned reasonably well. However, it omits failure modes (element not found), whether screen must be active, and any connection prerequisites, which an agent would need for reliable 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 coverage is 100%, so both parameters are fully documented by the schema. The description mentions the element being 'named' on a screen, reinforcing the schema's element name presence requirement. It does not add syntax or format details beyond schema, so baseline 3–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?

States a specific verb (inspect/get detailed info) and resource (named element on a screen), and enumerates what is returned (position, size, visibility, text content). This clearly distinguishes it from siblings like find_element_at (locates by position) or get_screen_state (whole screen).

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 naming the input as 'a named element on a screen', but gives no explicit when-to-use or when-to-prefer-alternatives guidance, nor does it mention prerequisites such as requiring an active connection or that the element must be visible.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the target must be 'live' (a running/connected programmable) and enumerates the returned data, but it says nothing about read-only behavior, what happens if the programmable does not exist, or error handling.

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

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

A single front-loaded sentence that names the action first and the inspected content after; the colon-separated list is dense but every item is informative and there is no filler.

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

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

No output schema exists, so the description's enumeration of retrieved fields carries the return-value load and does it well. It is slightly incomplete in not clarifying whether the programmable must be listed as active first (list_active_programmables) or what a failed lookup returns.

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?

Only one parameter ('programmable'), and the schema already documents it at 100% coverage as the 'Programmable name'. The description adds no format, naming, or qualification details beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('inspect') and resource ('programmable'), then enumerates exactly what is retrieved: parameter values, slots, dynamic refs, named elements, interactives, settings. This distinguishes it from the point-list siblings (list_slots, get_parameters, list_interactives), though that contrast is implied rather than named.

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 'deep inspection of a live programmable' implies the tool is for getting a comprehensive snapshot of a running programmable, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative (e.g. get_parameters or list_slots for narrow reads) is 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, the description carries the full burden and does disclose the returned payload contents (parameter values, definitions, named elements, slots, interactive counts, position, visibility), which is useful. However it omits the read-only/side-effect profile, ordering, or scope caveats beyond the incremental:true filter.

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 tight sentences, front-loaded with the scope and purpose, followed by return contents and the tracking constraint. No redundant or filler text.

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

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

With no output schema, enumerating what each entry contains (values, definitions, elements, slots, counts, position, visibility) compensates well for the missing return spec. Minor gaps remain around defaults for sceneGraph/depth, but the core call context is complete.

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

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

Schema description coverage is 100%, so depth, sceneGraph, and programmable are fully documented in the schema itself. The description adds no parameter-level detail (e.g., how 'programmable' filtering interacts with the incremental-only scope), so the baseline 3 applies.

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

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

States a specific verb+resource ('List all live incremental-mode programmables') and adds the scoping constraint that only incremental:true programmables are tracked, which meaningfully distinguishes it from inspect_programmable and list_interactives. It stops short of explicitly naming the sibling tools it differs from.

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 'Only programmables built with incremental:true are tracked' clause implies the context in which this tool is relevant, but there is no explicit when-to-use guidance or contrast with siblings like inspect_programmable (single-item) or list_interactives.

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 behavioral burden. It states it lists loaded atlases, but doesn't disclose read-only nature, whether it includes metadata, ordering, or failure modes when no atlases are loaded.

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

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

A single, tight sentence with no filler, front-loading the verb and resource.

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 no-arg, read-only list tool with no annotations and no output schema, the description is minimally adequate but lacks details about return contents (e.g., structure, tile vs sprite distinction) and behavioral traits.

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?

Zero parameters, so the baseline is 4. The description correctly indicates no filtering parameters are involved, matching the empty 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?

States a specific verb (list) and resource (loaded sprite atlases) plus what is returned (tile/sprite names). It is clearly distinguishable from siblings like list_fonts or list_resources by naming the exact resource type.

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 saying 'loaded sprite atlases', which suggests it's for inspection, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. With many sibling 'list_*' tools, no routing is 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 burden of behavioral disclosure. It states that it lists all loaded builders with their names and parameter definitions, which implies a read-only operation, but it does not disclose side effects, permissions, or return format details. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that is efficient and contains no unnecessary 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?

Given the tool is a simple list operation with no parameters, no output schema, and no annotations, the description provides the essential information. However, it could benefit from indicating usage context relative to siblings.

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 parameter semantics are not applicable. The baseline for no parameters is 4.

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

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

States a specific verb (List) and resource (.manim builders), and clarifies the return content (programmable names and parameter definitions). An agent can distinguish this from siblings like list_fonts or inspect_programmable.

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 does not indicate when to use this tool versus alternatives such as inspect_programmable or get_parameters. There is no explicit guidance on context or 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, the description carries the full burden. It conveys that this is a non-mutating enumeration of 'registered' fonts, which sets a safe expectation, but says nothing about ordering, whether it includes unregistered/unavailable fonts, or rate/size limits for the returned list.

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

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

A single front-loaded sentence with no filler or redundancy. Every word contributes to identifying the resource and its scope.

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 list tool with no output schema and no annotations, the description is nearly sufficient: the implied return is a set of font names usable in .manim files. It could be strengthened by stating the return shape (names as strings) or whether the list is environment-dependent, but nothing critical is missing.

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

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

The tool takes zero parameters, so the schema has nothing to document; the baseline of 4 applies. The description correctly signals the no-argument, enumerate-all nature of the call, leaving no parameter ambiguity.

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 (List) and resource (registered font names) plus scope (available for use in .manim files). The resource is clearly distinct from siblings like list_atlases and list_screens, though it never names those siblings explicitly.

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

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

The phrase 'available for use in .manim files' implies the context in which the result matters, but there is no explicit when-to-use guidance, no prerequisites, and no pointer to an alternative way of discovering fonts.

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, and it does well: it discloses the return object's top-level keys (queries, commands, events), the per-entry fields, and the schema-lite hint format (e.g. {lane: "int", count: "int?"}). It does not mention cost, caching, or whether the registry can change mid-session, so a small gap remains.

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 tightly packed sentences: purpose first, then return contract, then the call-order guidance. Every sentence earns its place and the most actionable instruction ('call this first') is retained.

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 and zero params, the description must explain what comes back, and it does so at the right level of detail (top-level keys, entry fields, hint syntax) while also positioning the tool in the discovery workflow. Nothing needed to call 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?

The tool takes zero input parameters, so there are no parameter semantics to explain; baseline is 4. The description's param-like detail pertains to returned payload shapes, which is useful but not input 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?

States a specific verb+resource ('List game-specific custom operations registered by the running game') and goes further by describing the exact return shape. It is clearly distinguishable from sibling listers like list_fonts, list_screens, and list_active_programmables, and it names its natural follow-up 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?

Explicitly says to call this first to discover what the game exposes, then routes to game_op for invoking queries/commands or get_game_events for polling events. This is a complete when-to-use plus alternatives statement with nothing left 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?

With no annotations, the description carries the full behavioral burden. It does disclose the return content (IDs, positions, metadata), which is valuable given the absent output schema, but says nothing about read-only safety, ordering, inclusion of hidden/inactive regions, or error behavior.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though the brevity leaves little room for the usage context an agent would want.

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, optional-parameter, read-only list tool this is close to adequate, and the return-field summary partly compensates for the missing output schema. However, the absence of annotations and any sibling routing leaves meaningful gaps for an agent choosing among the many list_* tools.

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

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

Schema coverage is 100% and the single 'screen' parameter is fully documented in the schema, including the aggregate-from-all-screens fallback. The description adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description gives a specific verb ('List') and a precise resource ('registered interactive hit-test regions') plus the returned fields, which is clearly distinct from siblings like list_fonts or list_screens. It does not explicitly name a sibling it is not, so it stops short of the top mark.

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 call this versus adjacent tools such as find_element_at, inspect_element, or check_overlaps, nor any stated prerequisites. Usage must be inferred entirely from the tool name.

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 the content of the listing (sprite sheets, fonts, .manim, .anim files), which is the key behavioral fact for a read-only enumerator, but it says nothing about ordering, whether results reflect an instant snapshot, or how load state is determined.

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

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

A single front-loaded clause with the resource categories immediately after the colon. No filler, no redundancy, every token contributes to identifying what is returned.

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, read-only listing with no output schema, the description covers the essential question of what will come back by naming the resource classes. It is only slightly short of complete because it omits any relationship to the more specific list_* siblings.

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, so per the baseline there is nothing for the description to disambiguate. No parameter-level explanation is needed or expected.

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 (List) and resource (loaded resources) and enumerates what counts as a resource: sprite sheets, fonts, .manim and .anim files. This distinguishes it from narrow siblings like list_fonts and list_atlases by scope, though it doesn't explicitly say it is the superset of 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 when-to-use guidance or explicit routing to alternatives. With siblings list_fonts and list_atlases present, an agent must infer whether this overlaps with or supersedes them; the description never says to prefer those for narrower queries.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that statuses are returned, but does not disclose read-only nature, side effects, ordering, pagination, permissions, or output shape.

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 states the action, resource, scope, and returned status efficiently.

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

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

For a zero-parameter read-only list tool, the description covers the essential output content (screens and active/failed status). It lacks richer return details such as ordering or pagination, but no annotations or output schema are available to carry that 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 tool has zero parameters, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and no additional parameter context 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 gives a specific verb ('List'), resource ('screens'), and scope ('all registered screens') plus returned status. It is clear against most siblings, but it does not explicitly differentiate itself from closely related tools like get_screen_state.

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 such as get_screen_state or list_active_programmables. Usage is only implied by the resource name, with no exclusions or 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the return semantics ('occupied/empty status'), which is real behavioral information beyond a bare list, but says nothing about ordering, permissions, or pagination 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?

One sentence, front-loaded with the verb and resource, with the clarifying parenthetical and status detail packed in without waste.

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 one-parameter read tool with no output schema and no annotations, the description tells the agent what it lists and what status information comes back. Sufficient, though ordering/format of the result is left unspecified.

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

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

Schema description coverage is 100% for the single 'programmable' parameter, so the schema already documents it. The phrase 'on a programmable' merely echoes the parameter without adding format or syntax detail; baseline 3 applies.

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

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

States a specific verb (List) and resource (slots), and helpfully parenthesizes what slots are ('swappable containers') plus the scope ('on a programmable'). It is clearly distinguishable from list_fonts/list_atlases, though it does not explicitly name a sibling it differs from.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternative tools to consider. Usage is only implied by the name and the 'on a programmable' scoping.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains that game logic, animations, and rendering stop while the DevBridge remains responsive, which is exactly the kind of state-effect information an agent needs, though it omits return/error behavior.

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

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

The description is three tight sentences, front-loaded with the core action, followed by the behavioral effect and then the alternative. Every sentence adds useful information with no waste.

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 one-parameter state toggle, the definition covers purpose, effect, and the main alternative well. It lacks any note on return values or confirmation behavior, but the schema fully covers the only parameter.

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

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

Schema coverage is 100%, and the schema already documents the paused boolean with its default. The description restates pause/resume but adds no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: pause or resume the game loop. It also distinguishes from the sibling step() by naming it as the way to advance while paused, so the agent can tell the two apart.

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 usage context: pause for inspection while DevBridge remains responsive, and use step() to advance frame-by-frame while paused. It does not explicitly state when not to use pause, so it falls short of the highest tier.

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 behavioral burden. 'Get' implies a read, but the description says nothing about whether this is non-mutating, whether it requires a connected/running session, or how expensive the call is; it only enumerates returned fields, which is closer to output documentation than 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?

A single compact sentence with no filler, and the metric list is front-loaded. It is appropriately sized for a simple getter, though the list format could be marginally tightened.

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 diagnostic getter with no output schema, the description usefully enumerates the returned metrics, which is the main thing an agent needs. It lacks any note on the return format or when the data is unavailable, but it is largely complete for this tool's complexity.

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, so there are no parameter semantics to document; the baseline for a 0-param tool is 4. The empty schema is consistent with the description, which implies a no-argument fetch.

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 gives a specific verb ('Get') and enumerates the exact metrics returned (FPS, draw calls, triangle count, object count, scene dimensions), which rescues the vague tool name 'performance'. It is reasonably distinguishable from siblings like get_screen_state or scene_graph, though it does not explicitly name how it differs from 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?

There is no guidance on when to call this tool versus alternatives such as screenshot, scene_graph, or get_screen_state, nor any stated preconditions. The agent must infer usage purely from the metric list.

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 disclosure burden. It states the return payload ('uptime and port') and characterizes the operation as lightweight, implicitly non-destructive. It stops short of explicitly confirming read-only safety or error behavior, but for a no-param health check this is reasonably 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?

Two short sentences, zero waste, front-loaded with the core purpose and followed by the routing hint. Every clause earns its place.

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

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

With no output schema, the description must disclose return values, and it does ('uptime and port'). Combined with the routing guidance, this is complete enough for an agent to call it correctly; only finer output-format details are absent, which is minor for a ping.

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, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly adds no parameter noise.

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+resource ('Health check') and names exactly what it returns ('uptime and port'). It explicitly differentiates itself from the sibling tool 'performance' by positioning itself as a lightweight alternative, so an agent can distinguish the two without opening either schema.

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

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

Names the alternative tool ('performance') and the condition that selects this one ('connection testing', 'lightweight'). It lacks an explicit when-not-to-use statement, but the routing guidance is clear enough for correct selection.

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. 'Cleanly' hints at a graceful shutdown, but it does not say whether the action is irreversible, whether state is saved, or whether the connection is severed afterwards — critical for a terminal 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?

A single, front-loaded sentence with no filler or redundancy; every word earns its place.

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

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

For a zero-param tool no output schema is required, but as a destructive/terminal action with no annotations the description should say what happens after shutdown and whether it can be undone. It is minimally adequate but leaves meaningful gaps.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing further for the description to document.

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 ('shut down') and resource ('the running game application'), which is unambiguous. It does not, however, distinguish itself from siblings like 'pause' or 'reload', so the agent must infer the difference between a transient pause and a full termination.

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

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

The description gives no guidance on when to use this tool versus 'pause', 'step', or 'reload', nor any prerequisites such as requiring an active connection. Usage is only implied by the word 'quit'.

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 usefully discloses failure semantics by enumerating the errors[] fields and errorType values, which is genuine added context. However, it says nothing about success behavior, permissions, or what state changes, leaving the write/mutation profile undeclared.

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 and scope. The error-detail sentence is dense but earns its place by documenting the failure contract. No filler.

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

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

No output schema and no annotations mean the description must carry more. It covers the parameter and error shape reasonably, but omits success return values and the nature of the reload side effects, leaving gaps for a mutation-style tool.

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

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

Schema description coverage is 100% and the single 'file' parameter is already documented in the schema, including the 'omit to reload all' behavior that the description largely restates. No additional syntax or format detail is added, so baseline 3 applies.

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

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

States a specific verb ('Hot-reload') and resource ('.manim file'), with scope clarified by 'or all files if no file specified'. It is distinguishable from siblings like eval_manim or list_builders, though it does not explicitly name a sibling to contrast against.

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 reload versus alternatives such as eval_manim, nor any preconditions or exclusions. The only 'when' signal is the implicit default of reloading all changed files when no file is given.

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 burden; 'Dump' weakly implies a read-only snapshot but never states it. It does disclose the content of the traversal (types, positions, visibility, names), which is useful, but omits whether traversal is truncated, how large output can get, 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?

A single front-loaded sentence with zero filler; the resource comes first and the output contents are listed compactly.

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-optional-parameter inspection tool with no output schema, naming the fields included in the dump largely covers what an agent needs. The remaining gaps are behavioral (snapshot timing, size, read-only guarantee) rather than structural.

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

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

Schema description coverage is 100% and the single optional 'depth' parameter is fully documented with its default in the schema. The description adds nothing about depth semantics, so the baseline 3 applies.

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

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

States a specific verb ('Dump') and resource ('scene graph tree') and enumerates the payload (object types, positions, visibility, names). It is distinguishable from visual siblings like screenshot, though it never explicitly names an alternative.

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 indication of when to prefer this over screenshot, inspect_element, list_interactives, or get_screen_state. The agent must infer the debugging/inspection scenario entirely on its own.

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 burden. It mentions the output format (PNG) but doesn't disclose behavioral traits like whether it's a read-only operation, performance implications, whether it blocks, or error conditions beyond aspect ratio mismatch. A screenshot tool could have significant side effects (e.g., freezing the app), which aren't mentioned.

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 purpose, then parameter behavior. Every sentence is informative and no waste.

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 no-annotation, no-output-schema tool with 2 parameters, the description covers the essentials but leaves gaps: no mention of read-only nature, error handling beyond aspect ratio, or performance. It's adequate but not rich.

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

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

Schema coverage is 100%, so the schema already documents width and height semantics. The description adds marginal value by explaining aspect-ratio behavior and error conditions, but the schema already covers this. Baseline for high coverage is 3, but the explicit error condition adds a bit.

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: capture the current frame as a PNG. It's clear what the tool does, though it doesn't differentiate from sibling tools like list_screens (which likely just lists screens without capturing). The scope (current frame) is precise.

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 scaling, but doesn't say when to use this versus alternatives like get_screen_state or list_screens. No explicit when/when-not guidance is provided, only conditional behavior for parameters.

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 behavioral disclosure burden. It states that an event is injected, but does not cover side effects, whether the input is queued or synchronous, required application state, error behavior, or what the tool returns. For an input-injection mutation tool, this is a notable 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 front-loaded with a clear one-sentence purpose followed by a well-organized bullet list of event types. Every bullet adds useful parameter semantics or event behavior, and there is no filler.

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

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

There is no output schema or annotation coverage, so the description must carry the burden for a 7-parameter tool. It adequately explains event types and parameter usage, but omits when to choose this tool over siblings like send_events and click_button, and lacks behavioral context for safe invocation.

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

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

The input schema itself has 100% parameter description coverage, setting a baseline of 3. The description adds meaningful event-type-specific parameter mappings, such as click using x,y,button; key_down using keyCode; text using charCode; and wheel using delta. It also lists common key codes, which supplements the schema's hxd.Key reference.

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: 'Inject an input event into the running application.' It also enumerates supported event types, making the tool's scope clear. It does not differentiate from the similar sibling send_events or click_button, 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 explains what each event type does but gives no explicit guidance on when to use this tool versus alternatives like send_events, click_button, or other input-related siblings. It also omits prerequisites such as whether the application must be connected or focused before injection.

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, and it does well: it discloses the pause requirement, what frame steps actually do (process animations, state machines, zone detection), and the auto-pause/resume side effect of auto_pause. It omits failure modes (e.g., what happens if frame steps are used while unpaused) and any notion of return values.

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?

Front-loaded purpose sentence, then structured bullet list of entry types, then the pause/auto_pause caveat, then a worked example. Every element earns its place, though the example is somewhat long and the 'same params as send_event' cross-reference is doing work the text could state directly.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers the essential contract: input shape, ordering semantics, pause prerequisite, and a usage example. It leaves return-value behavior and error conditions unspecified, which is a gap given no output schema exists to fill it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it enumerates the two entry shapes ({type,x,y,...} vs {step:N}) that the schema only gestures at with 'event objects and frame steps,' and explains what a step does mechanically. auto_pause's semantics are also echoed usefully.

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+resource ('send a sequence of input events with game frame steps') and immediately frames the scope that separates it from send_event (singular) and step: multi-step interactions in one call. The concrete use cases (drag-and-drop, slider scrub, card hand drag) 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?

Clear about when this tool is needed (multi-step interactions) and states an operational prerequisite: the game must be paused for frame steps, with auto_pause:true as the remedy. It implies the sibling send_event for single events via 'same params as send_event' but never explicitly says 'use send_event instead for a single event,' so it falls short of full alternative routing.

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. It mentions 'incremental mode' and the target is a 'live' result, hinting at mutation and possibly triggering re-evaluation, but doesn't disclose side effects, reversibility, or performance implications. The behavior is only partially 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?

Single sentence with front-loaded action and parenthetical note about mode. No wasted words, though it could be slightly more structured by stating prerequisites upfront.

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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after setting the parameter, whether it triggers an update, or what 'incremental mode' entails, leaving gaps for an agent to invoke 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 coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameter formats or constraints, which is acceptable given the high coverage.

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

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

States a specific verb (Set) and resource (parameter on a live programmable BuilderResult), which is clear. However, it does not differentiate from the sibling get_parameters, which likely retrieves parameters, so the 'set vs get' distinction is implied rather than named.

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 when-to-use guidance or alternatives are given. The description says 'on a live programmable' but doesn't state prerequisites like whether the programmable must be connected or paused, and it doesn't mention get_parameters for reading values.

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, yet it discloses nothing about whether this is idempotent, what happens if the screen or element does not exist, or whether the change requires the scene to be running. 'Toggle' is also slightly misleading since the parameter sets an explicit boolean rather than flipping state.

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

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

A single, front-loaded sentence with no wasted words. It is efficient, though its brevity comes at the cost of detail rather than being a model of concise-yet-complete writing.

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 3-parameter mutation tool with full schema coverage and no output schema, the description is minimally adequate. It omits failure behavior and any note on what state the target must be in, which matters more here because there are no annotations to fall back on.

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

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

Schema description coverage is 100%, so the schema already documents screen, element, and visible. The description adds no syntax, naming conventions, or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description names a specific verb and resource: setting the visibility of a named element on a screen, with the scope (element + screen) matching the required parameters. It does not differentiate itself from siblings like click_button or inspect_element, but 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?

There is no when-to-use guidance, no prerequisites (e.g., does the screen need to be active?), and no mention of alternatives such as interaction tools that might also affect visibility. The agent must infer all usage 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 carries the full burden and discloses the core behavior: advancing frames and then re-pausing. It also states the required initial state. It omits error handling if the game is not paused or if the frame count exceeds the maximum, but for a simple state-advancing tool this is reasonably 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?

Two sentences, front-loaded with the core action and immediately followed by the essential precondition. No redundant or wasted wording.

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 or annotations, the description covers purpose, precondition, and postcondition adequately. It could mention what happens on invalid input or the return value, but these are minor gaps given the tool's simplicity.

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

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

The input schema has 100% description coverage for the 'frames' parameter, including default and max values. The description only restates 'N frames' without adding syntax or format details, so it does not go beyond the schema and the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Advance') and resource ('the game by N frames') with clear scope ('while paused, then re-pause'). It implicitly distinguishes itself from sibling tools like 'pause' (which only pauses) and 'wait_for_idle' (which waits for idle) by describing a unique frame-stepping behavior.

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

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

It states a clear precondition ('Game must be paused first'), which tells the agent when the tool is applicable. However, it does not explicitly name alternatives or exclusions, so it falls short of a full when/when-not 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 carries the full behavioral burden. It does disclose the critical trait that the call is non-blocking and returns current state, and defines what 'idle' means, but it never specifies the return shape (boolean vs. state object) or whether repeated polling is expected.

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 tight sentences with zero waste. The purpose and its defining criteria come first, and the non-blocking clarification follows where it is most needed to counter the tool name.

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

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

For a simple no-arg read tool this is nearly complete: purpose, idle criteria, and non-blocking semantics are all covered. The one gap is the unspecified return format, which matters more here because there is no output schema to fall back on.

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, so there is nothing to document and the baseline is 4. No parameter-level guidance is required or missing.

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

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

States a specific verb (Check) plus resource (system idle state) and defines the exact criteria for 'idle' (no active tweens, no screen transitions). This scoping lets an agent distinguish it from siblings like get_tween_state and get_screen_state, which report only one component of idleness.

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 corrects the misleading name by clarifying the call does not block, which is useful context, but it never states when to use this versus polling get_tween_state/get_screen_state or any alternative. Usage is only implied.

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