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 add genuinely useful behavior: "A color sensor over the tape reads its color name" tells the agent the tape is detectable during simulation runs. It does not disclose whether tape persists across resets, whether overlapping tape is allowed, or whether tape physically affects the robot, which are the mutation semantics an agent needs for a world-editing 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, purpose front-loaded, and the second sentence earns its place by explaining the observable effect of the tape. No filler or repetition of the title.

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 world-authoring tool with no annotations and no output schema, the description covers what it creates and how sensors perceive it, but omits persistence, overlap/limits, and any return information. Adequate to call the tool, not sufficient to predict its side effects.

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 83%, with x/y/angle/width/length all documented in-schema including defaults and ranges, so the baseline is 3. The description adds no parameter-level meaning of its own (no guidance on placement, orientation, or typical dimensions), so it neither compensates nor detracts.

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 resource ("Stick a strip of colored tape on the floor") and even names the consumers (color sensor, line following, camera), so the agent knows exactly what the tool creates. The add/remove pairing with sibling remove_color_tape is obvious from the names, but the description never explicitly contrasts the two, keeping it just 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 stated use cases (color sensor readings, line following, camera detection) imply when to reach for this tool, which gives usable context. However, there is no explicit when-to-use/when-not guidance, no mention of the removal counterpart, and no constraints on how much tape can be placed.

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 two non-obvious behaviors: validation failure on rover overlap and fallback to per-kind defaults for unspecified size and color. It omits persistence across reset_world, any object-count limits, or what the call returns.

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 dense sentences, each earning its place: purpose, kind-to-parameter mapping, and the refusal condition. Front-loaded and free of 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 an 8-parameter mutating tool with no annotations and no output schema, the description covers geometry and validation but says nothing about the created object's identity, lifetime, or how it is later targeted by remove_obstacle. Adequate but with a real gap for downstream operations.

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?

Coverage is already 75% and the schema documents each parameter's units and ranges. The description adds genuine value by mapping kinds to parameters (ball = radius r, wall = w × h rotated by angle°) and stating default behavior, but that pairing is only partially new information.

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?

Opens with a concrete verb+resource ('Place an object in the world') and states the intent (test sensors, collisions or the camera). It implicitly complements remove_obstacle but never names a sibling to distinguish itself 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?

Gives clear situational context (testing sensors, collisions, camera) plus a hard precondition: the call is refused if the object would overlap the rover. No explicit when-not or named alternatives, which keeps it below 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. It usefully discloses that unspecified fields default to type defaults (centre of body, facing forward), but it omits failure modes, duplicate-name behavior, enabled-state defaults, and what the call returns.

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 purpose and followed by the most important omitted-field behavior. No wasted text.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers defaults but leaves out prerequisites, side effects, and error behavior. It is minimally adequate but not 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 coverage is 71%, so the schema documents most parameters, but the description adds meaningful semantics for omitted fields by explaining their positional and angle defaults. It still doesn't clarify what each sensor type does or type-specific range defaults.

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 verb and resource, 'Install a new sensor on the rover body,' and the word 'new' distinguishes it from update_sensor and remove_sensor. It does not name those siblings explicitly, so it stops short of the top score.

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 update_sensor, remove_sensor, or list_sensors, and no prerequisites such as requiring an open simulator. Only the defaulting behavior 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value with the camera-module dependency and by spelling out the return payload (a 320×240 PNG and a JSON list with type, id, color, bearing_deg, distance_cm). It doesn't say what happens when the module is missing, but this is a strong addition over the annotations.

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 action, then the return format. The field list (bearing_deg, distance_cm) is dense but each item earns its place because there is no output schema. Slightly long, but not padded.

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 properly explains the return payload and per-object field meanings. The prerequisite is stated. What's missing is failure behavior when the camera module is absent and the image encoding (base64 vs. path), which an agent would need to use the result.

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 fov_deg parameter already documents its 40–100 range and 60° default. The description never mentions fov_deg, so it adds little meaning; baseline 3 applies when the schema carries the parameter 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?

The description states a specific verb and resource: 'Take a picture with the rover's forward-facing camera.' The phrase 'forward-facing' and 'camera module' distinguish this tool from the other sensor-reading sibling tools (read_sensors, get_observation) and from the display tools, so an agent can select it without opening the 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?

The parenthetical '(needs the camera module)' gives one useful prerequisite for calling the tool. However, the description never says when to use this tool versus read_sensors or get_observation, nor does it state what to do if the camera module is not installed. Usage is implied by the prerequisite but never routed.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description needn't repeat it. However, with no output schema present, the description carries the full burden of describing the return shape and it does not — an agent cannot tell whether a disconnected state is reported as a boolean, a status string, or an error, nor whether the check is passive or triggers a reconnect attempt.

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, appropriately sized for a parameterless status check.

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-input, read-only probe, the description covers what the tool does but not what an agent gets back or how to interpret it, and there is no output schema to compensate. That return-value gap is the one thing an agent needs to act on the result.

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 disambiguate and the baseline of 4 applies. The description correctly implies no input 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?

States a specific verb ('Report') and a specific resource ('whether the simulator page is connected to this MCP server'), so an agent knows exactly what the call answers. No sibling tool performs a connectivity check, so differentiation is implicit rather than stated, and 'connected' is left undefined (WebSocket open? page loaded? responding to pings?).

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 purpose: check link health before or after driving the simulator. There is no explicit guidance on when to call it versus alternatives such as open_simulator (which presumably establishes the connection) or how to act on a negative result, leaving the agent to infer the diagnostic workflow.

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 substantial work: it discloses the bubble capacity (~11 chars/line, 2 lines per bubble, extra bubbles follow) and the timing semantics — return to the big face after `seconds` or after all bubbles, whichever is longer. Missing only failure/truncation behavior for over-long or unsupported input.

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?

