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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a detailed enumeration of returned fields, including nested threadState and alarmHub, but it does not disclose error behavior, authentication needs, or edge cases.

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 a crisp, front-loaded purpose statement. The long return-field list is dense but organized and serves as a useful summary, though some of it duplicates the output schema and the docs-version parenthetical adds minor noise.

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-param read tool with annotations and an output schema, the description is sufficient: it names the resource, retrieval key, and the shape of returned data. No critical invocation information appears 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 only parameter, id, already describes itself as 'Alarm hub ID' with required=true. The description reiterates that retrieval is 'by ID' but adds no format, precedence, or additional semantic detail beyond the schema.

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

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

The description opens with a specific action and target: 'Get full details for a specific alarm hub by ID.' The mention of 'full details' and the specific resource distinguishes it from list_alarm_hubs and other get_* siblings without relying on 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?

It clearly positions the tool as the single-entity retrieval variant ('by ID'), implying use when an ID is already known rather than for listing alarm hubs. It does not explicitly name the alternative list_alarm_hubs or state when not to use it, so it stops short of a perfect 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating the exact returned fields, including the clients array and the maxClients version note, which the annotations do not convey.

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

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

A single, front-loaded sentence states the action, then lists return fields in a compact colon-delimited format. Every word earns its place; no filler or redundancy.

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

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

For a low-complexity get-by-id tool with one documented parameter, read-only annotations, and an output schema, the description is complete. It even adds the returned-field list, which exceeds what the structured fields require.

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

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

The schema already describes 'id' as 'Bridge ID' (100% coverage), so the baseline is 3. The description reinforces that the ID identifies a specific bridge but adds no format, source, or usage details beyond the schema.

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

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

States a specific verb ('Get'), a precise resource ('full details for a specific bridge by ID'), and clearly distinguishes itself from list_bridges and other get_* siblings. The returned-field list further clarifies the tool's scope.

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' makes it clear this is for retrieving one specific bridge, not enumerating bridges (which list_bridges handles). It does not explicitly name alternative tools or exclusion conditions, but the context is unambiguous for a get-by-id 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 mark this as read-only and non-destructive. The description adds substantial behavioral context beyond annotations by enumerating the exact returned field set, confirming there is no hidden extended payload, and explicitly stating which common camera data is not available. This is valuable, non-redundant disclosure.

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 key purpose is front-loaded in the first sentence, and the rest of the description earns its place: the field enumeration sets expectations and the explicit exclusions prevent misuse. Despite the long field list, there is no filler.

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

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

For a simple single-parameter read-only getter with an output schema, this description is complete. It tells the agent what will be returned, what will not be returned, and confirms there is no hidden extra payload, making the tool safely callable without further investigation.

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

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

The input schema already documents the single 'id' parameter as 'Camera ID' with 100% coverage. The description only restates that lookup is by ID, adding no format, source, or usage detail beyond the schema.

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

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

The description opens with a specific verb and resource: 'Get details for a specific camera by ID.' It further distinguishes itself from protect_list_cameras by clarifying it returns the same field set and offers no extended by-id payload, so an agent can confidently tell them apart.

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 makes the primary use case clear: fetch details for one camera by ID. It also gives useful exclusions by stating recording state, motion events, zones, and channel/RTSP config are not exposed, though it does not explicitly name alternative tools for those 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, covering the safety profile. The description adds response-shape detail and a 'verified live 7.3.47' reliability signal, but no additional behavioral or error context beyond that.

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

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

The description is a single front-loaded sentence that identifies the operation before listing return fields. The field list is compact, and the version note is a short reliability cue with no filler.

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

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

For a one-parameter, read-only lookup with annotations and an output schema, the description provides everything needed to invoke the tool correctly and understand the response. No critical 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 only parameter, id, is already fully documented in the schema as 'Chime ID' with 100% coverage. The description adds no new semantic meaning beyond 'by ID', so the schema does the heavy lifting and 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'), a concrete resource ('chime'), and the selection criterion ('by ID'). It also enumerates the returned fields, making it easy to distinguish from list_chimes and other sibling get_* 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?

