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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool starts with summaries and a bounded number of transitions for incremental drilling, but does not state whether the operation is read-only, what the summaries contain, authentication needs, or pagination/drill-down mechanics.

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 core purpose front-loaded and zero filler. Every clause adds information about scope or incremental 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?

There is no output schema and no annotations, so the description should do more for a five-parameter analytical tool. It omits the meaning of key parameters, return shape beyond 'summaries,' and operational constraints, leaving the agent under-equipped 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 description coverage is 0%, so the description must compensate for all five parameters. It explains max_edges partially and gestures at a time window, but leaves capture_id, channel, start_s, and duration_s semantics, defaults, and units undocumented.

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

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

States a specific verb and resource: analyzing a bounded time window of a saved channel. It is clear enough to distinguish from generic capture/decode siblings, though it does not explicitly name or differentiate itself from any sibling 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?

The phrase 'so the agent can drill down incrementally' implies an iterative workflow, but the description gives no explicit when-to-use, when-not-to-use, prerequisites, or alternatives among the 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, the description carries the full burden. It does disclose the three categories of information returned (backends, safety limits, workflow), which is meaningful behavioral content, but it never states that the call is read-only/side-effect-free or whether results are cached or static.

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

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

A single front-loaded sentence with no filler; the most important information (what is reported) comes first and 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 zero-argument, read-only introspection tool with no output schema, stating the three returned content categories is close to sufficient. Only the absence of any read-only assurance or first-call recommendation keeps it from being fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema and description are consistent. Baseline 4 applies for a parameterless tool.

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 ('Report') and enumerates concrete contents: available backends, safety limits, and the recommended workflow. An agent can tell this is an introspection/discovery tool, though it does not explicitly contrast itself with siblings like self_test or list_devices.

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 statement, but the mention of 'recommended workflow' implies this is an onboarding/orientation call an agent should make early. The guidance is inferable rather than stated, and no alternative tools are 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 load and does disclose two meaningful behaviors: results are persisted under a capture_id, and the return is per-channel statistics (edges, pulse widths, rough frequency), never the raw samples. That prevents an agent from expecting raw data. It still omits hardware/permission needs, backend selection consequences, and failure modes, keeping it short of a 5.

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

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

Three tight sentences, front-loaded with the action and persistence, followed by return shape and practical advice. No filler and nothing redundant.

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

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

The description usefully compensates for the missing output schema by describing return contents, and it hints at cost with 'short window first'. But for a 7-parameter acquisition tool with no annotations and a nested trigger object, leaving backend/device/trigger semantics entirely unexplained is a real gap for correct invocation.

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

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

Schema description coverage is 0% across 7 parameters, including a nested trigger object and a backend enum (mock/sigrok/dslab) whose meaning is critical to invocation. The description explains none of them, so an agent gets no help interpreting device vs backend, trigger semantics, or sensible sample_rate/duration values.

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

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

States a specific verb and resource ('Capture digital channels') and adds the persistence effect ('persist them under a capture_id'). It implicitly distinguishes itself from analysis siblings like analyze_window and decode_uart by being the acquisition step, but it never names a sibling explicitly.

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

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

'Prefer a short window first' gives one piece of tactical advice, which is more than nothing. However, it never says when to choose this over list_captures (does capture create a new one?), nor when to use a trigger or which backend to pick, so guidance is implied 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. It usefully discloses the return shape ("bounded structured events, never raw waveform arrays"), which tells the agent output is size-limited and non-raw. It says nothing about failure modes (unsupported protocol, channel/role mismatch), cost of decoding, or how bounds interact with max_events.

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, front-loaded sentences with no filler, and the channel-mapping example is well placed. The 22-protocol list duplicates the enum verbatim, which is redundant text, though it does aid at-a-glance capability scanning.

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

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

For a 9-parameter tool with no annotations, no output schema, and only 33% schema coverage, the description covers the return contract and defers options detail to capabilities. It leaves the temporal windowing (start_s/duration_s) and the practical meaning of max_events/include_bits unexplained.

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 only 33%, so several parameters (capture_id, start_s, duration_s, max_events, include_bits) are undocumented anywhere. The description reinforces the channels role-mapping and the decoder.option stacking syntax, but those are already in the schema; it adds nothing for the time-window or event-limit parameters beyond the vague "bounded".

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+resource ("Decode a saved capture") and enumerates the supported protocol decoders, which clearly distinguishes it from the narrow sibling decode_uart. It never names a sibling directly, so the differentiation is implicit rather than explicit.

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

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

It tells the agent to "Inspect capabilities for each protocol's required/optional channels and typed options" before calling, which is an actionable prerequisite pointing at the capabilities sibling. It gives a concrete channel-mapping example but no when-not-to-use guidance (e.g., when to prefer decode_uart).

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 an important behavior: framing/parity warnings should always be reported rather than silently trusting decoded text. However, it does not explain permissions, failure modes, return format, or other operational traits.

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, front-loads the core decode operation, and uses the second sentence for a critical behavioral instruction. There is no wasted language.

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 tool has six parameters, a nested UART configuration object, no annotations, and no output schema. The description identifies the operation and one output-quality requirement but leaves parameter behavior and configuration semantics largely unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain capture_id, channel, start_s, duration_s, max_bytes, or the nested uart configuration fields such as baud, parity, data_bits, and stop_bits.

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: decode UART/RS-232-style asynchronous serial from a saved channel window. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling decode_protocol 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?

