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

With no annotations, the description carries full burden, and it does disclose the exact deterministic transformation with no side effects implied. It does not state what happens with non-numeric or missing input, but as a pure math transform the behavioral profile is essentially 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?

One sentence, front-loaded with the purpose, with the mapping appended as compact clarification. Zero 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?

An output schema exists, so return values need not be explained, and the description fully specifies the transform. For a 3-parameter pure conversion tool, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and the formula (AC x = Bx, AC y = Bz, AC z = -By) effectively documents each input as a Blender-space component and its mapping. It does not restate that x/y/z are numbers, but that is clear from the schema types and formula.

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 (convert) and both resources (Blender coordinates to AC world coordinates), and even gives the exact mapping. It is trivially distinguishable from all sibling tools, which are state/camera/session operations.

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 input/output framing makes the trigger obvious: use it when you have Blender-space coordinates and need AC-space ones. No alternatives or exclusions are named, but for a pure coordinate transform there are no meaningful siblings to distinguish from.

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 two useful behavioral facts — 'hold' implies the pose persists, and 'fov: 0 = keep' defines a no-op default — but it never says whether entering free camera overrides an active camera mode, whether it is reversible, or whether the call takes effect immediately.

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

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

Three short clauses, each adding information (position, yaw/pitch conventions, fov sentinel), with the primary action front-loaded. Slightly dense run-on formatting but no wasted sentences.

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 six-parameter camera mutation with no annotations and no output schema, the description covers angle and fov semantics adequately but omits units for position, interaction with camera modes, and the effect/return of the call. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate and it partially does: it defines yaw degrees with concrete compass mapping, pitch sign, and the fov sentinel value. It leaves x/y/z as bare world coordinates with no units, scale, or reference origin, so three of six parameters remain semantically thin.

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 ('Hold the camera at AC world position') with the coordinate system named. It is distinguishable from a targeted-camera sibling only implicitly (explicit yaw/pitch angles rather than a look-at target), so it falls short of outright sibling differentiation.

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

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

No guidance on when to use this versus ac_camera_look_at or ac_camera_mode, both of which set camera orientation in a different way. The angle conventions clarify how to call it, but not when to choose it.

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

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

No annotations exist, so the description carries the full burden. 'Hold the camera' hints that the setting persists, but the description doesn't say whether this switches camera mode away from free/mode, whether it is reversible, what happens on subsequent frames, or that `fov` is left unchanged when omitted.

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 dense sentence, front-loaded with the core action and no filler. Its brevity comes at the cost of omitting `fov`, but nothing is 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?

A three-parameter tool with no annotations, no output schema, and 0% schema coverage needs more from the description than a single sentence. The `fov` parameter and the relationship to the other camera tools (`ac_camera_free`, `ac_camera_mode`) are unaddressed.

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

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

Schema coverage is 0%, so the description must compensate, and it does partially: it explains that `pos` and `target` are [x, y, z] triples in AC world coordinates. However, the third parameter `fov` is never mentioned in either the description or schema, leaving its meaning (and the `0` default) opaque.

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 action: place the camera at `pos` and orient it toward `target`. That distinguishes it from `ac_camera_free` and `ac_camera_mode` by implication, though it never names those siblings or contrasts with them 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?

No when-to-use or when-not-to-use guidance. An agent must infer from the tool name alone whether this is a one-shot reposition, a persistent mode, or how it interacts with `ac_camera_free` / `ac_camera_mode`.

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 meaningful side effect, that the currently held camera is released, which is real context beyond a bare mode setter. It says nothing about what happens with an invalid mode string, whether the simulator must be running, or whether the change is immediate or requires a rendering tick.

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 that front-loads the action and then enumerates values; the hotkey hints are short and genuinely useful rather than 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?

For a one-parameter command tool with no annotations and no output schema, the description covers the action and the complete value domain, which is the critical information. It stops short of describing the response or failure behavior, which would be worth a clause given there is no output schema.

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

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

Schema coverage is 0% with no enum on 'mode', so the description must supply the value domain, and it does: free, cockpit, chase, chase2, bonnet, car, track, release, with parenthetical notes for free (F7), car (F6) and track (replay cams). It omits case sensitivity and whether an unknown value errors or is ignored, which keeps it below a 5.

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

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

States a specific action (release held camera and switch AC camera) plus the full set of accepted modes, so the resource and operation are unmistakable. It implicitly differentiates from siblings like ac_camera_free by folding 'free' and 'release' into this tool's mode vocabulary, though no sibling is named directly.

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?

