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 meaningful behavior: the result is a live MCP image result, nothing is written to disk by default, and cropping/annotation of defined regions is possible. It omits permission requirements, latency/blocking behavior, and what happens when the requested camera or region does not exist.

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?

Four short sentences, zero filler, with the usage directive and the return type front-loaded. The final sentence about cropping/annotating is slightly compressed but still 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 capture tool with no output schema and no annotations, the description covers the essentials an agent needs: what is produced, that it is not persisted, and that cropping/annotation are available. Missing error/failure semantics and sibling routing are the only real gaps.

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

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

Schema description coverage is 100%, so width, camera, format, region, and annotate are already documented in the schema, making 3 the baseline. The description adds only light cross-context for 'region' and 'annotate' (tying annotation to previously defined regions) and says nothing about the other three parameters.

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 ('Captures a live frame directly as an MCP image result') plus the intent ('visually inspect the hardware'), which is clearly distinct from siblings like capture_sequence or read_text. It does not name or contrast any sibling 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?

'Use this any time you need to visually inspect the hardware' is an explicit trigger condition, which is stronger than implied usage. However, no alternatives are offered: with siblings such as capture_sequence (multi-frame), read_text (text extraction), and measure present, the description never says when a different tool is the better choice.

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 valuably discloses the return shape (a single contact sheet with timestamps) and its token-efficiency, which matters since there is no output schema. It does not state whether the call blocks for the full duration, camera-access requirements, or limits beyond what the schema implies, leaving meaningful behavioral gaps.

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: what it does and what comes back first, then when to use it. Nothing is padded or redundant.

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

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

For a 4-parameter tool with full schema coverage and no output schema, the description supplies the missing piece — the shape and efficiency of the return value — plus usage scenarios. It is nearly complete; only blocking/duration behavior and camera prerequisites would add further value.

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

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

Schema description coverage is 100%, so fps, camera, region, and seconds are already documented with ranges and defaults in the schema. The description's 'over time' and 'with timestamps' hint at how seconds/fps combine, but adds no syntax or meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (captures) and resource (a sequence of frames over time) and describes the artifact produced (a token-efficient contact sheet with timestamps). It implicitly distinguishes itself from the sibling capture_image by emphasizing a sequence over time rather than a single frame, though it never names that sibling explicitly.

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

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

Gives clear use cases: observing physical motions, LED blink patterns, mechanical movements. This tells the agent what class of problem the tool fits. However, it offers no exclusions or explicit routing against capture_image, watch, or measure, which an agent choosing among 16 siblings would benefit from.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload (SSIM score, changed-pixel percentage, difference heatmap), which is genuinely useful, but it omits whether a fresh capture occurs, permission requirements, and whether the operation is read-only.

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 zero filler; the comparison operation is front-loaded and the return values follow immediately.

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

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

With no output schema, the description compensates well by enumerating what is returned. It remains slightly incomplete about prerequisites (baseline existence) and whether it triggers its own capture, but is largely sufficient for invocation.

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

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

Schema description coverage is 100%, so the schema already documents name, camera, and region. The description adds no format, defaulting, or scope detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb ('Compare') and resource ('current physical camera state against a saved baseline'), which clearly distinguishes it from the save_baseline sibling. It even previews the outputs, though it doesn't name the counterpart tool 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?

Usage is only implied: the mention of a 'saved baseline' suggests this follows save_baseline, but there is no explicit when-to-use guidance, no statement of prerequisites (e.g. a baseline must already exist), and no alternatives named.

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

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

With no annotations, the description carries the full behavioral burden. 'Save' implies persistence, but it does not disclose whether re-defining an existing name overwrites, errors, or versions; whether regions survive across sessions; or what permissions are required. Those are exactly the facts an agent needs before a mutating call.

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

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

A single front-loaded sentence that leads with the action and resource, then supplies coordinate conventions and examples. 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?

