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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description's added content is a field-by-field return list, which is redundant because an output schema already exists, and it discloses nothing about auth, scoping, or error 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?

Front-loaded and short, which is good, but roughly half the text is a return-field enumeration that duplicates the output schema, and the trailing '(7.1.83 docs)' citation consumes space without helping invocation.

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

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

For a simple single-ID read with a full output schema and readOnly annotations, the description covers what the agent needs to call it correctly. Only the missing routing versus protect_list_alarm_hubs keeps it short of 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 description coverage is 100% for the single 'id' parameter, so the schema fully documents its meaning. The description only restates 'by ID' and adds no format, prefix, or sourcing guidance beyond 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 ('Get') and resource ('alarm hub') plus the lookup key ('by ID'), so the agent knows this is a single-resource fetch. It does not, however, differentiate itself from the sibling protect_list_alarm_hubs or acknowledge the odd 'linkstation' modelKey overlap with protect_get_link_station.

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 the natural alternative (protect_list_alarm_hubs) for enumerating hubs. The agent must infer that 'by ID' implies it already has an ID from a prior list call.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond that — no auth requirements, no rate limits, no error behavior — and its return-field list duplicates the existing output 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?

Two short sentences, front-loaded with the action and resource, with no filler. The enumerated return fields are somewhat redundant against the output schema but cost little.

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

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

For a single-parameter read tool with annotations covering safety and an output schema covering returns, the description is essentially complete. Only the origin of the ID (which list tool supplies it) 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?

There is a single parameter with 100% schema description coverage ('Bridge ID'), so the schema already documents it fully. The description restates 'by ID' without adding format, sourcing, or validation detail, 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 (get), resource (bridge), and scope (by ID), which is unambiguous. It does not explicitly contrast with the sibling protect_list_bridges or protect_get_link_station, but the get-vs-list naming makes the distinction inferable.

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

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

The phrase 'by ID' implies the caller must already have a bridge ID, likely from protect_list_bridges, but no when-to-use condition or alternative tool is named. 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?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses a live-confirmed behavioral fact (identical field set to list entries, no extended payload) and enumerates what the API does NOT expose (recording state, motion events, zones, RTSP config). That is exactly the kind of absence-of-data context that prevents wasted calls.

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

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

Front-loaded with the core action, then layered with useful caveats. The parenthetical field enumeration is long, but each clause earns its place by defining the payload shape and its limits.

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, yet the description still completes the picture by clarifying what the returned fields are and what is absent. Nothing an agent needs to call this correctly 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 100% schema description coverage and a single documented 'id' parameter, the schema already carries the parameter semantics. The description only echoes 'by ID' and adds no format, source, or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get details for a specific camera by ID'), which is unambiguously distinct from the sibling protect_list_cameras. An agent can immediately tell this is the by-ID fetch versus the list operation.

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

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

The description gives clear context for when this is worth calling: it warns that the payload equals protect_list_cameras entries, so an agent that already listed cameras need not re-fetch. It does not, however, explicitly name protect_list_cameras or state a when-not-to-use rule, leaving that 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the version-verification note ('verified live 7.1.83') and field-level return shape, but since an output schema exists, most of that field list is redundant rather than new 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?

Front-loads the purpose in the first clause, then gives the return shape. The field enumeration is long but each item is concrete; only the nested-object expansion borders on surplus given an output schema is present.

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

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

For a single-parameter read tool with an output schema and read-only annotations, the description is more than sufficient — it even over-delivers by restating the return fields. Nothing needed to invoke it correctly 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?

Only one parameter, and the schema documents it at 100% coverage ('Chime ID'). The description's 'by ID' adds no syntax, format, or sourcing 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 and resource ('Get full details for a specific chime by ID'), which clearly distinguishes it from the list-style sibling protect_list_chimes. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

The 'by ID' phrasing implies the caller must already have a chime ID, conventionally obtained from protect_list_chimes, but the description never says so or names an alternative. Usage is implied by the getter pattern rather than explained.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description does not contradict them, but it adds no behavioral traits beyond the annotations; the returned fields are covered by the output 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 first sentence is concise and front-loads the purpose. The second sentence enumerates return fields that are already provided by the output schema, so it does not fully earn its place.

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

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

With an output schema and explicit read-only annotations, the description needs only to state the resource and ID scope, which it does. The only minor gap is guidance on obtaining the fob ID, but that is not critical for a simple getter.

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 id parameter is documented as 'Fob ID'. The description only repeats 'by ID' and adds no format or semantics 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?

The description states a specific verb (Get), resource (fob), and scope (specific fob by ID). It clearly distinguishes the tool from protect_list_fobs and from other protect_get_* siblings by naming the resource.

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

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