'release' is annotated as 'only let go of the held camera', which hints at the choice between full mode switching and merely dropping the held camera. However, there is no explicit guidance on when to use this versus ac_camera_free, ac_camera_look_at, or the F6/F7 hotkeys directly, and no preconditions 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?

No annotations exist, so the description carries the full burden: 'live state' implies a passive read with no mutation, and the field list documents what is returned. It does not explicitly state that nothing is modified, whether the call blocks or how expensive the read is, or how fresh the data is beyond the word 'live'.

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, and the payload fields are listed compactly. The fragmentary phrasing ('Live state from the bridge: ...') is dense but slightly telegraphic, which costs it a point.

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 sensibly enumerates the returned fields, and a no-arg getter needs little more. What's missing is the read-only guarantee and any freshness or cost note, minor for a state-read but relevant given there are no annotations.

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 for the description to disambiguate; baseline 4 applies. The description adds no confusion about arguments.

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?

It states a specific resource ('live state from the bridge') and enumerates exactly which fields come back (camera mode/position/look/fov, car speed, time of year, fps), so an agent knows what it gets. It never distinguishes itself from the sibling ac_status, which plausibly returns a different kind of status, leaving the boundary implicit.

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

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

There is no statement of when to call this versus ac_status, ac_camera_mode, ac_set_time, or any other sibling, and no mention of polling or freshness expectations. The word 'live' weakly hints at reading current runtime state, but selection guidance is essentially 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 takes on the whole burden and does well: it discloses that race.ini is written (after backup), that video.ini is temporarily modified and restored by ac_quit, that acs.exe is spawned, and that it blocks on a bridge heartbeat before pressing Drive. It leaves the timeout parameter and failure behavior unexplained, so not a 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?

Dense and front-loaded: the main action comes first, then side effects, then parameter caveats. No filler sentences, though the parenthetical stacking makes it slightly hard to parse at a glance.

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 9-parameter mutation tool with no annotations and no output schema, the description covers the launch sequence and the two config-file side effects but omits the return value, what timeout controls, and what start_session toggles. Adequate but with clear gaps for a tool this consequential.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It explains hour (08..18 range), window_width/window_height (>0 switches to a windowed screen of that size), and implicitly track via 'offline practice session'. It says nothing about car, skin, layout, start_session, or timeout, leaving roughly half the surface undocumented.

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

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

States a specific verb and resource ('Start an offline practice session') and then describes the concrete mechanics: writing a temporary race.ini, launching acs.exe, waiting for the bridge heartbeat, pressing Drive. It also differentiates from the sibling ac_set_time for any non-08..18 time.

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 routes the agent away for one case ('use ac_set_time for any time/date'), which is a real alternative with a clear condition. However, it gives no guidance on when NOT to launch (e.g. whether a prior ac_launch/ac_quit cycle must complete first) or on preconditions like the config state.

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 two important behaviors — only the FIRST matching mesh is read, and which properties are returned by default. It omits what happens when no mesh matches the filter (error vs. empty result) and never states the operation is side-effect free, leaving meaningful gaps for a mutation-adjacent runtime tool.

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

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

Two compact sentences, front-loaded with the core action and scope, followed by the default return set. Nothing is wasted and the filter example is placed exactly where it is needed.

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 2-parameter tool with no output schema and no annotations, the description covers purpose, selection scope, and default return fields. It still lacks failure/no-match behavior and the semantics of the properties argument, which are the two things an agent must know to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It handles 'filter' well with the 'material:MyMat' example identifying the CSP filter syntax, but the 'properties' parameter is only indirectly referenced via 'Default properties' — it never says that passing properties overrides that default list or what form values take.

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+resource ('Read material properties at runtime') and defines the selection scope precisely: the first mesh matching a CSP mesh filter. It implicitly contrasts with the sibling ac_material_set (write) but never names it, so differentiation is inferable rather than explicit.

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 'at runtime' and the filter example, but there is no explicit statement of when to prefer this over ac_material_set or ac_get_state, and no prerequisite/conditions described. An agent can infer purpose but is given no routing 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 burden and does disclose the crucial trait: nothing is written to disk and the change is lost on restart — behavior an agent cannot safely assume. It stops short of describing error handling for invalid property names or whether an existing override is replaced or merged.

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, front-loaded with the persistence caveat and followed by the one concrete format hint that matters. No filler and nothing 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?