For a 7-parameter mutating tool with no annotations and no output schema, the description covers purpose and coordinate units but omits collision behavior, persistence scope, and whether the created region is returned. Adequate as a minimum viable definition, but not complete for a write tool of this complexity.

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

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

Schema coverage is already 100% (baseline 3), and the description adds genuinely new information the schema lacks: the normalized coordinate range (0.0 to 1.0). It stops short of clarifying pixel-space origin or how units interacts with x/y/w/h, so it is an increment rather than a full complement.

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 (define and save), the resource (a named region of interest), and concrete domain examples ('status_led', 'oled_screen', 'nozzle_area') that make the intent unmistakable. It also distinguishes itself from the sibling list_regions/delete_region by emphasizing creation and persistence, so an agent can tell it apart without opening 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 never says when to choose this tool over the nearby alternatives such as request_region_from_user or measure, nor does it state prerequisites (e.g. a bound camera, existing name collisions). It offers the normalized-vs-pixels choice but no guidance on which context calls for it.

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

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

With no annotations, the description carries the full behavioral burden. It implies a destructive mutation but does not state whether deletion is reversible, what permissions are required, or what happens if the region does not exist.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core action efficiently.

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

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

For a destructive tool with no annotations and no output schema, the description is too sparse. It does not cover error conditions, reversibility, or permission requirements, leaving significant gaps for safe invocation.

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

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

The schema has 100% description coverage for the single 'name' parameter, so the baseline is 3. The description does not add any meaning beyond what the schema already provides for that parameter.

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: 'Delete a saved named region.' It clearly distinguishes deletion from sibling operations like define_region and list_regions, though it does not explicitly name alternatives or explain the distinction.

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 action of deleting a saved named region, but there is no explicit guidance on when to use this tool versus alternatives such as define_region or request_region_from_user. No prerequisites or exclusions are mentioned.

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

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

With no annotations, the description carries the full disclosure burden and does meaningfully discharge it by listing the exact returned fields and the recommended call timing. It stops short of stating read-only/non-mutating behavior or any cost/latency characteristics, which would be the remaining gap for a zero-annotation 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?

Three short sentences, front-loaded with usage guidance and then the return contents. There is mild redundancy between 'any time you need to see the physical hardware,' 'Do not wait until the end of a task,' and 'Always call this first,' which slightly dilutes the emphasis.

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

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

With no output schema and no parameters, the description must explain returns, and it does so exhaustively; it also supplies call-timing guidance. Missing only error/edge-case behavior (e.g., what happens when the daemon is unreachable), a minor gap for such a simple read tool.

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

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

The tool takes no parameters, so the schema cannot document anything further; per the baseline for zero-parameter tools, the description is not required to compensate and a 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 states the resource (physical hardware status) and enumerates exactly what is returned: daemon version, uptime, camera states, pause flag, buffer fill, adapters, system warnings. That lets an agent distinguish it from action-oriented siblings like capture_image, measure, or watch, though no sibling is named 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?

Gives concrete timing context (while debugging, after reboots, during serial output, mid-process) plus an imperative 'Always call this first' and 'Do not wait until the end of a task.' It never states when NOT to use it or names an alternative, which keeps it short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It does describe the composite output (frames + event lines) and the data sources, but it says nothing about permissions, window limits beyond the schema's 1-60 range, whether the call is read-only, or how large the returned payload might be.

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, zero filler, and the resource description is front-loaded before the usage guidance. Every clause earns its place.

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

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

With no output schema, the description must convey return content, and it does so at a high level (contact sheet plus timestamp-aligned event lines). For a three-parameter, all-optional tool this is largely sufficient, though more on output shape/size would help.

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

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

Schema description coverage is 100%, so the schema already documents camera, last_seconds, and include_events. The description hints at the relationship between buffered history frames and last_seconds, and event lines and include_events, but adds no format or syntax detail beyond the schema baseline.

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 (Returns) and a concrete composite resource: a contact sheet of buffered history frames plus timestamp-aligned event lines from serial/log adapters. This is distinguishable from siblings like capture_image or read_events, though it does not explicitly name those alternatives to sharpen 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 second sentence gives a clear use case (correlating hardware events such as crash, reset, or button press with visual frames), which tells the agent when this tool is appropriate. It stops short of stating when NOT to use it or naming the sibling tools that would be used instead.

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

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