The phrase 'by ID' implies that an ID is required, but there is no explicit guidance on when to use this tool versus protect_list_fobs or the other getters. 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only that the payload contains applicationVersion, which is largely redundant with the existing output schema, and says nothing about latency, auth, or scope beyond the app itself.

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 verb and resource, and no filler. Every clause earns its place.

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

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

For a zero-parameter, read-only tool with an output schema already defining the return shape, the description contains everything an agent needs to call it correctly. There is no meaningful gap left to fill.

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 of 4 applies. No misleading parameter claims are made.

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 a specific resource ('UniFi Protect application information'), which is clearly distinct from the sibling device-scoped tools like protect_get_camera or protect_list_nvrs. An agent can identify this as the application-level info endpoint 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 — this is the only tool for application-level metadata, so there is no real alternative to route to — but the description never states when an agent should reach for it (e.g., version checks or capability probing). No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds a field-level return preview, which is mild but real context beyond the annotations; it says nothing about failure modes or data freshness.

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

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

Purpose is front-loaded in the first clause, which is correct. The long parenthetical enumeration of return fields is bulky and largely duplicates the declared output schema, but it is a single structured list rather than rambling prose, so it remains scannable.

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

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

For a one-parameter read-only getter, the description covers purpose and payload sufficiently and the output schema carries the return contract. The redundant field dump is the only excess; nothing an agent needs to invoke it correctly 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 100% and the single required 'id' parameter is fully documented in the schema. The description only restates 'by ID' and adds no format, prefix, or sourcing details beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Get full details for a specific light by ID.' The single-item framing implicitly distinguishes it from protect_list_lights, but the description never names that sibling or any other get_* counterpart, so differentiation is left to inference.

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

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

Usage is implied by 'for a specific light by ID' — an agent can infer this is the tool for fetching one light once it has an ID. There is no explicit when-to-use guidance, no mention of when to prefer protect_list_lights, and no note on error behavior for unknown IDs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return-field inventory and a docs version reference ('7.1.83 docs'), which is mild extra context but no error/not-found or permission behavior for an ID lookup.

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. The returns enumeration is somewhat redundant against the existing output schema but is compact and not padded.

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

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

For a single-parameter read with a full output schema and covering annotations, the description is sufficient to invoke correctly. The return-field list and doc-version note are the only extras, and nothing essential is missing.

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

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

Schema coverage is 100% and the single parameter already documents 'Link station ID'. The description's 'by ID' adds nothing beyond the schema, so this is the baseline 3 for a fully documented parameter set.

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 full details for a specific link station by ID') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not explicitly contrast itself with the sibling protect_list_link_stations, but the singular/ID-based framing makes the distinction inferable.

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 statement of when to use this tool versus protect_list_link_stations or protect_get_alarm_hub, nor any prerequisites. Usage is only implied by the name and the ID 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Beyond that, the description explains the critical round-trip behavior with PATCH replacing the slots array – real behavioral context that helps the agent avoid data loss. The output field list overlaps with the output schema, but the slot-level detail is useful.

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

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

Two sentences, front-loaded with the purpose, followed by the relevant return shape and the update caveat. Efficient with minimal waste, though the return field enumeration is partially redundant with an existing 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 simple single-parameter read tool with an output schema present, this description covers purpose, return shape, and the key behavioral caveat about PATCH replacing slots. Nothing needed for 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?

Schema coverage is 100%, so the single 'id' parameter is fully documented in the schema. The description adds no syntax or format details beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get details for a specific live view by ID'), consistent with the get-by-id pattern in its sibling set (protect_get_camera, protect_get_user, etc.). An agent can tell it apart from protect_list_liveviews without ambiguity.

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?

Provides a clear usage condition by linking to the update workflow ('needed when updating because PATCH replaces the slots array'). It does not explicitly name protect_update_liveview or warn about when not to call it, but the context is sufficient for correct invocation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds the returned field surface (state, ledSettings, outputs, inputs, wirelessConnectionState) with a docs version reference, but says nothing about error behavior for an invalid/missing ID or any auth requirements.

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

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

Two tightly written sentences with the operation front-loaded and the payload enumerated compactly. The return-field list is somewhat redundant given an output schema exists, but it costs little and is not padded.

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

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

For a simple single-ID getter with full annotations and an existing output schema, the description is sufficient: the agent knows what it fetches and what comes back. Missing only edge-case behavior (unknown ID, permissions), which is minor here.

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

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

Only one parameter ('Relay ID') with 100% schema description coverage, so the schema carries full semantic load. The description's phrase 'by ID' restates the schema rather than adding format or sourcing detail, which is the baseline case.

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 full details for a specific relay by ID'), so the agent knows exactly what the tool returns. It does not explicitly contrast with its obvious sibling protect_list_relays, but the get/list naming pattern makes the distinction inferable.

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

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

Usage is only implied: the tool takes a single required ID, which signals 'use this once you know which relay you want', versus protect_list_relays to discover IDs. No explicit when-to-use, prerequisites, or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful return semantics: the quality keys (high, medium, low, package) and the meaning of empty/missing keys, which no annotation conveys.

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

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