The phrase 'for a specific chime by ID' clearly implies use when an ID is already known and full details are needed, while list_chimes would cover enumeration. It does not explicitly name alternatives or exclusions, so it falls 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating the returned fields, including nested objects and a version reference for wirelessConnectionState. However, it does not disclose behavior on missing IDs, error conditions, or any rate limits. Given the annotation coverage, this is acceptable but not outstanding.

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 and front-loaded with the core action and resource. It lists the return fields in a structured manner, which is informative without being excessively verbose. The mention of a documentation version for one field is a minor extra that could be omitted, but overall the structure is efficient.

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

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

The tool is a straightforward get-by-ID operation with a single parameter and a detailed output schema. The description covers the purpose and the expected return content, making it complete for an agent to call correctly. The only missing element is explicit error handling behavior, but the presence of an output schema mitigates this.

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

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

The schema already describes the single 'id' parameter with 100% coverage, so the baseline is 3. The description does not add any additional semantic detail about the ID (e.g., format, length, or validation rules) beyond what the schema provides, which is sufficient for a simple parameter.

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

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

The description clearly states the tool's purpose: 'Get full details for a specific fob by ID.' It specifies the resource (fob) and the action (get details), and the list of returned fields adds specificity. It is easily distinguished from the sibling protect_list_fobs which lists all fobs, and from other get_* tools by naming the 'fob' 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 usage context is implied: you need a specific fob ID to retrieve full details. However, it does not explicitly state when to prefer this over protect_list_fobs (e.g., when you already have an ID and need detailed attributes) or mention any exclusions or alternatives. The guidance is adequate for a simple get-by-ID tool but relies on the standard pattern.

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. The description adds an explicit list of returned fields, but this largely duplicates what the output schema would provide and does not disclose behaviors like not-found handling or permissions. It is adequate, not exceptional.

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 sentence, which is good. However, the long enumeration of return fields is redundant when an output schema exists and makes the description longer than necessary for such a simple one-parameter 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 simple read-only retrieval with one required parameter, an output schema, and read-only annotations, the description provides enough context to invoke the tool correctly. Only minor gaps like error behavior or authentication requirements remain, which are not critical 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?

The input schema has 100% description coverage for the single required 'id' parameter, defining it as 'Light ID.' The description does not add additional parameter semantics beyond restating that the lookup is by ID, so the baseline score of 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?

The description uses a specific verb and resource: 'Get full details for a specific light by ID.' It clearly identifies the tool as a single-light retrieval operation and distinguishes it from sibling tools like protect_list_lights or protect_get_sensor.

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 'for a specific light by ID' conveys when to use the tool: when full details for one light are needed. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it over list-style siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds detail about the returned fields and references the 7.3.47 docs, but does not discuss errors, permissions, or other behavioral edge cases.

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 action is front-loaded and the description is compact. The long list of returned fields is somewhat redundant with the existing output schema, but it is structured and informative enough not to feel like wasted 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 a single well-documented parameter, read-only annotations, and an output schema covering return values, the description is complete for an agent to select and invoke the tool correctly. The included docs reference adds helpful provenance.

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

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

The schema already describes the single `id` parameter as 'Link station ID', giving 100% schema coverage. The description adds no extra semantic detail beyond restating that the lookup is by ID, 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?

The description states a specific verb ('Get'), a clear resource ('link station'), and the selection criterion ('by ID'). It is differentiated from sibling tools like protect_list_link_stations, which lists stations rather than retrieving one.

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 clearly implies this tool is for retrieving a single link station when its ID is known, as opposed to listing all stations. It does not explicitly name an alternative such as protect_list_link_stations, so it stops short of full 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. 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 read-only nature is covered. The description adds value by listing the returned fields and noting a version-specific field (wirelessConnectionState). No contradiction with 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 a single, front-loaded sentence that states the purpose and then lists returned fields. No wasted words, and the most important information (the verb and resource) appears first.

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 read-only tool with one parameter and no side effects, the description fully covers what it does, what it returns, and even a version note. An agent has everything needed to invoke it correctly, especially given the output schema exists.

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

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