The description implies the tool is used for decoding UART-style serial from saved channel windows, but it gives no explicit when-to-use guidance, prerequisites, or alternatives such as decode_protocol or analyze_window.

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 one useful behavioral trait — large/wide exports are costly, so export a narrow time range first — but says nothing about failure modes for malformed CSVs, whether an existing capture is overwritten, file-size limits, or what is 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?

Three short sentences, zero filler, front-loading the identification of the input format before the usage hint and the practical caveat. 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 file-import tool with no annotations, no output schema, and zero schema descriptions on three parameters, the definition leaves too much unsaid: what `channels` does (filter vs. required mapping), what `label` labels, what the tool returns, and how errors surface.

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

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

Schema description coverage is 0% across three parameters, and the description adds no meaning for any of them: `path` is only implied, `label` (max 120 chars) and `channels` (a min-1 array, presumably a subset filter) are never explained. The 'narrow time range' note refers to the external DSView export step, not to any tool 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?

Specific verb+resource: 'Import a DSView CSV export ... as a capture', with the source format and provenance (Export Data -> CSV) spelled out. It implicitly distinguishes itself from the live `capture` sibling via 'reliable offline path when DSView was driven manually', 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 a clear when-to-use condition: DSView was driven manually, so the data must come in offline. It lacks an explicit when-not clause or a named alternative (e.g., use `capture` when the API controls the device directly), so routing is implied 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?

No annotations are provided, so the description carries the full burden. It discloses only the sort order ("newest first") and says nothing about read-only semantics, whether results are paginated, how large the list can get, or whether captures include metadata versus raw data.

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 short sentence with no filler, and the ordering detail is placed where it will be read. It is appropriately sized but so spare that it borders on under-specification rather than tight writing.

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

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

For a no-param, no-annotation, no-output-schema tool the description should still say what a capture record looks like or roughly how many come back. It gives ordering but leaves the return shape entirely unstated, which is a real gap given no output schema exists.

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 properties, so there are no parameters to explain; the baseline for a no-param tool applies. The description correctly implies there is no filtering or paging argument to supply.

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 saved captures") plus an ordering guarantee, which is enough to distinguish it from sibling tools like list_devices or capture. It stops short of naming any sibling or clarifying what a 'capture' contains, so it doesn't reach the top band.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative named. For a zero-parameter listing tool the intent is largely self-evident from the name, but the description adds nothing about context, prerequisites, or where it fits alongside capture/analyze_window.

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 discovery does not initiate a capture (side-effect-free), which is meaningful behavioral context. However it says nothing about return format, whether hardware probing can block/timeout, or what happens if no backend is specified.

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 waste; the discovery action and its key constraint are stated 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?

For a simple one-parameter discovery tool with no output schema or annotations, the description covers the action but omits what is returned and how the backend parameter affects behavior. Adequate but with clear gaps an agent would want filled.

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 is one optional parameter (backend) with 0% schema description coverage, and the description never mentions it. The enum values (mock, sigrok, dslab) are somewhat self-evident, but there is no explanation of default behavior or what each backend means for discovery, so the description fails to compensate for the coverage gap.

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 (Discover) and resource (connected logic analyzers), and the clause 'without starting a capture' implicitly separates it from the capture-centric siblings. It does not name a sibling explicitly, 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?

'Without starting a capture' hints at when to use it (pre-capture discovery), but there is no explicit when-to-use/when-not guidance or reference to alternatives like capabilities or self_test. 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?

No annotations exist, so the description carries the full burden, and it does disclose one genuinely useful behavioral trait: periodic=false when fewer than two rising edges fall in the window. It says nothing about required capture state, whether the capture must already be loaded, how the window is chosen if start_s/duration_s are omitted, or what the full return shape looks like.

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

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

Two tight sentences with no filler, and the primary capability is front-loaded before the edge-case caveat. Every clause adds 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 four-parameter tool with no annotations, no output schema, and 0% schema coverage gets only two sentences of explanation. The agent is left without windowing semantics, capture prerequisites, or return-field detail beyond the single periodic flag.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It only clarifies 'channel' as a clock/PWM channel; capture_id, start_s, and duration_s are never mentioned, leaving the agent to guess whether the window defaults to the whole capture and what identifiers are valid.

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 ('Measure') with a concrete set of quantities (period, frequency, duty cycle, jitter) and a clearly bounded resource (clock/PWM channel). An agent can distinguish it from decode_uart or decode_protocol, though it never explicitly contrasts itself with the closer sibling analyze_window.

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 measurement list implies the use case (periodic signal characterization), and the edge-condition sentence hints at input requirements. But there is no explicit 'use this instead of analyze_window when...' guidance and no stated prerequisites such as the capture needing a digital channel.

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. It usefully discloses the diagnostic's blind spot (it cannot validate external wiring), which prevents an agent from over-trusting a pass. It stops short of saying how long it takes, whether it affects device state, or how pass/fail is signaled.

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

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

Three sentences, front-loaded with the action, then the motivation, then the caveat. Nothing is redundant or 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 zero-param diagnostic with no output schema, the main remaining gap is the shape of the result — the agent is not told whether to expect a boolean, a log, or a status string. Otherwise the definition gives enough 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?

Zero parameters, so there is no semantic burden; the baseline of 4 applies. The description correctly implies the tool needs no input beyond the attached device.

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 ('Hardware self-test using the DSLogic internal pattern generator') and immediately distinguishes itself from the capture-centric siblings by positioning itself as pre-flight verification.

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

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

Explicitly says when to run it ('before protocol work') and what decision it informs ('distinguish a broken capture path from a bad probe signal'), plus a clear scope exclusion ('does not prove that external wiring is correct'). This is the when/when-not/limitation triad done well.

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