Three tight sentences, front-loaded with the purpose, then return shape, then the follow-up action. No 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?

For a simple one-parameter read tool with annotations and an output schema, the description covers purpose, return key semantics, and next-step routing. 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?

Only one parameter (id) and schema coverage is 100%, so the schema already documents it as the Camera ID. The description adds nothing beyond implying the scope is a single camera, which is the expected baseline when the schema does the work.

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 (active RTSPS stream sessions) scoped to a camera, and immediately clarifies what is returned (per-quality stream URLs). This is easily distinguishable from the sibling get/list tools.

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

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

Explicitly explains the empty/missing-key condition and routes the agent to protect_create_rtsp_stream when a session needs to be started. This is exactly the when-to-use/when-to-switch guidance an agent needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a long return-field inventory, but with an output schema present that content is largely redundant, and it discloses nothing about auth, rate limits, or error behavior.

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

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

The purpose is front-loaded, but the bulk of the text is a 25+ item return-field enumeration that duplicates the output schema and adds little value. This is bloat rather than earned content.

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 read-only single-parameter getter with an output schema and covering annotations, the definition is functionally sufficient. The only real gap is the missing pointer to protect_list_sensors for obtaining an id.

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% with a single 'id' parameter already described as 'Sensor ID.' The description restates 'by ID' without adding format, source, or lookup semantics beyond the schema. Baseline 3 is correct.

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

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

Clear verb+resource+scope: 'Get full details for a specific sensor by ID.' The 'specific...by ID' phrasing implicitly separates it from protect_list_sensors, but no sibling is named explicitly. An agent can identify the operation, just without an explicit contrast.

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 mention of protect_list_sensors as the way to discover a valid id, and no prerequisites or auth notes. The agent gets no routing help versus alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description does not add behavioral context such as error behavior for an unknown ID, staleness of state, or rate limits; its field list is return-value content, not 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?

Front-loaded with the core action in one sentence, followed by a compact field enumeration. The enumeration is somewhat redundant given an output schema exists, but nothing is padded or buried.

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

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

For a one-parameter read tool with both annotations and an output schema, the definition is nearly sufficient. The remaining gap is the absence of guidance on how to obtain a valid ID and what happens on a missing/invalid 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?

Schema description coverage is 100% for the single 'id' parameter, so the schema already documents it fully. The description adds only the phrase 'by ID' and no format, prefix, or source guidance beyond the schema. Baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('siren') with the scope qualifier 'by ID', which is enough to separate it from the sibling protect_list_sirens 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?

Usage is only implied: a caller who already holds a siren ID and wants full details. No explicit when-to-use, no prerequisite (e.g., obtain ID from protect_list_sirens), and no stated alternatives.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds value by specifying the return format (base64-encoded image/jpeg) and the conditional behavior for package camera capture, enhancing transparency beyond annotations.

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

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

The description is concise, with two sentences that front-load the main purpose. Every sentence provides essential information, and there is no redundancy or 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?

Given the simple nature of the tool and good annotations/schema, the description is complete enough. It covers the return type and parameter guidance. No output schema exists, but the description compensates by explaining the output format.

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% with parameter descriptions, but the description adds meaningful semantics: highQuality=true for full-resolution and channel=package for secondary camera usage. This provides context that the schema alone lacks.

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

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

The description clearly states the tool's function: 'Get a JPEG snapshot from a camera.' It specifies the verb and resource, and the mention of base64-encoded output distinguishes it from other protect_get_* siblings which retrieve different device data.

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

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

The description provides explicit guidelines for parameter usage: use highQuality=true for full-resolution and channel=package for secondary camera on doorbells with hasPackageCamera=true. This helps the agent decide when to use these parameters, though it does not explicitly state when not to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond a field list that the output schema already provides — nothing about error handling, auth requirements, or freshness of the returned state.

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

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

The purpose sentence is well front-loaded, but the enumerated return fields duplicate the output schema and the trailing '(7.1.83 docs)' is unexplained noise that does not earn its place.

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

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

For a simple single-parameter read tool with an output schema and read-only annotations, the description covers the essentials. It is slightly padded with redundant return-field detail rather than adding routing or failure guidance, but nothing critical 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 100% for the single 'id' parameter, so the schema fully documents the input. The description only repeats 'by ID' and adds no format, prefix, or sourcing guidance beyond the schema, making baseline 3 correct.

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

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

States a specific verb ('Get full details') and resource ('a specific speaker by ID'), which clearly separates it from the sibling protect_list_speakers. An agent can identify the tool's role without opening the schema.

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

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