Action and target are front-loaded, and the parenthetical spec plus the timing sentence each add real information. It is dense but no sentence is filler; the only cost is a long single run-on that could be split for scanability.

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, non-destructive display tool with no output schema and no annotations, the description covers rendering, capacity, duration, and the auto-revert behavior — everything an agent needs to call it sensibly. Edge cases (empty text, text exceeding bubble count, invalid `seconds`) are the remaining gap.

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 50%: `seconds` is documented in the schema, but `text` has no schema description. The description compensates by explaining what `text` is rendered as, its Thai support, and effective line/bubble capacity, which is genuinely more useful than a type constraint. It stops short of explaining the interaction between the 200-char max and the bubble overflow behavior.

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 resource ("Make the rover 'say' a text on the Face Display module") and immediately qualifies the rendering mode (face with talking mouth, speech bubble), which distinguishes it from sibling display tools like set_display, draw_display, and read_display. An agent can tell what this does without opening the 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?

The rendering description implies when this tool fits (short, character-based announcements on the face display), but it never explicitly contrasts with set_display/draw_display or send_chat, nor does it state exclusions. Usage is inferable rather than 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 and does so well: it discloses the timed display window, auto-centring, automatic scale reduction if the image would not fit, per-character colour semantics, and that the result returns read_display showing actual output. It does not describe error behaviour for oversized/malformed rows or whether the call blocks for `seconds`.

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 dense paragraph with the primary action and timing front-loaded, then constraints by module type, then rendering rules. Every clause carries information, though the colour-letter enumeration is bulky and could be tightened without losing meaning.

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 5-parameter tool with a nested palette object and no output schema, the description covers what the tool does, how rows map to pixels and colours, module-specific behaviour, scaling and fit rules, and that the return is equivalent to read_display. An agent has everything needed 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 100%, but the description still adds substantial meaning beyond it: it explains the character-to-colour mapping, which characters are dark, that palette letters add or override colours, that `panel` only matters on the monochrome SSD1306, and how `scale` interacts with the module resolution. That is real semantic value layered on top of 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?

The description opens with a specific verb+resource+lifecycle: 'Show a picture on the Face Display module for `seconds`, then return to the face.' An agent immediately understands this is a multi-row pixel-art draw with a timed revert. It stops short of naming how it differs from nearby siblings like display_text or set_display, so the distinction is inferable rather than stated.

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 'one string per pixel row' and resolution constraints, and it points to read_display for module sizes. However, it never states when to prefer this over display_text, set_display, or display_text-like siblings, nor what happens when the picture exceeds the module. No explicit 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 only readOnlyHint=false and openWorldHint=false in annotations, the description carries the load and does so well: it discloses the side effects of disabling autopilot and starting the simulation, that the rover stops on collisions, concrete speed/turn rates, and that wait=true yields the post-move observation. These are exactly the behavioral facts an agent needs before mutating world 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?

Front-loaded with the core action and direction enum, then side effects, then timing math, then return behavior. Dense but every sentence carries operational value; nothing is redundant with the 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?

For a mutating, single-step motion tool with no output schema and minimal annotations, the description covers action, units, side effects, collision termination, and return semantics. Only the relationship to the sibling 'turn' tool is 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 67% (wait and seconds documented; direction is an enum without prose), and the description adds real semantics: 2 rad/s so 90 degrees takes about 0.8 s, forward at 65% of max (approx 61 px/s), backward approx 51 px/s, and what wait=true returns. That lets an agent choose 'seconds' intelligently rather than guess.

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 ('Move the rover') plus the direction set and that turns are in place, which separates it from generic motion. It never mentions the sibling tool 'turn', so an agent cannot tell from the description alone why it would pick one over the other.

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 provides implied usage context: turns autopilot off and starts the simulation, and wait=true returns the observation after the move. But there is no explicit when-to-use vs 'turn', 'run_program', or 'set_autopilot', and no guidance on when to set wait=false.

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?

The annotations say readOnlyHint=false and openWorldHint=false; the description is consistent with that by disclosing that the `board` parameter 'switches the board first,' which explains the non-read-only side effect. It also describes the returned contents, though it does not clarify default/current-board behavior when `board` is 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?

The description is front-loaded with 'Bill of materials' and most of the long first sentence is substantive detail about returned parts and fields. It is somewhat sprawling due to the long parenthetical and list, but it does not waste many words on irrelevant material.

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, so the description usefully enumerates the return contents: quantities, approximate THB prices, shop links when known, and a plain-text copy list. It also discloses the board-switching side effect. The main remaining gap is what happens when the optional `board` argument is not supplied.

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

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

With one optional enum parameter and 0% schema description coverage, the description carries the burden and does add meaning: `board` switches the board first, and the accepted values are 'esp32', 'uno', or 'raspberrypi'. It repeats the enum values but also explains the parameter's side effect; only the default behavior when omitted is left unstated.

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 identifies a specific resource, the rover's bill of materials, and enumerates its scope: board, motor driver, sensors, display, camera, head servo, chassis, battery, buck converter, resistors, level shifter, quantities, prices, shop links, and a copyable plain-text list. This is far more specific than a name/title restatement and clearly distinguishes it from generic manifest, sensor, or wiring 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?

It gives clear usage context by tying the tool to 'building the fitted rover body for real' and 'the parts tab on the Wiring page.' It does not explicitly name alternatives such as get_manifest or get_wiring, but the context is strong enough for an agent to know when this tool is appropriate.

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

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

The description explains the trait that matters most and that the annotations only hint at: the event buffer is drained on read ("since the last call ... then cleared"), which is exactly why readOnlyHint=false despite being a getter. It also discloses ordering (oldest first) and the exact record shape including the short/long enum and ms-epoch timestamp.

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, no filler, and the payload shape is stated compactly with an inline schema. The one weakness is ordering: the return structure comes before the purpose sentence, so the agent reads the format before learning why it should call the tool.

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

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

There is no output schema, so the description must carry the return contract — and it does, listing every field and its type. Combined with the polling/clearing semantics, an agent has everything needed to call and consume this tool 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?

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description instead spends its words on the return payload, which is the useful place for detail 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+resource: retrieves button press events since the last call, plus current held state. This is clearly distinguishable from the sibling press_button (which injects a press) and from get_observation/read_sensors, so an agent can select it without opening a 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?

