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

With no annotations, the description carries the full burden, and it delivers: hardware vs sim getup differences, no-op semantics, timing ranges, busy-flag behavior, battery/health gating, and the quack exception. This is rich behavioral disclosure beyond a generic 'runs a behavior' statement.

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 dense sentences with no filler. The core action and enum list lead, followed by exception notes and monitoring guidance. Every clause adds actionable information, and the structure is easy to parse.

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 behavior tool, this is nearly complete: it defines all behavior outcomes, timing, and follow-up monitoring. The only gap is that it doesn't describe the tool's own return value (e.g., immediate acknowledgment vs completion status), which matters since there is no output schema.

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

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

Although schema coverage is 100%, the schema only says 'Which behavior to run.' The description adds critical per-enum semantics for getup, pickup, sit/stand no-ops, and the fact that quack is free. This substantially enriches parameter understanding beyond the enum names alone.

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 ('Trigger') and resource ('named built-in behavior'), then enumerates all seven behaviors. It distinguishes itself from duck_walk by saying it is battery/health-gated 'like walking' and from duck_monitor by instructing the agent to call it afterward.

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 operational context: sit/stand are no-ops in the same posture, scripted moves have a duration, and duck_monitor must be polled to see when 'busy' clears. It doesn't explicitly name when-not-to-use alternatives, but the behavior-vs-walk distinction is implied and the monitoring follow-up is explicit.

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 provided, the description carries the full burden. It explicitly discloses 'Read-only, never moves the robot,' the PNG output format, what each view means, and the divergent behavior across transports (sim, hardware, mock). This goes beyond typical tool descriptions and clearly sets expectations for the agent.

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 concise sentences that are front-loaded with the core purpose, followed by view details and then safety/availability. Every sentence carries necessary information, and there is no redundant filler or repetition of schema defaults.

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 small camera tool with no output schema, the description covers the key context: return type, view semantics, safety, and transport limitations. It leaves minor gaps such as exact behavior on unsupported transports or how the placeholder looks, but nothing critical is missing for an agent to invoke 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 low at 33%, and the description compensates well for the `view` parameter by explaining each enum value's meaning. However, `width` and `height` receive no semantic explanation beyond the schema's numeric bounds and defaults. The tool's output as an image makes them somewhat self-explanatory, but the description still leaves those parameters underspecified.

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 clearly states the tool returns a still frame as a PNG image, naming the resource (duck_camera) and the action. It also breaks down the view options, which distinguishes it from the sibling tool names that are all about version, health, updates, stop, monitoring, walking, and behavior.

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

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

The description provides clear context on when the tool is usable ('Available on the sim transport today', hardware not wired yet, mock returns placeholder) and explicitly says it is read-only. It does not explicitly name alternatives or when not to use it, but the siblings are clearly not camera alternatives, so the guidance is sufficient without 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?

No annotations are provided, so the description carries the full burden. It explicitly states the tool is read-only and always safe to call, and it discloses what data the report contains. This is sufficient for a non-mutating health check, though it could mention output formatting or frequency limits.

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 sentences with no filler. The first sentence front-loads the core purpose and contents; the second adds essential usage guidance. Every word earns its place.

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

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

For a zero-parameter, read-only tool with no output schema, the description is complete: it lists expected report contents, declares safety, and tells exactly when to call it. An agent has everything needed to select and invoke 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 has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning because there is nothing to pass. The schema and context signals fully cover this dimension.

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 clearly identifies a specific resource (full hardware+software health report) and enumerates its contents: battery, control-loop rate, temperatures, loaded policy, and self-health status. This makes the tool's purpose immediately distinguishable from siblings like duck_version or duck_walk without needing to inspect schemas.

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 explicit timing guidance: call FIRST in any session and again before motion sequences. It also notes the tool is always safe to call. It does not reference sibling alternatives or exclusion conditions, but the use context is clear enough for an agent.

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 provided, the description carries full burden and does well: it states 'Read-only and always safe to call', clarifies the gravity vector interpretation (including fall detection), and explains the safety flags. This gives an agent a clear picture of the tool's behavior and output semantics.

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 dense but every clause earns its place: it front-loads the core 'one frame' concept, lists the important fields, adds interpretation guidance, and closes with usage direction and a sibling reference. No filler words or redundant phrasing.

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 tool with no parameters and no output schema, the description must explain what the tool returns and when to use it. It does both thoroughly, including interpretation of potentially ambiguous fields (gravity, safety flags) and a clear relationship to duck_health. Nothing essential is missing.

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

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

The input schema has zero parameters, so there is nothing to document. The description adds no parameter details because none exist, matching the baseline of 4 for parameterless tools.

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 clearly states that this tool returns one robot.state frame and enumerates its contents (policy, velocity requested vs applied, joints, gravity, odometry, safety flags). It differentiates itself from duck_health by explicitly redirecting battery/temperature queries, making its purpose unambiguous.

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

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