Usage is implied by 'by ID' (fetch one record once the ID is known), but the description never states when to reach for this versus protect_list_speakers or what happens if the ID is invalid. No explicit alternatives or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds the returned field list, but since an output schema exists this is largely redundant, and it says nothing about auth scope, error behavior for a bad ID, or rate limits. Consistent with annotations but adds little beyond them.

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 core purpose front-loaded before the return fields. 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?

For a trivial one-parameter read tool with annotations and an output schema, this is essentially complete – the agent knows what it fetches and that it is safe. The only soft spot is the absence of any routing hint relative to protect_get_user, which is a minor gap given the richness of the structured fields.

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 a single parameter and 100% schema description coverage, the schema already documents 'id' as the ULP user ID. The description's 'by ID' phrasing adds no format, source, or lookup guidance beyond that, 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 (Get), resource (UniFi Identity/ULP user) and scope (by ID), with the parenthetical expansion of ULP removing ambiguity. It implicitly separates itself from protect_list_ulp_users, but never explicitly contrasts with protect_get_user, the other 'get user' sibling, so it falls short of the 5-level sibling differentiation.

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 statement of when to use this tool versus protect_list_ulp_users (to find an ID) or protect_get_user (a different user domain). The 'get by ID' pattern implies usage, but nothing tells the agent when this is the right call or what prerequisite ID it needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the concrete return field set (id, modelKey, name, email, ucoreUserId), which is useful shape context, but says nothing about error behavior for invalid IDs or permissions.

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

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

Two short sentences, front-loaded with purpose and then the return shape. No filler, no repetition of the tool name as a sentence.

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 have been enumerated (though doing so is harmless). For a one-parameter read tool with full annotations, the definition is essentially complete; only the ambiguity with protect_get_ulp_user/protect_list_users keeps it from a 5.

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 'id' parameter is documented in the schema as 'User ID.' The description's 'by ID' adds nothing beyond that. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Get details for a specific Protect user by ID.' An agent understands exactly what it fetches. However, it does not distinguish itself from close siblings such as protect_get_ulp_user or protect_list_users, which is what would push this to 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?

No when-to-use guidance is given beyond the implicit 'you have an ID.' With siblings protect_get_ulp_user and protect_list_users in the same namespace, the agent is left to infer which user-lookup tool applies. No conditions, prerequisites, or alternatives are named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the shape of the payload, but says nothing about behavior on an unknown ID, auth requirements, or whether fields can be absent — modest added context against an already-covered safety 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?

Two short sentences, front-loaded with the action and scope. The trailing '(7.1.83 docs)' is a minor provenance tag that is arguably useful but borders on clutter.

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, the inline return-field list is largely redundant, and annotations cover safety, so the description is adequate. The only real gap is unstated error behavior for a missing or invalid ID.

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

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

Schema description coverage is 100% with a single documented 'id' parameter, so the schema already carries the semantics. The phrase 'by ID' adds no format, sourcing, or validation detail beyond what the schema provides — 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 and resource with scope: 'Get full details for a specific viewer by ID.' This clearly contrasts with the sibling protect_list_viewers by being singular and ID-scoped, but it never names that sibling explicitly, so differentiation is implied rather than stated.

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

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

Usage is only implied: an agent infers it should call this after obtaining a viewer ID, and that the list tool precedes it. There is no explicit when-to-use, no preconditions, and no stated alternative for bulk or filtered retrieval.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the returned field set (id, modelKey, name, mac, state, ledSettings, lastEvent, alarmHub), which is useful transparency, though somewhat redundant with the output 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?

Two compact sentences, front-loaded with purpose then field list. The doc-version citation '(7.1.83 docs)' is slightly extraneous but harmless.

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

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

For a zero-parameter read-only list tool with an output schema and full annotations, the description is adequate. Field enumeration duplicates output-schema info, so it's slightly over-specified but 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?

Zero parameters and 100% schema description coverage, so the baseline is 4. The description correctly notes no filtering arguments, aligning with the empty schema.

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

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

States a specific verb (List) and resource (alarm hubs managed by UniFi Protect), clearly distinguishing it from the sibling protect_get_alarm_hub and the other protect_list_* tools for different device types.

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 'List all' phrasing implies bulk retrieval versus the single-item protect_get_alarm_hub sibling, but the description never states when to use this versus alternatives, nor any exclusions 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the environment constraint (local alarm manager only) and the shape of the returned array, which is genuinely useful context beyond the annotations.

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

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

Two compact sentences with the availability constraint front-loaded. The field enumeration is somewhat redundant given an output schema exists, but it stays brief and does not bloat the definition.

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

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

For a zero-parameter read tool with full annotation coverage and an output schema, the description supplies the key missing piece — the local-alarm-manager-only scope. Return-value detail is already handled by the output schema, so the definition is essentially 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 per the baseline the description carries no parameter burden. Nothing is missing or misleading on this dimension.

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

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