"People press buttons in the simulator page; poll this to react to them" gives a clear use condition — polling to react to human input in the simulator. It stops short of naming an alternative or an exclusion (e.g., when not to poll, or how it relates to press_button), but the context is unambiguous.

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?

Beyond the annotations, the description discloses substantial behavior: it generates an Arduino sketch or Python script, returns { name, text }, and notes that `board` switches the board first. It also describes the generated firmware's runtime behavior and serial/stdin command protocol, which gives the agent rich context for what to expect.

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 purpose is front-loaded and there is no filler, but the description is a dense run-on with a long embedded command list. It is information-rich and mostly earns its length, though the structure could be easier to scan.

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, but the description supplies the return shape, board behavior, generated artifact variants, and runtime command protocol. For an agent invoking this tool, the key behavioral and output information is present.

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%, but the description compensates well for the single `board` parameter by mapping `esp32`/`uno` to an Arduino sketch, `raspberrypi` to a Python script, and noting that it switches the board first. It stops short of stating whether `board` is optional or what the default is when omitted.

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 resource and action: generating a complete robot program from the fitted body and wiring pin map, with concrete output filenames and board variants. It is clear what the tool produces, though it does not explicitly contrast itself with siblings like get_program or run_program.

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 phrase 'complete program for the real robot' and the board variants, but the description never explicitly says when to use this tool versus alternatives such as run_program or get_program, nor does it state 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload is the head module's live state fields, but says nothing about freshness/polling, whether values reflect the simulator's current tick, or what happens before a simulator is opened.

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 resource first and then the returned fields; no filler. It reads slightly like a schema dump rather than a purpose statement, which keeps it just short of a 5.

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

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

With no output schema, the description carries the return-value burden and does list the fields, including the mode enum values. It is not fully self-contained: 'tracking phase' is left undefined (no enum values) and units/ranges for angle_deg and brightness are not given, but an agent can still 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?

The tool takes zero parameters, which is the baseline-4 case; there are no arguments whose meaning needs elaboration. The description's field list describes outputs rather than inputs, which is appropriate 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?

The description names the resource (head module) and enumerates exactly what state is read: angle_deg, target_deg, mode with its legal values, tracking phase, and head light brightness. That is enough to distinguish it from the generic get_observation/read_sensors siblings, but it never uses an explicit verb ('Get'/'Read') nor names set_head as the mutating counterpart.

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: the tool is a status read for the head module, so an agent can infer it should call this before/after set_head. There is no explicit 'when to use this vs get_observation or read_sensors' guidance and no noted prerequisites or timing considerations.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing what the response contains (motors, modules, display), which partly substitutes for the missing output schema, but it says nothing about whether this is static configuration versus live state, or how it differs from live sensor reads.

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 short sentence with no filler, and the identifying spec ('ai-cartridge/body-v1') is front-loaded. The only weakness is that it reads as a label rather than a statement of behavior.

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 parameters and no output schema, the description is the only source of return-value information, and it only gestures at the contents without describing structure or what 'manifest' fields an agent will get back. Adequate to identify the tool, thin for deciding what to do with the result.

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.

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 resource ('Robot Capability Manifest (ai-cartridge/body-v1)') and enumerates its contents (motors, sensor modules, display), so an agent can infer it returns a static capability listing. However, it is a bare noun phrase with no verb, and it never contrasts itself with siblings like list_sensors or get_sensor_map that touch the same domain.

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 or when-not-to-use guidance and no named alternative. An agent must infer on its own whether this is the right call versus get_observation, read_sensors, or list_sensors.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that this is a full snapshot covering sim status as well as robot state, which is modestly useful context, but it says nothing about freshness/latency or whether sensors not enabled are omitted (it only implies 'every enabled sensor').

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 pose (the most commonly needed value), then velocity, sensors, display, and sim status. Every clause names a distinct returned field; nothing is wasted.

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, so the description must carry the return contract, and it does so reasonably completely for a snapshot getter. Minor gaps: the shape of individual sensor readings and whether large sensor sets make the response heavy are unstated.

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; baseline 4 applies. The description's field list is the return-value payload, not parameter 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 resource ('current robot pose ... velocity, sensor readings, face display state, simulation status'), so an agent knows exactly what comes back. It does not, however, distinguish itself from overlapping siblings such as read_sensors, connection_status, or get_head, which also expose parts of this 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?

No guidance on when to call this versus read_sensors (subset of sensor data) or connection_status (simulation status). The description only implies usage through the enumeration of returned fields, leaving the agent to infer 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?

readOnlyHint and openWorldHint are already declared, so the safety bar is low and the description earns credit for adding real behavior: the exact status vocabulary (idle, running, listening, done, stopped, error), the error object shape with line number, and the hard cap of the last 50 console lines. That cap is the kind of behavioral detail annotations cannot convey.

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 dense sentence, front-loaded with the resource and then the return fields. No filler and no repetition of what the title already says.

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, so the description must carry the return shape itself and does so completely: program code, enumerated status, structured error, and truncated console log. The one gap is behavior when no program has ever run, but for a zero-argument status reader this is nearly complete.

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

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

The tool takes zero parameters and the schema is empty, which is the baseline-4 case. Nothing about argument semantics is left ambiguous because there are no 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?

Names a specific resource (the rover program) and enumerates exactly what is returned: code, status, error, and console output. It is clear what the tool does, but it never contrasts itself with siblings like run_program, stop_program, or get_observation, so the agent must infer the boundary.

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 statement, no prerequisites, and no alternatives. The 'current/last' wording hints that it also works when nothing is running, but the agent gets no explicit signal about polling cadence or which sibling to prefer for program state versus observation data.

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?

Annotations set readOnlyHint=false and openWorldHint=false, and the description cooperates by disclosing that clear=true wipes the map first — the key destructive nuance the annotation alone does not convey. It also states the content is sensor-derived, not ground truth, which is important behavioral context; it stops short of describing response shape or size/pagination of the grid.

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 but front-loaded sentence: what it is, what it is not, the full legend, then contents, then the side-effect flag last. The parenthetical legend is information-dense rather than wasteful.

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, so the description carries the return-value burden and does so thoroughly — grid encoding, landmark coordinates, bumper points, pose, and stats — plus the one side effect. An agent can call this correctly without further information.

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

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