The description gives concrete use cases: confirming a walk moved the robot and checking posture before/after a behavior. It also explicitly names an alternative (duck_health) for a different concern, establishing when not to use this tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly describes the action ('zero all motion intents'), immediacy, and operational guarantees. It does not detail potential side effects or return behavior, but for a stop command the core behavioral trait is well covered.

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 purposeful sentences. The critical action is front-loaded, followed by availability guarantees and explicit when-to-call guidance. Every word earns its place.

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

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

For a parameterless emergency-stop tool with no output schema, the description fully covers what it does, when to invoke it, and its availability guarantees. No additional context is needed for an agent to call this 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 has zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter-specific details, which is appropriate since there are none. 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 states a specific action and resource: 'Immediately zero all motion intents.' This clearly differentiates it from siblings like duck_walk or duck_behavior by establishing duck_stop as the inverse/emergency operation.

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?

Explicit usage conditions are provided: 'if anything looks wrong, if a human asks you to stop, or if you are unsure what the robot is doing.' It also sets availability expectations ('NEVER gated, never rate-limited'), which tells the agent this tool is always safe to call in emergencies.

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 explicitly discloses read-only behavior and clarifies that install/rollback is deliberately unavailable, which is valuable transparency. It does not mention rate limits or authentication, but for a simple read-only list tool these are less critical.

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 tightly written sentences with no fluff. The main purpose is front-loaded, followed by the read-only safety note and a pointer to the excluded functionality. 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 zero-parameter tool with no output schema, the description fully explains what the tool does and what it returns (installed releases and the active/golden one). The read-only and exclusion notes round out the context. Nothing essential is missing.

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

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

The tool has zero parameters and the schema coverage is trivially 100%. According to the rubric, 0 params earns a baseline of 4. There is no parameter meaning to add.

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

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

The description uses a specific verb ('List') and resource ('installed daemon releases'), and adds the distinct detail of identifying which release is active/golden. This clearly distinguishes it from the sibling tools, none of which mention release 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?

The read-only note and the explicit statement that installing/rolling back is not exposed give some usage context, but there is no explicit guidance on when to prefer this tool over alternatives like duck_version or duck_health. Usage is implied rather than spelled out.

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 provided, the description carries the full burden of behavioral disclosure. It explicitly says 'Read-only,' which is an important behavioral trait since it assures the agent the tool has no side effects, and it identifies the data source as configd system.info. It could additionally mention failure behavior or output format, but for a simple read-only identity tool this is largely sufficient.

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

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

The description is a single front-loaded sentence that immediately identifies what the tool provides, followed by the read-only qualifier. Every word earns its place and there is no fluff or redundancy.

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

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

For a no-parameter, read-only information tool, the description covers the essential content: what data is returned and that it is safe. The only minor limitation is that it does not describe output format or units for uptime, but the low complexity makes that gap acceptable.

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

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

The tool has zero parameters and the schema already covers 100% of the (nonexistent) parameter space, so the baseline of 4 applies. The description does not need to add parameter details, and none 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 clearly states the tool returns the robot's name, serial, and uptime, with the underlying source configd system.info. This is specific enough to distinguish it from siblings like duck_health and duck_updates, though it lacks an explicit verb such as 'returns' or 'gets' and does not directly name alternatives.

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 is given about when to use this tool versus its siblings. It merely says 'Read-only,' which implies safe usage, but it does not explain when to choose duck_versus over duck_health, duck_updates, or other sibling tools.

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 provided, the description carries the full burden and delivers: it discloses value clamping (±0.25 m/s linear, ±1 rad/s yaw), the fact that the call blocks until the walk finishes, the deadman safety mechanism that stops the duck if the server dies, and the battery/fallen refusal conditions. This is rich behavioral context well beyond what a schema could 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?

Every sentence in the description earns its place: the intent definition, the safety clamps, the timing behavior, the interruption and deadman guarantees, the follow-up monitor suggestion, and the refusal conditions. It is compact, well-ordered, and front-loads the core action before secondary details, with no redundant phrasing.

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 robot-motion tool with no output schema and no annotations, this description is remarkably complete: it explains blocking semantics, failure/refusal conditions, safety fallbacks, and where to get results afterward. An agent has everything needed to invoke it correctly and know what to expect, making the description self-sufficient.

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. The description adds value by stating the physical clamping limits for vx/vy/wz, which are absent from the schema itself, and by confirming the duration default and maximum in plain language. It doesn't add per-parameter syntax details, but the clamping information meaningfully supplements the schema, so 4 is appropriate.

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

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

The description opens with 'Send a velocity intent: vx forward m/s, vy sideways m/s, wz yaw rad/s' — a specific verb ('send'), a clear resource (the duck), and the exact axes of motion. It distinguishes itself from sibling tools by explicitly pointing to duck_stop for interrupting and duck_monitor for checking progress, so an agent can tell at a glance what this tool uniquely does.

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 explicit usage conditions, including when the tool is refused ('below 15% battery or when fallen'), the default and maximum duration, and direct guidance on alternatives: 'duck_stop interrupts it at any time' and 'Call duck_monitor afterwards to see how far it got.' This is clear when-to-use and when-not-to-use guidance that routes the agent to the correct sibling.

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