Schema coverage is 100% (the id parameter is documented as 'Relay ID'). The description reinforces that the ID identifies a relay but does not add syntax or format details beyond the schema. The baseline of 3 applies because the schema carries the 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?

The description states a specific verb ('Get') and resource ('full details for a specific relay by ID'), and it enumerates the returned fields. This clearly distinguishes it from sibling tools like protect_list_relays (which lists all relays) and other get_* tools. The purpose is unambiguous.

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

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

The description implies usage (when you need details for one relay by ID) but does not explicitly mention alternatives or exclusions. Given the sibling list_relays exists, an agent can infer the distinction, but there is no explicit guidance like 'use list_relays to enumerate all relays'.

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 the safety profile is covered. The description goes beyond annotations by enumerating the exact fields returned, which is valuable behavioral context. It also notes the wirelessConnectionState field is from version 7.3.47 docs, adding version-specific transparency. This does not contradict any 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 front-loads the purpose in the first sentence, then provides a comprehensive but structured list of return fields. It is lengthy, but each item adds value by informing the agent what data is available. The trailing note about '(7.3.47 docs)' is slightly ambiguous but not wasteful. Overall, it is well-organized and not repetitive.

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 description doesn't need to explain return values, yet it does, which is a bonus. It covers the single parameter fully via the schema and provides a thorough field list. The version note adds nuance. Nothing critical is missing for an agent to call this tool correctly, though it could explicitly mention it's for sensors only, which is already implied.

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 only one parameter, id, which the schema already describes as 'Sensor ID' (100% coverage). The description adds no additional meaning about the parameter itself, but the schema fully covers it. Baseline 3 is appropriate since the schema does the heavy lifting and the description focuses on the response rather than the 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?

The description clearly states the verb and resource: 'Get full details for a specific sensor by ID.' This distinguishes it from list_sensors (which lists) and other get tools for different resources (camera, light, etc.). The resource is explicit, so an agent can immediately identify this as the per-sensor retrieval tool.

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

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

The description does not explicitly mention when to use this versus alternatives, but it clearly implies usage: when you need full details for one specific sensor, not a list. The sibling list shows other get tools for other resources, so the context is clear. It doesn't provide exclusions or alternatives, but the purpose is unambiguous enough that an agent would know to use this for a sensor ID.

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 read-only, non-destructive operation. The description adds the full field list and nested structure (ledSettings, sirenStatus), which exceeds what the annotations alone convey, and it does not contradict 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 compact sentences front-load the purpose and then present the return schema as a readable inline list.

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 with output schema and safety annotations, the description covers purpose, parameters, and return shape without missing operational details.

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 only parameter id is already fully described in the schema as 'Siren ID'; the description's reference to 'by ID' adds no new syntax or format, so 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 explicit fetch-by-ID semantics and enumerates returned attributes; distinguishes itself from sibling list_sirens by focusing on a specific siren.

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' makes it clear this is for retrieving one known siren rather than enumerating all sirens, but it does not explicitly point to list_sirens for ID discovery.

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 establish readOnlyHint=true and destructiveHint=false, so the description adds no contradiction. It contributes only a version reference and a return-field list, without disclosing extra behaviors like error handling, permissions, or latency; for a simple getter this is adequate but not rich.

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 states the action and key parameter, followed by a compact return-field list and docs reference. No filler or redundant explanation.

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 with full schema parameter coverage and an output schema, the description is essentially complete. There are no missing details an agent needs to select and invoke this tool correctly.

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

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