Schema coverage is 100%, so the boolean is already documented; the description nonetheless adds the consequence semantics ("wipes the map first"), which the schema's "Clear the map before returning it" only partly conveys. Nothing more is needed for a single optional flag.

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 precise picture of the resource: an occupancy grid the rover built from its own sensors, with a full ASCII legend, camera landmarks, bumper hits, pose, and stats. It explicitly contrasts itself with the true layout ("not the true layout"), which implicitly separates it from list_world/get_manifest, though it never names those siblings.

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: the phrase "not the true layout" hints that this is the choice when you want the rover's belief rather than ground truth, but no sibling (get_observation, read_sensors, list_world) is named and there are no stated when/when-not conditions.

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?

Annotations declare readOnlyHint=false, and the description explains why: `board` "switches the board first," disclosing a real side effect that an agent must know about before calling. It also goes beyond annotations by enumerating the diagnostics returned (pin conflicts, 5 V into 3.3 V pins, duplicate I²C addresses, ESP32 strapping/ADC2 pins) and the output formats produced. It stops short of saying whether the pin file is written to the project or merely returned.

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?

Content is front-loaded with the core output description before the board-switching detail, and nearly every clause adds information an agent needs. It is dense — two very long sentences with heavy parenthetical stacking — which slightly hurts scannability.

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 does the work of explaining return content: per-part pin destinations, rail power budgets, issue categories, and the pin-file artifact. The remaining ambiguity is whether that pin file is returned as text or written into the project, and how the board parameter interacts with an already-fitted body.

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 carries the burden, and it does: it spells out each enum value with concrete board identity (ESP32 DevKit V1, Arduino Uno R3, Raspberry Pi 4/5 40-pin header) plus the Pi-specific routing through an ADS1115 and CSI ribbon. It does not state what happens when `board` is omitted (presumably keep the current board), leaving the optional-parameter default implicit.

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 resource and its scope: the Wiring page for the fitted rover body, listing per-part pin mappings, rail power budget, detected issues, and a generated pin file. It is clearly distinct from siblings like get_bom, get_firmware, and get_sensor_map, which cover different artifacts.

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 rather than stated: an agent can infer this is the tool to call when it needs real-hardware wiring after building the rover, and the `board` clause signals it can be used to switch targets. But there is no explicit 'use this instead of X' routing against get_bom/get_firmware, and no statement of prerequisites such as whether a body must be fitted first.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact — that disabled sensors are included, so the result set is not filtered by state — but says nothing about ordering, size, or failure 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 that front-loads the resource and then the returned fields. No filler, nothing repeated from the 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 parameters, no output schema, and annotations covering the read-only nature, the description's field enumeration effectively stands in for a return-value spec. The remaining gap is the lack of differentiation from read_sensors/get_sensor_map in a crowded sensor-related sibling set.

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; the baseline is 4. The description correctly implies no filtering arguments exist.

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?

Names a specific resource (configured sensors) and enumerates the fields returned (id, type, mounting position, angle, range), and clarifies scope with 'enabled or not'. It does not explicitly distinguish itself from close siblings like read_sensors (live readings) or get_sensor_map, which an agent could easily confuse with a configuration listing.

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 statement and no named alternative. The parenthetical 'enabled or not' hints that this is a static/config enumeration rather than a live read, which is a weak implicit cue, but nothing tells the agent to prefer this over read_sensors or get_sensor_map.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Given there is no output schema, the description usefully discloses the returned fields (id, kind, shape, position, size, color), but says nothing about ordering, snapshot-vs-live semantics, or whether the list can be empty.

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, leading directly with the payload contents. The parenthetical field enumeration is dense but earns its place by substituting for the missing 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?

For a zero-parameter read tool with no output schema, the description adequately covers the return shape. The only gap is the lack of any hint about live-vs-static behavior or result ordering, which is minor for a layout dump.

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. The schema is fully self-describing (empty object) and the description correctly implies no input 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 names the resource (world layout) and enumerates exactly what is returned: size, light position, obstacles with their fields, and colored floor tapes. This is specific enough to distinguish it from mutators like move_light or add_obstacle, though it does not differentiate it from the read-oriented sibling get_observation.

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 alternatives such as get_observation, list_sensors, or read_sensors, all of which return overlapping world state. The agent must infer that this is the static-geometry snapshot rather than a live sensor reading.

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?

The annotations only declare idempotentHint=true. The description adds a useful behavioral constraint by stating that coordinates are clamped to 42–758 × 42–478, which is information beyond the annotation. However, it does not describe what happens when values are out of range beyond clamping, nor any return or failure 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 a single sentence with no wasted words. The action and coordinate clamp constraint are front-loaded and immediately useful.

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 two-parameter movement tool with an idempotent annotation and no output schema, the description provides enough context to call it correctly. Minor gaps remain around units and exact x/y-to-bound mapping, but the core behavior is covered.

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 carry the burden. It identifies the values as 'world coordinates' and provides the clamping ranges, which adds meaning beyond the bare numeric x/y schema. It still does not explicitly map each bound to x or y or specify units, so compensation is partial.

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: 'Move the light source to world coordinates'. It is clear what the tool does, though it does not explicitly differentiate itself from any sibling tool because none of the listed siblings appear to move the light source.

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 that this tool is used to reposition the light source, but it gives no explicit guidance about when to use it versus alternatives or any prerequisites. No when-not-to-use conditions are provided.

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

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

The description adds real behavioral context beyond the annotations: the call blocks, it waits up to 15 seconds, and its purpose is to establish connectivity to this MCP server. It stops short of saying what happens on timeout (error vs. false status) or whether the browser is left open, which matters given readOnlyHint=false.

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 the action first and the constraint (15 s wait) second. Nothing is redundant and nothing needs trimming.

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 parameters and no output schema, the description carries the full burden of describing the result, yet it never says what is returned on success or on timeout failure. For a blocking, connectivity-establishing call, the missing outcome semantics leave a real gap.

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; the baseline applies. The one tunable concept, the 15-second timeout, is noted as fixed rather than parameterized, which is consistent 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?