States a specific verb and resource ('List all arm profiles') and immediately scopes it to the local alarm manager rather than Protect cloud alerts. An agent can distinguish this tool's domain 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 parenthetical explicitly states the condition under which the tool is available ('only available when using the local alarm manager — the standalone NVR alarm system, not Protect cloud alerts'), which tells the agent when it applies. It does not name a specific alternative sibling to use otherwise, so it stops short of a 5.

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

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

The readOnlyHint/destructiveHint annotations already establish the safe-read profile, so the description's main addition is the return shape. It does not disclose pagination, ordering, or the meaning of 'state'/'platform' values, and the '(7.1.83 docs)' tag is an ambiguous version caveat rather than usable 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?

One purpose sentence followed by a compact field list — front-loaded and free of filler. The field enumeration is somewhat redundant given an output schema exists, which keeps it from a 5.

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

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

With annotations covering safety, an output schema covering returns, and no input parameters, the definition covers what an agent needs to invoke it. Remaining gaps (ordering, whether results are paginated) are minor.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly stays silent on input.

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

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

States a specific verb and resource ('List all bridges managed by UniFi Protect'), making it clearly distinguishable from the singular protect_get_bridge sibling despite not naming it. The scope ('all') is explicit, but there is no explicit contrast drawn against the other list tools in the family.

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

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

Usage is only implied by the 'List all' framing; there is no statement of when to prefer this over protect_get_bridge or protect_list_link_stations, and no mention of filtering or prerequisites. Adequate but with a clear gap in 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context beyond annotations by stating the return shape and explicitly listing what the Integration API does NOT expose (recording state, motion timestamps, connection/last-seen, firmware, host, per-channel stream config), which prevents an agent from expecting unavailable data.

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

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

The first sentence is front-loaded and clear. However, the long enumeration of output fields largely duplicates information already available in the output schema, and it includes an API version tag ('7.1.83-verified') that adds noise. The inclusion of unavailable fields is useful, but the overall length is excessive for a parameterless list tool.

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

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

For a zero-parameter, read-only list tool with a rich output schema and clear annotations, the description is more than complete. It covers scope, return structure, field availability, and API limitations, leaving no critical gap for correct invocation.

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

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

The tool has zero input parameters, so there are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gaps.

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: 'List all cameras managed by UniFi Protect.' The scope ('all') distinguishes it from the sibling protect_get_camera, which retrieves a single camera, and from list tools for other device types.

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 does not say when to use this tool versus alternatives such as protect_get_camera, protect_list_sensors, or protect_get_snapshot. Usage is only implied by the tool name and resource, with no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a version-verification note ('verified live 7.1.83'); the field enumeration largely duplicates the output schema, so the incremental behavioral value is modest.

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

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

Purpose is front-loaded in the first sentence, with the return shape following as supporting detail. The nested ringSettings enumeration is somewhat verbose given an output schema exists, but nothing is truly wasted.

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

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

For a no-argument list tool with an output schema and clear safety annotations, the description covers what an agent needs to select and call it. It could mention the absence of filtering/pagination, but that is a minor omission.

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 parameter-wise the description needs to compensate for, and it correctly implies a no-argument retrieval.

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') plus resource ('chimes') and the scope is 'all', which cleanly separates it from the singular sibling protect_get_chime in the same family.

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?

Enumeration usage is implied by 'List all chimes', but there is no explicit statement of when to prefer this over protect_get_chime or any sibling, and no filters/exclusions are mentioned (none exist, but nothing says so).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'only animations currently supported' limitation, but that same statement is already duplicated in the schema parameter description, and it says nothing about pagination, auth, or 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?

Front-loaded with purpose and constraint in the first clause, efficient overall. However, the trailing 'Returns array; each record ... name, type, originalName, path' is redundant since an output schema exists, so it dilutes rather than adds value.

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 and 100% parameter coverage, the description covers the purpose and the key limitation; it need not explain return values. It is complete enough to call the tool correctly, missing only minor usage routing context.

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

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

Only one parameter with 100% schema description coverage, so the schema already documents fileType and its supported value. The description merely restates the same constraint without adding format, default, or enumeration detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (List) and resource (files) plus the scoping constraint that only 'animations' file type is supported. The sibling set is all distinct-protected-resource list/get pairs, so there is no ambiguity about which resource this touches.

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

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

Usage is implied by the name and the single supported fileType value, but there is no explicit when-to-use statement, no mention of related tools, and no note on what to do with the returned records (e.g., feeding an upload endpoint). Adequate but leaves routing guidance 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the '7.1.83 docs' provenance note and enumerates fields, but with an output schema present those field details are largely redundant, and no pagination, ordering, or rate-limit behavior 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?

Two front-loaded sentences that lead with the purpose before the enumeration. The second sentence's field list is somewhat expendable given the output schema, but it stays compact.

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

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

For a zero-parameter, read-only list tool with a dedicated output schema and readOnlyHint annotations, the description supplies everything an agent needs to select and call it. The only redundancy is restating fields the output schema already defines.

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

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