The only parameter, id, is 100% covered by the schema ('Speaker ID'), and the description merely restates that selection is by ID. No additional format, uniqueness, or lookup semantics are supplied, 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 an explicit verb ('Get'), a specific resource ('full details for a specific speaker'), and the selection key 'by ID.' This cleanly contrasts with list-oriented siblings like protect_list_speakers while matching the get_* pattern across sibling 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?

The description implies the intended use — fetch one speaker once an ID is known — but it does not explicitly say when to choose this over protect_list_speakers or state any exclusions. There is enough context to infer usage, but no direct 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, covering safety. The description adds the list of return fields, which is useful but largely redundant given the output schema. It does not mention error behavior, permissions, or other behavioral details, but with annotations providing the safety profile and the output schema covering return structure, 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 description is a single sentence that front-loads the action and resource, then lists return fields. There is no wasted wording or redundant information. It is appropriately concise for a simple get-by-ID 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?

The description is sufficient for a one-parameter tool with a known output schema and safe read-only annotations. It clearly states what the tool does and what it returns. It does not cover edge cases like not-found behavior, but given the tool's simplicity and the presence of an output schema, the description is reasonably complete.

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

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

Schema coverage is 100% for the single parameter 'id', and its schema description ('ULP user ID') already defines it. The description repeats 'by ID' but adds no additional semantics, such as format or constraints, beyond the schema. Baseline 3 is correct for high schema coverage.

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

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

The description states a clear verb ('Get'), a specific resource ('details for a specific UniFi Identity (ULP) user'), and the retrieval method ('by ID'). It also lists the returned fields, which makes the purpose unambiguous. It distinguishes from sibling tools like protect_get_user by explicitly specifying ULP users, and from protect_list_ulp_users by targeting a single ID.

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

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

The description implies the tool should be used when a single ULP user ID is known, but it does not explicitly state when not to use it or point to alternatives such as protect_list_ulp_users for listing all users. The usage context is clear enough for a get-by-id tool, but explicit guidance would improve the score.

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, and the description adds value by enumerating the returned fields and citing the docs version. It does not contradict the annotations and gives useful context about what the call returns.

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

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

The description is two concise sentences, front-loaded with the core action and resource, followed by a compact field list. No filler or redundant restatement of the tool name.

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

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

For a single-parameter read-only tool with annotations and an output schema, this description covers what the tool does, what it returns, and when to use it. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100% and the single parameter 'id' is already described as 'Viewer ID'. The description adds no extra semantic detail about the parameter beyond what the schema provides, so 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?

The description uses a specific verb ('Get full details') and resource ('a specific viewer by ID'), clearly distinguishing this from list_viewers and the other get_* siblings. The focus on ID-based retrieval makes the tool's purpose unmistakable.

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 clearly indicates this is the tool to use when you have a specific viewer ID and need full details. It does not explicitly mention list_viewers as the alternative for enumeration, but the context is clear enough for an agent to select it correctly.

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, covering the safety profile. The description adds behavioral transparency by detailing the exact fields in the returned array, including the nested threadState object, and notes the documentation version (7.3.47). This goes beyond the annotations and helps the agent anticipate the response shape.

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

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

The description is front-loaded with the core purpose and then provides a dense list of return fields. It is concise for the amount of information conveyed, though the field enumeration is extensive. The single-sentence structure is efficient and well-organized.

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 list operation, the description covers the resource, scope, and return structure adequately. An output schema exists, so the field enumeration is redundant but not harmful. The main missing context is a clarification of how this tool differs from list_link_stations, which could affect agent selection.

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

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

The tool has zero parameters, so the schema fully covers parameter semantics. The description correctly omits parameter details, and the baseline of 4 applies because there is nothing to compensate for.

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 action 'List all alarm hubs managed by UniFi Protect' with a specific resource. It also enumerates the expected return fields, which distinguishes it from a singular get_alarm_hub. The mention of modelKey 'linkstation' could hint at overlap with list_link_stations, but the tool name and scope are unambiguous.

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

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