A mutation tool with no annotations, no output schema, and 0% schema coverage needs to define its parameters, and this one does not: an agent still cannot tell what 'filter' matches or which 'property' names are legal. The persistence caveat is excellent, but the calling contract is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains 'value' (1-4 numbers, with a ksEmissive example). 'filter' and 'property' — two of three required params — get no explanation of expected syntax or valid property names, leaving most of the call under-specified.

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: override a material property, at runtime. The transient scoping is clear and implicitly contrasts with the sibling ac_material_get, but the description never names that sibling or any other alternative, so differentiation is left to inference.

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

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

'at runtime only (lost on restart)' implies this is for temporary tweaks rather than persistent edits, which is a useful usage cue. However, there is no explicit when-to-use statement, no mention of pairing with ac_material_get to read back current values, and no warning about how to persist changes instead.

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 usefully discloses the shutdown sequence and the fallback to taskkill only if the bridge hangs, but it does not state whether quitting is destructive, what happens to unsaved state, or what permissions are required.

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 definition is a single compact sentence with the main action front-loaded and the fallback condition in parentheses. Every part contributes useful information 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?

For a quit/shutdown tool with no annotations, no output schema, and an undocumented parameter, the description covers the core sequence but leaves gaps around parameter effect, failure behavior, and destructive side effects. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by naming the specific config files restored (race.ini/video.ini), which gives meaning to restore_configs, but it never explains the boolean toggle or what happens when restore_configs is false.

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: 'Quit AC' plus backup restoration. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling tool ac_restore_configs, which likely handles restoration separately.

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 'Quit AC' and the mention of restoring backups, but there is no explicit guidance on when to use this versus ac_restore_configs or ac_launch. No conditions or exclusions 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 burden; it does disclose the operational precondition that AC must be stopped and the source of the data being restored, which is genuinely useful. However, it never says whether restoration overwrites current configs, whether it is reversible, or what happens if no backup is present — the main risk questions for a mutation tool remain unanswered.

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

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

Two short sentences with zero filler; the what (restore backed-up configs) is front-loaded and the precondition follows. Every clause 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 zero-parameter, no-output-schema, unannotated tool, the description covers what it does, where the data comes from, and the key precondition. It leaves only a small gap around failure modes (no backup available) and the effect on currently active configs.

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 no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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 (Restore) and resource (configs) plus provenance — configs backed up by ac_launch — which explicitly ties it to a named sibling and prevents confusion with ac_launch itself. The crash-recovery parenthetical makes the 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?

Gives an explicit precondition ('Only when AC is not running') and a triggering scenario ('after a crash'), which is exactly the kind of when-to-use context an agent needs. It stops short of naming the inverse tool (ac_launch) as the alternative or saying what to do if no backup exists, so not 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 behavioral burden. It usefully discloses the primary mechanism and the PowerShell fallback, plus what is returned. However, it omits permission requirements, whether the AC window must be foreground/visible, and side effects such as overwriting an existing file at `path`.

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 clauses, front-loaded with the action and mechanism, then the fallback and return value. 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, and the description does cover return values ('path and method used'), which is good. But for a 2-param tool with zero schema descriptions, leaving `hide_apps` unexplained and not addressing overwrite/permission behavior leaves gaps an agent would hit on first call.

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

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

Schema coverage is 0%, so the description must compensate. It adds real meaning for `path` by explaining the output format is inferred from the file extension, but `hide_apps` (a 2nd parameter with default true) is never mentioned, leaving half the surface undocumented.

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

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

States a specific verb and resource ('Save a screenshot') plus the mechanism (CSP ac.makeScreenshot). It is clearly distinguishable from siblings like ac_get_state or ac_status, which do not write image files.

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 (capturing the AC window) but gives no explicit when-to-use vs alternatives or prerequisites. The fallback behavior is stated, which implicitly tells the agent the tool may still succeed if the CSP path fails, but there is no guidance on when this is the right tool over others.

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 that the tool is offline-only, that it operates via ac.setWeatherExactUTC0Timestamp, and that freeze=True zeroes the time multiplier. It does not say what happens online, whether the change is reversible, or what a failure looks like.

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, followed by parameter notes. Little waste, though the parenthetical 'via ac.setWeatherExactUTC0Timestamp' is implementation detail an agent doesn't need.

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 6-parameter mutation tool with no annotations and no output schema, the description covers the key sentinels and the offline constraint but omits hour/minute semantics, valid ranges, and any statement of what the tool returns or how errors surface.

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

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