The tool takes zero parameters, which sets the baseline at 4. The description correctly implies no filtering arguments are needed to list the full collection.

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

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

States a specific verb and resource ('List all fobs managed by UniFi Protect') and explicitly scopes to the full collection, which implicitly separates it from the singular protect_get_fob sibling. It stops short of naming that alternative, so the differentiation relies on inference from the plural phrasing.

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

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

There is no explicit guidance on when to use this versus protect_get_fob or the other list_* tools. The 'List all' phrasing weakly implies enumeration, but no conditions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the scope 'all lights' (no filtering) and lists return fields, but the latter duplicates the output schema and it does not mention pagination, rate limits, or auth. With annotations covering the safety profile, a 3 is appropriate.

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

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

The purpose is front-loaded in the first clause, but the long parenthetical enumeration of return fields is excessive given the output schema already documents them. It adds noise rather than earning its place.

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

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

For a simple no-param list tool with a rich output schema and safety annotations, the description covers what it does and what it returns. It is complete enough, though the return-field listing is redundant and usage guidance 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 no parameters, so there are no parameter semantics to explain; baseline for zero parameters is 4. The description does not need to add parameter meaning.

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 (List) and resource (lights managed by UniFi Protect), and the scope 'all lights' distinguishes it from the singular sibling protect_get_light. An agent can identify its function without opening the schema.

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

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

There is no explicit guidance on when to use this tool versus alternatives like protect_get_light. The description only restates the listing action, leaving usage context 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?

The readOnlyHint/destructiveHint annotations already establish the safe-read profile, and an output schema exists that carries the return shape. The description's field enumeration (id, modelKey, name, mac, etc.) largely restates that structured data, adding only marginal context like the literal modelKey value.

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

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

Two sentences, front-loaded with the purpose followed by return detail; the '(7.1.83 docs)' parenthetical is minor clutter but the whole thing is efficient and no sentence is wasted.

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

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

For a zero-parameter read tool with annotations and a dedicated output schema, the description is essentially complete; the only unaddressed element is when to prefer this list over the single-station sibling.

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

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

The tool takes no parameters, so per the baseline a 4 applies. There is nothing further the description could add about arguments since there are none.

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 (link stations) with scope (managed by UniFi Protect), which implicitly distinguishes the bulk listing from the sibling protect_get_link_station. It does not name the alternative, so it falls just short of a 5.

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

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

Usage is only implied by the verb 'List all'; there is no explicit when-to-use, when-not, or routing to protect_get_link_station for a single station. Adequate for a trivial zero-arg list tool but adds no 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful schema-level context beyond annotations: the exact shape of returned fields, the API version verification (7.1.83), and a getcha about the 'cameras' string-array field name. It doesn't cover pagination or empty-result behavior, but that's a minor gap given annotations handle safety.

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 and follows with the return shape and a caveat. Slightly dense with field enumeration, but every sentence earns its place by adding information an agent needs to interpret or use the response.

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

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

For a zero-parameter list tool with a covered output schema and annotations, this is complete: purpose is clear, return shape is enumerated, a notable field-name pitfall is flagged, and safety is handled by annotations. Nothing an agent needs to call it correctly 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?

There are zero parameters, so the baseline is 4. The description compensates appropriately by thoroughly documenting the meaningful fields of the returned objects, which is the relevant 'semantics' here.

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

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

The description states a specific verb and resource ('List all live views') and immediately defines what a liveview is ('camera grid layouts shown on viewers / in the Protect UI'). This distinguishes it from siblings like protect_list_viewers, which lists viewer devices rather than the grid layouts themselves.

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 — an agent needing to enumerate liveviews would call this — but the description offers no explicit when-to-use, when-not-to-use, or pointers to alternatives such as protect_get_liveview for fetching a single liveview. The implicit contrast is present 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the genuinely valuable behavioral quirk that the /nvrs endpoint returns a single object rather than an array. It goes beyond annotations, though it doesn't discuss permissions or failure modes.

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 'NOTE' caveat, which is the right ordering. The trailing enumeration of return fields is somewhat verbose given an output schema exists, but it stays readable and earns most of its 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?

With read-only annotations, no parameters, and an output schema present, the description covers everything an agent needs; the singular-object warning is the key missing piece that structured fields would not reveal. Listing return fields is largely redundant with the output schema, so it is not a full 5.

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. Nothing in the description misrepresents or needs to compensate for parameter semantics.

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

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