The description implies usage when you need all alarm hubs, but it provides no explicit guidance on when to use this tool over the similar sibling list_link_stations. Since both tools exist and the description notes modelKey 'linkstation', the lack of differentiation is a gap. No alternatives or exclusions are mentioned.

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

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

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?

Annotations already signal a safe read operation. The description adds value by disclosing the return shape as an array and enumerating the fields included per bridge, including clients and maxClients. This goes beyond the annotation-only view without contradicting it.

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

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

The description is a single, front-loaded sentence that names the action and scope first, then provides a compact field list. There is no filler or redundant phrasing.

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

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

For a parameterless, read-only list operation with an output schema available, the description is complete. It states the resource, scope, return type, and key fields, leaving no ambiguity for an agent deciding to invoke it.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The empty input schema is fully covered, and the description adds no unnecessary parameter assumptions.

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." The scope is explicit, and it is clearly distinguishable from sibling list tools like protect_list_cameras and protect_list_sensors.

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 clearly implies use when an agent needs all bridges in the Protect system. It does not explicitly mention alternatives such as protect_get_bridge for a single bridge, but the list-all framing provides sufficient context.

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 description goes well beyond the readOnlyHint/destructiveHint annotations by disclosing exact returned fields, state enum values, and a critical caveat that guid is a model GUID rather than a per-camera identifier. It also explicitly lists what the Integration API does NOT expose, setting accurate expectations and preventing misuse.

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 long but front-loaded with its core purpose. The field enumeration is dense and detailed, yet every part adds either return-contract precision or limitation context. It could be slightly more compact, but no sentence is 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?

For a parameterless read-only list tool, the description is exceptionally complete. It states the scope, enumerates the returned fields, clarifies the semantics of a confusing field (guid), and names the data the API cannot provide. An agent has everything needed to invoke it correctly and interpret results.

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

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

The input schema has zero parameters, so parameter semantics are not applicable. The description correctly focuses on the output contract instead, which is the only meaningful semantic content for this parameterless tool.

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

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

The description opens with a specific verb and resource: 'List all cameras managed by UniFi Protect.' It clearly distinguishes itself from sibling tools such as protect_get_camera, which retrieves a single camera, and other protect_list_* tools for different device types. The resource scope is unambiguous.

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

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

The description makes the usage context clear: use it when you need all cameras managed by UniFi Protect. It does not explicitly name alternatives or state exclusions, but the phrase 'all cameras' strongly implies this is the enumeration tool rather than a single-camera getter, which is adequate 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, and the description adds meaningful behavioral detail by specifying the exact return shape, field names, and nested ringSettings structure. It also notes verification against firmware 7.3.47, adding credibility beyond the annotations. Missing pagination or ordering details, but for a list-all read operation this is sufficient.

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

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

The description is compact and front-loaded: the main purpose comes first, followed by the return structure and a verification note. The field enumeration is dense but directly useful, 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 no-parameter, read-only list tool, the description provides everything an agent needs: the scope ('all chimes'), the output type ('array'), and the complete field layout. The output-schema signal further reinforces the completeness, so no critical context is missing.

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

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

The tool has zero parameters and the schema coverage is 100%, so the parameter contract is fully complete by default. The description has no need to elaborate on parameters and correctly omits them.

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

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

The description opens with a specific verb and resource: 'List all chimes managed by UniFi Protect.' It unambiguously identifies the tool's function and distinguishes it from sibling list/get tools for other device types by naming the exact resource (chimes).

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 clearly implies when to use the tool: when you need the full set of chimes. However, it does not explicitly mention alternatives such as protect_get_chime for retrieving a single chime, nor does it provide exclusion criteria, so it stops short of full 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 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 description correctly avoids repeating safety. It adds behavioral value by specifying the return type ('Returns array'), enumerating the exact fields, and noting a version-specific detail (wirelessConnectionState in 7.3.47). This goes beyond annotations without contradicting 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?

