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

With no annotations, the description must carry the behavioral burden, and it does meaningfully: it discloses that the tool reports process-scoped failed logins, lockout counters, and a frozen-login flag, and explicitly states 'No network I/O', signaling a cheap, side-effect-free local read. It stops short of stating whether querying it affects lockout state or whether auth is required to call it.

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

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

A single compact sentence with the core subject ('NVR session state') front-loaded, followed by a colon-list of the exact fields returned and a terse behavioral note. No filler, no repetition of 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?

An output schema exists, so return values need not be explained, and the description still enumerates the key reported fields. For a zero-param status tool this is nearly complete; the only omission is whether the call has any effect on lockout counters or requires prior authentication.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to compensate for, and the schema is trivially complete.

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

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

The description names a specific resource (NVR session/auth state) and enumerates exactly what it reports: authentication result, failed-login count for this process, lockout counters, and frozen-login flag. This is far more specific than a tautology. It does not explicitly distinguish itself from siblings like nvr_login or nvr_status, which keeps it from 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. An agent can loosely infer it is used to diagnose authentication state (e.g., after nvr_login or a failed call), but the description never states that context or routes to alternatives.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that a file is written to the server's backup directory with mode 0600, and explicitly reassures that the operation is read-only on the NVR (no device mutation). It does not mention authentication prerequisites (nvr_login), overwrite/retention behavior, or backup size, leaving some 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 short sentences, front-loaded with the action and destination, followed by the safety profile and ordering constraint. No filler sentences; each clause carries information.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers destination, file permissions, device-side safety, and workflow ordering. It omits auth requirements and whether an existing backup is overwritten, which an agent invoking this tool would plausibly want to know.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is no parameter syntax the description could add. Schema coverage is moot at 0 params.

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 ('Download the NVR configuration backup') plus the destination, and it is the only backup-oriented tool among 45 siblings. An agent can distinguish it from nvr_plan_channel_cleanup or nvr_export_clip 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?

Explicitly prescribes workflow ordering ('run this before any channel cleanup'), which is real usage guidance tied to the sibling cleanup tools. It stops short of naming the specific alternative tools (nvr_plan_channel_cleanup, nvr_remove_channel) or stating when not to run it, so it is not a full 5.

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

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

With no annotations, the description carries the full burden and does it well: unknown calls are refused with nearest matches, mutating or non-'get' methods require an env flag plus confirm_write, dry-run returns the exact body as data.request with data.dry_run=true and sends nothing, and credential fields are redacted. These are exactly the behaviors an agent must know before calling.

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?

Six dense sentences, front-loaded with the identification triple before the gating and dry-run rules. No filler; each sentence adds an operational fact.

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 high-complexity gateway tool it covers refusal, write gating, extra-key handling, dry-run output shape and redaction, and an output schema exists so return values needn't be described. Minor gaps: no auth prerequisite mention and the ambiguous 'key' parameter.

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 17%, so the description must compensate and largely does: params is the module body, allow_extra permits keys outside the call's example, and confirm_write is a strict JSON boolean. However, module/method/key formats are only referenced indirectly and the 'key' parameter is never actually explained.

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 ('catalogued gateway to any NVR call') and explains that a call is identified by the (module, method, key) triple sourced from nvr_list_calls/nvr_describe_call. It does not, however, contrast itself with the nearest sibling nvr_raw_call, leaving an agent to guess which gateway to pick.

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 workflow: discover the call via nvr_list_calls/nvr_describe_call, then pass the module body as params. It states the conditions that gate mutating calls (VIGI_NVR_ALLOW_WRITES=true AND confirm_write=true) and when to set allow_extra=true. It never explicitly says when to prefer nvr_raw_call 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 and does well: it discloses the read-only intent, the side effect of writing frames into the export dir, the required environment (RTSP + ffmpeg), and the return shape (file info plus tile->timestamp map). It omits auth requirements, rate limits, and expected latency, which keeps 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?

The core output is front-loaded in the first clause, and the remaining sentences each add a distinct fact (time format, side effect, return value, prerequisites). Dense but nearly every phrase earns its place, with only minor redundancy around the read-only/export-dir framing.

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 tool with an output schema, no annotations, and 0% schema coverage, the description covers purpose, side effects, prerequisites, and return contents well enough to invoke correctly. The residual gap is the undocumented channel, width, and stream parameters, which the agent can only guess at.

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

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

Schema coverage is 0% across 7 parameters, so the description must compensate. It usefully specifies ISO-8601 with a required UTC offset for start/end and explains that cols x rows defines the sampling grid, but channel, width, and stream are left entirely undocumented in both the description and 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?

States a specific verb and resource: produces one JPEG contact sheet of cols x rows frames evenly sampled across a replay window, with timestamps burned in. This clearly distinguishes it from nvr_snapshot (single image) and nvr_export_clip (video), but it never names those siblings, so the agent must infer the routing itself.

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

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

The description gives a prerequisite ('Needs RTSP enabled and ffmpeg available') and an implied use case (visual overview of a replay window), but it does not say when to prefer this over nvr_snapshot, nvr_sample_frames, or nvr_export_clip. Usage 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 provided, the description carries the full burden and does well: it flags the operation as a WRITE, names both gates (VIGI_NVR_ALLOW_WRITES=true and confirm_write=true), and discloses path confinement so the agent knows the blast radius. It stops short of stating whether deletion is reversible or what happens when the named file does not exist, which are the remaining behaviors an agent would want.

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 zero filler. The core action leads, followed by the naming constraint, then the write gate. Every clause carries information an agent needs to call the tool correctly.

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

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

An output schema exists, so return values need no explanation, and the description covers the action, parameter constraint, and write authorization. For an unannotated destructive tool it is nearly complete; a note on reversibility or missing-file behavior would close the last gap.

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

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

Schema coverage is 50%: confirm_write is heavily documented in the schema, but the required 'name' parameter has only a title of 'Name'. The description compensates by defining what that name must be (a generated export filename, path-confined), which the schema does not say. That added meaning for the undocumented parameter lifts this above the 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, resource, and scope: delete ONE file from the export directory, with the path-confined constraint and the requirement that the name be a generated export filename. This cleanly separates it from the sibling nvr_purge_exports (bulk delete) and nvr_get_export/nvr_list_exports without needing to open 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 description implies usage context by constraining the name to a generated export filename (implying you must have listed/identified an export first), and it states the write preconditions. However, it never explicitly names the alternative tool (nvr_purge_exports) or states when to prefer deleting a single file versus purging all exports. 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 behavioral burden. It usefully discloses that the tool is read-only and that the described call's mutation status is part of the result, but it omits authentication needs, error behavior, and any rate-limit or side-effect context.

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 efficiently packs the tool's purpose, required arguments, output content, and read-only nature into minimal space.

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

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