States a concrete verb and resource ('Open the AI Rover Studio page in the default browser') plus the scope of the wait, so the action is unambiguous. It does not reference the closest sibling (connection_status) to clarify when each is appropriate, leaving the routing 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?

Usage is only implied: an agent must infer that this is the launch step before querying connection_status or reading sensors. There is no explicit when-to-use, when-not-to-use, or named alternative, though the 'wait for it to connect' clause hints it is a bootstrap action.

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?

Annotations only say readOnlyHint=false and openWorldHint=false; the description goes well beyond by naming exactly what the press destroys or changes — toggling head light tracking, or stopping driving, autopilot and tracking while pausing the simulation. It also defines the long-press threshold (≥ 0.8 s) and states the return value (the press event). This is exactly the mutation-side context annotations cannot carry.

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 action, followed by the threshold and the resulting side effects. Every clause carries decision-relevant information; nothing is padding.

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 mutation tool with no output schema, the description covers the action, the threshold semantics, the side effects on the running program, and the fact that an event is returned. An agent has everything needed to call it safely.

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 to `seconds` by defining the ≥ 0.8 s long-press boundary — a semantic distinction the numeric 0.05–5 range does not convey. It does not say what the returned press event contains beyond its existence.

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 (press/release), the exact resource (a sensor of type "button"), and the mechanic (holds for `seconds`, like a person would). That is far more specific than the bare name. It stops short of naming siblings, so an agent must infer on its own how this relates to get_button_events (does the press generate events that tool can read?).

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?

Effectively tells the agent when to reach for this tool by describing the two built-in reactions: short press toggles light tracking (happy face), long press stops driving/autopilot/tracking and pauses the simulation. That makes the consequence of use clear. It does not state exclusions or point to alternatives (e.g. stop_program, set_head, get_button_events) for achieving the same outcome more directly.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: the exact payload contents and the rendering convention for the pixel dump (█▀▄, 2 pixel rows per line). It does not warn that a 128×64 dump is ~32 lines of 128 characters, which matters for context budget.

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 dense sentence, front-loaded with the verb and resource, then the return contents. Nothing redundant given annnotations already carry safety hints.

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 must carry the return-value burden, and it largely does by enumerating mode, text, stats and pixel rendering. The gap is the shape/magnitude of the ASCII art output and whether stats are cumulative or per-frame, which an agent budgeting context would want to know.

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?

There are zero parameters, so the baseline is 4 — there is nothing for the description to disambiguate. It correctly implies the tool takes no arguments by framing it as pure read-back.

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?