The description is a single sentence that front-loads the core purpose, then lists return fields. While the field enumeration is lengthy, it is structured and informative, not redundant waste. It could be slightly shorter by relying on the output schema, but it serves as a quick reference.

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 present, the description is complete. It states what it does, what it returns, and adds a version note. 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?

The tool has zero parameters and schema coverage is 100% (empty schema). Baseline for 0 params is 4, and the description correctly omits any parameter details since none exist. No additional meaning is 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?

The description clearly states 'List all fobs managed by UniFi Protect' – a specific verb and resource, and the word 'all' differentiates it from the singular get_fob sibling. It also enumerates the return fields, making the purpose unambiguous.

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

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

The description implies use for retrieving all fobs, but does not explicitly name alternatives or provide when-not-to-use guidance. The existence of protect_get_fob is not referenced, so an agent must infer which to choose. The context is clear but not explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds substantial behavioral detail beyond annotations, including the exact return shape, field names, nested setting groups, and even a documentation version reference. No contradiction with 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 core action is front-loaded in the first sentence, and the field list is organized into grouped settings. The enumeration is somewhat long and partly redundant with the existing output schema, but it remains compact and information-dense.

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

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

For a parameterless, read-only list tool with an output schema, the description covers everything an agent needs: what it lists, what the returned array contains, and the relevant documentation version. No prerequisites, pagination, or auth details are necessary given the annotations.

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

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

The tool has zero parameters, and the input schema is empty with 100% schema description coverage. There is nothing for the description to clarify about parameters, so the baseline of 4 applies.

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

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

The description uses a specific verb ('List'), resource ('lights'), and scope ('all lights managed by UniFi Protect'), making the tool's purpose unmistakable. It also distinguishes itself from the sibling protect_get_light by emphasizing 'all' rather than a single light.

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 'List all lights' gives clear context for when this tool is appropriate. However, it does not explicitly mention alternative tools like protect_get_light for retrieving an individual light, so there is no direct exclusion or when-not-to-use 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 valuable behavioral context beyond annotations: it specifies the return shape (array), the exact fields included, and notes the documentation version (7.3.47 docs). It does not disclose potential pagination, rate limits, or error behavior, but for a read-only list operation with no parameters, the provided detail is strong.

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

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

The description is a single, information-dense sentence that front-loads the core action ('List all link stations') and then enumerates the return fields. It is not overly verbose, but the field list is long and somewhat technical; it could be slightly more scannable with bullet points or a shorter summary. Still, every part earns its place by documenting the output structure.

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 tool has no parameters, an output schema exists, and annotations cover safety, the description is largely complete. It details the return fields extensively, which is the main thing an agent needs to know. Minor gaps: it doesn't mention whether the list is sorted, whether it can be empty, or any error conditions, but these are not critical for a read-only list tool with no inputs.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds no parameter semantics because there are none to describe. Per the rubric, 0 params = baseline 4, and the description appropriately focuses on the return payload instead. It could theoretically mention that no arguments are required, but the empty schema already conveys that.

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 verb 'List' and the resource 'all link stations managed by UniFi Protect', which distinguishes it from sibling tools like protect_get_link_station (singular) and protect_list_cameras. It also specifies the return type (array) and enumerates the fields included, making the tool's purpose unambiguous.

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

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

The description implies usage context: it lists all link stations, contrasting with the singular get_link_station sibling. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'use get_link_station for a single station'), nor does it mention any exclusions or prerequisites. The context is clear enough for an agent to infer the primary use case, but explicit routing guidance is absent.

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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by revealing the singular response shape and enumerating the returned fields (id, modelKey, type, doorbellSettings, armMode), going beyond what annotations provide.

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 front-loaded with the purpose and the critical singular-object caveat before listing return fields. The field enumeration is somewhat long but relevant and not padded; it remains compact enough for a zero-parameter 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 tool with an output schema and annotations present, the description is complete. It covers the main purpose, the important array-vs-single-object behavior, and the expected return fields, leaving no gaps for an agent 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 has zero parameters and schema description coverage is 100%, so the schema fully covers parameters. A zero-parameter tool gets a baseline of 4; no additional parameter explanation is 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?