An output schema exists, so return values need not be explained in the description. However, with three required parameters at 0% schema description coverage and no annotations or usage guidance, the definition leaves the agent without enough information to know what module, method, and key values to supply.

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

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

Schema description coverage is 0%, so the description must compensate but does not. It repeats the parameter names (module, method, key) in order without explaining what values are valid, how to obtain them, or what each identifier means, adding almost no semantic value beyond the bare schema.

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

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

The description states a specific verb ('Describe') and resource ('one call') and identifies the required triple (module, method, key). It clearly contrasts with execution-oriented siblings like nvr_call by emphasizing description and read-only behavior, though it does not explicitly name those 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?

The description gives no explicit when-to-use guidance, no conditions for selecting this tool over nvr_call, nvr_raw_call, or nvr_get_module_spec, and no prerequisites. The only hint is 'Read-only,' which implies a metadata-inspection role but does not tell the agent when that role is appropriate.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it declares this is a WRITE, names the required VIGI_NVR_ALLOW_WRITES gate, the confirm_write requirement, and dry-run behaviour via VIGI_NVR_DRY_RUN. It also discloses the re-read and enabled_before/after result, though it does not cover reversibility (a matching disable) or auth/permission scope beyond the env flags.

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?

Terse and front-loaded: purpose first, then the WRITE preconditions, then dry-run and return semantics. Every fragment carries information with no filler.

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

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

An output schema exists, so return values needn't be explained, yet the description usefully notes the re-read and enabled_before/after. For a one-parameter mutating tool with no annotations, the preconditions and dry-run disclosure make it nearly self-sufficient, with only alternative-routing guidance missing.

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

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

Schema description coverage is 100% and the single confirm_write parameter is fully documented in the schema, including the boolean-only rejection behaviour. The description restates the confirm_write=true requirement without adding format or syntax detail beyond the schema, 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?

States a specific verb (Enable) and resource (ONVIF/RTSP on the NVR), plus the concrete backend effect ('onvif_server set'). The mutation verb cleanly distinguishes it from read-side siblings like nvr_get_rtsp_status and nvr_get_stream_url.

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

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

'One-time setup' implies when the tool applies, and the WRITE preconditions frame the context. However, it never explicitly routes the agent to alternatives (e.g., checking state via nvr_get_rtsp_status first) or states when-not to use it, leaving usage to inference.

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

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

With no annotations, the description carries the full behavioral burden and delivers: write gating with two required flags, dry-run argv behavior with URL redaction, the lossless ffmpeg -c copy default, the libx264 re-encode path when target_max_mb/max_width are set, extra return fields (original_bytes, encoded_bytes, fits_target) and the NO_FOOTAGE_IN_WINDOW error surface.

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

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

Dense but front-loaded: the core action and output artifact come first, then gating, then the optional re-encode behavior and return values. Nearly every clause carries operational information, though the run-on packaging of dry-run, encoding and return fields could be tightened.

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

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

For a mutating export tool with no annotations, the description covers gating, dry-run, duration limits, re-encode triggers and error codes; return values are spelled out even though an output schema exists. An agent has everything needed to invoke it correctly and interpret the result.

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

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

Schema coverage is only 14% (just confirm_write), so the description must compensate and largely does: start/end are ISO-8601 with a required UTC offset, target_max_mb is illustrated ('e.g. 20 for Gmail'), max_width triggers re-encoding, and confirm_write semantics are covered in both places. channel and stream are left to inference, which keeps it below a 5.

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

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

States a specific verb and resource ('Export a replay window ... to an mp4 in the export dir') with the scope (start/end window) and output artifact. It is clearly distinguishable from sibling read tools like nvr_snapshot, nvr_get_export and nvr_list_exports 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?

Gives strong when-to-use context: it is gated like a write (VIGI_NVR_ALLOW_WRITES=true AND confirm_write=true), VIGI_NVR_DRY_RUN previews the argv, and the window is bounded by VIGI_NVR_EXPORT_MAX_MINUTES. It does not explicitly name when to prefer a sibling (e.g. nvr_snapshot or nvr_sample_frames) over exporting a clip, so it stops short of full alternative routing.

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 the core logic: grouping key (device uuid) and the staleness rule (online="0" or conn_status!="0"). However, it never states that the operation is read-only/non-mutating or whether it touches the device, leaving the safety profile to inference.

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 primary action front-loaded and the qualifying detail (staleness rule) second. No filler; every clause carries information.

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

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

An output schema exists, so return values need not be described, and there are no parameters. The remaining gap is the absence of any guidance on how this relates to the cleanup workflow (nvr_plan_channel_cleanup, nvr_remove_channel), which an agent would need to chain it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is trivially complete.

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 ('find duplicate channels') and elaborates the mechanism (group by device uuid, flag duplicates). It is clearly distinct from siblings like nvr_remove_channel or nvr_move_channel, though it never explicitly names a sibling to disambiguate.

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 this is an analysis step ('removal candidates') but never states when to use it versus related tools such as nvr_plan_channel_cleanup or nvr_list_channels. No exclusions, prerequisites, or sequencing guidance are provided.

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

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

With no annotations, the description carries the full burden, but it does add one genuinely useful behavioral fact: credential fields are redacted in the response. It says nothing about read-only nature, authentication requirements, or what happens when the id 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?

A single terse sentence with zero waste, and the resource plus scoping constraint are front-loaded. It is arguably too sparse for a tool with no annotations, but nothing is redundant.

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

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

An output schema exists, so return structure need not be explained, and the redaction note covers response content. However, with no annotations and no auth or not-found behavior described, the definition is only minimally sufficient for an agent to call it confidently.

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

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

There is a single required parameter with 0% schema description coverage, so the description must compensate. "By id" conveys that channel_id is the channel identifier, but adds no format, source, or validation detail beyond the parameter name.

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 (get a single channel) and scopes it to lookup by id, which implicitly contrasts with the sibling nvr_list_channels. It does not explicitly name that sibling, so it falls 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?

"One channel by id" implies you must already have a channel id, but there is no explicit guidance on when to use this versus nvr_list_channels, nvr_get_channel is the singular counterpart of, nor any prerequisite or error condition noted.

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 declares read-only semantics and explains that include_raw=true appends the raw reply at data.raw, but says nothing about authentication prerequisites, failure modes, or rate limits for a cloud-binding check.

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

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

Two compact sentences, front-loaded with the resource and scope, followed immediately by the one parameter's effect. 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?

An output schema exists, so return values need not be described. For a single-parameter read tool this is nearly sufficient; only the meaning of a 'not bound' result and any auth requirement are left unaddressed.

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

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

Schema coverage is 0% and there is one parameter, so the description must compensate. It does: include_raw is documented with its default behavior and exactly where the added data appears (data.raw), which is more than the schema provides.

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: retrieving TP-Link cloud (TP-Link ID) binding and connection status. This is clearly distinguishable from siblings like nvr_get_rtsp_status or nvr_auth_status, though the description never explicitly names those 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?