With no annotations, the description carries the full burden. It discloses the returned field set (ID, name, resolution, fps, state), which usefully signals a read-only enumeration, but it says nothing about permissions, whether discovery is cached, or how long a scan takes. Adequate but with clear gaps.

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 padding, and the returned fields are placed after the core action. Efficient, though the field enumeration is the only elaboration.

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

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

For a one-optional-param read tool with no output schema, stating the returned fields plus the refresh rescan in the schema is nearly sufficient. Missing only behavioral notes such as permission requirements or scan latency.

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 only parameter (refresh) is fully documented in the schema as triggering a USB/PNP rescan. The description mentions no parameters, so baseline 3 applies — the schema does the heavy lifting.

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 ('List all detected physical USB webcams and IP cameras') and even enumerates the returned fields, so the agent knows exactly what this produces. It is clear without opening the schema, though it does not explicitly contrast itself with siblings like get_status or set_camera_settings.

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: listing cameras is self-evidently the way to discover device IDs before calling set_camera_settings or capture_image, but the description never says when to use this over alternatives. 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?

With no annotations, the description carries the full burden, and it does disclose meaningful entity context: the regions are 'saved', 'named', and 'hardware' (i.e., registered on-device rather than transient). It says nothing about return format, ordering, or whether empty results are possible, so it is only partially transparent.

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

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

One sentence, verb-first, with every qualifier ('saved', 'named', 'hardware', 'of interest') narrowing the resource meaningfully. No filler or redundancy.

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

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

For a zero-parameter, zero-annotation list tool the description covers what the agent needs to select it. The only gap is the absence of an output schema combined with no textual hint about what each region record contains.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming the operation is unfiltered and parameterless.

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 pairs a specific verb ('List') with a precisely qualified resource ('saved named hardware regions of interest'), which is far more informative than a bare 'List regions'. It implicitly separates this read operation from define_region/delete_region/request_region_from_user, though it never names a sibling explicitly, so a 4 rather than 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 read-only listing nature is implied by 'List all' and the noun phrase, so an agent can infer when to reach for it. However, there is no explicit when-to-use guidance, no statement of prerequisites, and no mention of how it relates to define_region or delete_region.

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 behavioral burden. It helps by enumerating the computed metrics and stating the lightweight, non-image return, which implies a side-effect-free read. It stops short of explicitly declaring it is read-only/advisory, whether it analyzes a live frame or cached frame, or any permission requirements.

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

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

Two tight sentences, front-loaded with the action and the key differentiating constraint, then the payload of returned metrics. Every clause earns its place with no filler.

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

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

There is no output schema, and the description compensates well by enumerating the exact metrics returned (brightness, contrast, lit-pixel %, dominant colors, edge density, sharpness, motion). The gap is that with zero required parameters it never explains what happens if 'camera' or 'region' is omitted, though for a simple two-param read tool this is minor.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description only echoes the camera/region scoping ('camera frame or region') without adding format, default, or behavior detail beyond the schema, so baseline 3 applies.

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

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

The description states a precise verb (compute quantitative measurements) and resource (camera frame or region), and immediately distinguishes itself from image-returning siblings like capture_image by noting it works 'without returning heavy images'. An agent can select this over capture_image without opening any 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 phrase 'without returning heavy images' implies the appropriate context (use this when you need numbers, not an image), which is adequate implied guidance. However, it never names capture_image or compare_to_baseline as alternatives, nor does it state any exclusions or prerequisites for use.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the single most important trait: the call can block until matching text appears or until timeout. It does not state whether reading consumes/advances the buffer, what happens for an unknown source, or any error/permission behavior, leaving meaningful gaps for a snapshot-less 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 tightly written sentences with the resource and source types front-loaded, followed by the blocking behavior. No filler and 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?