The description states a specific verb and resource: 'Get the NVR (Network Video Recorder) console info.' It also explicitly corrects the name's implication by noting the endpoint returns a SINGLE NVR object, not an array, which distinguishes it from a typical list operation and from sibling 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?

The description gives clear context for when to use the tool: to retrieve console information for the single NVR. The explicit 'not an array' caveat helps prevent misuse, though it does not name alternative sibling tools or provide explicit when-not conditions beyond that caveat.

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 return-format transparency by enumerating the relay fields and noting the docs version, going beyond the annotations without contradicting 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?

One compact sentence, front-loaded with the action and resource, followed by a terse field list. No filler or redundant 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?

A zero-parameter read-only list with an output schema and siblings for context; the description is sufficient for an agent to call it correctly and understand the result structure.

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 accepts zero parameters, so there is no parameter burden. Per the baseline for 0-param tools, the description does not need to explain 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 and resource ('List all relays managed by UniFi Protect') and the return shape. It is clearly distinct from sibling list tools and from protect_get_relay.

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 use case (need all relays) is only implied by the verb 'List'. The description does not explicitly mention when to use this instead of protect_get_relay or other list tools, and it gives no exclusions or 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 the safety profile is covered. The description adds the return type (array) and a detailed field enumeration, giving the agent concrete visibility into response contents beyond what annotations provide.

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 and easy to parse, but the long comma-separated field inventory makes the description heavier than necessary, especially since an output schema exists. The information is relevant, but some trimming would improve conciseness.

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 operation with an output schema, the description fully covers scope, return type, and field details. Nothing an agent needs to invoke the tool 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?

The tool has zero parameters and the schema covers 100% of the input surface, so there are no parameters for the description to explain. Baseline 4 applies.

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

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

States a specific verb ('List') and resource ('all sensors managed by UniFi Protect'), making its scope unambiguous. It is clearly distinct from sibling protect_get_sensor and other 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?

The phrase 'List all sensors' implies the tool is for batch retrieval of the full sensor set, but it does not explicitly name alternatives such as protect_get_sensor for individual sensors or state when not to use it. Usage is implied rather than spelled out.

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

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

The annotations already establish that this is read-only and non-destructive; the description adds meaningful behavioral detail by specifying the return type (array) and enumerating the exact fields available. It also notes a version-dependent field, which is useful context.

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

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

The description is compact: two sentences with no filler. It front-loads the core purpose and then succinctly lists the return fields, including a useful version note.

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

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

For a zero-parameter, read-only list operation, the description is complete. An agent can invoke the tool without additional info and knows exactly what fields will be returned.

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 no parameters, so the schema covers everything and the description does not need to explain inputs. The returned fields are described, adding value beyond the empty input schema.

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

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

The description clearly states that the tool lists all sirens managed by UniFi Protect, which is a specific verb and resource. It also includes the return structure, making it easy to distinguish from the get_siren and other sibling 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?

The intended use is implied: call this when you need a list of all sirens rather than a single siren. However, there is no explicit guidance about when to prefer this over protect_get_siren or other list tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the return shape (array of speakers with specific fields), but it does not disclose operational behaviors such as filtering, pagination, permissions, or rate limits. This is adequate but not rich behavioral context.

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

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

The description is front-loaded with the core purpose and remains compact. The enumeration of returned fields is useful, though somewhat redundant given that an output schema exists; overall it stays concise and readable.

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

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

For a zero-parameter read-only list tool with annotations and an output schema, the description is complete: it states the resource, the action, the return shape, and even the documentation version. No further details are necessary for an agent to invoke it correctly.

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

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