States a specific verb ('Get') and resource ('NVR console info'), and critically resolves the misleading 'list_' prefix by explaining the endpoint returns a SINGLE object. This lets an agent distinguish it from the many true list_* siblings 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 ('Get the NVR console info') and there is no sibling alternative for NVR data, but the description never states when to reach for this tool versus protect_get_info or the per-device get_* tools. Adequate but no explicit conditions or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds payload shape (array, per-relay field list) and a docs/firmware reference, which is useful context, but it omits any behavioral notes like pagination, ordering, or empty-result 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 dense sentence front-loads the purpose before enumerating returned fields. The long field enumeration is somewhat redundant given an output schema exists, but it is compact and not padded.

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

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

With no parameters, a full output schema, and annotations covering the safety profile, the description has little remaining burden and is adequate. Return-field detail is technically redundant with the output schema, and no pagination or empty-result behavior is noted, keeping it just short of a 5.

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

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

The tool takes zero parameters, which sets the baseline at 4 per the rubric. There is nothing for the description to clarify beyond confirming this is an unfiltered listing operation.

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 ('List all relays managed by UniFi Protect'), which is unambiguous and easily distinguished from the get-style sibling (protect_get_relay). However, it never explicitly contrasts itself with siblings or clarifies the list-vs-get relationship, so it stops short of full sibling differentiation.

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 use this tool versus protect_get_relay or other list tools, and no prerequisites are mentioned. Usage is only inferable from the tool name, which matches the MID calibration case for 'no when-to-use, no 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is carried by structured data. The description adds the return shape but says nothing about permissions, pagination, ordering, or rate limits, so it contributes only marginal behavioral context beyond the annotations and output 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 purpose sentence is short and front-loaded, but it is followed by a long verbatim enumeration of ~30 return fields. Since an output schema already exists, that dump largely duplicates structured data and bloats the definition.

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

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

For a zero-parameter list tool with an output schema and safety annotations, all an agent needs to invoke it correctly is present. The redundant field list is not harmful, but the absence of any filtering/ordering or sibling-routing note leaves minor room for improvement.

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

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

The tool takes zero parameters, so there is nothing to document and the schema fully covers the (empty) input. Baseline 4 applies with no compensating need.

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 ('List all sensors managed by UniFi Protect'), which clearly separates it from the camera/light/chime listers in the sibling set. It does not, however, explicitly distinguish itself from the related protect_get_sensor single-sensor tool, so it falls short of full sibling differentiation.

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 mention of the sibling alternative (protect_get_sensor for a single sensor), and no stated prerequisites or exclusions. Usage is only implied by the word 'List'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no auth requirements, no pagination/rate-limit notes — and its remaining content is about return fields rather than behavior.

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

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

The purpose is front-loaded in one clean sentence, but the long inline enumeration of siren fields (id, modelKey, name, mac, state, volume, ledSettings, sirenStatus, connectionType, wirelessConnectionState) duplicates the declared output schema and bloats the definition without adding selection value.

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

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

For a zero-parameter, read-only list tool with an existing output schema and covering annotations, the description is sufficient to call it correctly. It errs on the side of restating the return payload rather than omitting anything needed.

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; the baseline of 4 applies. No parameter information is provided or needed.

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

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

States a specific verb (List) and resource (sirens managed by UniFi Protect), and the 'sirens' resource cleanly distinguishes it from sibling listers such as protect_list_cameras, protect_list_lights and protect_list_sensors. An agent can identify the target entity without opening the schema.

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

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

The description gives no when-to-use guidance, no prerequisites, and never mentions the obvious alternative protect_get_siren for fetching a single siren. Usage is only weakly implied by 'List all'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds little beyond that: it enumerates return fields (which the output schema already defines) and cites a docs version, but says nothing about pagination, ordering, or failure modes.

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 purpose first, followed by the return shape. The inline field enumeration is somewhat listy, but it stays compact and does not pad with 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 and annotations covering safety, the description need not explain return values — yet it does, which is mildly redundant rather than harmful. For a zero-parameter read tool, nothing an agent needs in order to call it 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 the baseline is 4. There is nothing to document and the description correctly does not invent parameters.

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

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

States a specific verb and resource ('List all speakers managed by UniFi Protect'), which clearly distinguishes a bulk-list operation from the sibling protect_get_speaker. It does not explicitly name the get-vs-list alternative, so it stops short of full sibling differentiation.

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 scope phrase 'all speakers' implicitly signals this is the bulk enumeration tool versus the singular protect_get_speaker, but there is no explicit when-to-use/when-not guidance or named alternative. Adequate but with a clear gap for a 30+ sibling toolset.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it discloses the returned field set and, importantly, the negative capability that enrolled-credential detail (NFC cards, fingerprints) is NOT exposed, which prevents an agent from promising or hunting for data that does not exist. It stops short of noting pagination or size limits for a 'list all' call.

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

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

Three tight sentences, front-loaded with the action and scope, then return shape, then the key limitation. Every sentence earns its place, though the parenthetical '(Integration API 7.1.83-verified)' is version trivia that adds little routing value.

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

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