The '(read-only)' note implies it is a safe diagnostic call, but there is no explicit when-to-use guidance or comparison against related status tools such as nvr_auth_status or nvr_get_network_info. Usage must be inferred.

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 load, and it does well: it declares the operation read-only, states refusal behavior for unknown kinds and out-of-range channels, and explains the include_raw side effect (raw device reply under data.raw). Auth/rate-limit behavior is not covered, 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?

Front-loaded with purpose and scope, then parameters, then edge-case behavior. The long kind enumeration is necessary because the schema supplies no enum, so it earns its space rather than being filler.

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

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

With an output schema present, return values need not be re-explained, and the description only adds the data.raw note. It is essentially complete for a read tool, with only minor gaps around authentication or failure recovery.

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

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

Schema description coverage is 0%, so the description must compensate and does: it documents the channel range (1-16), enumerates all twelve valid kind values, and defines include_raw's default effect and output location. Every parameter is meaningfully specified.

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

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

States a specific verb (get) and resource (detection configuration) scoped to exactly one channel (1-16) and one detection kind. This cleanly separates it from adjacent config readers like nvr_get_video_config and nvr_get_image_config without opening a schema.

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

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

Usage is implied — fetch detection config for a given channel/kind — but the description never says when to prefer this over siblings such as nvr_get_module_spec or nvr_call, nor does it name exclusions. The 'read-only' marker gives context but no routing guidance.

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

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

No annotations are provided, so the description carries the burden; it does disclose the (read-only) nature of the call, which is the single most useful behavioral signal for a getter. It says nothing about authentication prerequisites (nvr_login/nvr_auth_status exist as siblings) or failure modes on an unauthenticated NVR.

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 phrase, front-loaded with the concrete fields returned and the read-only trait. Efficient, though the parenthetical qualifier is doing a lot of work that a slightly fuller sentence could carry.

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

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

An output schema exists so return values need not be documented, and with no inputs and no annotations there is little else missing. The remaining gap is distinguishing this tool's scope from the other nvr_get_*_info siblings.

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

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

The tool takes zero parameters, and the schema is fully covered, so there are no parameter semantics to compensate for. Baseline for a parameterless tool applies.

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

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

Names a concrete resource set (model, firmware, identity) returned by a read-only fetch, which is more specific than a generic 'get info'. However, it does not differentiate itself from overlapping siblings such as nvr_get_system_info or nvr_get_network_info, so an agent cannot tell which identity fields live where.

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

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

No when-to-use guidance and no mention of alternatives, despite several sibling info tools (system, network, storage, video config) that an agent must choose between. The scope of 'identity' is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden and does well: it discloses the base64 encoding, the TOO_LARGE error with size and recovery hints, the path-confinement security constraint, and the default limit. It omits auth/permission requirements and any note on very large payload handling.

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

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

Front-loads the core purpose before the limit/error mechanics, and each sentence carries distinct information with no filler. Dense but appropriate for the error-handling context it conveys.

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

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