For a 5-parameter tool with no output schema and no annotations, the description covers the source domain and blocking semantics but omits return shape (line format, ordering), buffer-consumption behavior, and failure modes for an invalid source. Adequate to make the call, insufficient to predict 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 description coverage is 100%, so the baseline is 3. The description adds one relational detail the schema does not convey on its own — that until_text pairs with a timeout — but lines, last_seconds, and source semantics are left entirely to 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?

Names a specific verb and resource ('Read timestamped lines from an active event adapter') and enumerates concrete source types (serial, log file, MQTT), so the agent knows exactly what the tool operates on. It does not, however, differentiate itself from the sibling read_text, which an agent may reasonably confuse with this tool.

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

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

Usage is only implied: the source examples and the blocking capability hint at when this applies, but there is no explicit when-to-use statement, no mention of prerequisites (adapter must be active), and no routing away from read_text. The bar for 4 (clear context, no exclusions) is not met.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the output shape ("extracted text and confidence") and that the source can be a full frame or a named region, but omits whether the camera must be streaming, error/failure behavior when no text is found, or any auth/resource constraints.

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 action and followed by the return value. No filler or redundancy.

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

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

There is no output schema, so the description correctly summarizes the return (text + confidence). For a two-parameter, zero-required tool this is nearly sufficient; the only real gap is the absence of any precondition or failure-mode context, which is minor given the tool's simplicity.

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

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