Specific verb (read back) plus specific resource (the Face Display module's current state), and it enumerates exactly what is returned: mode, text lines, stats, and GDDRAM pixels. This clearly separates it from the write-side siblings set_display / draw_display / display_text.

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 is the read-back/diagnostic counterpart to the display-writing tools. There is no explicit statement of when to call it (e.g., after set_display to verify) and no naming of alternatives.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by enumerating what each sensor entry carries (position, angle, range, unit) and by scoping to enabled sensors, which signals disabled ones are omitted. It does not say whether readings are cached or when they are sampled.

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 resource and scope, then the return fields. Nothing to trim.

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 input parameters and no output schema, the description carries the return-value burden and does so by listing the fields returned. Missing only edge behavior – what comes back with zero enabled sensors, ordering of entries, or whether a timestamp accompanies 'fresh'.

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. No syntax or format clarification is possible or needed; the description does not waste space restating an 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-resource pair ('read_sensors' → 'fresh readings from all enabled sensors') and tells the agent the payload includes mounting position, angle, range and unit. It never names a sibling, so the agent must infer the split from list_sensors/update_sensor, which keeps it out of the 5 tier.

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?

'Fresh readings from all enabled sensors' implies the use case (get current sensor values) and the scope (enabled only), but there is no explicit when-to-use, no exclusion, and no pointer to list_sensors for metadata-only lookups. Usage is inferable rather than 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?

The destructiveHint=true annotation already tells the agent this is a mutation, so the description should add what destruction means here — irreversibility, whether the tape's slot is freed, whether it affects overlapping obstacles. Instead it only restates 'remove ... by id', adding no behavioral context beyond the annotation.

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 short sentence with the key parameter and the lookup hint front-loaded, no filler. It is terse to the point of leaving gaps, but nothing in it is wasted.

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 destructive, no-output-schema tool the agent still lacks the essentials: confirmation/return behavior, reversibility, and what happens to the floor cell after removal. The lookup hint alone is not enough to call this safely and correctly.

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

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

Schema description coverage is 0%, so the description carries the burden for the single 'id' parameter. It does add real value by pointing to list_world as the source of valid ids, but it never states the id format or what happens on an invalid id.

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 ('Remove') and resource ('floor tape') plus the keying parameter ('by id'), which cleanly separates it from the sibling add_color_tape. It stops short of explicitly naming the inverse sibling, but the intent is unambiguous.

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

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

The parenthetical '(see list_world)' gives a concrete prerequisite for obtaining the id, which is useful implied guidance. However, there is no statement of when to use this versus other world-mutating siblings, nor any exclusions or preconditions.

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?

Annotations already declare destructiveHint=true, so the description's only job is to add context such as irreversibility, effect on the simulation state, or behavior on an unknown id — none of which is present. 'Remove an obstacle' essentially restates the name and title.

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 short, front-loaded clause with no filler. Its efficiency is close to ideal, though the brevity edges into under-specification rather than being optimally 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?

For a one-parameter destructive tool with annotations covering the safety signal and no output schema to explain, the definition is minimally adequate. It still leaves open what removal changes in the world and how invalid ids behave, which an agent calling a destructive operation would want to know.

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% and the parameter is a bare string, so the description must carry the burden. It usefully tells the agent the id is an obstacle identifier discoverable via list_world, but gives no format or validity details, so compensation is only partial.

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 ('Remove an obstacle') and scopes it to 'by id', which is enough to distinguish it from add_obstacle and remove_color_tape. It does not explicitly name the counterpart tool, so it stops just 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?

The parenthetical '(see list_world)' gives a concrete pointer for obtaining the id, which is real usage guidance. There is no statement of when not to use it, preconditions, or what a failed removal looks like, so the guidance remains implicit.

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?

destructiveHint=true already tells the agent this is irreversible, and 'uninstall' is consistent with that. But the description adds nothing beyond the annotation: it doesn't say whether removal is permanent, what happens to the sensor's data/state, or whether an attached sensor can be removed while the simulation is running. For a destructive tool the description should carry more of that burden.

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 short sentence with the resource and key front-loaded; nothing is redundant or padded. It is arguably too terse for a destructive operation, but on pure conciseness it earns a high mark.

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 no annotations cover side effects beyond the destructive flag, so the description should explain the effect of removal and the failure mode for an unknown id. Neither is present, which is a real gap for an uninstall operation.

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 supply meaning for the lone 'id' parameter. 'by id' does confirm that the single argument identifies the target sensor, but it does not specify the id format (name string? numeric handle?) or where the agent obtains a valid id. Marginal compensation at best.

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 ('uninstall') and resource ('sensor') plus the lookup key ('by id'), which is enough to distinguish it from add_sensor, update_sensor, and list_sensors. It stops short of explicitly contrasting itself with those siblings, so it lands at clear-but-undifferentiated.

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 remove versus update or re-add a sensor, no prerequisites (e.g., must the sensor be idle or disconnected first), and no mention of an alternative. The agent is left to infer all selection criteria from the name 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?

Annotations only declare idempotentHint, so the description carries most of the load and it does well: it discloses the destructive side effect (autopilot off) and yields exact post-state coordinates. It stops short of saying whether other world state (obstacles, tapes, running programs) is also cleared, which matters for a tool named 'reset_world'.

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 filler, with the resulting pose front-loaded and the side effect appended. Nothing could be removed 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?

A parameterless, no-output tool needs little more than target state plus side effects, both of which are present. The only real gap is scope: whether 'reset' extends beyond rover pose and light position to programs, tapes, or obstacles.

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 there is nothing for the description to disambiguate; baseline 4 applies. The coordinates given are hardcoded state, not inputs, and are correctly presented as such.

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 ('put back') plus the exact resources affected (rover, light) and the literal target values (120, 265, heading 0°; 690, 70). No sibling tool resets world pose, so an agent can identify this instantly without opening a 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?

Usage is only implied by the verb 'reset' – it never says when to prefer this over manually calling drive/turn/move_light, nor when a reset is undesirable (e.g. mid-program). The note that autopilot is turned off hints at one precondition but is not framed as 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?

Discloses the critical side effects beyond annotations: it 'replaces any running program and starts the simulation', returns immediately rather than blocking, and status/console must be retrieved via get_program. That is exactly the destructive-and-async context an agent needs and it is consistent with readOnlyHint=false.

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 with purpose and side effects before the reference dump, and the API list is grouped by concern (motion, readings, head, buttons, time, customisation) with terse notation. It is long, but nearly every token is load-bearing API signature; a slightly more scannable grouping would push it higher.

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-output-schema mutation tool it covers the essentials: what it does to the world, return-immediately semantics, and where to read status and console output. Missing are failure modes (syntax/runtime errors), the code length ceiling, and any concurrency/permission caveats.

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 `code` parameter is the entire payload, and the description effectively documents its contents by cataloguing the full `rover` API, including async-vs-sync distinctions and that top-level await works. Schema coverage is 0%, but the description compensates well; the only gap is that the 20000-char limit and error behavior are not mentioned.

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

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

States a specific verb and resource ('Run JavaScript on the robot with the `rover` library') and immediately anchors it to a known concept ('same as the Code page'). The API surface listed in the description makes clear this is the programmable-batch alternative to the granular movement/display siblings (drive, turn, set_head), so an agent can tell them apart without opening a 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?

It implies when to use it via 'same as the Code page' and tells the agent what to do afterwards ('poll get_program for status'), but never explicitly contrasts with siblings like drive, turn, stop_program, or set_head. An agent must infer that this is the batch/scripted route rather than the single-command route.

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 that messages are parsed offline (Thai/English) into rover commands and that a reply is returned and echoed in the chat panel, which is genuinely useful. It omits whether parsed commands actually mutate world state, what happens on unrecognized input, and whether there is any error or range feedback.

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 the action and target front-loaded, followed by the language/parser note and examples. Nothing is padded and no sentence 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?

For a one-parameter tool with no output schema, the description does state what comes back (the rover's reply) and where it appears. However, it leaves the execution semantics — whether the parsed command is actually carried out and how failures surface — unexplained, which matters because the examples are world-mutating actions.

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 one required string parameter, so the description must compensate, and it does: it names the supported languages and supplies three concrete example utterances showing expected phrasing. That adds real meaning beyond the bare string type, though it doesn't clarify whether commands must match a fixed vocabulary or free-form text is accepted.

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 (send a message to the in-page Agent Chat) and clarifies it is an offline Thai/English command parser, which is more than a restatement of the name. It does not explicitly contrast with direct-command siblings like drive, turn, or run_program, so the boundary with those tools is left 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?

Usage is implied rather than stated: the mention of an 'in-page Agent Chat' and natural-language examples suggests a conversational entry point, but there is no guidance on when to prefer this over drive/turn/run_program for the same actions. No exclusions or prerequisites are 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?

Annotations only declare idempotentHint, so the description carries the rest of the burden and does so with a genuinely useful disclosure: enabling as a side effect starts the simulation. It also characterizes the autopilot as rule-based, setting expectations for deterministic behavior. It does not say whether disabling autopilot also stops the simulation, which is the one remaining behavioral ambiguity.

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 action, with the important side effect in a tight parenthetical. Nothing redundant and nothing padded.

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-boolean toggle with only an idempotency annotation and no output schema, the description covers intent, effect, and the notable simulation-start side effect. The only gap is the inverse case — whether disabling halts the simulation or leaves it running.

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 carry the single boolean, and it does: 'Enable … or disable it' maps directly onto enabled=true/false. No further syntax or defaults are needed for a boolean flag.

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 pair (enable/disable) and a specific resource (the built-in rule-based autopilot), plus a one-line summary of what the autopilot actually does (seeks light, avoids obstacles). It is clearly distinct from siblings like set_simulation or drive, though it never names those alternatives 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 enable/disable framing implies the obvious usage, and 'also starts the simulation' hints at the relationship to the simulation lifecycle, but there is no explicit 'use this when…' guidance or warning about when not to use it (e.g. while manually driving).

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?

Annotations only declare idempotentHint=true. The description adds useful behavior: model resolutions/interfaces, adaptation of faces and text, colour-per-emotion on colour modules, and that it returns read_display. It does not disclose prerequisites such as connection/power state or side effects of swapping modules.

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 dense, front-loaded sentence that starts with the action and then enumerates the options. Every clause contributes model or behavior detail without 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?

With no output schema, the description usefully states that the tool returns read_display. It is complete enough to select a module and understand the display adaptation effects, though it omits operational prerequisites and side effects of switching hardware modules.

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 50%, and the undocumented model enum is fully compensated by the description, which explains each model's size, resolution, colour/monochrome type, interface, and default. The panel parameter is already described in the schema, and the description adds that it changes the SSD1306 glass colour.

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: fitting a different Face Display module. It enumerates all three model values, notes the default, and mentions the return sibling read_display, making the tool distinguishable from read_display and draw_display.

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 'Fit a different Face Display module' and the default is noted, but there is no explicit when-to-use guidance versus alternatives such as read_display, draw_display, or set_module. The agent can infer the context but is not routed explicitly.

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 and does a fair job: it discloses the display technology and dimensions, the text placement and overflow/scroll behavior, and critically the ~5 s hold before sensor-driven emotions resume. Gaps remain on what happens to a long message vs. the face, and whether the state can be cleared early.

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 no waste; the primary action leads, followed by rendering detail and then the temporal/state behavior that matters most for correct invocation.

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, no-annotation, no-output-schema tool, the description covers action, rendering, duration, and state restoration — enough to call it correctly. The message-placement inconsistency with the schema is the one thing an agent could still get wrong.

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 50% — the enum for 'emotion' is self-documenting and 'message' already has a schema description. The description adds rendering behavior for the message (top text line, scrolls if long), but this conflicts with the schema's 'Speech text shown under the face', leaving the agent unsure where the text actually renders.

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?

Specific verb and resource: 'Show an expression on the robot's face display', with the underlying hardware named (emulated SSD1306 128x64 OLED). It does not, however, distinguish itself from overlapping siblings such as set_display, display_text, or draw_display, which an agent could reasonably confuse it with.

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: 'Held ~5 s before sensor-driven emotions resume' suggests this is a transient manual override of automatic emotion behavior. There is no explicit statement of when to choose this over display_text or set_display, nor any exclusion.

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?

Adds substantial behavior beyond the annotations: it discloses the side effect of starting the simulation, that setting an angle switches the head to manual mode, the approx. 180°/s servo speed, and the full hill-climbing/rescan loop with the caveat that light sensors are directional and mounted on the head. This is exactly the context readOnlyHint=false alone cannot convey.

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?

Purpose and prerequisite are front-loaded, followed by the two parameter behaviors in the order they appear in the schema. The parentheticals are dense but every clause (speed, sign, rescan behavior) supplies information not available elsewhere.

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, no-output-schema tool with zero schema descriptions, the description covers everything needed to call it correctly in either mode, including the simulation-start side effect. The only gap is the default/empty-argument 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?

Schema coverage is 0%, so the description carries the full burden and does it well: it documents the −90…90° range, the (+ = right) sign convention, and the complete semantics of track_light. It omits defaults and the interaction when both parameters are passed, keeping it short of 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 verb and resource ("Control the Head module (pan servo)") and immediately distinguishes itself from get_head and set_module by naming the required prerequisite. An agent can tell this drives hardware rather than reads state without opening the 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?

Gives the prerequisite (set_module head first) and clearly separates the two usage modes: an explicit angle for manual positioning versus track_light=true for autonomous light-following. It does not say what happens when both or neither are supplied, and names no sibling alternative, so not a full 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?

Annotations only carry idempotentHint=true, yet the description adds real consequence context: it tells the agent that removing wheels makes the rover immobile and that the head module drives the pan servo for the face and light sensors. It does not say whether module changes take effect immediately, whether a running program is interrupted, or what errors occur when installing an already-installed module.

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 the verb pair and resource first, followed by the enumerated values, each with just enough gloss to be actionable. No filler 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 two-parameter mutation with no output schema, the description covers all valid inputs and their physical consequences, which is most of what an agent needs. It falls short only on side effects of toggling a module while a program is running and on what state to expect afterwards.

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 carry the load, and it does for the enum parameter by defining all four module values with their physical meaning. The boolean 'installed' parameter is only implied by the sentence structure (install vs remove) and is never explicitly mapped to true/false 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 pair (install/remove) against a specific resource (body module) and then enumerates the exact four valid modules with a gloss of what each one does. An agent can immediately distinguish this from siblings like set_head, set_display, or capture_camera, which manipulate parts of a module rather than installing/removing the module itself.

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 module glosses imply when you'd reach for this (e.g. 'without them the rover cannot move'), but there is no explicit when-to-use/when-not or named alternative such as 'to merely rotate the head, use set_head instead'. Usage is inferable from the enum rather than 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?

Beyond the idempotentHint annotation, the description usefully adds the maximum speed at 100% and the forward/backward drive scaling. However, it does not explain whether this overrides active drive commands, whether motion continues until changed, or how it relates to stop/emergency 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 two compact sentences with no wasted text. The core action and valid range are front-loaded, followed by useful speed context.

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 setter with no output schema, the description covers the essential action, valid range, and physical speed meaning. The main missing context is how this tool relates to sibling motion commands.

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 carry meaning. It does so by defining the unit as percent, specifying the 10–100 range, and tying 100% to 170 px/s, though it could clarify integer/decimal expectations or exact directional behavior.

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 and resource: 'Set motor power in percent.' It is clear what the tool does, but it does not explicitly distinguish this from sibling movement tools such as drive or turn.

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 use set_power versus drive, turn, stop, or other motion-related siblings. The percent range is stated, but that is parameter context rather than usage 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?

The annotations only declare idempotentHint=true; the description adds state-setting semantics consistent with that hint. However, it does not disclose whether pausing preserves simulation state, whether the simulator must already be open, or what side effects occur.

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 one compact sentence that front-loads both modes and maps the parameter value directly. 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?

For a one-parameter toggle with no output schema, the description covers the core invocation semantics well. It is slightly incomplete because it omits whether the simulator must be open and what happens to simulation state while paused.

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 boolean parameter has 0% schema description coverage, but the description fully defines its meaning: true starts and false pauses the simulation. No further parameter semantics are 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?

The description states a specific action (start/pause), resource (physics simulation), and the two modes controlled by the parameter. It clearly distinguishes this state toggle from siblings like open_simulator and stop.

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 provides the running=true/false mapping, which implies how to use the tool, but does not explain when to choose this over open_simulator, stop, or other simulation-control siblings. No preconditions 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?

Annotations only declare readOnlyHint=false and idempotentHint=true, so the description carries the burden of saying what the mutation touches, and it does: movement is cancelled, autopilot is switched off, and the simulation is paused. It does not say whether the paused state can be resumed or how autopilot gets re-enabled, which is the main remaining behavioral 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?

One sentence, front-loaded with the emergency framing followed by the concrete effects, 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 zero-parameter mutation with no output schema, the description covers the full scope of side effects. What is missing is lifecycle context: whether the simulation stays paused, and which sibling (open_simulator, set_autopilot, stop_program) resumes the stopped work.

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; the baseline for a no-param tool 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?

A specific verb (stop) with an enumerated effect list: cancel movement, turn autopilot off, pause the simulation. That tells an agent exactly what is affected. It does not distinguish itself from siblings such as stop_program or reset_world, so the agent can't tell from this text whether 'stop' is a superset of, or disjoint from, those tools.

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

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

The word 'Emergency' implies a usage context, but nothing states when to prefer this over stop_program or reset_world, nor whether it should be followed by any recovery step. Usage is implied rather than specified.

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?

Annotations already declare readOnlyHint=false and idempotentHint=true, so the mutating-but-safe profile is covered structurally; the description adds real value by naming the concrete effects (worker terminated, wheels stop). It does not say what happens when no program is running, though the idempotent hint largely covers that.

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 parenthetical-bearing sentence with zero waste, front-loading the action and following with the effect. Nothing could be removed 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-parameter control tool with no output schema and safety already covered by annotations, the definition supplies everything needed to invoke it correctly. The only residual gap, its relationship to the sibling 'stop', is a usage-routing concern scored elsewhere.

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. Schema coverage is reported at 100% with an empty properties object, so no gap exists.

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 ('stop the running rover program') plus the observable outcome, so the agent knows exactly what it does. It does not distinguish itself from the sibling tool 'stop', which reads as a near-synonym and could be confused with this one.

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 by 'running program' — the agent must infer it is the counterpart of run_program. There is no explicit when-to-use/when-not, and no routing guidance against the sibling 'stop', even though that ambiguity is the most likely selection error here.

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?

Beyond the annotations, the description discloses the approximate turn rate (≈115°/s), the absence of a 0.2 s minimum, and that the observation is returned. It does not describe blocking/obstacle behavior, but the key movement semantics are disclosed and do not contradict the annotations.

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, front-loaded with the primary action and sign convention, followed by the key behavioral distinction from drive. Every sentence 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 simple one-parameter turn tool, the description gives enough to call it correctly: units/sign, speed, exactness, and return behavior. Missing details about the returned observation payload or obstacle handling are minor given the schema and sibling 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It does so by defining the sign convention (+ right/clockwise, − left) and exact-angle intent for degrees, though it does not restate the schema's ±360 range.

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 ('Turn the rover in place'), states the exact-angle behavior, and gives the sign convention. It also distinguishes this from drive left/right, so an agent can identify the tool without opening the 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?

It explicitly names drive left/right as the alternative and explains the key condition for choosing turn: no 0.2 s minimum, so small corrections are exact. It does not fully spell out when to prefer drive for larger motions, but the relevant comparison is present.

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 for a mutation tool. It does not state whether unspecified fields are preserved (patch semantics) or reset, whether the change is reversible, whether certain fields are immutable per sensor type, or what errors arise from out-of-range/out-of-bounds values — all of which are the salient risks here.

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 the action front-loaded and the id-discovery hint trailing. The field enumeration overlaps what the schema already lists, which is the only wasted space.

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 an 8-parameter mutation with no annotations and no output schema, the description covers the what and where-to-get-ids but omits update semantics (partial vs. full), post-update behavior, and validation failure modes. Adequate to invoke, not adequate to invoke 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?

At 63% schema description coverage the schema already documents x, y, name, angle, range, and the type enum; the description's phrase 'mounting position' only loosely maps to x/y and adds no unit or constraint detail. Coverage is near the baseline threshold, so a 3 reflects marginal added value rather than compensation.

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?

Specific verb ('Change') plus resource ('a sensor') and an enumerated set of mutable fields, which separates it from add_sensor/remove_sensor by implication. It doesn't explicitly name the sibling tools it is not, 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 clause 'Use list_sensors to find ids' gives one concrete prerequisite for obtaining the required id, which is genuinely useful. However it says nothing about when to prefer this over remove_sensor+add_sensor, or what happens for sensors that don't support a field (e.g. range on a button).

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