An output schema exists, so return values need little explanation, and the description covers the key failure mode and security constraint. For a two-parameter getter it is nearly complete, with only auth requirements and the meaning of 'name' left unstated.

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

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains max_mb (default 20, Gmail's ~25 MB cap, over-limit behavior) but says nothing about the required 'name' parameter beyond implying it identifies the export, leaving half the parameters under-documented.

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: returns one export file's content, encoded as base64, with a clear single-file scope that implicitly distinguishes it from the sibling nvr_list_exports. It does not explicitly name or contrast with siblings, keeping it just below 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?

Gives clear context for the size-limit path and names concrete alternatives when over the limit (re-export with target_max_mb, or fetch the exports:// resource). It lacks an explicit 'use this when you need X' framing, but the conditional routing is genuinely helpful.

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 a real behavioral trait – that the call is read-only/non-mutating – and explains that include_raw=true surfaces the raw reply at data.raw. However it says nothing about permissions, failure modes, or payload size, so the disclosure is partial.

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 resource and its contents front-loaded and the optional parameter explained last. Nothing could be cut without losing information.

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

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

For a one-optional-parameter read-only getter with an output schema already describing the return shape, the description covers purpose, read-only status, and the only parameter's effect. The missing piece is any indication of prerequisites or when this getter is preferable to related config getters.

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

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

Schema coverage is 0% and the single boolean is only titled 'Include Raw'. The description compensates by stating exactly what setting it does ('adds the raw reply') and where the result lands ('at data.raw'), which is genuine meaning beyond the schema.

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

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

The description names a specific verb+resource ('Firewall configuration') and enumerates what the payload contains (allow/deny lists, protocol/service exposure), which is more concrete than the bare tool name. It does not explicitly contrast itself with siblings like nvr_get_network_info, but the overlap risk is low and the scope 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?

There is no when-to-use or when-not-to-use guidance; the '(read-only)' tag implies it is safe to call but the description never states a context or alternative. An agent must infer from the tool name alone when this getter is the right choice among ~40 siblings.

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 must carry the behavioral burden; it does declare 'read-only' and explains that include_raw adds the raw device reply at data.raw, which is genuine value. It omits auth/permission requirements, behavior for out-of-range channels, and failure modes, so it only partially covers the burden.

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

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

Two tightly written sentences with no filler; the scope and channel constraint lead, and the optional-parameter note follows. Every clause carries information.

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

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

An output schema exists, so return values need no explanation, and both parameters plus the read-only nature are documented. It is nearly complete; only auth/permission context and out-of-range channel behavior are unaddressed.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it constrains channel to 1-16 (absent from the schema) and explains include_raw's effect and its output location (data.raw). Both parameters receive meaning beyond their bare type/title.

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

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

The description names the specific resource and sub-domains ('Image, OSD, privacy-mask (cover) and ROI configuration for one channel'), which is far more informative than the tool name alone and implicitly separates it from nvr_get_video_config and nvr_get_detection_config. It never explicitly names or contrasts those siblings, 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?

Usage is implied by 'read-only' plus the single-channel scoping, which tells an agent this is a safe per-channel config read. There is no explicit when-to-use statement, no exclusion (e.g. 'use nvr_get_video_config for stream/encoding settings'), and no prerequisites such as login/auth being required.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose '(read-only)', which is the key safety trait, but says nothing about authentication requirements, whether a module id is needed elsewhere, or any side effects or 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?

A single compact line with the read-only safety cue placed at the end and the content listed up front. It is efficient, though slightly cryptic for an agent unfamiliar with the domain.

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

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

An output schema exists, so return-value detail need not be in the description, and zero params are easy. But in a 40+ tool server, the definition lacks any routing context to distinguish this spec lookup from the many other 'get_*' info tools.

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 clarify; baseline 4 applies. The description correctly implies no input is required.

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

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

The description names the resource (a module's capability spec) and enumerates what it returns (max channels, codecs, feature flags), which helps an agent distinguish it from e.g. nvr_get_device_info. However there is no verb and 'Capability spec' is a noun phrase, so the action is only implied.

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

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

No when-to-use guidance is given, and with ~40 siblings like nvr_list_modules, nvr_get_device_info, and nvr_get_video_resolutions, an agent gets no help deciding when this spec query is the right call versus those alternatives. The only implicit cue is the returned content.

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 disclosure burden, and it does state 'read-only', which correctly signals a non-mutating operation. It says nothing further, but for a zero-argument informational read the remaining behavioral surface is small, and the presence of an output schema covers return values.

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 phrase with no filler, and the resource is front-loaded. It is efficient, though almost too terse to be maximally useful.

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

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

For a simple zero-param read tool with an output schema, little is required, but the description gives no indication of what network attributes are covered or how it relates to the many sibling info tools. An agent can call it correctly but cannot confidently choose it over nvr_get_system_info or nvr_get_device_info.

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 (empty object schema), so there is nothing for the description to disambiguate. Baseline of 4 applies for a zero-parameter 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?

Names a specific resource (NVR network configuration), which distinguishes it from siblings like nvr_get_system_info and nvr_get_device_info. The verb is only implied by the tool name rather than stated, so it falls short of a fully explicit verb+resource statement.

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

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

There is no guidance on when to call this versus nvr_get_system_info, nvr_get_device_info, or nvr_get_storage, all of which are adjacent read-only configuration/info tools. The parenthetical '(read-only)' hints at safe usage but does not route the agent among alternatives.

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

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

With no annotations, the description carries the full behavioral burden, and it does contribute two useful facts: the call is read-only and the reply is raw/unparsed. However, it says nothing about permissions/auth requirements, error behavior, or whether "raw" means an unnormalized vendor payload the agent must interpret.

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 terse phrase with no filler and the key qualifier (read-only, raw reply) placed inline. It is efficient, though bordering on under-specified rather than truly well-structured.

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

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

An output schema exists so return values need not be explained, and there are no parameters to document. The remaining gap is disambiguation — for a tool sitting among ~40 NVR siblings, the description does not tell the agent when this status call is the right one.

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 no parameter semantics to clarify and the schema trivially matches the description.

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 resource area ("Recording / storage policy status") but the phrase is ambiguous — it could mean live recording activity or the stored recording policy config, and it does not distinguish itself from siblings like nvr_get_storage, nvr_status, or nvr_list_recording_segments. There is no clear verb+object that lets an agent pick this over those neighbors.

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

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

No when-to-use guidance is given, and none of the many adjacent tools (nvr_get_storage, nvr_status, nvr_list_recording_segments) are named as alternatives. The agent must guess from the ambiguous name alone.

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

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

No annotations are provided, so the description carries the full burden. It usefully declares 'Read-only', names the exact config field checked (onvif_server.onvif.enabled) and the port resolution (default 554, VIGI_NVR_RTSP_PORT). However it omits practical behavior such as whether the TCP probe can block/timeout, auth requirements, or rate limits for a connectivity check.

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 covering both checks, with the read-only nature appended. No filler; every clause carries information (enabled flag, port default, root requirement).

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

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

An output schema exists, so return-value explanation is not required, and the description covers the two states it reports plus read-only safety. It is nearly complete; only behavioral detail beyond what an agent needs to call a zero-param probe tool is thin.

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. The description adds no parameter meaning because none is needed, and the schema is fully described (100% coverage).

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

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

States a specific verb ('Report') and resource ('whether ONVIF/RTSP is enabled' + RTSP port TCP reachability), and even names the underlying config key and port constant. An agent can distinguish it from nvr_enable_rtsp (write) and nvr_get_stream_url 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?

Usage is implied rather than stated – it's a diagnostic check that would naturally precede nvr_get_stream_url or nvr_enable_rtsp, and 'Read-only' implicitly signals it is the non-mutating counterpart to nvr_enable_rtsp. But there is no explicit when-to-use/when-not or named alternative, so guidance 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 burden and does declare the operation is read-only, which is the key safety fact. It also discloses the side effect of include_raw (raw reply added at data.raw), but says nothing about authentication requirements or whether the returned policy data is device-level or per-channel.

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 clauses with no filler; the payload contents are front-loaded and the optional-parameter note comes last. Slightly dense punctuation but every phrase carries information.

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

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

An output schema exists, so return-value documentation is not required, and the read-only nature plus the parameter behavior are covered. The only real gap is the absence of any routing hint relative to the many storage-adjacent siblings.

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% and there is only one parameter, but the description fully explains it: include_raw=true appends the raw reply at data.raw. That is exactly the meaning an agent needs and it is absent from the schema itself.

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

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

Names a specific resource (storage/disks) and enumerates the concrete fields returned: status, capacity, free space, health, plus overwrite and recording-plan policy. It does not, however, differentiate itself from the sibling nvr_list_disks, which an agent could reasonably confuse it with.

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

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

There is no guidance on when to call this versus nvr_list_disks, nvr_get_system_info, or nvr_status. The '(read-only)' tag hints at the operation class but gives no selection criteria or prerequisites.

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 does disclose meaningful behavior: the URL is redacted, the password is never returned, credentials live in env vars (surfaced as a hint), and the operation is read-only. It omits whether login/auth is required first and any rate or expiry behavior, keeping it from 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?

Front-loads the core purpose (redacted RTSP URL) in the first clause, then adds compact parameter and safety detail. It is appropriately sized with no filler, though the parenthetical details make the middle slightly dense.

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

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

An output schema exists, so return-value structure need not be explained. Combined with the compensating parameter detail and the credential/redaction disclosure, the description is nearly complete for a two-param read tool; missing only auth prerequisites.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents channel range (1-16) and the stream mapping (1=main, 2=sub). Both parameters gain meaning beyond the bare schema titles, though the default value of stream=1 is only implied.

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: returns a redacted live RTSP URL for a channel. It clearly identifies what the tool produces and scopes it (channel 1-16, main/sub stream). It does not explicitly differentiate itself from siblings like nvr_get_rtsp_status or nvr_enable_rtsp, so it falls short of a 5.

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

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

The description implies the tool's use case (fetching a stream URL) but gives no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as nvr_get_rtsp_status or nvr_enable_rtsp. An agent must infer selection criteria on its own.

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 only discloses that the call is read-only. It says nothing about whether login/auth is required (relevant given nvr_login and nvr_auth_status siblings), whether results are cached or live, or any rate 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?

A single front-loaded sentence with the resource and its most useful fields; there is no filler. Appropriate length for a zero-argument informational call.

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

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

An output schema exists, so return-value detail need not be in the description, and a zero-param read tool needs little else. Completeness is only slightly weakened by the absence of any disambiguation from the many similar get_* siblings.

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 baseline there is nothing for the description to disambiguate. The listed fields describe the response rather than inputs, which is fine given the empty schema.

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

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

The description names the resource (system info) and enumerates the concrete fields returned (device name, time zone, session timeout), so an agent knows precisely what comes back. It does not distinguish itself from close siblings like nvr_get_device_info or nvr_get_time, which is the only gap.

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 guidance, no prerequisites, and no mention of alternatives despite overlapping siblings (nvr_get_device_info, nvr_get_time). The parenthetical '(read-only)' hints at safety but does not route the agent between candidates.

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 present, the description carries the full burden and does disclose two meaningful traits: the operation is read-only and include_raw places the raw reply at data.raw. It omits any auth requirement (relevant given the nvr_login sibling), which keeps it from 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?

Two tight sentences, purpose front-loaded in the first clause and the parameter detail second. Nothing is wasted and the read-only qualifier is placed where it is immediately visible.

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

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

An output schema exists, so return values need no explanation, and the description covers purpose, safety posture and the one parameter. Only the missing usage/alternative guidance and auth context keep it below 5 for a tool embedded in a large family of getters.

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% for the single include_raw boolean, so the description must compensate, and it does: it explains exactly what setting include_raw=true does and where the extra data appears. This meaning is absent from the schema itself.

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

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

States a specific resource (device time, time zone, NTP and DST configuration) with an implied read verb, which clearly distinguishes it from storage/network/video siblings. It does not explicitly name what separates it from adjacent getters like nvr_get_device_info or nvr_get_system_info, so it stops short of 5.

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

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

The '(read-only)' tag hints that this is a safe fetch, but there is no statement of when to call this tool versus the many other nvr_get_* getters, and no prerequisites are given. Usage must be inferred entirely from the name.

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 load and does well: it declares the operation read-only, guarantees credentials are never returned, and explains the redaction behavior of include_raw. It omits auth requirements and pagination, which keeps 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?

Two tight sentences with zero filler; the payload scope and safety guarantee are front-loaded before the optional-parameter note.

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

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

An output schema exists, so return-value detail is not required, and the description covers scope, safety, and the one parameter. The missing piece is authentication prerequisites, which is relevant given the nvr_login and nvr_auth_status siblings.

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 the single parameter, and it does: include_raw=true is explained as adding the redacted raw reply at data.raw, giving both effect and output location. Only the default value is left 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?

States a specific verb+resource (get NVR user accounts) and immediately bounds the payload: 'names and groups only (credentials are never returned)'. No sibling in the list covers user accounts, so an agent can route here 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?

The read-only framing and the scope statement imply the use case (inspecting who has accounts and what groups they belong to), but there is no explicit when-to-use, prerequisite (e.g. nvr_login first), or alternative-selection guidance. With no overlapping sibling, the gap is tolerable rather than harmful.

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

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

With no annotations, the description carries the full burden. It does disclose that the operation is read-only and that include_raw surfaces the unprocessed device reply under data.raw, which is genuinely useful behavioral detail. It omits anything about authentication requirements, failure modes, or per-channel scoping/cost.

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

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

Two compact sentences, front-loaded with what the tool returns and followed by the one parameter worth explaining. No filler and no repetition of the tool 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?

An output schema exists, so return values need not be explained, and the description covers the sole optional parameter's effect. For a simple read-only config getter with one flag, this is nearly sufficient; only auth/error behavior is left implicit.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that include_raw=true additionally returns the unprocessed device reply under data.raw, which is more than the schema's bare title/default conveys. It could still clarify whether the flag affects response size or performance.

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

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

Names a specific resource (per-channel video stream config) and enumerates its contents: main/minor resolution, codec, bitrate tables and encoder settings. It is clear what an agent gets back, though it does not explicitly distinguish itself from the closely related nvr_get_video_resolutions or nvr_get_image_config siblings.

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

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

Contains no when-to-use guidance and names no alternatives, despite several overlapping siblings (nvr_get_video_resolutions, nvr_get_image_config) that an agent could easily confuse it with. The only usage-like statement concerns the include_raw flag, not tool selection.

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

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

No annotations are supplied, so the description carries the full burden, and it does disclose the key trait: '(read-only)'. However, it says nothing about permissions required, caching, or whether the resolution tables are static or derived from live stream state, leaving behavioral gaps for a tool with zero annotation coverage.

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

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

A single compact fragment with no wasted words, and the read-only marker is included up front. It is a noun phrase rather than a sentence, which makes it slightly less front-loaded as an action statement.

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

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

An output schema exists, so return values need no explanation, and a zero-parameter read-only call is simple to invoke correctly. Still, the description omits any hint of the distinction from its many sibling 'get_*_config' tools, which is the main thing an agent needs to choose wisely.

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. The description correctly implies no filtering or selection inputs are needed, consistent with the empty schema.

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

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

The description names a specific resource — main/minor stream resolution tables — so an agent knows it returns encoding resolution metadata rather than the broader config returned by siblings like nvr_get_video_config. The verb is implicit in the name rather than stated in the description, and no sibling is explicitly contrasted.

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

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

There is no guidance on when to call this instead of nvr_get_video_config or nvr_get_image_config, both of which are plausibly adjacent. No prerequisites, exclusions, or alternative paths 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?

No annotations are provided, so the description carries the burden. It does disclose the key trait ('Read-only') and hints at the response contents, which is genuinely useful. However, it says nothing about auth requirements, whether the catalog is per-session, or rate/scope limits, leaving behavioral gaps for a no-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?

One sentence, front-loaded with the action and scope, with the parenthetical detail of returned fields placed after the core statement. No filler. Slightly dense but efficient.

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

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

An output schema exists, so the description need not explain return values, and the 'Read-only' note covers the safety angle. The gap is the unresolved module-identifier format and the absence of any pointer to companion tools (nvr_call, nvr_describe_call), which an agent needs to act on the listed calls.

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% and the single required parameter ('module') has no schema description. The description only restates 'for one module', which duplicates the parameter name rather than clarifying its expected format (ID, name, index?). With zero coverage it should have compensated, and it largely does not.

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 ('catalogued calls for one module') and even enumerates what each catalogued entry contains (method, key, mutates flag, example, response-shape hint). This distinguishes it well from siblings like nvr_call/nvr_raw_call (which execute calls) and nvr_list_modules (which lists modules). It stops short of naming those siblings explicitly, so it is clear but not sibling-routing.

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 intent (discover the callable surface of a module) is implied by the description, but there is no explicit when-to-use, no prerequisite (e.g. must be logged in), and no statement of when to prefer nvr_describe_call, nvr_call, or nvr_get_module_spec instead. Usage is inferable but not guided.

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 meaningful behavior beyond the schema: 'Credential fields always redacted.' However, it says nothing about read-only safety, auth requirements, or pagination, leaving significant behavioral gaps for a tool with zero annotation coverage.

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 terse fragments with no wasted words and the resource stated up front. The cryptic '(chm added_dev)' parenthetical occupies space without informing the caller.

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

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

An output schema exists, so return values need not be described, and zero params means little schema burden. Still, the description omits any when-to-use context and leaves the opaque parenthetical unexplained, so it is only minimally adequate.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter syntax for the description to document and the schema is empty.

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 phrase 'All bound NVR channels' gives a clear verb-implied resource and scope, and the plural 'channels' distinguishes it from the sibling nvr_get_channel. The parenthetical '(chm added_dev)' is opaque internal shorthand that adds no clarity for an agent, which keeps it 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?

There is no indication of when to call this versus alternatives such as nvr_get_channel, nvr_find_duplicate_channels, or nvr_list_modules. The agent must infer the use case entirely from the name.

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 two useful traits: the operation is read-only and returns a raw reply. It stops short of stating permission requirements, whether the raw reply format differs from other list tools, or any rate/refresh considerations.

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

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

A single compact phrase with no filler, and the resource is front-loaded before the qualifier. It is arguably too terse, but nothing in it is wasted.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. For a simple zero-arg list tool the description is nearly sufficient; only the missing sibling disambiguation 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 the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already communicates.

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

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

The description names a specific resource (installed hard disks) and the attribute it reports (their state), so the operation is unambiguous. It does not, however, distinguish itself from the nearby sibling nvr_get_storage, which an agent could 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?

There is no when-to-use guidance, no condition under which this is preferred over nvr_get_storage or nvr_get_system_info, and no stated prerequisites. The agent is left to infer the context entirely from the name.

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 add real behavioral color beyond the schema: 'read-only', 'best-effort' (results may be incomplete), and that only events with a 'parseable time' are filtered. However it says nothing about authentication/session requirements, result caps, or pagination, which matters given the nvr_login sibling in this family.

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 compact sentences, front-loaded with what the tool returns, then parameter guidance, then the side-effect of include_raw. No filler, though the parenthetical category list and 'and similar' hedge add slight looseness.

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

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

An output schema exists, so return-value explanation is correctly omitted, and the two optional params are covered. The gap is operational context: nothing about whether a login/session is required before calling, which is a meaningful omission in an NVR tool family that includes nvr_login and nvr_auth_status.

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

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

Schema coverage is 0%, so the description must carry both parameters and it does: 'since' is documented as an ISO-8601 timestamp whose effect is to drop older events with parseable times, and 'include_raw' is documented as adding the raw reply at data.raw. This is nearly complete, missing only the no-argument default behavior.

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

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

States a specific verb and resource ('list of recent NVR events/alerts'), enumerates the event categories (disk, network, video-loss) and marks it read-only, which distinguishes it from siblings like nvr_list_motion_windows and nvr_list_recording_segments. It does not name an alternative 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?

The description explains how to use the 'since' parameter but gives no guidance on when to reach for this tool versus nvr_list_motion_windows, nvr_search_recordings, or nvr_get_recording_status. There are no exclusions or prerequisites stated, only a usage mechanic for one parameter.

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 must carry the full behavioral burden. It discloses read-only status and the return fields, but says nothing about auth requirements, directory scoping, rate limits, or whether the listing is paginated.

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, front-loaded sentences with no waste. The output fields are grouped parenthetically and 'Read-only' is appended compactly, though the very terse style leaves room for a bit more useful context.

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

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

For a simple, parameterless listing tool with an output schema already covering return values, the description is nearly sufficient. It could still note auth or directory constraints, but nothing essential to correct invocation 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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4. The description's mention of name/bytes/mtime pertains to output rather than inputs.

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 mp4/jpg files in the export directory') and even names the returned fields (name, bytes, mtime). It is clear what the tool does, but it does not differentiate itself from siblings like nvr_get_export or nvr_list_recording_segments.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as nvr_get_export. The only hint is 'Read-only', which speaks to behavior, not to when this tool should be selected over its siblings.

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 and does state 'read-only' and 'no device I/O', which is exactly the safety characteristic an agent needs. It stops short of describing whether results are cached, how counts are computed, or expected cardinality, but the core behavioral profile is disclosed.

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 waste. Verb, resource, payload shape, and safety note all appear before any padding.

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

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

An output schema exists, so return value detail is not required. For a zero-param read-only listing tool the description is essentially complete; only marginal guidance about using nvr_get_module_spec for deeper inspection 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?

With zero parameters the baseline is 4; there is nothing to mis-specify and no compensating detail needed. The description correctly implies a no-argument call.

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 (List) and resource (API modules the NVR exposes), and clarifies the scope is the module inventory with call counts. Sibling tools like nvr_get_module_spec operate on a single module, so an agent can distinguish this inventory tool from the spec 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 parenthetical suffix 'read-only; no device I/O' signals when this is appropriate (safe discovery). However, it does not explicitly name alternatives such as nvr_get_module_spec or nvr_describe_call for drilling into a single module/call, leaving some routing to inference.

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

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

With no annotations present, the description carries the full burden and does declare 'read-only' plus the merge/dedup semantics (overlap within min_gap_s merged, windows under min_len_s dropped) — meaningful behavioral context. It omits auth requirements, rate limits, and error behavior, but covers the operation's core behavior well.

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?

It is a dense but well-ordered paragraph: purpose first, then merge behavior, then time/parameter guidance, then return shape. Nearly every clause earns its place, though the return-shape sentence is arguably redundant given the output schema.

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

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

For a complex 8-parameter, zero-annotation tool, the description is close to complete: it explains the merge model, all meaningful parameters, and the default kinds. Minor gaps remain (tz semantics, auth/permission needs), and the return explanation is redundant since an 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?

Schema description coverage is 0%, so the description must compensate, and it does: it documents channel ('1-16 or "all"'), date format, since/until as ISO-8601, kinds default ('motion/smart/alarm'), and the min_gap_s/min_len_s merge semantics. Only tz ('local' default) is left unexplained.

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

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

The description names a specific verb and resource ('Merged, de-duplicated activity windows for one channel') and clarifies the mechanism by stating it 'Combines the typed recording timeline with event logs.' It implicitly separates itself from nvr_list_events and nvr_list_recording_segments by describing the merge of both, though 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?

It gives real usage guidance for the time selector ('Provide date (YYYY-MM-DD) or since (ISO-8601); optionally narrow with since/until') but offers no when-to-use-vs-alternative routing against siblings like nvr_search_recordings. Usage is implied through parameter guidance rather than explicit task conditions.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation read-only, enumerates the returned fields and type values, explains include_raw and tz, and discloses an error mode (PROTOCOL_ERROR with payload under data.raw). It omits auth/session requirements and any pagination or size limits, which keeps 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?

A single dense paragraph, front-loaded with what the tool returns before the parameter notes and error behavior. Every clause adds information; there is no filler or restatement of the tool 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?

An output schema exists so return values need not be explained, yet the description still maps the record fields usefully. For a read-only listing tool this covers what an agent needs, with the only real gap being authentication prerequisites that the sibling nvr_login implies are required.

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

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

Schema description coverage is 0%, so the description must compensate and it does: channel range (1-16), date format (YYYY-MM-DD), tz accepted values ('local', 'utc', or IANA zone), and include_raw semantics (adds raw device reply at data.raw). All four parameters are documented with meaning beyond the bare schema types.

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 precise resource and scope: a typed recording timeline for one channel (1-16) on one day, with the returned record shape spelled out. That is far more specific than siblings like nvr_get_recording_status, though it never explicitly contrasts itself with nvr_search_recordings, which is the closest alternative.

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 describes what the tool returns but gives no when-to-use guidance, no exclusions, and does not mention when to prefer nvr_search_recordings or nvr_list_motion_windows instead. The single-channel/single-day scope hints at the use case but nothing is 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 behavioral burden and does so well: it discloses that this performs exactly one attempt and is never retried, that automatic logins stop after failures, and that the server refuses further attempts once its failure budget is spent. These are critical operational traits beyond the empty schema.

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

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

The definition is short and front-loaded: the primary action is stated first, followed immediately by the important caveats. Every sentence contributes operational guidance without 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 login tool with an output schema already present, the description is complete enough: it explains normal automatic behavior, when explicit login is needed, retry limits, and failure-budget consequences. No critical invocation context appears to be 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?

There are zero parameters, so the rubric baseline is 4. The description appropriately adds no parameter semantics because none exist; the schema's emptiness is not a 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?

The description states a specific verb and resource: 'Explicitly log in to the NVR.' It also distinguishes this manual login operation from ordinary NVR tool calls by explaining that the first NVR tool call normally logs in automatically.

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 explicit when-to-use and when-not-to-use guidance: 'Normally unnecessary' because the first NVR tool call handles login, but use it after failed logins stop automatic authentication and the cause has been fixed. It also describes the failure-budget limit and refusal-until-restart behavior.

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 well: it discloses that credentials/settings survive the move, that occupied targets are refused rather than overwritten, and that before/after rows are returned. The 'same gates as nvr_remove_channel' cross-reference is a weak spot since the agent must look up that other tool to learn the actual gating conditions.

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: purpose first, then the failure mode, then gating and return shape. No filler, no repetition of the schema, and the most decision-relevant fact (occupancy refusal) is front-loaded.

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 unannotated mutation tool this covers the essentials: preservation semantics, refusal behavior, shared gating, and return shape, and an output schema exists so return detail is not required. The gaps are the unexplained expected_uuid and the external reference for the actual gate conditions.

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 25%, with only confirm_write documented. The description conveys old_id/new_id roles contextually (source binding, target slot) and the occupancy constraint on new_id, but says nothing about the required expected_uuid, leaving an unexplained required parameter in both schema and description.

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

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

States a specific verb and resource ('Move a binding to another channel slot') and even names the underlying firmware call (chm_mod_dev_chn), so the agent knows exactly what operation this performs. It also implicitly separates itself from destructive siblings like nvr_remove_channel by noting credentials and settings are preserved.

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 a concrete precondition ('Refuses if new_id is occupied') and defers to a sibling's prerequisites ('Same gates as nvr_remove_channel'), which is useful routing context. However, it never states when to prefer this over a remove-then-add sequence or any other sibling, so usage is only implied rather than prescribed.

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, and it does well: declares 'Read-only' and 'Nothing is written', describes the returned summary and unsafe_if blocking conditions (duplicate uuids, >8 real cameras, online ghost). It could go further on preconditions/assumptions but the behavioral profile is largely disclosed.

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

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

Front-loads the key constraint ('Read-only') and the plan structure, and every clause adds information about steps or return shape. It is somewhat dense with multiple clauses, but there is little waste.

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

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

Despite an output schema existing, the description fully explains the plan's shape, per-step tool/argument/precondition structure, the summary, and the unsafe_if conditions. For a zero-param planner whose job is orchestration, nothing an agent needs 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 takes zero parameters, so there is nothing for the description to add about inputs; baseline 4 applies. The schema is trivially complete for an empty argument object.

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: 'Produce an ordered, resumable cleanup plan' with concrete sub-steps (back up config, remove ghosts, re-read, move cameras). This clearly distinguishes it from the write siblings (nvr_remove_channel, nvr_move_channel) since it only plans rather than mutates.

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 frames the workflow: 'Nothing is written; hand each step to the matching write tool yourself,' which tells the agent this is a planning step preceding the write tools. It doesn't name the specific write tools or say when NOT to use it, but the read-only planning role is clear.

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 well: it discloses the double-gate requirement, the environment flag needed, the default retention window, and the dry-run preview path. It does not state whether purged exports are recoverable or what happens if the retention env var is unset beyond the default, leaving a small gap for a destructive operation.

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 with no filler, front-loading the action and retention rule before the gating and preview details. 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?

An output schema exists, so return values need not be explained, and the description covers scope, gating, and dry-run preview adequately for a destructive retention purge. Minor omission: it never confirms irreversibility or whether the retention-days variable can be overridden per call.

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

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

Schema coverage is 100% and the single parameter's meaning (confirm_write must be literal boolean true) is fully documented in the schema. The description only echoes the gating semantics via the env flag, adding marginal value over the structured field — 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 precise verb+resource+predicate: delete exports older than a retention window (default 7 days). The retention-scoped bulk nature clearly separates it from the sibling nvr_delete_export, which acts on a single export, without needing to read either schema.

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

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

Gives concrete prerequisites for invocation (VIGI_NVR_ALLOW_WRITES=true plus confirm_write=true) and points at a safe alternative mode (VIGI_NVR_DRY_RUN=true) to preview the operation. It stops short of explicitly telling the agent when to prefer this over nvr_delete_export, so it is strong context rather than explicit routing.

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

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

With no annotations, the description carries the full burden and does so well: write-gate requirement for non-get methods, permanently refused modules, WARNING-level logging, VIGI_NVR_DRY_RUN support, and credential redaction in replies. The one gap is "both write gates," which is never enumerated, leaving the second gate ambiguous.

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 clause earns its place: safety posture, alternative, exclusions, logging, dry-run, redaction. The load-bearing info (escape hatch + prefer nvr_call) is front-loaded and there is 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?

An output schema exists so return values need no explanation, and the description covers authorization, refusals, logging, and dry-run for a mutating raw-call tool. Only the ambiguous "both write gates" phrasing and the undocumented params object keep 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?

Schema coverage is only 25% (only confirm_write is documented), so the description must compensate and largely does: it explains method="get" vs. mutating methods and constrains the module namespace. The params object itself is left entirely unexplained, so the compensation is incomplete.

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

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

Opens with a concrete metaphor plus mechanism ("Off-catalog escape hatch: send {method, module: params} directly"), so the agent immediately knows this bypasses the named-call catalog. It also explicitly names the sibling it is not ("Prefer nvr_call"), making it distinguishable without opening either schema.

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

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

Gives an explicit alternative and preference ("Prefer nvr_call") plus hard exclusions (login and user_management always refused; non-get methods need write gates). It stops short of stating the positive condition under which the escape hatch is actually warranted (i.e. the method is missing from the catalog).

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

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

With no annotations, the description carries the full burden and does so richly: it declares DESTRUCTIVE, the required env flag, the boolean-strict confirm_write gate, the optimistic-concurrency expected_uuid check, the online=='1' refusal with a force override, dry-run support, and the before/after return shape.

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

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

Front-loaded with the verb and DESTRUCTIVE warning, then prerequisites and edge-case behavior in terse, high-density sentences. No filler; every clause conveys a constraint or 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?

For a destructive mutation with zero annotations, it covers prerequisites, refusal conditions, override, dry-run, backup recommendation, and return shape; the presence of an output schema means return values need no further explanation. Nothing an agent needs to invoke it safely is missing.

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

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

Schema coverage is only 25% (only confirm_write documented), so the description must compensate: it explains expected_uuid semantics (must equal the live row's uuid) and force (bypass the connected-camera refusal), plus channel_id's role as the target row. This is strong added meaning, though it doesn't restate the confirm_write type nuance the schema already covers.

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 ('Unbind one channel') and even names the underlying method (chm_del_dev), which lets an agent distinguish it from siblings like nvr_move_channel or nvr_plan_channel_cleanup without opening a schema.

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

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

Gives clear operational context: run nvr_backup_config first, when force=true is required (connected camera), and the write-enable prerequisites. It stops short of explicitly contrasting with the alternative cleanup/move tools, so no explicit when-not guidance, but the usage conditions are concrete.

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 safety profile (read-only), the output format (JPEG), the return fields (name, path, timestamp), the spacing control, and a cap via max_frames. It omits rate-limit, payload-size, and empty-window behavior, which matters for a frame-extraction 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?

Front-loaded and dense: format, interval, window, cap, read-only, return shape, then the routing hint. Minor repetition ('every every_s seconds') and a slightly redundant return-field listing given an output schema exists, but no wasted sentences.

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

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

For a 6-parameter read-only sampling tool, the description covers timing format, sampling interval, frame cap, and the recommended workflow, and an output schema exists so return structure need not be explained. The gap is the unexplained channel/stream parameters and undefined behavior when the window contains no recording.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does: it explains every_s, max_frames, and the ISO-8601 start/end format with the UTC-offset requirement. The required parameter channel and the stream parameter receive no explanation anywhere, leaving two of six parameters opaque.

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

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

States a specific verb and resource: sampling individual JPEG frames from an NVR replay window at a fixed interval. It implicitly distinguishes itself from the sibling nvr_contact_sheet by positioning itself as the follow-up step ('after a contact-sheet hit'), though it does not explicitly contrast against nvr_snapshot or nvr_export_clip.

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 usage context: use this after a contact-sheet hit to pin the exact moment, which tells the agent when to reach for it rather than a coarser tool. It stops short of stating when not to use it (e.g. for bulk export, use nvr_export_clip).

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key 'read-only' trait, which substitutes for a missing readOnlyHint, but says nothing else about behavior (invalid channel handling, result shape, or the include_raw effect). It meets the minimum bar but does not add rich behavioral context.

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

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

Two compact sentences with zero filler; the compatibility/alias fact is front-loaded ahead of the functional description. Efficient, though the parenthetical could be placed to lead even more clearly.

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

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

An output schema exists, so return values need not be described, and the description covers purpose, read-only nature, and the two required parameters well. The only gap is include_raw, which is minor for a simple list tool but not fully resolved.

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

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

Schema coverage is 0%, so the description must compensate. It adds real meaning for two of three parameters (channel range 1-16, date format YYYY-MM-DD), but include_raw is left entirely unexplained in both the schema and the description, leaving one parameter 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 ('Lists recorded segments for one channel on one day') and explicitly identifies itself as an alias of nvr_list_recording_segments, which is a sibling tool. An agent can distinguish it from the canonical tool and understand its scope 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 '(kept for compatibility)' note signals this is a legacy duplicate and points the agent toward the canonical sibling, which is useful routing context. However, it never states an explicit preference or condition ('prefer nvr_list_recording_segments for new work'), so the guidance is implied rather than prescriptive.

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 supplied, the description carries the full behavioral burden and does reasonably well: it declares read-only semantics, states the external prerequisites (RTSP + ffmpeg), clarifies the stream default, and previews the return payload. It stops short of covering failure behavior or where the export dir physically lives.

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 clauses with the core action front-loaded, then read-only/default, then prerequisites and output. No filler sentences; every fragment adds an actionable fact.

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

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

An output schema exists, so the description needn't detail return values, yet it still summarizes path/bytes/sha256 helpfully. Combined with the read-only and prerequisite notes, it is nearly complete for a two-param tool, with only channel semantics left uncovered.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for 'stream' (2=sub, beyond the bare schema default) but leaves 'channel' entirely unexplained—no indication of valid range, numbering, or how to discover it via nvr_list_channels.

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 one JPEG frame from a channel's live stream into the export dir.' The 'one JPEG frame' phrasing cleanly separates it from siblings like nvr_sample_frames or nvr_contact_sheet that handle multiple frames, so an agent can route 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?

Gives a real prerequisite ('Needs RTSP enabled and ffmpeg available') and notes read-only behavior, which is useful context for invocation. However, it never names an alternative tool or states when to prefer this over nvr_sample_frames/nvr_export_clip, so 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 burden, and it does disclose a meaningful trait: it never logs in, so calling it will not open a session or change auth state. It also signals that lockout counters and safety policy are surfaced, which tells the agent this probe is safe to run even when an account is locked out. It stops short of stating rate-limit or lockout-triggering behavior.

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

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

A single front-loaded sentence that leads with the category ('Healthcheck:') and then lists the reported facets; nothing is wasted. The telegraphic noun list is slightly terse but still readable.

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

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

An output schema exists, so the description need not explain return values, and it correctly focuses on what is inspected and the no-login guarantee. The remaining gap is the absence of routing guidance versus the many sibling status/info tools, which is a minor omission for a zero-argument probe.

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 and the baseline is 4. The schema confirms an empty object, and the description adds no misleading argument hints.

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 the tool as a healthcheck and enumerates the specific resources it reports on: reachability, offered auth scheme, lockout counters, local session state, and safety policy. This is concrete enough to separate it from a generic info getter, but it never names the closest sibling (nvr_auth_status) or explains the boundary between them.

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

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

The closing 'Never logs in' implicitly contrasts this with nvr_login, hinting at when a safe, side-effect-free probe is appropriate. However, there is no explicit when-to-use or when-not-to-use statement, and no mention of alternatives such as nvr_auth_status or nvr_get_system_info, so an agent must infer the routing.

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