Schema description coverage is 100% with only two simple parameters, so the schema documents both. The phrase "camera frame or region" mildly reinforces how the two params relate (camera plus optional region), but adds no format or default detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ("Perform OCR to extract printed text or seven-segment display digits") and names the input surface ("camera frame or region"). No sibling tool does OCR, so the agent can route to it unambiguously.

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: this is the tool for reading text from a camera view. However, it never states when to use it versus siblings like capture_image, measure, or get_timeline, and gives no preconditions (e.g., whether a frame must be captured 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?

With no annotations, the description carries the full burden and does disclose the two traits that matter most: the call blocks, and it can end via timeout. That is genuinely useful beyond the schema. It does not say what happens on timeout (error vs. empty return) or whether the request requires an active Dashboard session.

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 interactive-drawing action and the blocking/timeout caveat both front-loaded where an agent will see them.

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 interactive tool with no output schema, the description covers the mechanics (UI prompt, drawing, blocking, timeout). The notable omission is the return value, since with no output schema the description is the only place an agent could learn what a completed or timed-out call yields.

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

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

Schema coverage is 100%, so both parameters (name, message) are already documented in the schema. The description adds no format, length, or default guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Ask the user ... to draw a region on the camera preview') and the interactive nature cleanly separates it from the programmatic define_region sibling. It stops short of naming any sibling explicitly, so an agent must infer the distinction, but the purpose itself 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 description implies the usage context (you want a human to pick a region on the live preview) but never states when to prefer this over define_region or list_regions, nor any prerequisite that a camera preview must be active. Usage is inferable but not 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the allowlist constraint, the approval-policy gate, and the conditional return of a post-action timeline sheet when observe_seconds is configured. It does not state whether actions have destructive/irreversible side effects or what happens on approval failure, leaving key behavioral questions open for an execution 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?

Three tightly packed sentences with the verb and constraint front-loaded; nothing is redundant. It is efficient, though the middle sentence about approval policy could be slightly more concrete.

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 execution tool with no annotations and no output schema, the description covers the allowlist, approval gate, and conditional return shape, which is a reasonable minimum. It is incomplete on side effects, reversibility, and error behavior, which matter for a tool that triggers configured 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 100%, so both parameters are already documented in the schema, which sets the baseline at 3. The description adds marginal value by giving concrete example action names and by tying observe_seconds to a return-behavior change, but adds no argument syntax or format detail.

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 ('Execute a configured allowlist action') and anchors it with concrete examples ('reset_board', 'pause_print'), so an agent can distinguish it from the read-only siblings like get_status and capture_image. It stops short of naming a sibling alternative, but the purpose is unambiguous.

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

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

'Subject to approval policy' implies a precondition for invocation, which is useful context. However, there is no explicit guidance on when to choose this over other tools, or what to do if the action is not allowlisted or approval is denied; usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the image is persisted and that it becomes a 'known-good' reference, which is useful context. However, it says nothing about overwrite behavior when a baseline of the same name exists, required permissions, or side effects on existing baselines – significant gaps for a persist/mutation 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 sentences, zero waste. The core action and scope are front-loaded, with the usage hint following immediately. 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?

For a simple 3-param persist tool with no output schema and no annotations, the description covers purpose and timing well. The remaining gap is the absence of overwrite/side-effect semantics, which matters for a save operation but is a modest omission here.

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

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

Schema description coverage is 100% with three documented params (name, camera, region), so the schema already carries parameter meaning. The description adds no syntax, defaults, or format details beyond it, making the baseline 3 correct.

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: 'Capture and persist a golden reference image for subsequent comparison.' The phrase 'golden reference... for subsequent comparison' implicitly separates it from capture_image and points toward compare_to_baseline. It stops short of naming a sibling explicitly, so it lands at 4 rather than 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?

Gives a clear trigger: 'Use to establish a known-good baseline before running experiments or flashing firmware.' That tells the agent when this tool is appropriate. It does not state when NOT to use it or name an alternative, so it is a clear-context 4, not a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: the driver may reject some parameters, and the tool reports which were accepted vs rejected — useful partial-success semantics. It omits whether settings persist, whether they apply immediately, permission requirements, and whether omitted parameters are left untouched.

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, zero waste: the capability statement comes first and the notable return behavior second. Nothing is padded or repeated from the name.

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

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

The description partially compensates for the missing output schema by describing the accepted/rejected return signal, but with no annotations, six parameters, and no prerequisites or units documented anywhere, an agent still lacks enough context to call this correctly in edge cases.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, and the description merely echoes their names. It adds no units, valid ranges, or interaction rules (e.g. how lock_auto relates to explicit exposure/focus values), so the baseline 3 applies.

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

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

Names a specific verb (Adjust) and resource (hardware camera parameters) and enumerates the exact settings it touches — exposure, focus, brightness, white balance, lock_auto. No sibling competes for this role (the others are list/capture/read tools), so the tool is distinguishable, though it never explicitly contrasts itself with alternatives like run_action.

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

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

The description implies usage ('adjust hardware camera parameters') but gives no when-to-use guidance, no prerequisites (e.g. whether the camera must be open or streaming), and no mention of the alternative path of using run_action or lock_auto versus setting individual values.

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

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

With no annotations, the description carries the disclosure burden. It reveals key behavior: asynchronous monitoring, return of fired status, timing, and before/after evidence images. However, it omits authentication requirements, whether the call blocks, and what happens on timeout (e.g., fired=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?

Two sentences, front-loaded with purpose and conditions, then return details. Efficient and mostly free of waste, though the condition list 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?

Given no output schema and no annotations, the description usefully discloses return values (fired status, timing, evidence images) and asynchronous behavior. It is largely complete for calling the tool, though it could clarify the optional camera/region defaults and timeout semantics beyond the schema.

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

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

Schema description coverage is 100%, so parameter meanings are fully documented in the schema. The description only repeats the condition enum values already present in the schema and adds no new semantic detail for camera, region, threshold, or timeout.

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 (monitor) and resource (camera) with the waiting condition and timeout. This clearly differentiates it from instantaneous siblings like capture_image or get_status, though it does not name 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?

No guidance on when to use this tool versus alternatives such as get_status, capture_sequence, or measure. The description only restates what the tool does, not when it should be selected.

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