The tool has zero parameters and the schema coverage is 100% (empty schema). With no parameters to document, the description does not need to add parameter meaning; the baseline of 4 applies because there is nothing for the description to compensate for.

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

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

The description opens with a specific verb and resource: 'List all speakers managed by UniFi Protect.' This clearly identifies the tool's action and scope, and the 'all speakers' wording differentiates it from the sibling protect_get_speaker, which targets a single speaker.

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 a listing use case, but the description does not explicitly state when to use this tool versus protect_get_speaker or any other list/get siblings, and it provides no exclusions or alternative 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 value by disclosing the exact fields returned and explicitly noting that enrolled-credential details (NFC cards, fingerprints) are NOT exposed. This goes beyond the annotations and provides useful behavioral context about the API surface's limitations.

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

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

The description is two sentences, front-loaded with the primary purpose. Every sentence adds meaningful information: the first states what the tool does, the second details the return shape and an important limitation. No wasted words.

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

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

For a parameterless list tool with an output schema, the description covers the essential information: the return type, the fields included, and the notable omission (credential details). It also notes API version verification. It doesn't discuss pagination or error handling, but these are minor for a simple list operation. The description is sufficient for an agent to call the tool correctly.

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

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

The tool has zero parameters, and the schema confirms no properties. Since there are no parameters to document, the description doesn't need to explain any. Baseline for zero parameters is 4, and the description correctly avoids adding irrelevant parameter details.

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 UniFi Identity (ULP) users.' It also clarifies the exact user type (ULP) and the return format (array), distinguishing it from sibling tools like protect_list_users (Protect users) and protect_get_ulp_user (singular). The API version verification adds specificity.

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

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

The description provides clear context: this tool lists all ULP users. However, it does not explicitly contrast with alternatives such as protect_list_users or protect_get_ulp_user, nor does it state when to use this tool versus others. The purpose is unambiguous, but there is no explicit 'when not to use' 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. The description adds meaningful behavioral context by disclosing API-key-based filtering and explicitly listing fields that are NOT exposed (roles, permissions, login history, groups, notification settings). This helps agents set expectations 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?

The description is compact and front-loaded: the core action and scope appear in the first sentence, followed by return fields and important exclusions. Every sentence earns its place, with no redundant or vague 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 tool's simple profile (0 parameters, read-only annotations, output schema present), the description is complete. It specifies the filtered listing behavior, the exact fields returned per the Integration API, and the notable data the API does not expose, 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 input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. The description adds value by explaining the filtered scope of the returned results, which is relevant even without parameters.

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

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

The description states a specific action ('List all Protect users') and resource, with explicit scoping ('filtered by the API key's access permissions'). This clearly distinguishes it from related siblings like protect_get_user (single resource) and protect_list_ulp_users (different user type).

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 when a caller needs the full set of Protect users visible to the API key. However, it does not explicitly state when to prefer this over alternatives such as protect_get_user or protect_list_ulp_users, nor does it mention exclusions or preconditions.

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 call returns an array with specific fields, which is useful, but it does not mention pagination, ordering, or any additional behavioral details.

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

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

The description is a single front-loaded sentence that states the operation, the resource, the return type, and the relevant fields. The documentation version note adds useful provenance without padding.

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

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

For a zero-parameter, read-only list tool with an output schema present, the description provides everything needed: what is listed, the scope, and the expected return shape. Nothing essential is missing.

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

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

The tool takes zero parameters, and the schema coverage is effectively 100% for that empty parameter set. There is no parameter semantic burden for the description to carry, so the baseline of 4 applies.

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

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

The description uses the specific verb 'List' with the resource 'viewers' and explicitly scopes to 'all viewers managed by UniFi Protect.' This clearly distinguishes it from sibling tools like protect_get_viewer and other list_* variants.

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 viewers' phrasing makes the enumeration use case clear, especially alongside the singular protect_get_viewer sibling. It does not explicitly state when not to use it or name an alternative, but the context is unambiguous.

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.