Schema coverage is 0% across 6 parameters, so the description must compensate. It explains the '0 = keep current date' sentinel for day/month/year and the freeze default behavior, which is genuinely valuable. But hour/minute have no stated format, unit, or range (24-hour? 0-59?), leaving the only required parameter under-specified.

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: 'Set track-local time and (optionally) date'. That is clear and distinct from the sibling tools (cameras, teleport, materials). It doesn't name a sibling to contrast with, so it stops short of 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?

'offline only' is a real gating condition that tells the agent when this will work. Beyond that there's no guidance on when to prefer this over other state-manipulation tools, no prerequisites, and no 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 burden of disclosure; it implies a read-only probe and enumerates the three result fields (camera, time, car), which is genuinely useful. However, it never says what happens when acs.exe is not running — whether the tool errors, returns a false flag, or times out — which is the key behavioral question for a health probe.

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 that front-loads the primary check and enumerates the secondary ones in a parenthetical. No filler, nothing that could be cut without losing 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 zero-param probe with no annotations and no output schema, the description does cover the returned fields, which is the main thing needed. It falls short on failure semantics and on how its output differs from ac_get_state, leaving an agent unsure which to call when checking game state.

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 parameter semantics are not a concern and the baseline of 4 applies. Nothing in the description conflicts with 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?

The description names three concrete checks: whether acs.exe is running, whether the bridge is alive with a session loaded, and the last heartbeat (camera, time, car). That is a specific, recognizable health-check rather than a tautology. It does not distinguish itself from the sibling ac_get_state, which an agent could easily confuse with a status query.

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 guidance on when to call this versus ac_get_state, ac_launch, or the camera/time siblings. The health-check intent is inferable but never stated, and no preconditions or follow-up actions are described.

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 two behaviors: the car is snapped to the track surface, and the call reports whether the move actually succeeded (an implicit failure mode). It omits larger behavioral questions – whether velocity/physics state is reset, whether a session must be active, and what happens on out-of-track coordinates.

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

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

Two short sentences with the action front-loaded and no filler; the parenthetical implementation reference and the return-value note both earn their place. The phrasing is slightly telegraphic ('aligned on the track surface'), which costs a point.

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 the description does cover the salient return semantics ('reports whether the car actually moved'), so the biggest gap is filled. Remaining gaps – coordinate frame and session prerequisites – are real but modest for a 4-parameter teleport call.

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

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

Schema coverage is 0%, so the description must compensate. It explains the non-obvious yaw convention ('yaw < 0 aligns to the AI spline', matching the default of -1), which is genuinely valuable, but leaves x/y/z undocumented – the coordinate frame (world vs track-relative) and whether y is overridden by surface alignment are left ambiguous.

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

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

States a concrete verb and target ('Move the player car') and even names the underlying call (physics.setCarPosition) plus the surface-alignment behavior. It is unambiguous and clearly distinct from the camera/state/config siblings, though it does not explicitly say how it relates to any 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?

Usage is only implied: an agent can infer this applies when a player car exists in a live session, but the description never states prerequisites (game running, car spawned), nor any when-not conditions. No alternatives are named, which is acceptable here since no sibling overlaps, but no positive guidance is given either.

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 does disclose key semantics: the config is CSP's parsed view with INCLUDEs merged (not the raw INI), and filtering is on the section name. It does not say whether output is section names only or key/value pairs, what limit does when exceeded, or whether the call has any 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?

Two sentences, front-loaded with what is returned, followed by the filter semantics and a motivating use case; the inline pattern example earns its place. Slightly dense phrasing but 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 and no annotations, so the description is the only source of truth. It conveys the general return content (parsed sections) but leaves the exact shape of a section, the meaning of 'values', and truncation behavior under 'limit' 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 coverage is 0%, so the description must compensate for all three parameters. It explains 'pattern' well (Lua pattern matched on section name, with an example), but 'values' is completely undefined even though it likely controls whether key/value content is returned, and 'limit' is left to inference.

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 concrete resource and scope: sections of the track's CSP config as CSP parsed it, with INCLUDEs merged. It does not name a verb, but the 'as CSP parsed it' qualifier and the filter example make the result clearly distinguishable from sibling tools like ac_material_get or ac_get_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?

One concrete use case is given: 'Useful to check whether an included INI was really loaded.' There is no guidance on when not to use it or which sibling to prefer for related config inspection (e.g. ac_restore_configs, ac_material_get), so the agent must infer the rest.

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