For a zero-parameter read tool with annotations and a sibling output schema already present, the description covers the essential ground: what it lists, the identity of the records returned, and a material limitation of the API surface. Nothing an agent needs in order to call it correctly or set expectations about the result 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 the baseline is 4. The description correctly adds no parameter discussion and instead spends its words on output shape, which the empty schema cannot convey.

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 a precisely qualified resource (UniFi Identity / ULP users), which disambiguates it from the neighboring protect_list_users and protect_get_user tools. An agent can identify the target entity and result shape without opening the schema.

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

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

The description never says when to use this tool versus protect_get_ulp_user (single-user lookup) or the broader protect_list_users. Scope is implied by 'List all', but there is no explicit condition or exclusion, so the agent must infer the routing rule from the tool names alone.

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

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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description goes beyond them by disclosing the negative space: roles, permissions, login history, groups and notification settings are NOT exposed by the Integration API, which prevents an agent from expecting or attempting to retrieve them.

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 the action and the access-scoping caveat, followed by return fields and the explicit exclusions. The '(Integration API 7.1.83-verified)' qualifier is slightly noisy but conveys version provenance.

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 explaining return fields is technically redundant, but the description nonetheless enumerates them and, more usefully, states what the API cannot return. For a no-argument read tool this is sufficient to call it correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to explain inputs and nothing misleading is present.

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: 'List all Protect users'. It is clear enough to distinguish from protect_list_cameras etc., but it never addresses the near-identical sibling protect_list_ulp_users, so the differentiation from that tool must be inferred.

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 '(filtered by the API key's access permissions)' implies when the result set will be scoped, but there is no explicit when-to-use guidance and no routing to alternatives such as protect_list_ulp_users or protect_get_user. 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the result is an array and enumerates per-viewer fields, but says nothing about pagination, result size, or ordering that would help an agent consume a full listing.

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 first, then return shape. The parenthetical docs version (7.1.83) is marginally useful provenance and does not bloat the text. Nothing to cut.

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

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

For a zero-parameter read-only listing with an output schema already present, the description is sufficient: purpose, scope, and return shape are all covered. Return-field detail is somewhat redundant against the output schema, but 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 the baseline of 4 applies. There is no parameter syntax or filtering behavior that the description could usefully add.

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

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

States a specific verb+resource ("List all viewers managed by UniFi Protect") and the scope word "all" implicitly distinguishes it from the singular protect_get_viewer sibling. It stops short of explicitly naming that sibling as the alternative, so it is clear but not fully differentiated.

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

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

Usage is only implied by the word "all" and the list-vs-get naming pattern shared with dozens of siblings. There is no explicit statement of when to reach for this tool versus protect_get_viewer for a single record.

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

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

Annotations already declare it a safe read (readOnlyHint=true, destructiveHint=false), and the description adds real behavioral context: the listen window (1-30s) and the key trait that only changed fields are delivered, not the full object. It stops short of mention of dropped connections or reconnection behavior, but adds genuine value over the annotations.

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

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

Front-loads the core action and return shape, then the use case. It is dense but every sentence carries information; only the return-shape detail is partly redundant given an output schema exists.

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?

Covers the action, duration constraint, return shape, and use case, which is enough to invoke it. Missing only differentiation from the sibling protect_subscribe_events, the closest alternative for an agent deciding between streaming 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?

Only one parameter, and schema coverage is 100% with the same 1-30s/default-5 detail already in the schema. The description's duration mention adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (subscribe/connect) and resource (device update WebSocket), and the exact operation (collect messages for 1-30s). It is clearly distinguishable from the sibling list_* and get_* tools, which are one-shot reads.

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 usage context ('use to detect state changes like isRecording flipping, battery drops, or new devices being adopted'). However, it never contrasts with the sibling protect_subscribe_events or states when a polling read (protect_list_cameras) is preferable, so no explicit alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true/destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: the duration range (1-30s), that events arrive as a stream, the ongoing-event semantics (end=null), and the full shape of returned event messages including optional error field.

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

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

A single dense sentence front-loads the connect-and-collect behavior, then enumerates return shape. It is long but information-dense with little filler; the enum listings are the bulk but arguably 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?

An output schema exists, so return-value explanation is optional—yet the description complements it with concrete event field semantics (type enum, smartDetectTypes, metadata examples) that help the agent interpret results. Only minor gap is the absence of explicit when-to-use guidance versus sibling 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?

Schema coverage is 100% and the single 'duration' parameter is fully documented in both schema and description (1-30s, default 5). The description adds no syntax or format beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb ('Connect... and collect messages') and resource ('Protect event WebSocket'), and the name/title align. Clearly distinct from sibling list/get tools, which are request-response, whereas this is a streaming/collection operation.

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

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

The description implies usage context (listening for live events over a duration) but never explicitly states when to use this tool versus alternatives like protect_list_cameras or protect_subscribe_devices. No exclusions or routing guidance are provided.

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